PCI DSS 4.0 is the most significant revision the payment card security standard has had in a decade. The transition window closed in March 2025 for most requirements, with a small set of future-dated requirements becoming mandatory in April 2025. By now, organisations subject to PCI DSS are expected to be operating against 4.0 — but a significant proportion still have gaps in the genuinely changed areas of the standard.
The Customised Approach: New Flexibility, New Discipline
PCI DSS 4.0 introduced the customised approach as an alternative to the defined approach. Under the customised approach, an entity can implement controls that meet the objective of a requirement using methods other than the defined controls — for example, alternative authentication mechanisms, novel data flow architectures, or controls that account for cloud-native deployment patterns. The flexibility is genuinely useful. The discipline required is significant: the entity must conduct and document a targeted risk analysis, define a customised approach for each applicable requirement, and demonstrate to the QSA how the alternative meets the objective.
Multi-Factor Authentication: Broader and Stricter
PCI DSS 4.0 expanded MFA requirements significantly. MFA is now required for all access into the cardholder data environment (CDE), not just remote access. The MFA requirements include resistance to replay attacks, system-driven enforcement, and at least two of the three factor categories (something you know, something you have, something you are) implemented independently. Programmes that previously deployed MFA only for VPN-style remote access have had to extend coverage substantially.
Authenticated Vulnerability Scans
Internal vulnerability scans must now use authenticated scanning. Unauthenticated scanning, the historical default, is no longer sufficient — it produces incomplete results that mask real vulnerabilities. Authenticated scanning requires credentials with sufficient privilege to inspect the configuration of each system. Operationally, this means coordinating credentials, scan accounts, network paths, and scan windows across the CDE in ways that previous scan programmes did not require.
A change that catches programmes by surprise: requirement 11.6 (formerly 11.6.1) now requires automated change-and-tamper detection for payment pages. The detection has to evaluate both the contents of the page and the headers. This addresses Magecart-style attacks where attackers inject JavaScript skimmers into checkout pages without changing the rendered output meaningfully. Most existing change-detection tools were not built for this — programme leads typically need to explicitly invest in tooling that meets the requirement.
Targeted Risk Analyses
Several requirements in 4.0 reference targeted risk analyses (TRAs) — formal documented risk analyses for specific decisions like password change frequency, training frequency, malware scanning frequency, and others. The TRA is not optional where the standard references it; it is the documented justification for the entity's specific implementation choice. Programmes that operate by analyst judgement rather than documented analysis tend to find this requirement disproportionately costly to retrofit.
Where Programmes Still Have Gaps
- Inventory of system components — many programmes still maintain partial inventories that miss recently added cloud services
- Customised approach documentation — used by exception, often without the rigorous risk analysis the standard requires
- MFA breadth — extended to remote access years ago, now needs extension to all CDE access
- Change-detection on payment pages — not yet implemented in many programmes that should have it
- Cryptographic algorithm and protocol documentation — clear inventories of what is in use are surprisingly rare
- Targeted risk analyses for the requirements that reference them — sometimes substituted by general risk register entries
How to Approach Closure
For programmes still working through 4.0 transition, the practical approach is gap-by-gap remediation prioritised by both compliance exposure and security value. Several of the new requirements (MFA expansion, authenticated scanning, change-and-tamper detection) deliver genuine security improvement, not just compliance optics. Programmes that lean into those changes and use 4.0 as the forcing function for capability uplift often emerge with materially stronger security posture rather than just a refreshed certification.