The PCI DSS 12 requirements are the heart of the standard — twelve control areas, grouped under six goals, that every organisation handling card data must meet. This guide breaks down all of the PCI DSS 12 requirements in plain English: what each one asks for, how they fit together, and which of them cause the most audit findings.
Goal 1: Build and maintain a secure network and systems
- Requirement 1 — Install and maintain network security controls. Firewalls and network segmentation to protect cardholder data.
- Requirement 2 — Apply secure configurations to all system components. No vendor defaults; harden every system.
Goal 2: Protect account data
- Requirement 3 — Protect stored account data. Minimize storage; encrypt or render unreadable any data you must keep.
- Requirement 4 — Protect cardholder data with strong cryptography during transmission over open, public networks.
Goal 3: Maintain a vulnerability management program
- Requirement 5 — Protect all systems and networks from malicious software. Anti-malware, kept current.
- Requirement 6 — Develop and maintain secure systems and software. Patch promptly and build securely.
Goal 4: Implement strong access control measures
- Requirement 7 — Restrict access to system components and cardholder data by business need to know.
- Requirement 8 — Identify users and authenticate access. Unique IDs and strong authentication, including MFA.
- Requirement 9 — Restrict physical access to cardholder data.
Goal 5: Regularly monitor and test networks
- Requirement 10 — Log and monitor all access to system components and cardholder data.
- Requirement 11 — Test security of systems and networks regularly. Vulnerability scans and penetration testing.
Goal 6: Maintain an information security policy
- Requirement 12 — Support information security with organizational policies and programs. The documentation and governance that ties it all together.
A policy for every requirement.
The PCI DSS Toolkit maps to all 12 requirements with ready-made policies and procedures — auditor-written and aligned to PCI DSS v4.0, ready to tailor to your environment.
The PCI DSS 12 requirements teams underestimate
Requirement 12 — policies and programs — is where many organizations stumble. It’s not glamorous, but auditors expect documented, maintained policies for everything above. That’s exactly the gap a ready-made policy set fills; see the documentation checklist.
How to evidence the PCI DSS 12 requirements
Passing an assessment is less about having controls and more about proving they run. For each of the PCI DSS 12 requirements, an assessor expects to see a documented policy, a repeatable procedure, and dated evidence that the procedure is actually followed — change tickets, scan reports, access reviews, and training records. The most common reason organisations stall is not a missing control but missing evidence: the firewall is configured correctly, yet nobody can show the quarterly rule review. Build an evidence folder mapped one-to-one against the requirements as published by the PCI Security Standards Council, and keep it current, so that when an assessor asks “show me,” the answer is already on file.
Frequently asked questions
Do all 12 requirements always apply?
The requirements apply based on how you handle cardholder data and your validation method. Reducing your scope (for example, by not storing card data) can reduce what applies.
Have the requirements changed in v4.0?
The 12 core requirements remain, but v4.0 added and clarified many sub-requirements — see our guide to what changed in v4.0.
New to PCI DSS? Start with our complete guide.
The takeaway: work through the PCI DSS 12 requirements in order, treat documentation and evidence as first-class deliverables rather than afterthoughts, and re-check your scope whenever your environment changes. Approach it that way and each annual assessment becomes a review of a programme you already run day to day, instead of a last-minute scramble to reconstruct a year of activity.