PCI DSS 4.0 was published in March 2022, with a transition period that ended in 2024 for the baseline change and a longer runway for the more substantial future-dated requirements that became mandatory in March 2025. The transition is now behind organisations that handle cardholder data — and many discovered that the standard is meaningfully different from 3.2.1 in ways that go beyond the version number. The standard increased its flexibility while raising the technical bar, and the assessments that genuinely demonstrate compliance look different from the ones that satisfied 3.2.1.
The Customised Approach
Version 4.0 introduced a second compliance path alongside the traditional defined approach: the customised approach, which allows organisations to demonstrate that they meet the security objective of a requirement through controls that differ from the defined implementation. The customised approach requires a documented controls matrix, a targeted risk analysis, and validation by the QSA — meaningfully more documentation than the defined approach for any requirement to which it is applied. Used selectively, the customised approach lets mature organisations replace prescriptive controls that fit poorly in their environment with controls that achieve the same objective in a way that works. Used broadly, it produces more work than the defined approach saves.
Targeted Risk Analysis as a Recurring Activity
Several 4.0 requirements ask entities to define the frequency of an activity based on a targeted risk analysis rather than against a fixed cadence. Antivirus scanning, log review frequency, vulnerability scanning intervals, and several others moved from prescriptive cadences to risk-based ones. The flexibility is genuine — a low-risk system can be assessed less frequently than a high-risk one — but each cadence decision must be documented in a targeted risk analysis that the QSA will sample. Entities that read this change as "we can do less" missed the documentation obligation that came with the flexibility.
Future-Dated Requirements That Are Now Live
The future-dated requirements that became enforceable in March 2025 are the substantive technical changes that justify the version increment. Multi-factor authentication for all access into the cardholder data environment (not just remote access). Specific anti-phishing technical controls. Authenticated internal vulnerability scanning. E-commerce payment page integrity monitoring to detect skimmer injection (a direct response to the Magecart-style attacks of the late 2010s). A more rigorous approach to encryption and certificate management. Each individual requirement is reasonable; collectively they are a substantial implementation programme that benefited from the multi-year runway.
A pattern we see in PCI DSS 4.0 readiness work: the entity addressed the headline future-dated requirements (MFA, anti-phishing controls, payment page integrity monitoring) and underestimated the volume of targeted risk analyses required across the standard. The first 4.0 assessment surfaces the gap when the QSA samples cadence decisions and asks for the underlying risk analysis. Build the targeted risk analysis discipline into the programme from the start — they are recurring artefacts, not one-off documents.
Scope Reduction as the High-Leverage Investment
The single most consequential PCI DSS decision is what is in scope. Every system that stores, processes, or transmits cardholder data — and every system connected to one — is in scope. Reducing scope through tokenisation, network segmentation, hosted payment pages, and offloading to PCI-validated providers is the single largest lever for reducing assessment cost and security risk simultaneously. The 4.0 changes increase the cost of an in-scope system substantially; scope reduction projects that were borderline economic under 3.2.1 are clearly economic under 4.0.
A 4.0 Readiness Programme
- Document the current scope precisely — every CDE system and every connected system
- Identify scope reduction opportunities through tokenisation, segmentation, or service provider offload
- Implement the future-dated technical requirements and validate them against the requirement text, not the bullet summary
- Decide where to use the customised approach and document the controls matrices and risk analyses
- Build the targeted risk analysis production line — these are recurring artefacts across many requirements
- Engage the QSA early on customised approach decisions so the documentation expectations are clear before the assessment
- Validate the e-commerce payment page integrity monitoring against representative threat scenarios, not just configuration
The Strategic Lens
PCI DSS 4.0 is, for the merchants and service providers it applies to, the most operationally consequential security standard they face annually. The QSA assessment is rigorous, the brand mandates are enforceable, and the reputational and financial cost of a breach involving cardholder data is severe. Treating 4.0 transition as a project that ends with assessment is the wrong mental model — the standard is a continuous operational discipline, and the entities that integrate it into their operating rhythm rather than mobilising annually for assessment produce better security outcomes for less total effort.