The Compliance Atlas·Volume VI
Volume VI · PCI DSS v4.0.1 · Edition 2026.1

The Compliance Atlas

Authoritative refs
PCI DSS v4.0.1 (June 2024)
PCI SSC ROC Template v4.0.1
Verified May 12, 2026

PCI DSS is the most prescriptive framework in the Atlas — and the only one whose audit outcome turns on a definition. Get the Cardholder Data Environment right and the assessment is bounded; get it wrong and the boundary swallows your whole network. Every PCI strategy is, at its heart, a scoping strategy.

Reading the Atlas

Internal — merchant / service provider External — QSA / acquirer / card brand Bridge / hand-off

PCI is enforced through merchant agreements, not regulation. The card brands set the rules; the acquirers enforce them; QSAs validate compliance for the largest merchants. v4.0.1 (June 2024) clarified v4.0 and the future-dated requirements became mandatory March 31, 2025.

I.
Layer 01 — Lifecycle

RoC and SAQ — two assessment paths, one standard

PCI DSS v4.0.1
RoC Template v4.0.1

The PCI annual cycle — internal program × external assessment

12-MONTH CYCLE → Scope & tier Pre-assessment Continuous ops Pre-validation Validation Submission Next cycle INTERNAL — MERCHANT / SERVICE PROVIDER EXTERNAL — QSA · ACQUIRER · CARD BRANDS Determine merchant level L1 / L2 / L3 / L4 by tx volume + brand Define CDE scope people · process · system CHD storage · processing · trans. Segmentation strategy tokenization · isolation reduce CDE = reduce cost Approach selection Defined or Customized v4.0+ option Continuous compliance 12 reqs operating "PCI is not a project" Evidence binder PBC · IPE · samples organized by req AOC + RoC submitted to acquirer / brand renewal annual Define entity type merchant vs SP SP requirements stricter Quarterly ASV scans external vuln scan ASV-approved vendor TRA for customized Targeted Risk Analysis required if not Defined Internal pen test at least annually + after major changes Segmentation testing required ≥ annually SPs every 6 mo SAQ self-assess L2-L4 path A · A-EP · B · C · D Breach response forensics & PFI if compromised QSA selection PCI SSC roster L1 only Engagement letter scope · timeline · fees QSA company SOW Scope confirmation QSA validates CDE network diagrams · flows Onsite assessment walkthroughs · interviews configs · evidence review Testing procedures 300+ in v4.0.1 per req in RoC template RoC drafted ~300 page document In Place / Not / N/A AOC signed Attestation of Compliance QSA + entity sign QSA QA review QSAC internal PCI SSC reviews QSACs Independence check no design + assess QSA cannot consult Sample population QSA-determined per testing procedure Customized review if Customized Approach QSA evaluates TRA + ctrls Compensating controls documented in App. C narrowed in v4 vs v3.2.1 Acquirer review acquiring bank enforcement starts here Card brand reporting Visa · MC · AmEx Discover · JCB CARD BRAND ENFORCEMENT Non-compliance → fines from acquirer (passed from card brands) CDE definition → QSA validates scope TRA → customized review segmentation evidence → testing procedures AOC submitted → acquirer reviews

RoC vs SAQ — two paths, very different rigor

PATH 1 · REPORT ON COMPLIANCE RoC QSA-led, full validation, ~300 page report Required for: Level 1 merchants (~6M+ tx/yr or after breach) Required for: All Level 1 service providers (~300k+ tx/yr) Period: 12-month coverage Effort: 3–6 months for QSA assessment alone Cost: $50k–$300k+ (size-dependent) DELIVERABLES — RoC: ~300 pp · narrative + testing per requirement — AOC: signed by QSA + entity — ASV scan attestations (quarterly) — Pen test reports + segmentation tests — Submitted to acquirer + card brands PATH 2 · SELF-ASSESSMENT QUESTIONNAIRE SAQ merchant-completed, eight types, scope-narrowed Available for: Levels 2–4 (varies by brand) Type: SAQ A (fully outsourced) → D (everything else) Period: point-in-time annual attestation Effort: days to weeks internal-only Cost: staff time + ASV scan ($200-2k/yr) SAQ TYPES (KEY ONES) — SAQ A · card-not-present, fully outsourced (~22 ctrls) — SAQ A-EP · e-commerce w/ partial outsourcing — SAQ B · imprint or standalone terminals — SAQ C · payment app on internet-connected POS — SAQ D · merchants storing CHD electronically

Why scoping is everything in PCI

The CDE is a contagion. Once a system stores, processes, or transmits cardholder data, it's in scope. Worse — any system connected to that system is also in scope unless segmentation is in place. A poorly designed network can pull half the corporate environment into the CDE, doubling assessment cost and quadrupling remediation burden. Mature programs invest more in segmentation than in any other control category.

