PCI DSS 4.0.1: what changed and how to prepare

January 9, 2026

PCI DSS 4.0 (refined as 4.0.1) is the largest revision of the standard in a decade. Here is what actually changed, and a pragmatic order to tackle it.

From 3.2.1 to 4.0.1

PCI DSS 4.0 replaced 3.2.1 as the only active version after 31 March 2024, and 4.0.1 is a limited-correction release that clarifies wording without adding new requirements. If your program is still organized around 3.2.1 control language, the first task is structural: re-map your evidence to the 4.0.1 requirement numbering, because several requirements were split, merged, or re-scoped.

The headline shift is philosophical. 4.0.1 keeps the prescriptive "defined approach" you already know, but adds a parallel "customized approach" that lets a mature organization meet a requirement's stated objective using its own controls — provided it documents a targeted risk analysis and the assessor agrees.

The customized approach

Under the customized approach, you are not following the standard's test procedures verbatim; you are demonstrating that your alternative controls meet the requirement's "Customized Approach Objective." That demands more documentation, not less: a control matrix, evidence of effectiveness, and a targeted risk analysis for each requirement you customize.

For most teams the right call is to use the defined approach by default and reserve the customized approach for the handful of requirements where a modern control genuinely fits better than the prescriptive text.

Targeted risk analysis (Req 12.3.1)

Several 4.0.1 requirements let you set your own frequency for an activity — but only if you back it with a targeted risk analysis (TRA). A TRA documents the asset being protected, the threat, the likelihood and impact, and the justification for the frequency you chose. Anywhere the standard says "at a frequency defined in the entity's targeted risk analysis," you owe a TRA.

The future-dated requirements

A large block of 4.0 requirements were "best practice until 31 March 2025," at which point they became mandatory. If your last assessment treated them as optional, they are not optional anymore — items like automated log review, anti-phishing controls, and the inventory of scripts on payment pages all moved into force.

A pragmatic order to tackle it

• Re-map existing evidence to the 4.0.1 requirement numbering before anything else.
• Confirm your scope and cardholder-data environment in a versioned Scope Statement (Req 12.5).
• Write targeted risk analyses for every requirement that uses an entity-defined frequency.
• Treat all former future-dated requirements as in force and close the gaps.
• Decide, requirement by requirement, where the customized approach is worth the extra documentation.