PCI Requirements 101

Having completed several PCI-DSS (Payment Card Industry – Data Security Standard) Reports on Compliance (RoCs) over the past couple of years, I have noticed a consistent pattern on the items needed for the 12 requirements. I have found that there are three basic components to most if not all PCI requirements:

  1. Documentation (Policies, Standards, and Procedures)
  2. Observations/Evidence
  3. Interviews

Let’s address these one at a time.

Documentation (Policies, Standards, and Procedures)

I have found that the terms policy, standards, and procedures are sometimes misunderstood in our industry. When an auditor requests either a policy, standard, or procedure, they may receive an artifact that does not fully satisfy the request. The terms are different and hopefully, these definitions will provide some clarity (from ISACA’s glossary of terms https://www.isaca.org/Knowledge-Center/Documents/Glossary/glossary.pdf):

Policies are generally a document that records a high-level principle or course of action that has been decided on by the enterprise’s management teams.

Standards are a mandatory requirement, code of practice, or specification approved by a recognized external standards organization such as the International Organization for Standardization (ISO).

Procedures are a document containing a detailed description of the steps necessary to perform specific operations in conformance with applicable standards. Procedures are defined as part of processes.

According to my research, some of the documentation items needed are as follows:

NOTE: The name of the document(s) may vary from one organization to another. Additionally, some documents may not apply to your environment.

Requirement # Description
1.1 Firewall and router configuration standard
2.2 Configuration Management Policy and/or Standard for all system components
3.1.a Data Retention and Disposal Policy
3.5 Encryption Key Management Policy
4.2 Acceptable Use of Assets Policy
5.1.1 Malicious Software Policy
6.1.a Vulnerability Management Policy
6.3 Application Security Management Policy
6.4.5 Change Management Policy
7.1.a Access Control Policy
8.1.a Password Management Policy
9.2.a Physical Security Policy
9.7 Information Exchange Policy
9.9 Asset Management Policy
10.6 Logging and Monitoring Policy
10.6.2 Risk Management Policy
11.1.2.a Incident Response Plan
12.1 Information Security Policy
12.6.b Security Awareness Policy
12.8 Third-Party Management Policy


Observations can serve as a form of evidence, especially when it isn’t feasible to produce a physical artifact. Also, in some cases, customers would rather not provide hardcopy evidence of sensitive items such as internal policies and procedures. A Qualified Security Assessor (QSA) can observe those policies or procedures while onsite to ensure the document satisfies the requirement. Another example where an observation may make sense is the evidence used to satisfy requirement 8.3, which pertains to securing all individual non-console administrative access and all remote access to the Cardholder Data Environment (CDE) using multi-factor authentication. Observing the administrator logging into the CDE or ‘shoulder surfing’ this process should suffice. A screenshot of the observation should be provided to satisfy the PCI-DSS mandated three years of evidence retention rule.

As for screenshots, they are often used by themselves as a source of evidence. A customer can provide screenshots of items such as password complexity requirement settings (Requirement 8.2.3). As a practice, I usually ask that the screenshot include the displayed computer date and time to ensure that the evidence is current. Most customers can provide screenshots, and even though producing them can be time-consuming, the information provided can be confirmed and used to validate the request.

Some of the best forms of evidence are those generated by scripts. Script evidence made systematically is less prone to user error. Although it can be cumbersome to initially build a script, once the script is validated, it can often be re-used year after year with minimal modifications. Scripted output, either through manual script generation or providing criteria to standard applications (e.g., Change Management or Ticketing systems), allows the customer to produce the evidence more efficiently through a repeatable process. 


Throughout the RoC are requirements with the wording, ‘Identify the responsible person interviewed who…’ Each of these items expects that a discussion occurs, either while on-site or over the phone. This interview should provide satisfactory responses to the question(s) requested in the RoC. The meetings can be with Subject Matter Experts (SMEs), but if not, the interviewee should be an employee who accepts ownership of the responses provided. A list of persons interviewed is documented in Section 4.10 of the RoC.


Keep in mind that not all 12 PCI-DSS requirements follow this pattern exactly. However, if the QSA keeps in mind the three components (Documentation, Observations/Evidence, and Interview) when conducting a PCI audit, they will address a majority of the items needed for RoC completion. Remember that the person responsible for conducting and signing a PCI RoC is attesting to the customer’s compliance according to the PCI DSS standard. Whoever conducts the engagement needs to take the time to collect all necessary evidence to ensure complete customer compliance.

You can refer to the PCI SSC website for additional information and guidance on this subject https://www.pcisecuritystandards.org.

Jonathan White

Author: Jonathan White

Jonathan White started his IT career in the United States Marine Corps as a Computer Programmer. After the Marine Corps, he started a job as a Computer Operator and advanced to serve as Manager of the company’s 24 X 7 data center. This is when he realized that providing solutions to issues and customer interaction was his passion. The next step in his career was as a Network Engineering Consultant for one of the national credit bureaus. In this role, he was responsible for the IP network for as many as 14 local offices in the Southern Region.