PCI DSS 3.2 Compendium (2017)

Tags: #<Tag:0x00007f0cabf65798> #<Tag:0x00007f0cabf65630> #<Tag:0x00007f0cabf654f0> #<Tag:0x00007f0cabf653b0> #<Tag:0x00007f0cabf65270> #<Tag:0x00007f0cabf65130> #<Tag:0x00007f0cabf64fc8> #<Tag:0x00007f0cabf64e88>


Payment Card Industry Data Security Standard 3.2 Cheat Sheet

This is my growing personal PCI DSS compendium. Please research the validity of these information independently. If you spot an error, please let me know.

Note that this compendium does in no way provide any advice on compliance, and obviously does not supersede the information from the PCI SSC or the payment brands.


Need to know basics to do a PCI assessment

The values in the table exclude costs for a forensic breach examination by a PCI Qualified Forensic Investigator (QFI). I have heard of entities, which were fined, and put under monthly external compliance audits (See DESV). It seems to be rare, and if that happens it becomes a legal matter. Therefore you may need to read between the lines.

Payment Card Industry Terminology

  • Payment Brand Networks: these are created by the payment brands to operate the services.
  • Cardholder: a person purchasing goods with Card Present or Card Not Present transaction, with a credit card of the brands under PCI DSS (exclusions may include Chinese brands for the time being).
  • Issuer: Visa and MasterCard cards get issued by a bank. Directly issued cards include: AmEx, Discover, JCB. Directly issued card brands are part of a closed loop network, for there there is no Acquirer.
  • Acquirer: bank, or an entity, the merchant can use to process payment transactions. Receives authorization from the merchant to forward to the Issuer for approval.
    • In short: Cardholder ----> Merchant --- _CC transmission to_ ---> Issuer --- _approval_ ---> Approval sent to Merchant
    • provides authorization, clearing and settlement services to the Merchant
    • Issuers are also named as: Merchant Banks or ISOs
  • Merchant: organization accepting the payment card for payment during a purchase
  • Authorization: this is a transaction approval process between the bank and the Issuers
  • Settlement: there is a reconciliation process between the banks and the payment brands
  • Clearing: this is part of the payment cycle here, and sometimes the cycles take up to 3 days in the US / EU

PCI Abbreviations

  • CHD - CardHolder Data
  • CDE - Cardholder Data Environment
  • (M)SP - (Managed) Service Provider
  • ERP - Enterprise Resource Planing (I usually mean SAP or Navision here)
  • FIM - File Integrity Monitoring

Merchant Levels in PCI DSS 3.2 (2017)

Merchants have different validation and reporting requirements.

  • Level 1: Onsite Assessment (ROC), usually >= 6 million transactions.
  • Level 2: Self-Assessment (SAQ and ASV)
  • Level 3 and 4: determined by Payment Brand or Acquirer

Service Provider Levels in PCI DSS 3.2 (2017)

Service Providers (SPs) have different validation and reporting requirements.

  • Level 1: Onsite Assessment (ROC)
  • Level 2, 3 AmEx: Self-Assessment (SAQ and ASV)

SPs can be used anywhere. Requirement 12.8 requires to manage these.

Microsoft has a PCI DSS overview with a responsibility matrix, which applies based on the relationship between a Merchant and their hosting services, their respective SP. This document illustrates the topic of shared responsibilities between Merchants and SPs.

Reference: Azure PCI DSS Responsibility Matrix 2016 - v5-readonly.xlsx
Local copy: Azure PCI DSS Responsibility Matrix 2016 - v5-readonly.xlsx (293.8 KB)

SAQs - Self Assessment Questionnaires

An engineer-friendly reference - for application developers

Reference: Data flow diagrams and SAQ eligibility by Visa: "Processing e-commerce payments from Visa"
Local copy: processing e-commerce payments guide-73-17337.pdf (208.1 KB)

