PCI DSS v4.0.1: what changed, what became mandatory in March 2025, and SAQ or ROC

Version 4.0 replaced 3.2.1 in March 2022. The Council’s own summary of its intent was four things: meeting evolving threats, treating security as a continuous process rather than an annual event, giving organisations more flexibility in how they meet objectives, and strengthening how compliance is validated.

Some of that shows in vocabulary. "Firewall" became "network security controls", to cover the range of technologies now doing that job. Some shows in substance: Requirement 8 was expanded so that multi-factor authentication covers all non-console access into the cardholder data environment (8.4.2), not only administrative access. And some shows in method — targeted risk analyses let an organisation justify, in writing, how often it performs certain activities rather than inheriting a fixed frequency.

By the Council’s own count, version 4 also added 64 new requirements. Thirteen took effect immediately. The other 51 were future-dated: written into the standard in March 2022 as best practice, so organisations had time to build them, with a fixed date after which they would be assessed like everything else.

Version 4.0.1, published in June 2024, is a limited revision. It corrects errors, clarifies intent and adds guidance; it adds and removes no requirements, and the Council stated plainly that it did not move the 31 March 2025 effective date.

Three of its clarifications are worth knowing. It restored the v3.2.1 position that the one-month patching window in Requirement 6.3.3 applies to patches for critical vulnerabilities, removing the v4.0 wording that had extended it to high-security patches. It added applicability notes on how the payment page script requirement applies. And it clarified that multi-factor authentication for non-administrative access into the cardholder data environment does not apply to accounts authenticated only with phishing-resistant factors.

Version 4.0 was retired on 31 December 2024, so any assessment today is against v4.0.1.

Each one is marked in the standard itself with the same note: a best practice until 31 March 2025, after which it will be required and must be fully considered during an assessment. The ones the Council has singled out in public guidance are the e-commerce requirements, so they come first here.

Requirement 6.4.3 deals with the scripts that run on a payment page, so that each one is authorised and its integrity checked. Requirement 11.6.1 deals with detecting tampering and unauthorised changes to the payment page. Requirement 12.3.1, the targeted risk analysis, exists in this context to support 11.6.1. The Council describes these as its answer to e-skimming, where attackers inject code into the scripts running in the shopper’s browser.

Beyond e-commerce, the future-dated set reaches most organisations directly. Requirement 5.4.1 asks for processes and automated mechanisms that detect and protect personnel against phishing. Requirement 8.3.6 sets a minimum password length of 12 characters, or eight where a system cannot support twelve. Requirement 8.4.2 requires multi-factor authentication for all non-console access into the cardholder data environment. Requirement 10.4.1.1 requires automated mechanisms for audit log review. Requirement 3.4.2 requires technical controls that stop PAN being copied or relocated over remote-access technologies without documented authorisation. And for service providers, Requirement 12.5.2.1 requires scope to be confirmed every six months rather than every twelve.

Two things follow for anyone who validated against 3.2.1 or early v4.0. First, these are no longer graded as best practice: an assessment after 31 March 2025 must fully consider them, and a gap is a gap. Second, many of them are operational — they need a cadence and evidence across time — so the work is not finished by writing a policy.

There are two ways to validate. A Self-Assessment Questionnaire is completed by the organisation itself, in one of several versions matched to how it accepts cards. A Report on Compliance is the output of an assessment by a Qualified Security Assessor — or, where the card brand permits, by the organisation’s own PCI SSC-certified Internal Security Assessor. Each route ends in an Attestation of Compliance.

Which route applies is not your choice, and it is not the Council’s either. The Council is explicit that it does not set validation requirements; the card brands and acquirers do. Mastercard, for example, requires its Level 1 merchants to complete an annual assessment resulting in a Report on Compliance, and accepts a QSA or a PCI SSC-certified ISA for it. Visa sets merchant levels by a merchant’s total Visa transaction volume over twelve months. Your acquirer will tell you which applies to you.

For merchants on the shortest questionnaire, SAQ A, two things changed. Version 4 brought quarterly external scans by an Approved Scanning Vendor into SAQ A for the first time. And the January 2025 revision removed 6.4.3, 11.6.1 and 12.3.1 from SAQ A, replacing them with an eligibility criterion: the merchant must confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The Council was clear that this changes how SAQ A merchants report, not what the standard requires.

Start with your acquirer. Confirm your merchant or service provider level and the validation document they expect, because a Report on Compliance and an SAQ are different projects.

Then scope honestly and as small as the facts allow. Every system that stores, processes or transmits account data — and every system connected to or able to affect them — is in scope, and version 4 requires that scope to be confirmed at least once a year. Segmentation and outsourcing are the levers that reduce it.

Finally, treat the future-dated requirements as the operational work they are. Payment page script authorisation, tamper detection on payment pages, targeted risk analyses and quarterly ASV scans all need a record that runs across time. An assessor samples that record; it cannot be reconstructed the month before.