Since 31 March 2025 every PCI DSS v4 assessment must include the requirements that were optional "best practices" during the transition, and many organisations are discovering that their scope, their SAQ choice and their identity controls were built for v3.2.1. PCI DSS v4.0.1, published by the PCI Security Standards Council (PCI SSC) in June 2024, is the current version; v4.0 was retired on 31 December 2024. This guide covers the 12 principal requirements, the future-dated requirements now in force, the defined and customised approaches, targeted risk analysis, scoping and segmentation, SAQ types and assessment roles, payment page script security, and the authentication rules in Requirement 8. It is written for security, compliance and engineering teams at merchants and service providers. Fraud controls that sit outside PCI DSS are covered in the Payment Fraud Guide.
Key takeaways
- v4.0.1 is the standard to assess against. It is "a limited revision" with "no additional or deleted requirements", mostly clarifications and applicability notes; the 31 March 2025 date for new requirements did not move.
- The future-dated requirements are now mandatory. Payment page scripts (6.4.3, 11.6.1), MFA into the CDE (8.4.2), 12-character passwords (8.3.6), system accounts (8.6.x) and targeted risk analyses (12.3.1) are now assessed in full.
- Customised approach is for risk-mature entities. It meets a requirement's stated objective with a different control, backed by a controls matrix and targeted risk analysis, and is validated only in a QSA-led Report on Compliance.
- Scope drives everything. Anything that stores, processes or transmits account data, connects to it without restriction, or could affect its security is in scope; segmentation is "not a PCI DSS requirement" but is the main way to shrink it.
- SAQ A changed in 2025. 6.4.3 and 11.6.1 were removed from SAQ A and replaced with an eligibility criterion that the merchant's site is "not susceptible to attacks from scripts"; the requirements themselves remain in the standard.
PCI DSS v4.0.1: versions and the 12 requirements
Versions and timeline
| Version or event | Date | What it means |
|---|---|---|
| PCI DSS v4.0 | March 2022 | Major rewrite: customised approach, targeted risk analysis and new requirements, many of them future-dated |
| PCI DSS v3.2.1 retired | 31 March 2024 | All assessments move to v4.x |
| PCI DSS v4.0.1 | June 2024 | Limited revision: clarifications to 3.3.x, 6.4.3, 8.4.2, 11.6.1, 12.3.1 and others; no requirements added or deleted |
| PCI DSS v4.0 retired | 31 December 2024 | Assess against v4.0.1 |
| SAQ A update | January 2025, effective 31 March 2025 | 6.4.3, 11.6.1 and 12.3.1 removed from SAQ A; new script eligibility criterion added |
| Future-dated requirements effective | 31 March 2025 | Best practices become required in all assessments |
The 12 requirements
| Req. | Title | v4 specifics worth knowing |
|---|---|---|
| 1 | Install and Maintain Network Security Controls | Network security controls (NSCs) replace "firewalls and routers" and include cloud security groups; configurations reviewed every six months (1.2.7) |
| 2 | Apply Secure Configurations to All System Components | Vendor defaults changed or disabled; one primary function per server, or isolation |
| 3 | Protect Stored Account Data | No sensitive authentication data after authorisation (3.3.1.2: card verification code); PAN masking (3.4.1); keyed hashes (3.5.1.1) |
| 4 | Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks | Inventory of trusted keys and certificates (4.2.1.1); certificates confirmed valid |
| 5 | Protect All Systems and Networks from Malicious Software | Anti-phishing mechanisms (5.4.1); removable media scanning (5.3.3) |
| 6 | Develop and Maintain Secure Systems and Software | Software and component inventory (6.3.2); automated web attack protection for public-facing apps (6.4.2); payment page scripts (6.4.3) |
| 7 | Restrict Access to System Components and Cardholder Data by Business Need to Know | User account and privilege reviews at least every six months (7.2.4); system account privileges (7.2.5) |
| 8 | Identify Users and Authenticate Access to System Components | MFA into the CDE (8.4.2); 12-character passwords (8.3.6); system and application accounts (8.6.1 to 8.6.3) |
| 9 | Restrict Physical Access to Cardholder Data | POI device inspection frequency set by targeted risk analysis (9.5.1.2.1) |
| 10 | Log and Monitor All Access to System Components and Cardholder Data | Automated log review (10.4.1.1); detect failures of critical security controls (10.7.2); 12 months retention, three immediately available (10.5.1) |
| 11 | Test Security of Systems and Networks Regularly | Authenticated internal scans (11.3.1.2); all vulnerabilities managed (11.3.1.1); annual internal and external penetration tests (11.4); payment page tamper detection (11.6.1) |
| 12 | Support Information Security with Organizational Policies and Programs | Targeted risk analysis (12.3.1); annual scope confirmation (12.5.2); phishing awareness (12.6.3.1); response to PAN found where not expected (12.10.7) |
Future-dated requirements now in force
These were best practice until 31 March 2025 and are now assessed in full. The ones most likely to need new tooling or process:
| Requirement | What it requires | Applies to |
|---|---|---|
| 3.4.2 | Technical controls stop PAN being copied or relocated over remote-access technologies without documented authorisation | All |
| 5.4.1 | Processes and automated mechanisms to detect and protect personnel against phishing | All |
| 6.4.2 | An automated technical solution that detects and prevents web attacks in front of public-facing web applications | All |
| 6.4.3, 11.6.1 | Authorise, integrity-check and inventory payment page scripts; detect unauthorised changes to scripts and security-impacting HTTP headers | All with payment pages |
| 7.2.4 | Review all user accounts and access privileges at least every six months | All |
| 8.3.6 | Passwords of at least 12 characters (eight if the system cannot support 12), with letters and numbers | All |
| 8.4.2 | MFA for all non-console access into the CDE | All |
| 8.5.1 | MFA systems resist replay, cannot be bypassed without documented exception, and require all factors to succeed | All |
| 8.6.1 to 8.6.3 | Interactive use of system and application accounts only by exception; no hard-coded passwords in scripts or files; passwords protected and changed on a risk-based schedule | All |
| 10.4.1.1 | Automated mechanisms for audit log reviews | All |
| 11.3.1.2 | Internal vulnerability scans performed with authenticated scanning | All |
| 12.3.1 | Targeted risk analysis for every requirement that lets the entity set the frequency | All |
| 12.5.2.1, 11.4.7 | Scope confirmed every six months; support customers' penetration testing (multi-tenant providers) | Service providers |
Defined approach, customised approach and compensating controls
Each requirement can be met in one of three ways. PCI DSS Section 8 states that the customised approach "is intended for risk-mature entities", that "There are no defined testing procedures; the assessor is required to derive testing procedures", and that controls must "meet or exceed the security provided by the requirement in the defined approach". It is "not an option" for requirements without a Customized Approach Objective.
| Approach | When to use it | Evidence | Validation |
|---|---|---|---|
| Defined | Default for most entities and requirements | Defined testing procedures | ROC or SAQ |
| Customised | The control meets the objective differently, for example a different MFA design or continuous monitoring in place of periodic review | Controls matrix and a targeted risk analysis per customised requirement (Appendices D and E), reviewed annually (12.3.2) | ROC only, by a QSA who designs the tests |
| Compensating control | A "legitimate and documented technical or business constraint" prevents meeting the requirement | Compensating control worksheet | ROC or SAQ, reviewed by the assessor |
Decision: use the customised approach only where an assessor can test that the objective is met and a risk function owns the analysis. SAQ merchants cannot use it; large service providers apply it selectively.
Targeted risk analysis (12.3.1) is separate: where a requirement lets you set a frequency (for example 11.6.1, 8.6.3, 7.2.5.1, 10.4.2.1, 9.5.1.2.1), you must document the asset, threats, likelihood and the frequency you chose, and review it at least every 12 months. v4.0.1 clarified that it applies only to requirements that specify completion of one.
Scoping and segmentation
PCI DSS Section 4 defines the cardholder data environment (CDE) as "System components, people, and processes that store, process, or transmit cardholder data" and components with "unrestricted connectivity" to them. Scope also includes anything that "could impact the security" of account data: identity providers, jump hosts, logging, patching and security tooling, and the people who administer them.
- Segmentation: "not a PCI DSS requirement" but "strongly recommended". Without it, the entire network is in scope. To be out of scope a system "must be properly segmented (isolated) from the CDE". Test segmentation at least annually and after changes (11.4.5); service providers every six months (11.4.6). See the Network Segmentation Guide.
- Scope confirmation: 12.5.2 requires documenting and confirming scope at least every 12 months and after significant change, including all data flows and locations of account data; service providers every six months (12.5.2.1).
- Scope reduction: tokenisation, PCI-listed P2PE solutions and outsourced hosted payment pages remove systems from scope only if PAN never reaches them. Data discovery (12.10.7 requires a response when PAN is found where it should not be) is how you prove it.
- Third-party service providers: 12.8 and 12.9 require a list of TPSPs, written agreements, and a responsibility matrix. PCI SSC states that a payment brand listing "is not sufficient evidence" that the services you rely on were assessed; ask for the AOC and its scope.
SAQs, ROCs and who assesses
Merchant levels and validation requirements are set by the card brands and acquirers, not PCI SSC. Broadly, the largest merchants (Level 1, typically over six million transactions a year) and Level 1 service providers complete a Report on Compliance (ROC) with a Qualified Security Assessor (QSA), or an Internal Security Assessor (ISA) where the brand allows; others usually complete a Self-Assessment Questionnaire (SAQ). Both end in an Attestation of Compliance (AOC) signed by the entity.
| SAQ | Who it is for |
|---|---|
| A | Card-not-present merchants that fully outsource payment pages or embed a TPSP form, with no electronic storage, processing or transmission of account data; must confirm the site is not susceptible to script attacks |
| A-EP | E-commerce merchants whose website controls or can affect the payment page (for example direct post) but does not receive account data |
| B | Imprint machines or standalone dial-out terminals only |
| B-IP | Standalone PTS-approved terminals with an IP connection to the processor |
| C-VT | Manual entry into a TPSP's virtual terminal, one transaction at a time, on an isolated device |
| C | Payment application systems connected to the internet, no electronic storage |
| P2PE | Only hardware terminals from a PCI-listed P2PE solution |
| SPoC | Software-based PIN entry on commercial off-the-shelf mobile devices with a listed SPoC solution |
| D (Merchant) | All other merchants eligible to self-assess |
| D (Service Provider) | Service providers eligible to self-assess; the only SAQ for service providers |
Choosing: the SAQ follows from the payment architecture, so change the architecture to change the SAQ. Moving from a merchant-hosted form (SAQ A-EP) to a TPSP iframe or redirect (SAQ A) is the largest scope reduction available to most online merchants. Confirm the choice with your acquirer, which decides what it will accept.
Payment page script security: 6.4.3 and 11.6.1
6.4.3 requires that "All payment page scripts that are loaded and executed in the consumer browser" are managed so that each is authorised, its integrity is assured, and "An inventory of all scripts is maintained with written business or technical justification". 11.6.1 requires a change- and tamper-detection mechanism that alerts on unauthorised modification "to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser", at least weekly or at a frequency set by targeted risk analysis.
- Redirects: PCI SSC's March 2025 information supplement says the requirements "do not apply to merchants with webpages that redirect to a TPSP's page".
- Iframes: the TPSP is responsible for scripts inside its iframe; the merchant for scripts on the parent page. "Where scripts are used to create an iframe, PCI DSS Requirements 6.4.3 and 11.6.1 will apply to those scripts."
- SAQ A merchants: FAQ 1588 says the script criterion can be met using techniques "such as, but not limited to, those detailed in PCI DSS Requirements 6.4.3 and 11.6.1", or by confirmation from a PCI DSS compliant TPSP when its solution is implemented per its instructions. PCI SSC FAQ 1331, on reporting these requirements in a ROC, has been revised since; read the current version before marking them not applicable.
- Techniques: Content Security Policy with an allowlist and reporting, Subresource Integrity for static third-party scripts, and client-side monitoring against an approved baseline.
Where identity fits
Many v4 changes in Requirements 7 and 8 concern non-human accounts as much as people.
- MFA into the CDE: 8.4.1 covers administrative access, 8.4.2 all non-console access into the CDE, and 8.4.3 remote network access from outside. v4.0.1 added that 8.4.2 does not apply to accounts "only authenticated with phishing-resistant authentication factors", so FIDO2 or smart cards can satisfy it. 8.5.1 forbids bypassable or replayable MFA. See the MFA Guide and the Passwordless and Passkeys Guide.
- Passwords: 8.3.6 sets 12 characters; 8.3.4 locks out after no more than 10 failed attempts for at least 30 minutes; 8.2.8 re-authenticates after 15 minutes idle; where a password is the only factor, change it every 90 days or analyse security posture dynamically (8.3.9). See the Password Security Guide.
- System and application accounts: 8.6.1 limits interactive use to documented exceptions, 8.6.2 bans hard-coded passwords in scripts, configuration files and source code, and 8.6.3 requires protection and risk-based rotation. 7.2.5 requires least privilege for them. See the Service Account Security Guide and the Secrets Management Guide.
- Access reviews: 7.2.4 requires all user accounts and privileges, including third-party accounts, to be reviewed every six months. See the Access Reviews Guide.
How to implement
- Confirm scope: map account data flows, run PAN discovery, and list TPSPs with their AOCs.
- Reduce before you control: move to tokenisation, P2PE or a TPSP iframe or redirect where it fits, and segment what remains; retest segmentation.
- Gap-assess against v4.0.1: use the defined approach first and list every future-dated requirement as its own work item.
- Write the targeted risk analyses: one per flexible-frequency requirement, approved and dated.
- Roll out authentication changes in rings: enable MFA into the CDE for administrators, then all non-console users, using report-only or monitor mode in the IdP or PAM tool first; keep a tested break-glass path and the previous policy to revert to.
- Deploy script controls in monitor mode: run CSP in report-only and client-side monitoring for two to four weeks to build the inventory, approve each script, then enforce and alert.
- Remove embedded secrets: scan code and configuration for hard-coded credentials, move them to a vault, and rotate.
- Validate: complete the SAQ or ROC and diarise scope reviews and quarterly scans.
Detection and measurement
Log all individual user access to cardholder data, administrative actions, access to audit logs, invalid logon attempts and changes to authentication credentials (10.2.1.x), review them with automated tooling (10.4.1.1), and alert on failures of critical security controls such as NSCs, IDS/IPS, change-detection mechanisms and anti-malware (10.7.2). Payment page alerts from 11.6.1 should go to the incident process, not a dashboard.
- Script coverage: percentage of payment page scripts in the inventory with authorisation and integrity controls (target 100%).
- Tamper alert response: median time from a 11.6.1 alert to triage.
- MFA coverage: percentage of non-console CDE access paths enforcing MFA or phishing-resistant authentication.
- Secrets hygiene: hard-coded credentials found per scan and median time to rotate.
- Scope accuracy: PAN discovery hits outside the CDE per quarter.
- Review completion: six-monthly access reviews completed on time, with revocations actioned.
Common failure patterns
- Treating SAQ A as zero work: the parent page that embeds the iframe can still be attacked, and the eligibility criterion must be evidenced.
- Forgotten connected systems: the IdP, CI/CD pipeline, backup service or monitoring agent with access to the CDE left out of scope.
- Secrets in the environment: cloud keys and vault tokens with reach into payment systems. The AI Agent Retail Card Theft Campaign used cloud keys, vault dumps and stolen admin access to steal 600,000 cards; 8.6.2 and 8.6.3 exist for exactly this.
- Customised approach as an escape route: choosing it to avoid a requirement, without a risk function or testable evidence.
- Risk analyses written after the fact: a frequency chosen for convenience with no documented threat or likelihood fails 12.3.1.
- Annual compliance: gathering evidence once a year instead of operating controls continuously.
Framework mapping
| PCI DSS area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 | CIS Controls v8.1 |
|---|---|---|---|---|
| Scope and inventory (12.5.1, 12.5.2) | ID.AM | CM-8 | A.5.9 | 1, 2 |
| Segmentation (1.2 to 1.4, 11.4.5) | PR.IR-01 | SC-7 | A.8.22 | 12 |
| Stored account data (3) | PR.DS-01 | SC-28 | A.8.24 | 3 |
| MFA and passwords (8.3, 8.4) | PR.AA-03 | IA-2(1), IA-2(2), IA-5 | A.8.5 | 6 |
| Service accounts (8.6) | PR.AA-01 | IA-5(7), AC-6 | A.5.17, A.8.2 | 5 |
| Payment page scripts (6.4.3, 11.6.1) | DE.CM-09 | SI-7, CM-7(5) | A.8.28, A.8.32 | 16 |
| Logging (10) | DE.CM | AU-2, AU-6 | A.8.15 | 8 |
| Vulnerability management (6.3, 11.3) | ID.RA-01 | RA-5 | A.8.8 | 7 |
Practitioner checklist
- Confirm you assess against PCI DSS v4.0.1 and that every future-dated requirement is implemented.
- Document scope and data flows, run PAN discovery, and confirm scope every 12 months (six for service providers).
- Test segmentation annually and after change, or every six months as a service provider.
- Pick the SAQ from the payment architecture and confirm it with the acquirer.
- Inventory, authorise and integrity-check payment page scripts, and monitor scripts and headers at least weekly.
- Enforce MFA or phishing-resistant authentication for all non-console access into the CDE, with no bypass.
- Remove hard-coded passwords and vault and rotate system account credentials.
- Write and annually review a targeted risk analysis for every flexible-frequency requirement.
- Collect TPSP AOCs and a responsibility matrix for every provider that touches account data.
Standards and references
- PCI SSC: Document Library (PCI DSS v4.0.1 and Summary of Changes)
- PCI SSC: Just Published, PCI DSS v4.0.1
- PCI SSC: Payment Page Security and Preventing E-Skimming
- PCI SSC: Important Updates for Merchants Validating to SAQ A
- PCI SSC: FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants
- PCI SSC: Guidance for PCI DSS E-Commerce Requirements Effective After 31 March 2025
Related NHI Mgmt Group resources: Payment Fraud Guide · Financial Services Identity Security Guide · MFA Guide · Secrets Management Guide. This guide summarises PCI DSS v4.0.1 and related PCI SSC guidance as of October 2026 and is not legal advice.