SAQ types for different use-cases of cardholder data

  • SAQ A - all cardholder data functions outsourced (example: iFrame solution, hosted by a PCI DSS compliant SP)

  • SAQ A-EP - payment processing is partially outsourced to PCI DSS validated 3rd parties. Cardholder data is Electronically Processed, but not stored (example: Direct Post, some JavaScript implementations)

  • SAQ B - Imprint-only merchants, no storage of cardholder data. Dial out terminals. Not for e-commerce.

  • SAQ B-IP - merchants with stand-alone PTS-approved payment terminals with an IP connection to the payment processor, no storage. Usual: E2EE and POI devices. Not for e-commerce.

  • SAQ C - Merchants with segmented payment applications connected to the internet. No storage. Not for e-commerce.

  • SAQ C-VT - Merchants using only web-based virtual payment terminals. No storage. Not for e-commerce.

  • SAQ D - Merchants: all other. SPs: if determined by the payment brand as eligible (usual). Example: ERP with XML interface, which is used for cardholder data transfers

  • SAQ P2PE - Merchants who have implemented a validated Point-to-Point Encryption Solution (listed on the PCI SSC site). No storage.

SAQs contain the requirements, testing procedures and additional guidance.

Scope a PCI DSS assessment

For a PCI DSS assessment it is required to have all the systems in scope, which:

  • store, process and transmit cardholder data (CHD).
    • that may include the ERP system, customer support case management systems for billing services, e-commerce websites such as web stores…
    • systems which are located and connected (without segmentation, local referance copy: Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf (1.3 MB)) to the CDE
    • systems that provide security services, or which may impact the security of the CDE

Scope verification is a good start

A good start of a PCI DSS assessment is to determine the scope accurately.

  • this needs to be re-confirmed at least annually for the assessed entity, and needs to be documented for assessor reference to confirm the accuracy

The scope includes people, processes and technology. PCI DSS is not limited to technical topics. A thorough understanding of the environment, including the system components and physical locations where cardholder data is stored and/or transmitted, is necessary.
An assessment usually takes multiple days or even weeks for larger entities.

Data flow diagrams, similar to the Visa reference, can help to speed up this process.

Avoid these traps during a PCI DSS assessment

  • Inventory gaps (missing or outdated asset lists, e.g. Desaster Recovery Solution site (DRS site) not listed, backup systems missing)
  • don’t forget customer payment related case management systems for refunds, charge-backs and cancellation
    • log data of billing support services
    • you might have VoIP in scope, and the call recording systems if cardholder data has been recorded
  • Missing networks, or entire physical locations (might be new)
    • DRS site and site tunnels of the CDE, fail-over networks, backup networks…
  • Don’t ignore “unknown data”, which might leak out of applications and databases.
    • Encrypted data is in scope.
  • Effective network segmentation guidelines apply (not as a requirement, but as a possible scope limiter)
  • POS terminals may periodically print transaction logs on paper for reconciliation
    • paper records are often ignored in Data Retention Policies and Business Record Policies
  • an assessment includes all roles of seniority
  • Policies and processes may tangent
    • log reviews, change management, configuration management, firewall review processes, approval processes… security policies, On-boarding processes. Legacy processes, fall-back processes (are there manual, maybe paper driven, processes?) and more


Sampling is an assessment tool; your’s. The method used for the sampling approach needs to be documented in a ROC or SAQ. An entity does not decide on sampling for an assessor.

The sampling must be large enough to provide assurance about the implemented PCI DSS objectives. Therefore they must include all combinations.

Sampling should mind people, processes and technology.

My strategy orientation: 30% people, 30% processes, 30% technology and the last 10% are proportionally added to support the assurance, individually depending on the Merchant.

Pre-assessment planing / enumeration - optional step

Initial interviews can be used to reliably estimate upon the dimension (and time) of the assessment, and to exchange detailed information. The goal of this can be to avoid re-assessment items, and to reduce delays once the assessment has commenced. Usually there are deadlines, and contractual periods.