Tokenization is the cheat code. If you can replace cardholder data with a token early in your processing flow and never store, process, or transmit the original, you collapse most of your CDE. Stripe, Adyen, and Braintree have built billion-dollar businesses around this principle. The tradeoff: you depend on their PCI compliance and their tokenization architecture's correctness.

Service providers face stricter requirements than merchants. If you process payments on behalf of others (PSPs, acquirers, ISO/MSPs, hosting providers handling CHD), you must comply with additional requirements specifically for service providers — including more frequent segmentation testing (every 6 months vs annually), executive accountability for the program, and Service Provider AOC.

You don't pass PCI by passing controls. You pass by shrinking the CDE until passing controls becomes feasible.

v4.0.1 made the future-dated requirements real. Released March 2024, mandatory March 2025: customized passwords (12+ chars), MFA on all CDE access (not just admin), authenticated vulnerability scanning, automated log review, anti-phishing controls (Req 5.4.1), payment page integrity monitoring (Req 6.4.3 + 11.6.1), and TRA documentation for many security controls. Programs still on v3.2.1 muscle memory are now non-compliant.

II.
Layer 02 — Control universe

Twelve requirements, four goals, two approaches

PCI DSS v4.0.1
12 Requirements

The four goals — protecting cardholder data front to back

4 GOALS · 6 CONTROL OBJECTIVES · 12 REQUIREMENTS GOAL 1 Build & Maintain a Secure Network Reqs 1 + 2 GOAL 2 Protect Account Data Reqs 3 + 4 GOAL 3 Maintain Vuln Mgmt Program Reqs 5 + 6 GOALS 4–6 Access · Monitor · Policy Reqs 7–12 Req 1 Network security controls Firewalls, routers, network segmentation, DMZ, default deny, change control on rules ~16 sub-reqs Req 2 Secure config all components Vendor defaults removed, hardening standards, CIS / NIST baselines, non-console admin enc. ~7 sub-reqs Req 3 Protect stored account data Minimize CHD storage, PAN encryption (AES), key mgmt lifecycle, SAD never stored post-auth ~10 sub-reqs Req 4 Encrypt transmission over public networks TLS 1.2+ in transit, cert validation, cipher strength current, no PAN over messaging ~3 sub-reqs Req 5 Anti-malware protection EDR/AV deployed, phishing protections (5.4.1), log all malware events, integrity-monitoring ~6 sub-reqs Req 6 Develop & maintain secure systems Patch SLAs (critical 30d), code review, SDLC + threat modeling, payment page integrity ~9 sub-reqs Req 7 Restrict access by need-to-know Default deny, role-based access, least privilege, access provisioning controls ~3 sub-reqs Req 8 Identify users authenticate access Unique IDs, 12+ char passwords, MFA on ALL CDE access, session timeout ~6 sub-reqs Req 9 Restrict physical access Badge / visitor logs, media controls, device tampering checks (POI), backup site security, media disposal procedures ~5 sub-reqs Req 10 Log + monitor everything Audit logs all CDE activity, log integrity (FIM), 365-day retention (90 immediate), automated log reviews (10.4.1.1), time synchronization ~7 sub-reqs Req 11 Test security regularly Quarterly ASV scans (external), internal vuln scans, annual pen test + segmentation, payment page integrity (11.6.1), IDS/IPS ~6 sub-reqs Req 12 Information security policy Annual policy review, risk assessment + TRA documentation, awareness training, incident response plan, vendor mgmt (12.8 + 12.9), SP executive accountability (12.4.2) ~10 sub-reqs · largest v4.0+ INTRODUCES TWO APPROACHES Defined Approach — meet the requirement exactly as written. The traditional path. Easy to validate, easy to fail by-the-letter. Customized Approach — meet the requirement's objective via alternative controls. Requires Targeted Risk Analysis (TRA). QSA evaluates whether the alternative meets intent. Compensating Controls (App. C) still exist but are narrower in v4.

Why PCI feels different from every other framework

The prescription is the point. Where SOC 2 says "the entity restricts logical access" (CC6.1), PCI says "MFA must be implemented for all non-console administrative access into the CDE" (Req 8.4.1) and "MFA must be implemented for all access into the CDE" (Req 8.4.2 — added in v4.0). The shift from principle to specification is unmistakable. Defined Approach controls leave no room for interpretation; you either do exactly what's stated or you don't.

