Skip to Main Content
September 12, 2019

PCI Requirements 101

Written by Jonathan White
PCI Assessment Program Assessment & Compliance

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

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.1Firewall and router configuration standard
2.2Configuration Management Policy and/or Standard for all system components
3.1.aData Retention and Disposal Policy
3.5Encryption Key Management Policy
4.2Acceptable Use of Assets Policy
5.1.1Malicious Software Policy
6.1.aVulnerability Management Policy
6.3Application Security Management Policy
6.4.5Change Management Policy
7.1.aAccess Control Policy
8.1.aPassword Management Policy
9.2.aPhysical Security Policy
9.7Information Exchange Policy
9.9Asset Management Policy
10.6Logging and Monitoring Policy
10.6.2Risk Management Policy
11.1.2.aIncident Response Plan
12.1Information Security Policy
12.6.bSecurity Awareness Policy
12.8Third-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