Why PCI DSS v4.0 matters in 2026
PCI DSS v3.2.1 was retired on 31 March 2025. From that point, v4.0 is the only version accepted for compliance validation. If you store, process, or transmit cardholder data — or if you could affect the security of cardholder data — you need to be v4.0 compliant.
The stakes are significant: card brand fines range from $5,000 to $100,000 per month for non-compliant merchants, acquirers can pass on chargebacks from breaches, and a compromise of cardholder data can trigger forensic investigation costs, notification obligations, and reputational damage that far exceeds the fine itself.
This guide covers how to conduct a PCI DSS v4.0 gap assessment across all 12 requirements, explains the four changes introduced in v4.0, and describes what QSAs actually look for when validating your compliance.
Who PCI DSS applies to
PCI DSS applies to any organisation that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD), or that could affect the security of the cardholder data environment (CDE). This includes:
- Merchants who accept payment cards (classified into Levels 1–4 by annual transaction volume)
- Service providers who provide services that could affect the security of cardholder data (classified into Levels 1–2)
- SaaS companies whose platforms process payments or whose infrastructure hosts components that handle CHD
Your entity type and level determines your compliance validation path: a self-assessment questionnaire (SAQ) for most merchants, a Report on Compliance (RoC) conducted by a Qualified Security Assessor (QSA) for Level 1 merchants and Level 1 service providers.
The 12 PCI DSS v4.0 requirement groups
PCI DSS v4.0 organises its requirements into 12 groups across 6 goals:
| Goal | Requirement | Group |
|---|---|---|
| Build and Maintain a Secure Network | Req 1 | Network security controls (NSCs) configured and maintained |
| Req 2 | Secure configurations applied to all system components | |
| Protect Account Data | Req 3 | Stored account data protected |
| Req 4 | Cardholder data protected during transmission over open/public networks | |
| Maintain a Vulnerability Management Programme | Req 5 | All systems and networks protected from malicious software |
| Req 6 | Secure systems and software developed and maintained | |
| Implement Strong Access Control Measures | Req 7 | Access restricted based on business need to know |
| Req 8 | Users identified and authenticated before accessing system components | |
| Req 9 | Physical access to cardholder data restricted | |
| Regularly Monitor and Test Networks | Req 10 | All access to system components and cardholder data logged and monitored |
| Req 11 | Security of systems and networks tested regularly | |
| Support Information Security Policy | Req 12 | Organisational security supported by policies and programmes |
The four key changes in PCI DSS v4.0
While v4.0 contains hundreds of clarifications and refinements compared to v3.2.1, four changes have the most practical impact on SaaS companies:
1. Req 8.4 — MFA now required for all access into the CDE (not just remote)
In v3.2.1, multi-factor authentication was required for remote access and for administrators accessing the CDE. In v4.0, MFA is required for all access to the CDE — including local console access for anyone who manages system components in the CDE.
Practical impact: if you have developers, DBAs, or ops staff who access CDE systems from within your internal network (not just remotely), they now need MFA too. Cloud console access, SSH to CDE servers, database admin tools — all require MFA under Req 8.4.
The QSA will review your access control system configuration, sample workforce members, and verify MFA is enforced at the technical layer (not just policy).
2. Req 6.4.3 — Payment page scripts must be managed and authorised
This is one of the most significant new requirements for e-commerce merchants. Every script running on a consumer-facing payment page must be: inventoried, authorised, with its integrity verified, and its reason for use documented.
This targets JavaScript skimming attacks (Magecart-style) where attackers inject malicious JavaScript into checkout pages to steal card numbers. The requirement applies to all scripts on the payment page — your own code, third-party libraries, analytics, chat widgets, A/B testing tools, and CDN-loaded resources.
QSAs will ask for your script inventory, the method you use to verify integrity (Content Security Policy, Subresource Integrity hashes, or a third-party monitoring tool), and evidence of your change management process for adding new scripts.
3. Req 11.6.1 — Payment page change/tamper detection required weekly
Closely related to Req 6.4.3, this requires a mechanism to detect unauthorised modification of HTTP headers and payment page content as received by the consumer browser. The mechanism must be evaluated at least weekly.
This is designed to catch Magecart and similar attacks where code is injected at the CDN, third-party script, or network level rather than in your application code. Tools like Feroot, PerimeterX, or PCI-specialist monitoring services address this requirement. Note that this is not just about scanning your origin server — it's about detecting what's actually delivered to end users.
4. Req 5.4 — Protection from phishing attacks
v4.0 adds an explicit requirement to implement controls to protect personnel against phishing attacks. This includes anti-phishing technical controls (email filtering, DNS filtering, domain impersonation monitoring) and security awareness training that specifically covers phishing.
This wasn't an explicit requirement in v3.2.1 — it was implied under security awareness and vulnerability management. Now it's a standalone requirement with specific implementation expectations.
How to conduct a PCI DSS v4.0 gap assessment
A gap assessment is not a formal compliance validation (that's a SAQ or RoC). It's a structured self-assessment that identifies where your controls are compliant, partially compliant, or missing — so you can prioritise remediation before engaging a QSA.
Step 1: Define your CDE scope
The cardholder data environment is the people, processes, and technology that store, process, or transmit CHD — and any system that could affect the security of those systems. Scope reduction is critical: the smaller your CDE, the fewer requirements apply. Consider:
- Using a PCI-certified payment processor that handles all card data (you never see PANs)
- Tokenisation to replace CHD with tokens in your systems
- Network segmentation to isolate CDE components from other systems
Your gap assessment should document your CDE scope clearly — QSAs spend significant time validating that your scope is accurate.
Step 2: Work through all 12 requirement groups
For each requirement, assess whether your controls are In Place, Partially In Place, or Not In Place. Document evidence for in-place controls and gaps for anything that's not compliant. Key areas QSAs scrutinise most heavily:
- Req 3: Are you storing any cardholder data you don't need? Many companies retain more than they realise in logs and error dumps.
- Req 8: Is MFA enforced technically, not just by policy? QSAs will attempt to access CDE systems without MFA.
- Req 10: Are audit logs covering all required events? Log retention must be 12 months (3 months immediately available).
- Req 11: Are quarterly ASV scans actually clean? Are pen tests using an industry-accepted methodology?
- Req 12: Is your targeted risk analysis for each requirement documented? v4.0 requires a risk analysis before defining frequencies for each customisable requirement.
Step 3: Determine your SAQ type
Most merchants validate compliance via a Self-Assessment Questionnaire. Your SAQ type depends on how you process card payments:
- SAQ A: Fully outsourced card data functions — no cardholder data on your systems (e-commerce using an iframe/redirect to a PCI-certified processor). Fewest requirements.
- SAQ A-EP: E-commerce merchant, payment page partially outsourced but scripts run on your website (relevant for Req 6.4.3 and 11.6.1).
- SAQ D-Merchant: All other merchants — covers all 12 requirements.
- SAQ D-Service Provider: All service providers — covers all 12 requirements plus additional service provider obligations.
What QSAs look for in common areas
| Requirement | Most Common Findings | Evidence QSA Requests |
|---|---|---|
| Req 1 (Network Security) | Default-deny not enforced, IaC-managed rules without quarterly review, direct internet ingress to CDE | Firewall ruleset export, IaC templates, quarterly review records |
| Req 3 (Stored Data) | PANs in application logs, CHD in old backups, SAD retained post-authorisation | Data discovery scan results, retention policy, log samples |
| Req 6 (Secure Software) | Known CVEs unpatched, no WAF for public-facing apps, no script inventory for payment pages | Vulnerability scan results, WAF logs, script inventory and integrity evidence |
| Req 8 (Authentication) | Shared accounts in CDE, MFA not enforced locally (only for remote access), service accounts with weak credentials | IAM configuration export, MFA enforcement evidence, service account list |
| Req 10 (Logging) | Logs not covering all required events, log retention less than 12 months, no daily review | SIEM configuration, log retention settings, daily review records |
| Req 11 (Testing) | ASV scan failures not remediated, pen test scope too narrow (excludes CDE components), no FIM | ASV scan reports (clean), pen test report and methodology, FIM configuration |
| Req 12 (Policy) | Policies not updated for v4.0, TPSP agreements missing, IRP not tested annually | Policy versions and review dates, TPSP list with compliance confirmation, IRP test records |
Use our free PCI DSS v4.0 Gap Assessment Generator to work through all 12 requirements, get a gap report with QSA-ready evidence guidance, and a phased remediation roadmap. For related compliance areas, see the Vulnerability Management Policy Generator, Change Management Policy Generator, and Network Security Policy Generator.