Customized Approach is genuinely new. Until v4.0, alternative controls only existed via Compensating Controls (Appendix C) — which required a documented business or technical reason why the requirement couldn't be met as written. Customized Approach is different: you can voluntarily design a different control that meets the same security objective. This unlocks innovation but adds documentation burden — every Customized Approach control requires its own Targeted Risk Analysis (TRA).

PCI is the framework that tells you exactly what to do. v4 quietly admits that "exactly" wasn't always the right answer.

Requirement 12 is the largest and most-failed. Despite being labeled "information security policy," Req 12 covers risk assessment, TRA documentation, awareness training, incident response, vendor management, executive accountability, and several other governance topics. It's the requirement most likely to surface program-wide weaknesses during a QSA visit. Treat Req 12 as a meta-requirement that examines whether everything else is being managed.

The 2024–2025 transition reshaped programs. Future-dated requirements that became mandatory March 31, 2025 changed the day-to-day program for most merchants: MFA for all CDE access (not just admin), 12-character passwords (was 7), authenticated vulnerability scanning, automated log review (Req 10.4.1.1), payment page integrity monitoring (Req 6.4.3 + 11.6.1), and TRA documentation requirements throughout. Programs that "passed v3.2.1 with ease" are now finding v4.0.1 considerably harder.

III.
Layer 03 — Evidence

QSA testing — examine, observe, interview

PCI DSS v4.0.1 Testing Procedures
QSA Evidence Requirements

QSA testing methods — three procedures, applied per requirement

METHOD 1 · EXAMINE Examine documents · configs · records — Policies and procedures — System configurations — Logs and reports — Network diagrams — Change tickets — ASV / pen test reports QSA RECORDS — What was examined — Date observed — Reference number / hash METHOD 2 · OBSERVE Observe processes in action — User authentication flow — Provisioning / deprovisioning — Backup process — Incident response simulation — Physical security walks — POI device inspection QSA RECORDS — Process observed step-by-step — Personnel involved — Date and location METHOD 3 · INTERVIEW Interview verifying knowledge & practice — System administrators — Application developers — Security operations staff — Incident responders — Vendor managers — Executive sponsor (Req 12.4) QSA RECORDS — Who was interviewed (role) — Topics covered — Knowledge gaps surfaced EVERY TESTING PROCEDURE COMBINES THESE For every sub-requirement, the RoC Template specifies which method(s) the QSA must use. Most use 2–3 methods together — Examine + Observe, or Interview + Examine — to triangulate. Single-method evidence is rarely accepted for high-risk controls.

Targeted Risk Analysis — the v4 documentation requirement

Control with flexible cadence e.g., scan freq, log review Identify the asset what's being protected data, system, control Identify the threat what could happen if control fails Define frequency based on risk magnitude + business impact Document review cadence (annually or on significant change) Approval & ownership accountable executive, documented signoff QSA SCRUTINIZES TRA QUALITY Generic / boilerplate TRAs fail; documented TRAs that match actual decisions pass. v4.0.1 added explicit TRA requirements to ~25 sub-requirements. REAL EXAMPLES OF TRA-DRIVEN CONTROLS Frequency of POI device inspection · Frequency of review of access privileges · Frequency of pen test scope · Frequency of vendor security review

Where PCI evidence work goes wrong

Sample sizes are negotiable but bounded. Unlike SOX's prescribed sample sizes, PCI's testing procedures specify "examine a sample" or "observe processes" without numeric floors. QSAs use professional judgment — but firm policies and PCI SSC guidance establish typical floors: 25 for most population-based tests, 10–15 for less risky controls, and 100% for critical controls (e.g., privileged users, all firewall rules). Negotiate sample size at engagement start, not at draft RoC review.

IPE testing is mandatory but often skipped. Reports used as evidence — vulnerability scan reports, log review records, access matrices — must themselves be tested for completeness and accuracy. The QSA confirms how the report was generated, what filters or parameters were used, and whether the data matches the source system. Programs that submit "the screenshot from the dashboard" as evidence without provenance routinely fail this step.

TRA documentation became a separate work product in v4.0.1. Many sub-requirements that previously specified a fixed cadence ("monthly review of audit logs") now allow risk-based cadence ("at a frequency defined by the entity's TRA"). Each such control needs its own documented TRA: identifying the asset, threat, likelihood, impact, and resulting control frequency. Generic "we reviewed and decided weekly" TRAs are flagged. Real ones reference specific assets, specific threats, and the analytical reasoning.

PCI's prescription was always "do this." v4 added "document why doing this is enough."

Compensating Controls (Appendix C) are not the easy way out. A Compensating Control requires (a) a documented business or technical reason why the requirement can't be met as written, (b) an alternative that meets the same security objective, (c) a TRA showing the alternative is at least as effective, and (d) QSA validation. Most attempts at Compensating Controls fail because the "business reason" is actually "we didn't want to" — a reason QSAs reject. v4 narrowed this further; Customized Approach is now the preferred path for genuine alternatives.

