PCI DSS 4.0, Part 2: How the 12 Requirements Ladder Up to 6 Goals
6/13/2026
In Part 1 I walked through the fundamentals — the terminology, the payments ecosystem, and the history of the standard. I closed with a promise to myself: map the 12 requirements to the 6 goals, and stop reading PCI DSS as a flat checklist.
This is that map. It's the lens I now use whenever I assess an environment that touches cardholder data — and most of it generalises well beyond payments.
The mental model: goals are the "why," requirements are the "how"
PCI DSS is often taught as "the 12 requirements," which makes it feel like a to-do list. But the standard is structured as 6 control objectives (goals), each satisfied by one or more requirements. Read top-down, it's a coherent security model:
| Goal | Requirements | The intent |
|---|---|---|
| 1. Build & maintain a secure network | 1, 2 | Control the perimeter and kill insecure defaults |
| 2. Protect account data | 3, 4 | Minimise stored data; encrypt it in transit |
| 3. Maintain a vulnerability management program | 5, 6 | Find and fix weaknesses continuously |
| 4. Implement strong access control | 7, 8, 9 | Least privilege, strong identity, physical control |
| 5. Monitor & test networks | 10, 11 | See what's happening; prove the controls work |
| 6. Maintain an information security policy | 12 | Govern all of the above with people and process |
Once you see it this way, an auditor's question like "show me requirement 8.3" stops being arbitrary. It's "show me how you do strong authentication," which ladders up to "show me your access control objective."
Walking the ladder
Goal 1 — Secure network (Req 1–2). Requirement 1 is network security controls (the modern, vendor-neutral language for "firewalls"). Requirement 2 is the one people underrate: change vendor defaults. Default credentials and unnecessary services are still among the most common root causes in breach reports worldwide.
Goal 2 — Protect account data (Req 3–4). Requirement 3 governs stored data — and its first principle is don't store what you don't need. Sensitive Authentication Data (CVV, PIN, full track) may never be stored post-authorisation, anywhere. Requirement 4 protects data in transit with strong cryptography over open networks.
Goal 3 — Vulnerability management (Req 5–6). Requirement 5 is anti-malware. Requirement 6 is secure software — patching on a risk-ranked cadence and building security into the SDLC. This is where PCI DSS overlaps almost perfectly with general DevSecOps practice.
Goal 4 — Access control (Req 7–9). The heart of the standard. Req 7 = least privilege (need-to-know). Req 8 = identity and authentication, where 4.0 pushes MFA hard, including for all access into the cardholder data environment. Req 9 = physical access. Note the shape: logical least privilege, strong identity, physical control — the same triad you'd apply to any sensitive system.
Goal 5 — Monitor & test (Req 10–11). Req 10 is logging and monitoring — tying every action to an individual and keeping tamper-resistant trails. Req 11 is testing: vulnerability scans and penetration tests that prove the other controls actually hold. Controls you never test are assumptions, not controls.
Goal 6 — Policy & governance (Req 12). The connective tissue: an information security policy, risk assessment, awareness training, and third-party/service-provider management. Without Req 12, the other eleven are tools with no operating manual.
What actually changed in 4.0
The version 4.0 shifts that matter most in practice:
- The Customized Approach. You can now meet a requirement's objective with your own controls, provided you document the design and prove it works. Flexibility, but it moves the burden onto your evidence and risk analysis.
- Continuous, not annual. The language pushes toward security as a business-as-usual posture rather than a once-a-year scramble before the assessment.
- Stronger authentication. Expanded MFA and tighter password/credential requirements across the board.
- Targeted risk analyses. Several requirements now let you set frequencies based on a documented risk analysis — again, evidence-driven.
The future-dated requirements became mandatory in 2025, so "we'll get to it" is no longer a posture.
Why this matters beyond payments
I keep coming back to PCI DSS because it's one of the few standards specific enough to be actionable while still mapping cleanly onto the big frameworks. The 6 goals line up almost one-to-one with NIST CSF functions (Identify, Protect, Detect, Respond, Recover) and with ISO 27001 Annex A control families. If you can operate PCI DSS well, you've effectively built the muscle for ISO, SOC 2, and most regional regimes too.
What I'd do next
- Build the requirements-to-goals matrix as a one-page reference and pin it to every cardholder-data assessment.
- Cross-map each goal to NIST CSF and ISO 27001 Annex A to find overlapping evidence I can reuse across audits.
- Draft a mock Customized Approach write-up for one requirement, end to end, to feel where the evidence burden really bites.
- Write Part 3 on the scoping problem — because every requirement above is only as good as the boundary you drew around the environment.
Closing thought
A checklist tells you what to do. A model tells you why, which is what you need when an auditor asks an unexpected question or when you're meeting an objective with a control the authors never imagined. PCI DSS 4.0 rewards the people who read it as the latter.
The question I now open every assessment with: "Which of the six goals is this control serving — and can I prove it?"