Streamline the PCI Assessment Process with a Playbook

Why Create a PCI Assessment Playbook

Having gone through the Payment Card Industry Data Security Standard (PCI DSS) yearly assessment process several times, I can confirm it is a fairly intensive assessment that will require a large effort from a lot people!

Each assessment the Assessors will request evidence, review documentation, ask for sample system configurations, be onsite to interview and observe personnel, and present observations or findings that must be remediated. These various assessment activities and last-minute remediation efforts can be very disruptive to all involved, and usually result in “fire drill” activities that require personnel to be pulled away from their daily tasks to react to the assessment requests.

Since the PCI assessment is very similar from year to year, and with some well thought out planning it is possible to streamline the assessment process. Just like in football, having a well thought out strategy in the form of a playbook can assist everyone that needs to know their part, or what needs to be done when. With this cylinder process in place and in the form of a PCI Assessment Playbook that everyone can follow, it can greatly reduce the stress historically associated with the assessment and attaining PCI compliance.

Business as Usual

Business as usual is a buzz term within the PCI assessment world, and to build on that theme the ideal way to organize the playbook is in a chronological order to document all the yearly activities to support PCI and the assessment. Obliviously the months the assessment is going on will be the peak of the activities and the bulk of the playbook. Some activities that can happen outside that time frame, for example the internal and external pentest and the risk assessment are just two examples of activities that can be done any time during the year. When the Assessors ask for these reports there is no reactive response to schedule the activities, and the reports will be available.

Playbook Management

Make the playbook a public accessible document, either on a company intranet site or on a shared drive, but anyone should be able to view the playbook and reference the document at any time.

It is extremely important to create an organized process to collect information about the PCI assessment process. This is where you will record key pieces of information about the assessment and what you’ve gathered or supplied in support of assessment. This should carry over from year to year and include links to the critical documentation and where the submitted evidence is stored.

There are various ways to organize this, and you can leverage spreadsheets, a project management solution, a well-organized folder structure on a shared drive, or even a cloud based solution. Have a place where you can record the responses, related documents and any information from the PCI assessment that may be used by the Assessors.

Another tip, and since I work for a large organization and we have dozens of infrastructure and application teams that are pulled into the evidence collection effort is to have each team maintain their evidence gathering instructions in mini playbooks, or what we call “Evidence Collection Guides”. 

Record Responses and Owners

To start making use of the Playbook record any information about what specific pieces of evidence the Assessors ask for, and what evidence you have supplied in response to these requests, and who was able to acquire this information, such as a Subject Matter Experts (SMEs).

Solution Owners are important to keep in the loop when the assessment and requests start flowing, but obtain a SME or Engineer contact who is closer to the day to day operations of the various solutions. This person has intimate knowledge of the solution, and may have some basic security knowledge, and they can understand the request for evidence and can collect what is precisely needed.

Our Assessors provide us with an Information Request List (IRL), and it will have the requested documentation to verify security controls are in place for each PCI DSS requirement. Since the IRL is in an Excel spread sheet we can easily add a couple of columns to list and track the teams and/or SMEs responsible to provide evidence for each IRL line item. We also add a column to the spread sheet and document the evidence to gather, rather it is in our policies, documentation we maintain, or system configs we need to gather, and we also list the preferred file format of the various documents.

Most importantly, when working with the SMEs ask them to record how they obtained the various pieces of evidence. If they ran a report have them write down the type of report and the process they followed to create it. You’ll be very likely to follow the same process next year. These instructions should be kept in each teams Evidence Collection Toolkit, and having the process written down can also assist if new personnel take over the PCI assessment responsibilities and that person will have the data they need to quickly reproduce the effort.

Automate Evidence Collection

When possible try to automate the collection of evidence. For example, if you need to collect server configurations to show Telnet is disabled from a sampled set of servers create a script to automate that process. You can engage a SME for assistance to create the script, and then store that script along with any instructions or procedures to run the script. These scripts and any automated processes can be reused for future assessments.

As mentioned, if each team is maintaining their own Evidence Collection Toolkit it is the ideal place to record all the instructions to gather evidence and reference any scripts to be used.

