# PCI-DSS v4.0 Readiness Pack > Working readiness template for PCI-DSS v4.0 / v4.0.1 compliance. Scope worksheet, the 12 requirements with evidence checklist, the future-dated controls (in force from 2025-03-31), and the reporting tier quick-check. MIT licensed. Adapt to your card-handling scope. **Who this is for:** a merchant, service provider or processor handling cardholder data (CHD) or sensitive authentication data (SAD). This pack assumes you already know whether you need SAQ, RoC (Report on Compliance) or self-assessment — if not, Section 1 helps you decide. **v4.0.1 status:** v4.0 was mandatory from **2024-03-31**. The *future-dated* requirements moved from best practice to mandatory on **2025-03-31**. If today is on or after 2025-03-31, everything in Section 14 is in scope. --- ## 0. Pack contents | Section | Purpose | |---|---| | 1. Scoping & tier | Decide SAQ / RoC / service provider | | 2. Cardholder Data Environment (CDE) definition | Scope boundary worksheet | | 3. Network security controls (Req 1) | Firewall + segmentation | | 4. Secure configurations (Req 2) | Defaults, hardening | | 5. Protect stored account data (Req 3) | Storage, encryption, key mgmt | | 6. Protect transmitted data (Req 4) | TLS, secure transmission | | 7. Malware protection (Req 5) | Anti-malware | | 8. Secure development (Req 6) | SDLC, patch, vuln mgmt | | 9. Access controls (Req 7 & 8) | Least privilege + authentication | | 10. Physical access (Req 9) | Facility + media | | 11. Logging + monitoring (Req 10) | Log coverage + retention | | 12. Testing (Req 11) | Scanning, pen test, IDS | | 13. Policy + programme (Req 12) | Governance | | 14. Future-dated v4.0 controls | Mandatory from 2025-03-31 | | 15. Evidence index | What to hand to the QSA | --- ## 1. Scoping & reporting tier **Service provider?** You store, process or transmit card data *on behalf of* another entity. Annual RoC with a QSA is typical. **Merchant?** You take cards for your own goods/services. Tier depends on annual transaction volume. | Tier | Annual transactions | Report | |---|---|---| | Merchant Level 1 | 6M+ Visa/MC | RoC by QSA | | Merchant Level 2 | 1M–6M | SAQ-D + QSA validation (brand-dependent) | | Merchant Level 3 | 20k–1M e-com | SAQ-D | | Merchant Level 4 | Everything smaller | SAQ, flavour depends on acceptance channel | **SAQ flavour for merchants:** - `SAQ A` — fully outsourced, e-commerce, no card data on merchant systems. - `SAQ A-EP` — e-commerce, merchant controls page but not card capture (redirect / iframe to PSP). - `SAQ B` — imprint machines, standalone dial-out terminals. - `SAQ B-IP` — IP-connected terminals, no e-com. - `SAQ C-VT` — virtual terminal only. - `SAQ C` — payment app + IP-connected, no e-com. - `SAQ P2PE` — validated P2PE solution from the PCI council list. - `SAQ D` — everything else; the full monty. Getting the flavour wrong is the most common scoping mistake. If unsure, default to SAQ D and narrow. --- ## 2. Cardholder Data Environment (CDE) definition A system is *in scope* if any of: 1. Stores, processes or transmits CHD or SAD. 2. Is on the same network segment as a system that does (unless segmentation is validated). 3. Can affect the security of a system that does. Document the CDE with: - [ ] **Data flow diagram** showing every path CHD/SAD takes, including transient memory. - [ ] **Network diagram** showing every network + every trust zone + firewall positions. - [ ] **System inventory** — every in-scope system with hostname, IP, role, owner. - [ ] **Account inventory** — every identity (human + service) with access to the CDE. - [ ] **Third-party inventory** — payment gateways, PSPs, tokenisation providers. - [ ] **Out-of-scope rationale** — for every "not in scope" claim, the technical basis (segmentation, tokenisation, no CHD present, etc.) Segmentation must be validated. Just having a VLAN isn't sufficient. You need firewall rules, a pen test confirming no leakage, and annual re-validation. --- ## 3. Requirement 1 — Network security controls - [ ] Firewall policy with explicit deny-by-default, documented per-rule business justification. - [ ] Firewall rule review every 6 months (v4.0 moved this from annually). - [ ] All connections entering and exiting the CDE inspected. - [ ] Inbound direct internet to CDE is forbidden. Internet-facing tier → DMZ → CDE is the model. - [ ] Outbound from CDE to the internet is restricted to authorised flows only. - [ ] Personal firewall or equivalent on any device that connects to the CDE from outside the LAN. ## 4. Requirement 2 — Secure configurations - [ ] All vendor defaults changed before production: passwords, SNMP community strings, cipher suites. - [ ] Hardening standard per platform (CIS benchmarks are the easy answer). - [ ] Evidence of application against sample: one router config, one Linux host, one Windows host, one application server. - [ ] Insecure services disabled (telnet, http-admin, rsh, finger, etc.). - [ ] Primary function per server is one primary function or equivalent virtualisation isolation. ## 5. Requirement 3 — Stored account data Rules of thumb: - Do **not** store SAD after authorisation. Ever. This includes CVV2/CVC2, full track, PIN/PIN block. - PAN must be rendered unreadable: hash, truncate, tokenise, or strong crypto + key mgmt. - Display PAN truncated: **first six + last four** maximum (v4.0 tightened from "first six + last four" wording but the practical rule is the same). - Encryption keys stored and managed per Requirement 3.5–3.7. Evidence: - [ ] Data retention schedule for CHD, with business justification - [ ] Data discovery scan results (e.g. Varonis, Spirion) — confirm no rogue PAN - [ ] KMS / HSM configuration + key lifecycle procedure - [ ] Key custodian list + signed responsibility statements - [ ] Annual key rotation evidence ## 6. Requirement 4 — Transmitted data - [ ] TLS 1.2+ for all CHD transmission over open networks. TLS 1.0/1.1 have been forbidden for years. - [ ] Strong cryptography on wireless (WPA3; WPA2-Enterprise acceptable interim). - [ ] Cert inventory; no self-signed certs for CHD transport. - [ ] Email / IM policy forbids sending PAN by unprotected channels; DLP evidence supports it. ## 7. Requirement 5 — Malware - [ ] Anti-malware on systems commonly affected (historically Windows; v4.0 broadens — you need a defined risk-based approach for other OS). - [ ] Continuous scanning (not just on-demand). - [ ] Evidence of malware detection outcomes and response tickets. - [ ] Periodic evaluation for systems not commonly affected — risk-based justification. ## 8. Requirement 6 — Secure development - [ ] Secure coding training attestation for developers. - [ ] SAST in CI pipeline; results reviewed. - [ ] DAST on applications at least annually and after significant change. - [ ] SCA for third-party components; CVE triage SLAs. - [ ] Patch management: critical patches within 30 days, high within 90 (v4 is risk-based but these are still the defensible bars). - [ ] OWASP Top 10 coverage evidenced. - [ ] Separation of dev / test / prod. - [ ] Live PAN never in non-production environments. - [ ] Change control: requirements (Sec 6.5). ## 9. Requirement 7 + 8 — Access controls **Req 7 — Least privilege:** - [ ] Role definitions with access rationale. - [ ] Default-deny on access control systems. - [ ] Access assignment documented with approvals. **Req 8 — Authentication:** - [ ] Unique user IDs. No shared generic accounts — if shared accounts exist for applications, they must be technical-only and managed by a vault. - [ ] MFA enforced for all remote network access and all non-console admin access (v4 extended: also for all access into the CDE, including by internal users — in force from 2025-03-31). - [ ] Password min 12 chars (v4 bumped from 7), complexity or length variants acceptable per config. - [ ] Password change cadence: annually or triggered on compromise / role change. - [ ] Inactive accounts disabled within 90 days. - [ ] Authentication logs retained for at least 3 months immediately available, 1 year total retention. ## 10. Requirement 9 — Physical access - [ ] Access control to sensitive areas (server rooms, telco closets, POS device storage). - [ ] Visitor management log + badging. - [ ] Camera coverage where applicable, retention at least 90 days. - [ ] Media disposal procedure — degaussing / shredding / crypto-erasure with certificates. - [ ] POI (Point of Interaction) device inventory with serials + periodic tamper inspection. ## 11. Requirement 10 — Logging + monitoring - [ ] Log coverage: user identification, individual access to CHD, all admin actions, failed access attempts, privilege changes, auth mechanism events, system-level object access, system events. - [ ] Log retention: 1 year minimum; last 3 months immediately available. - [ ] Time synchronisation with authoritative source. - [ ] Daily review of security events (automated SIEM fine; someone must be looking). - [ ] File integrity monitoring on in-scope systems (v4 framed as "change detection" but FIM still fits). ## 12. Requirement 11 — Testing - [ ] Internal vulnerability scan every 3 months; passing scan on file after remediation. - [ ] External ASV scan every 3 months; passing scan on file. - [ ] Penetration test at least annually and after significant change — external + internal. - [ ] Segmentation validation test at least every 6 months for service providers (annually for merchants). - [ ] Intrusion detection / prevention on the perimeter and critical segments; alerts investigated. - [ ] File integrity monitoring alerting on changes. ## 13. Requirement 12 — Programme - [ ] Information security policy reviewed annually. - [ ] Risk assessment at least annually — PCI-specific, documented. - [ ] Security awareness training on hire + annually, attestation log. - [ ] Incident response plan with PCI-specific notification obligations (card brands, acquirer, forensics firm engagement process). - [ ] Third-party service provider (TPSP) list — PCI status evidence per provider. - [ ] Responsibility matrix per TPSP: who does what control. --- ## 14. Future-dated v4.0 controls — mandatory 2025-03-31 The big ones: - **MFA everywhere inside the CDE** (not just remote / admin) — every authenticated session into the CDE requires multi-factor. - **Targeted risk analysis per control** where PCI lets you set your own frequency or parameters — document the analysis. - **Automated account-data discovery** on a defined frequency — to catch CHD sprawl. - **Anti-phishing mechanism** — technical + process controls. - **Payment page integrity** — script monitoring and tamper detection on public-facing payment pages. - **Client-side scripts on payment pages** — inventory, authorised, integrity-validated (Req 6.4.3). - **Automated log reviews** — you can't just claim "someone looks". - **Cryptographic inventory** — keys, algorithms, expiries. If any of these are missing as of 2025-03-31 you have a *gap on a mandatory control*. QSAs treat these as ordinary findings with remediation windows; acquirers can be stricter. --- ## 15. Evidence index (QSA first-request) | # | Artefact | Owner | |---|---|---| | 1 | System description + diagram | Architecture | | 2 | CDE inventory | SecOps | | 3 | Data flow diagram | Product + SecOps | | 4 | Policy pack | CISO | | 5 | Control matrix | Compliance | | 6 | Firewall rule export + review records | Network | | 7 | Hardening baselines per platform | Platform | | 8 | Encryption design doc + KMS config | Security eng | | 9 | TLS inventory | Platform | | 10 | Access review evidence (4 quarters) | IAM | | 11 | MFA enforcement evidence | IAM | | 12 | SIEM rule pack + sample alerts | SecOps | | 13 | Quarterly internal + ASV scan reports | SecOps | | 14 | Annual pen test report + retest | SecOps | | 15 | Segmentation test report | SecOps | | 16 | Incident log + 2 sample tickets | SOC | | 17 | Vendor list + PCI status evidence | Vendor mgmt | | 18 | Training attestation log | HR | | 19 | Change tickets sample | Engineering | | 20 | Risk assessment (annual + targeted) | Compliance | --- ## 16. Fast-track gap analysis For a team new to PCI, this is the 10-question readiness check: 1. Do we know exactly where PAN lives? (Requirement 3) 2. Do we truncate/tokenise/hash before any storage we control? (Req 3) 3. Is TLS 1.2+ enforced everywhere with no weak ciphers? (Req 4) 4. Is MFA enforced for every authenticated session into the CDE? (Req 8 + v4 future-dated) 5. Is every admin action logged with a unique user ID and sent to a SIEM with 1-year retention? (Req 10) 6. Do we run a passing internal + ASV external scan every 3 months? (Req 11) 7. Was the last external pen test within 12 months with remediation closed out? (Req 11) 8. Do we have an incident response plan that references card brand notification? (Req 12) 9. Is every third-party PSP / tokenisation vendor on a list with current PCI validation evidence? (Req 12) 10. Has the security policy been reviewed in the last 12 months? (Req 12) If you can answer yes to all ten, you are in a fightable position for RoC fieldwork. --- ## Attribution Built by **Hak** at **VantagePoint Networks**. Based on PCI-DSS v4.0 and v4.0.1 normative requirements + real engagements with QSAs across retail, fintech and SaaS. MIT licensed — fork, customise, ship.