Determine eligibility - SAQ scope

For L 3 and 4 Merchants an Acquirer may decide upon the eligibility, and the entity confirms this in the SAQ. The criteria are listed in the SAQ.

Assess 6 goals and 12 requirements


Local copy: Prioritized-Approach-for-PCI_DSS-v3_2.pdf (1.1 MB)

Goals of PCI DSS

It’s usually best to motivate the goals.

  1. Build and Maintain a Secure Network and Systems
  • Install and maintain a firewall config to protect cardholder data
  • Don’t use vendor-supplied defaults for system passwords and other security parameters
  1. Protect Cardholder Data
  • Protect stored cardholder data
  • Encrypt transmission of cardholder data across open, public networks
  1. Maintain a Vulnerability Management Program
  • Protect all systems against Malware and regularly update AntiVirus software or programs
  • Develop and maintain secure systems and applications
  1. Implement Strong Access Control Measures
  • Restrict access to cardholder data by business need-to-know
  • Identify and authenticate access to system components
  • Restrict physical access to cardholder data
  1. Regularly Monitor and Test Networks
  • Track and monitor all access to network resources and cardholder data
  • Regularily test security systems and processes
  1. Maintain an Information Security Policy
  • Maintain a policy that addresses information security for all personnel

Requirement Gap analysis

The applicable PCI requirements, depending on the SAQ, need to be 100% in place, so that you can mark them as “in place”. I do not provide a complete description of each requirement here, because that is in the SAQ that applies to your entity. I try to illustrate the intention of the requirements.

Requirement 1: Install and maintain a firewall configuration to protect cardholder data


Local copy: Guidance-PCI-DSS-Scoping-and-Segmentation_v1.pdf (1.3 MB)

May include and not be limited to:

  • can include routers and FWs, as well Personal and Host OS Firewalls of systems in CDE (config standard)
  • FWs control traffic that is allowed between the entity’s (internal) CDE networks (in-scope) and un-trusted out-of-scope nets.
  • Needs network and CC Data Flow diagrams (can be combined)
  • FWs need to located at any DMZ or internet connection
  • FW and/or router config need to restrict ingress and egress traffic limited to what is required for the CDE
  • Rules need to be documented and reviewed every 6 months
  • Direct public access to the CDE is prohibited (DMZ needs to be present)
  • No disclosure of private IP addresses (usually NAT is used)
  • interviews, processes and documentation

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

May include and not be limited to:

  • procedure reviews on the configuration standard
  • SNMP is included, as well as POS terminal setup guidelines
  • Firmware updates (on Wireless devices), and support for strong encryption and authentication
  • System configuration standards need to be developed
  • one primary function per server paradigm
  • SSLv3 / TLS 1.0 should be disabled. TLS 1.1 and 1.2 (blog post)

Local copy: Migrating_from_SSL_Early_TLS_Information Supplement_v1.pdf (758.3 KB),

  • Remote Administration tools need to use strong encryption. No Telnet or RShell
  • Asset Inventory
  • interviews, processes and documentation (includes network diagrams)
  • Vulnerability Scans or Pentests can be useful as additional references (enumeration of protocols and services)

Requirement 3: Protect Stored Cardholder Data

