On this page
PCI DSS 4.0.1 is the current, and only active, version of the Payment Card Industry Data Security Standard. Version 4.0, published in March 2022, added 64 new requirements. Version 4.0.1, published in June 2024, clarified the text without adding any. v3.2.1 was retired on 31 March 2024, and the 51 future-dated requirements became mandatory on 31 March 2025.
Looking for the standard itself? Get PCI DSS v4.0.1, the official Summary of Changes and every SAQ free from the PCI SSC document library.
This guide sets out the key dates, what changed in v4.0 and v4.0.1, and a tracker of the future-dated requirements so you can confirm each one is working. A common gap is an organisation that updated its documents but not its controls.
Key takeaways
- v4.0.1 is the only active version, and all future-dated requirements have been mandatory since 31 March 2025.
- MFA now applies to all non-console access into the cardholder data environment, not just admin and remote access.
- E-commerce merchants must control and monitor scripts on payment pages, unless eligible for SAQ A.
- Targeted risk analyses now justify how often many controls run, and they must be documented.
- Evidence must show controls operating throughout the year, not just on assessment day.
When did PCI DSS 4.0 become mandatory?
| Date | What happened |
|---|---|
| March 2022 | PCI DSS v4.0 published |
| 31 March 2024 | v3.2.1 retired; all assessments move to v4.0 |
| June 2024 | v4.0.1 published (clarifications and corrections) |
| 31 December 2024 | v4.0 retired; v4.0.1 becomes the only active version |
| January 2025 | SAQ A revised: 6.4.3 and 11.6.1 removed, script-attack eligibility criterion added |
| 31 March 2025 | The 51 future-dated requirements become mandatory |
What’s new in PCI DSS 4.0?
v4.0 was the biggest revision of the standard in over a decade. The main themes:
- Objectives, not just rules. Every requirement now states its purpose, and the customised approach lets mature organisations meet that objective with a different control, validated by a QSA.
- Targeted risk analysis. Where the standard lets you choose how often a control runs, you must document why that frequency is right (12.3.1).
- Stronger authentication. MFA for all non-console access into the cardholder data environment (8.4.2), passwords of at least 12 characters (8.3.6) and tighter control of system accounts (8.6). Our guide to PCI DSS Requirement 8 explains each one.
- E-commerce skimming. Payment page scripts must be authorised and inventoried (6.4.3), with tamper detection on payment pages (11.6.1).
- Phishing. Automated anti-phishing controls (5.4.1) and training that covers phishing and social engineering (12.6.3.1).
- Network security controls. “Firewalls and routers” became network security controls, covering cloud security groups and other traffic-filtering technology. Our guide to PCI DSS firewall requirements explains the new Requirement 1.
- Continuous compliance. Roles and responsibilities for every requirement, and scope confirmed at least every 12 months (12.5.2).
For a walk through all 12 requirements as they now stand, see our guide to the PCI DSS requirements.
What changed in PCI DSS 4.0.1?
v4.0.1 is a limited revision. It corrected formatting and typographical errors, clarified wording, guidance and applicability notes, and added no new requirements. Two changes matter most in practice:
- Patching (6.3.3) reverted to the v3.2.1 position: critical vulnerabilities must be patched within one month of release, with other patches applied within an appropriate timeframe based on your risk ranking.
- Payment page scripts (6.4.3 and 11.6.1) gained clarifications on how they apply to pages that embed a provider’s payment form.
If your policies still quote v4.0 wording, update them. Assessors test against v4.0.1.
PCI DSS future-dated requirements tracker
All of these have been mandatory since 31 March 2025. Use the Done? box for each requirement to track your own status, or download the tracker as a free spreadsheet (.xlsx) with columns for whether each requirement applies to you, its owner, the evidence and its status.
| Requirement | What it requires | Applies to | Done? |
|---|---|---|---|
| 3.4.2 | Technical controls stop PAN being copied or moved over remote access unless authorised | All | ☐ |
| 3.5.1.1 | Hashes of PAN are keyed cryptographic hashes | All | ☐ |
| 3.5.1.2 | Disk-level encryption alone is used only for removable media | All | ☐ |
| 4.2.1 / 4.2.1.1 | Certificates for PAN in transit confirmed valid; inventory of trusted keys and certificates | All | ☐ |
| 5.3.3 | Anti-malware scans removable media, or analyses behaviour continuously | All | ☐ |
| 5.4.1 | Automated mechanisms detect and protect against phishing | All | ☐ |
| 6.3.2 | Inventory of bespoke and custom software and its third-party components | All | ☐ |
| 6.4.2 | Automated solution (such as a WAF) protects public-facing web applications | All | ☐ |
| 6.4.3 | Payment page scripts authorised, integrity-checked and inventoried | E-commerce (not SAQ A) | ☐ |
| 7.2.4 | User accounts and privileges reviewed every six months | All | ☐ |
| 7.2.5 / 7.2.5.1 | System and application accounts on least privilege, reviewed periodically | All | ☐ |
| 8.3.6 | Passwords at least 12 characters (8 if the system cannot support 12) | All | ☐ |
| 8.4.2 | MFA for all non-console access into the CDE | All | ☐ |
| 8.5.1 | MFA resists replay attacks and cannot be bypassed | All | ☐ |
| 8.6.1 to 8.6.3 | Interactive use of system accounts controlled; no hard-coded passwords | All | ☐ |
| 10.4.1.1 | Automated mechanisms perform audit log reviews | All | ☐ |
| 10.7.2 | Failures of critical security controls detected and alerted | All (previously service providers only) | ☐ |
| 11.3.1.1 | Lower-risk vulnerabilities managed on a risk-based schedule | All | ☐ |
| 11.3.1.2 | Internal vulnerability scans are authenticated | All | ☐ |
| 11.4.7 | Support customers’ external penetration testing | Multi-tenant service providers | ☐ |
| 11.5.1.1 | Detect covert malware communication channels | Service providers | ☐ |
| 11.6.1 | Change and tamper detection on payment pages, at least weekly | E-commerce (not SAQ A) | ☐ |
| 12.3.1 | Targeted risk analysis for each flexible-frequency requirement | All | ☐ |
| 12.3.3 / 12.3.4 | Annual review of cipher suites, protocols and end-of-life technology | All | ☐ |
| 12.5.2.1 | Scope confirmed every six months and after significant change | Service providers | ☐ |
| 12.6.3.1 / 12.6.3.2 | Training covers phishing, social engineering and acceptable use | All | ☐ |
| 12.10.7 | Incident response triggered if PAN is found where it should not be | All | ☐ |
For the full standard as a checkable list, with the evidence assessors ask for, use our PCI compliance checklist.
Which v4.0.1 changes cause the most findings?
The same themes come up again and again in v4.0.1 assessments:
- MFA gaps. MFA on remote access but not on internal non-console access into the CDE, such as administrator or support sessions from the corporate network or through jump hosts.
- Script inventories. A list of payment page scripts with no justification or integrity check, and no one owning it across development and marketing.
- Unauthenticated scanning. Internal scans still run without credentials. Our vulnerability scanning services cover authenticated internal scans, and external ASV scans are delivered through our PCI SSC Approved Scanning Vendor partner.
- Risk analyses with no reasoning. A frequency chosen without a documented targeted risk analysis will not be accepted.
- Point-in-time evidence. A screenshot shows a setting exists. Logs, tickets and review records show it operated all year.
Service providers should also check segmentation testing every six months and the multi-tenant testing obligation. Our PCI DSS penetration testing covers Requirement 11.4 in full.
Defined or customised approach?
The defined approach is the traditional method: implement the control as written and the assessor follows the standard testing procedures. It suits most organisations and is the only option when validating with an SAQ.
The customised approach lets you meet a requirement’s objective with a different control. You need a controls matrix and a targeted risk analysis for each one (12.3.2), and your QSA must design specific testing. It needs more documentation and assessor time, so most organisations use it, if at all, for only a few requirements.
Does PCI DSS 4.0.1 change the SAQs?
Yes. Every SAQ was updated for v4.0.1, and SAQ A was revised again in January 2025. If you self-assess, re-check your eligibility with our guide to which PCI SAQ you need or our free PCI compliance check before your next submission.
How Sovereign Secure can help
If you have not compared your environment with the full v4.0.1 requirements, a gap analysis is the quickest way to find out where you stand. Our PCI DSS consultancy runs v4.0.1 gap analyses and remediation plans (our gap analysis guide explains the process), and as a PCI SSC-approved QSA company we carry out the PCI compliance audit that follows, from SAQ support to Report on Compliance.
Your next step
- PCI compliance checkAnswer 22 questions for a readiness score, your likely SAQ and a fix list.Start the free check
- PCI DSS document indexThe policies, procedures and records each PCI DSS requirement needs, as a free spreadsheet.Get the document index
- Get a PCI quoteTell us how you take card payments and we will confirm your validation route and scope.Get a PCI quote
