What are the Twelve PCI DSS Requirements?

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.

Build and Maintain a Secure Network and Systems1Install and maintain a firewall configuration to protect cardholder data
2Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data3Protect stored cardholder data
4Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program5Protect all systems against malware and regularly update anti-virus software or programs
6Develop and maintain secure systems and applications
Implement Strong Access Control Measures7Restrict access to cardholder data by business need to know
8Identify and authenticate access to system components
9Restrict physical access to cardholder data
Regularly Monitor and Test Networks10Track and monitor all access to network resources and cardholder data
11Regularly test security systems and processes
Maintain an Information Security Policy12Maintain 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.

9Restrict physical access to cardholder data
12Maintain 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.

SAQ A Requirement 12

As the image illustrates, the set of PCI DSS testing procedures can be greatly minimized if you can outsource your card handling entirely.