May include and not be limited to:

  • policies and procedures regarding retention and disposal of CHD
  • automatic CHD data-location routines
  • Sensitive Authentication Data (SAD) must not be stored (full track data from magnetic stripe, PIN and PAN block, CVC, CVV2, CID, CAV2 data)
    • unless you have a business reason (documented)
    • this restriction includes logs
  • For the PAN only the first 6 or last 4 digits are allowed for storage, the rest needs to be masked.
    • also includes paper, DBs, files, spread sheets, audit logs, transaction records and reports
  • PAN must be rendered unreadable during transmission over public wireless networks (via hashing)
  • If the PAN is stored, one-way hashes, index tokens and strong cryptography can be used:
    • If PAN data is stored on HDs, flash drives or in DBs, then truncation, strong cryptography and key management, index tokens and pads can be used to render the data unreadable at the storage system directly
  • Disk Encryption needs to be separately accessed, not just from the OS
  • Crypto Keys need to protected (policies) against disclosure and misuse
    • HSM (Hardware Security Modules) and CSDs used for the key inventory need to be documented, as well as key storage locations (approved forms apply)
    • policies and procedures include the custodians
  • Split knowledge AND dual control for key-management (do not split AES Keys in half…)
  • This needs documentation, people and processes
    • Data Retention and Disposal Policies, Key Management Documentation, Encryption System documentation
    • in order to fully accommodate requirement 3, the (sampled) systems need to get deeply reviewed. It is not acceptable if SAD is stored in an encrypted form after authorization.

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Local copy: Migrating_from_SSL_Early_TLS_Information Supplement_v1.pdf (758.3 KB),

May include and not be limited to:

  • protocols like TLS, IPSEC, SSH … are used (public nets include internet, wireless and SAT)
  • is HTTPS enforced for the CHD submission?
  • clear-text PANs do not go into end-user systems, like IM, mail, SMS…
  • also wireless systems, with WEP need some special attention (if they exist)

Requirement 5: Protect all systems against malware and regularly update AntiVirus software or programs

May Include and not be limited to:

  • deployed and running (cannot be disabled without reason) to all systems in scope
  • Detect, remove, protect (remediation)
  • signature updated happen automatically
  • periodic scans are configured
  • Check: logging is enabled

Requirement 6: Develop and maintain secure systems and applications


Local copy: PCI_DSS_Risk_Assmt_Guidelines_v1.pdf (2.2 MB)

May Include and not be limited to:

  • Vulnerability Scans are required (This is not the ASV.)
  • security vulnerabilities need to be identified, handled with a process, ranked (via an outside source score) and managed (criticality kept lower than CVSS score of 7 for example)
  • patches and security updates need to be installed within 1 month of release
  • SDLC needs to reflect PCI DSS requirements and security requirements
    • code security reviews, change reviews
    • software development policies
  • separation between test and production environment
    • independent checkpoints should prevent end to end control for a single individual in the production environment (policy, procedure)
  • Live PANs are not to be used for testing
  • Coding training needs to be conducted regularly and can be oriented with the OWASP Top 10
    • injection flaws need to be covered, BOFs, crypto flaws like downgrade attacks, improper error handling (like exception stack trace disclosure), XSS, SQLi, access control flaws, CSRF, session management issues
  • Either there is an App Sec review or a WAF
    • WAF needs to be part of a remediation process, so that attacks are prevented in a timely manor and not just detected. A risk assessment can determine what an adequate time to incident response is. That needs to be documented.
  • Check: policies and procedures for vuln management, and whether they are known to relevant parties (regardless of seniority the aspects of risk needs to be transparent throughout the org)
    • Check: patch management procedures, incident response procedures and plans, training logs, test processes, WAF config management, network diagram, change requests…

Requirement 7: Restrict access to cardholder data by business need to know

May Include and not be limited to:

  • access policies, interviews with management on job requirements (access needs), review of approval documentation
  • preferably there is Role Based Access Control
  • procedures should be documented, in-use and known
    • also by default no one should have access (to prevent unknown access to the CHD) - Least Privilege Access paradigm
  • Check: Access Control Policy, New User Request Forms

Requirement 8: Identify and authenticate access to system components

May include and not be limited to:

  • User Identification Management for all System Administrators (excludes consumer users only)
  • account-bound Multi Factor Authentication (MFA), and a Unique ID, is used for admin logins
    • this includes RADIUS, Active Directory, LDAP challenges etc.
  • User Accounts, which are no longer needed, get disabled immediately. For example of terminated users.
    • inactive accounts older than 90 days get removed or disabled
  • if there are more than 6 failed logon attempts on 1 user account (non consumer), that account gets locked for at least 30m
  • Idle sessions are closed after maximally 15m
  • Users are properly identified before credential resets
  • Password policies apply (see SAQ guidance), with complexity and change-frequency requirements