IV.
Layer 04 — Cross-framework

PCI DSS as the prescriptive baseline

PCI v4.0.1 maps cleanly to others;
scope is the differentiator
PCI requirement SOX SOC 2 (TSC) ISO 27001:2022 NIST CSF 2.0 HIPAA HITRUST v11 Shared evidence
Req 1 — Network Sec ITGC — Operations CC6.6 A.8.20 · A.8.22 PR.IR-01 §164.312(e)(1) 09.m Firewall config, network diagram, segmentation tests
Req 2 — Secure Config ITGC — Change CC6.6 · CC6.8 A.8.9 PR.PS-01 §164.312(a)(1) 09.h · 10.b CIS benchmarks, hardening guides, drift detection
Req 3 — Stored Data ITGC + BPC C1.1 · CC6.1 A.8.10 · A.8.11 · A.8.24 PR.DS-01 §164.312(a)(2)(iv) 06.c · 10.f KMS config, encryption inventory, key rotation logs
Req 4 — Transmission ITGC — Operations CC6.7 A.8.24 PR.DS-02 §164.312(e)(2)(ii) 09.s TLS scan, cert inventory, VPN config
Req 5 — Anti-malware ITGC — Operations CC6.8 A.8.7 PR.PS-05 §164.308(a)(5)(ii)(B) 09.j EDR/AV deployment, scan logs, IOC alerts
Req 6 — Secure Dev ITGC — SDLC CC8.1 A.8.25 – A.8.32 PR.PS-06 — 10.a · 10.b SAST/DAST, code review, change tickets, pen test
Req 7 — Need-to-know ITGC — Access CC6.1 · CC6.3 A.5.15 · A.8.2 · A.8.3 PR.AA-05 §164.308(a)(4) 01.b · 01.v RBAC config, role definitions, access tickets
Req 8 — Authentication ITGC — Access CC6.1 · CC6.2 A.5.16 · A.5.17 PR.AA-01 · PR.AA-03 §164.308(a)(3) · §164.312(a)(2)(i) 01.b · 01.d MFA enforcement, password policy, IAM logs
Req 9 — Physical Access ITGC — Operations CC6.4 A.7.1 – A.7.14 PR.AA-06 §164.310 08.b · 08.j Badge logs, CCTV, visitor records, POI inspections
Req 10 — Logging ITGC — Operations CC7.1 · CC7.2 A.8.15 · A.8.16 DE.CM-01 §164.312(b) 09.aa SIEM rules, log retention, automated review
Req 11 — Security Testing ITGC — Operations CC7.1 A.8.8 ID.RA-01 §164.308(a)(1)(ii)(B) 10.k · 10.m ASV scans, internal scans, pen test, segmentation test
Req 12 — Policy & Program ELC · governance CC1.1 – CC9.2 Cl. 5 · A.5.1 · A.6.3 GV.PO · GV.RR §164.308(a)(1) – (8) 02 · 03 · 05.k Policies, training records, IR plan, vendor mgmt, TRAs

What PCI gives the rest of the program

PCI is the most prescriptive framework in the Atlas, which means evidence built for PCI satisfies the others by default. If your firewall rules pass Req 1, they pass SOC 2 CC6.6 and ISO A.8.20. If your encryption passes Req 3, it passes HIPAA §164.312(a)(2)(iv) and ISO A.8.24. The crosswalk above shows clean one-to-many mappings — every PCI requirement maps to multiple controls in every other framework, and the PCI-level rigor exceeds what most other frameworks demand.

The asymmetry: PCI requires specific things (TLS 1.2+, AES-256, 12-character passwords, MFA on all CDE access). The other frameworks require that things — they care that encryption exists, not that it's AES-256. So PCI evidence over-satisfies, but you must explicitly document that fact in your other frameworks' work papers. Don't assume the SOC 2 auditor will infer your PCI controls cover their CC6.x.

PCI is the floor. If you pass PCI, the rest of your security crosswalks fall into place. The reverse is rarely true.

The scope difference is the trap. SOX scopes to financial systems; SOC 2 to systems supporting the service description; HIPAA to systems handling ePHI; PCI to systems handling cardholder data. If your CDE is a small subset of your larger environment (which is the goal — that's the whole tokenization strategy), then PCI evidence covers only that subset. The CDE-only evidence does not satisfy the rest of your environment for SOC 2 or ISO 27001. You'll need to document scope deltas explicitly — and consider running broader controls programs that cover both CDE and non-CDE consistently.