PCI DSS exists with the goal of protecting payment card data. But that’s a big task, and in the past different companies went about this in very different ways. To make this more manageable, the PCI DSS creates six high level objectives for card data security. These objectives are then subdivided into the twelve PCI DSS requirements you’re likely familiar with.
These twelve requirements support the six higher level objectives, and work together to safeguard payment card account data. These requirements are what drives any PCI DSS compliance program you go through.
When you read the individual requirements they can seem fairly straightforward. “Restrict physical access to cardholder data”. Or “Regularly test security systems and processes”. But as ever, the devil is in the details. Each requirement is split up into many sub requirements, and it’s these which are ultimately assessed.
Mapping Objectives to the Twelve PCI DSS Requirements
The following table maps the six PCI DSS objectives to the twelve requirements. Note that the distribution is uneven: the objective to maintain an Information Security Policy has one requirement, whereas implement strong access control measures is supported by 3 requirements.
Objective | # | Requirement |
---|---|---|
Build and Maintain a Secure Network and Systems | 1 | Install and maintain a firewall configuration to protect cardholder data |
2 | Do not use vendor-supplied defaults for system passwords and other security parameters | |
Protect Cardholder Data | 3 | Protect stored cardholder data |
4 | Encrypt transmission of cardholder data across open, public networks | |
Maintain a Vulnerability Management Program | 5 | Protect all systems against malware and regularly update anti-virus software or programs |
6 | Develop and maintain secure systems and applications | |
Implement Strong Access Control Measures | 7 | Restrict access to cardholder data by business need to know |
8 | Identify and authenticate access to system components | |
9 | Restrict physical access to cardholder data | |
Regularly Monitor and Test Networks | 10 | Track and monitor all access to network resources and cardholder data |
11 | Regularly test security systems and processes | |
Maintain an Information Security Policy | 12 | Maintain a policy that addresses information security for all personnel |
How is compliance with the requirements assessed?
Nobody is assessed directly against the requirements as they are written. That is, nobody simply has to answer the question “Do you have an Information Security Policy for all personnel?” Instead, each sub requirement has a defined testing procedure associated with it. That testing procedure varies depending on whether you do a SAQ, or go through a full QSA-led assessment.
The exact sub requirements you have to address depend on your level and the type of assessment you go through. Depending on the type of your business, these can vary greatly. A level 1 service provider will have a QSA perform around 250 separate testing procedures across all 12 requirements. Each of these must be found to be either in place (possibly with a CCW), or N/A.
Meanwhile, a merchant eligible to use a SAQ A faces a very different situation. First, they are allowed to self assess rather than using a QSA. Second, while PCI DSS has 12 requirements, SAQ A only covers 2 of them.
# | Requirement |
---|---|
9 | Restrict physical access to cardholder data |
12 | Maintain a policy that addresses information security for all personnel |
Even within this limited case, the set of items to test per requirement is a small subset of the full testing procedures. For requirement 12, SAQ A only requires that section 12.8 be tested at all. The rationale for this? Anyone eligible to use SAQ A has outsourced all of their PCI DSS responsibilities to a service provider. So the PCI requirement is to ensure appropriate processes are in place to manage service providers.
As the image illustrates, the set of PCI DSS testing procedures can be greatly minimized if you can outsource your card handling entirely.