“A minimum password length of at least seven characters, Contain both numeric and alphabetic characters

  • change PWs every 90 days
  • Users need guidance for credential management (dispensated documents)
  • shared credentials are removed (shared User IDs like “Administrator”)
    • if there is a remote POS, the management PW needs to be unique per customer for a SP
  • Check: Access Control Policies, Config Standard, observation of logon procedures, documents

Requirement 9: Restrict physical access to cardholder data

May include and not be limited to:

  • physical access controls like badge readers, includes consoles
  • actively monitored video cameras (to monitor access to sensitive areas)
  • access to network jacks needs to be restricted (shut down unused network ports)
  • onsite personnel and visitors need to be distinguished (badges)
  • revocation process for termination of personal with access permission to sensitive areas need to include that keys, cards etc. are returned (also of visitors)
  • visitor authorization process, 3 month visitor log
  • a safe, a secure physical storage, for media, is present
  • Media Classification and Access Policy - org has identified sensitive media (not just a confidential label). Media, which is sent, can be tracked.
  • There is a media inventory
  • media destruction requirements apply to assure, that reconstruction is reasonably hard
  • Secure Wipe Programs are used, in accordance with Industry Standards (documentation)
  • Physical Security Policies need to exist
  • Card Readers need to be protected (there is a qualified list of devices), and get inspected periodically

Requirement 10: Track and monitor all access to network resources and cardholder data

May include and not be limited to:

  • Logging and Audit trails are activated for all system components
  • audit-able events may need to be recorded, e.g. logon failures, changes to time-settings, file-integrity monitoring (FIM), log-frequency (sudden size changes of a log file are focused)
  • time-synchronization is used (central time servers)
  • audit-trails are protected from unauthorized modification, and access-restricted, and backed up
  • certain log types are reviewed daily (via log tools, in accordance with the org’s risk management strategy)
  • log retention is at least 1 year, with 3 months of logs being available immediately
  • Check: information security policy, audit and logging procedures, log retention policy, system config standard, observation of system settings, FIM protection etc.

Requirement 11: Regularly test security systems and processes

May include and not be limited to:

  • Detection of authorized and rogue wireless APs - quarterly (note that this is for the CDE scope)
  • 4 quarterly internal AND external Vulnerability Scans need to occur within the year, and high-risk findings need to be addressed as part of the vulnerability management process. Then a re-scan is required.
    • after significant changes a (scoped) re-scan needs to be conducted
  • Quarterly ASV scans may be required to be performed
  • Yearly external and internal Penetration Testing of the CDE is required:
    Local copy: Penetration_Testing_Guidance_March_2015.pdf (1.1 MB)
  • this needs to be industry accepted pentetration testing (e.g. use the NIST SP800-15 approach)
    • exploitable vulnerabilities need to be fixed, segmentation controls may be in scope (internal and external)
  • after significant changes to the CDE, pentests may be required to verify the security of the environment again. This needs to be determined by qualified internal resources or independent 3rd parties
  • Network IDS / IPS systems may need to be present at the CDE perimeter to inspect all traffic (ingress and egress)
  • FIM tools may need to provide change-detection mechanisms (weekly file-comparison checks); includes procedures on how to react to generated alerts

Requirement 12: Maintain a policy that addresses information security for all personnel