The objective here is to reduce the amount of work time necessary to collect the evidence, and to ensure the consistency of the output.

Avoid Single use Documentation

When supplying documentation such as network diagrams, lists of personnel with access to cardholder data, asset inventories, hardening guides, SDLCs, etc… avoid having these documents being specifically crafted to support the PCI assessment. Having an assessment only document practically guarantees it will be stale when the document is needed, or when the next assessment cycle comes around.

Whenever possible try to adapt a “living” document and consistently update that document. Chances are these updated documents will be more useful during the year, and may serve other needs, and possibly may be requested for other audits your business goes through during the year. 

It is also worth noting that even if there are no environmental changes that would require changes to the documentation, all the documents should still be reviewed once every twelve months. The revision history should reflect the review with no updates and that way the Assessors can verify documentation is reviewed annually.

Update, Update, and Keep Updating

As mentioned, each time you go through the yearly assessment refresh your playbook and contacts to keep it current and accurate. Revise process documentation based on any environmental changes and try to increase the evidence collection automation level whenever you can. The point of having the PCI Assessment Playbook is not so you can create it once and then never update it. The goal is to leverage the work already done in the past and make sure the information gathering documentation and processes are up to date. Each year should be an opportunity to not only respond to the current assessment, but also to prepare for the next one as well.


While there is no one size fits all Playbook out there, it is more then worth the effort to create a customized PCI Assessment Playbook and having it in place. The strategies I discuss here can reduce the required effort when you go through the yearly assessment, and this planning and capturing the useful information about the assessment process can cut down significantly on the reactive fire drills that can occur each year during an assessment. It’s well worth the extra hours this year to save yourself ten times that effort when the assessment cycle comes around again, and again, and again…

The Importance of System Hardening


Most operating systems are not very secure out of the box and favor convenience and ease of use over security. IT Security professionals may not agree with a vendor’s user friendly approach to their OS, but that does not mean they have to accept it. There are steps that can be taken to harden a system and eliminate as many security risks as possible

System Hardening Examples

The most basic hardening procedure is to change the vendor default user name and password. You would be surprised how many vendor default access codes can found with a simple Google search!

System hardening can include configuration settings to remove unnecessary services, applying firewall rules, enforcing password complexity, setting failed login thresholds, and system idle time outs.

System hardening can also include installing an anti-virus program, forwarding logs to a centralized log management solution, and applying vendor released system patches.

Basically system hardening is a way to lock down the Operating System before the system goes into production. The hardening guides can not only detail the steps to follow to secure a system, but can complement any system deployment guides. Along with the list of procedures to follow to improve system security the hardening guides can reference vendor best practices, and industry standard security requirements such as NIST or the PCI requirements, and how those standards can be meet as part of the overall system hardening process.

Keys to System Hardening and Hardening Guides

  • Review your inventory of the network connected systems and understand what you have and how it’s at risk before you can completely implement any hardening procedures. This includes reviewing current deployment and operational processes and understanding the threats and vulnerabilities to the various deployed systems and addressing any discovered security gaps.
  • The hardening guides shouldn’t be interpreted as one-size-fits-all solution. There may need to be separate guides for the servers versus workstations, or for different OS’s being run in the environment. Specific hardening guides may need to be developed depending on the systems function and criticality along with its placement in the environment.
  • If your company places an importance on security and there is C level buy in for security it can still be balancing act to secure your systems and to do what is right for the business.
  • The hardening guides are a baseline to secure your systems and no matter how tight the systems are locked down they’re still going to be exploitable in some way. It is important to never let your guard down and not get into the mindset of everything is secure because of the procedures you have followed in the hardening guides.
  • Hardening guides should be a “living document” and should be reviewed and updated whenever there are changes to your internal policies or procedures, or when there are changes to any followed external policies or standards.
  • The guides should not only document how to deploy a secure system, but how to maintain a secure system with continued vulnerability management and system patching.


To review, system hardening is the process of enhancing security through an assortment of methods which results in a more secure operating system environment, and system hardening is another defense layer to protect resources and data.