May include and not be limited to:

  • information security policy needs to be published, maintained and disseminated
  • risk assessment processes need to be implemented (at least annually)
  • Personal Usage Policies / Acceptable Use Policies may be required to define proper use of technology
  • for a credible PCI DSS compliance program, executive management should define and assign information security roles and responsibilities
  • A security awareness program (yearly), and should require an acknowledgement that personnel is aware of the policies.
  • background checks and screening of personnel may be needed
  • manage 3rd party service providers, which you share CHDs with
    • written agreements are required
    • you may need the AoCs of SPs for hosting, or payment processing
    • shared responsibilities apply
      • but the final responsibility may be with the Acquirer (which accepts the SAQ) in case of e-commerce merchants (L 3,4)
  • You may need a security incident response plan to react to a breach
    • tested annually, periodically trained
    • monitoring and responding to alerts needs to be included in the testing
      • lessons learned need to be incorporated
  • regularly confirm that the review processes and cyclical tasks are assigned and executed

PCI DSS assessment tools

Report on Compliance / Attestation of Compliance

The L1 entity may need a Report On Compliance (ROC), with a report. Think of an Assessor Quality Assurance review, internally. A final report review, and the signature and submission process.

For Level 1 entities you have to use this ROC template.

PCI DSS compliance dashboard - Excel

There are others. This works for entities as well, which do not need a ROC.

Compensating controls are an assessment tool

Compensating controls are an assessment tool for the assessor. The entity does not decide upon the definition and acceptance criteria. This is often misunderstood. The compensating controls can get accepted if they meet the the structure of the Compensating Control Worksheet (CCW):


The Merchant entity, eligible for an SAQ A, states that they “cannot use Multi Factor Authentication”.

During the assessment this gets narrowed down: Requirement 8.2 cannot be fulfilled. The system in place does not offer a any viable integration option for MFA. The system in place is very expensive.

This results into a Constraint which also lists a business reason. The Objective of the original control is to prevent unauthorized access, and to protect the CHD.

The Identified Risk is, that the lack of Multi Factor Authentication may allow intruders to gain access, either by eavesdropping or by brute-force. In short: the risk is unauthorized access.

The Definition of Compensating Controls is up to you. A bastion host / jump host with an MFA integration, that is conform to requirement 8.2, may seem appropriate. - With the respective network changes to restrict access to the affected systems.
There also need to be processes for this, so that the jump host is maintained, and to ensure that there is logging (tracebility), that the logs get reviewed, and that there is a procedure for Incident Response.

The Validation of Compensating Controls should include people, processes and technology.

The Maintenance of this control would include a network review, a system review of the jump host, a process review of the log review procedures and of the policies and procedures for Incident Response.

DESV - Designated Entities Supplemental Validation

There also is a ROC template for DESV entities. On the PCI SSC website is an FAQ document related to that.

This usually affects entities which have failed to setup the PCI DSS processes to put the requirements in place. Such entities may have to fill out the DESV ROC. It’s important that the acquirer or payment brand, which requested the additional validation in conjunction with a PCI DSS assessment states if an S-ROC / S-AoC is needed.

Summary: is it just ticking boxes?

I wrote this for my PCI ISA exam, and kept it very condensed / incomplete.

The ISA exam is similar to the QSA exam. The ISA certification process has 2 steps: PCI DSS Fundamentals and the ISA examination. The Fundamentals test has got 60 questions, multiple-choice. The ISA examination is 75 questions / 90 minutes.

I think it’s very clear that PCI DSS is not about ticking boxes. There are people who finish it every year like that, and get away with it. That is a disservice, similar to a dentist who tells you your teeth are fine. And next time you take a bite into an apple, you have to call the emergency service. Sure that dentist can save me some money at that exact moment. But that might backfire one moment later.

The other dimension with that inappropriate tick-box attitude are the proportionality vs. liability conerns, related to the business risks.

If you don’t want to work with people, processes and technology, don’t do PCI DSS. There are many information security jobs which need less people and process skills.

Version history
  • 01.05.2017 - beta release, many typos and formulation errors fixed
  • 05.05.2017 - I added the DESV section. I am thinking of opting into the PCIP program.

Law and Data Security - a growing compendium