What is PCI DSS v4.0.1?

PCI DSS v4.0.1 is the June 2024 errata release to PCI DSS v4.0. It's not a new version of the standard — it's the same 12 high-level requirements and the same overall structure as v4.0 — but the PCI Security Standards Council made enough wording changes that v4.0 and v4.0.1 are formally separate documents. After 31 March 2025, v4.0 is retired and every assessment, every Self-Assessment Questionnaire, and every Report on Compliance has to be against v4.0.1. The big practical impact is that the future-dated requirements from v4.0 — including 6.4.3 (script inventory and integrity monitoring) and 11.6.1 (page-change detection) — are now mandatory and being assessed at the same time as the v4.0.1 wording is being used.

If you're new to the v4 family, start with the broader PCI DSS v4.0 explainer. This page is for merchants and service providers who already passed v4.0 and need to know what v4.0.1 actually changed, and for anyone whose QSA has just told them the assessment they're about to start will be on v4.0.1.

Why a 4.0.1 at all?

PCI DSS v4.0 was published in March 2022 with a long transition window. The first wave of mandatory requirements kicked in on 31 March 2024 (when v3.2.1 retired). A second wave — the "future-dated" requirements — was deferred until 31 March 2025 to give merchants and service providers time to build the new controls (script management, page-change detection, automated log review, stronger MFA).

Between March 2022 and June 2024, the PCI Council collected feedback from QSAs, ISAs, and participating organisations on places where the v4.0 wording was ambiguous, internally inconsistent, or had unintended consequences. The cleanup was published as v4.0.1 in June 2024, with a nine-month overlap window (June 2024 to 31 March 2025) where either v4.0 or v4.0.1 could be used for an assessment. After the deadline, only v4.0.1.

The Council was explicit: v4.0.1 introduces no new requirements. Every requirement in v4.0.1 was already in v4.0. What changed is how some of them are written.

What actually changed between v4.0 and v4.0.1

There are roughly 60 individual edits in the v4.0.1 document compared to v4.0, ranging from typo fixes to substantive clarifications. The ones that matter most in practice:

Multi-factor authentication (Requirement 8)

Several MFA requirements had wording that read like an absolute prohibition on certain authentication factors, when the Council's intent was "can't be the only factor." v4.0.1 reworded those to make it clear that, for example, knowledge-based factors are still allowed as one factor in an MFA combination — you just can't use two knowledge factors to satisfy the MFA requirement. The applicability notes around MFA for administrative access (8.4.2) and MFA into the cardholder data environment (8.4.3) were also tightened.

Requirement 6.4.3 — script management

6.4.3 is the rule that says every script loaded on a public-facing payment page (the page where the cardholder enters card data) has to be in an inventory with a documented business reason, must be authorised before being loaded, and must have its integrity assured. v4.0.1 clarified two things: which pages count as "payment pages" (the page that captures or transmits cardholder data, including iframe content that does so), and what "integrity assured" means in practice (a documented mechanism that detects unauthorised changes — Subresource Integrity hashes, a tag manager allowlist, or a content-security-policy script-src enforcement plus a monitoring control).

This is the requirement that lit a fire under retailers running heavy analytics and chat-widget stacks on their checkout pages, because every Google Tag Manager script, every chat widget, every A/B testing snippet is in scope.

Requirement 11.6.1 — change-and-tamper detection

11.6.1 is the companion to 6.4.3. It requires merchants to detect unauthorised changes to the HTTP headers and the script content of their payment pages, with alerts on change, at a frequency defined by a targeted risk analysis (but at minimum once every seven days). v4.0.1 clarified what "HTTP headers" means in scope (the headers that affect security — CSP, X-Frame-Options, HSTS, etc., not Content-Length) and confirmed that a manual periodic review doesn't satisfy 11.6.1 — it has to be a mechanism that detects changes and generates an alert.

Smaller clarifications

• Requirement 3.5.1 (rendering PAN unreadable) had its acceptable methods list tightened.
• Requirement 12.5.2 (annual scope confirmation) gained an explicit reference to what counts as "significant change" and triggers an interim scope review.
• The Customised Approach Objectives appendix was edited for several requirements to remove circular language.
• Multiple footnotes and applicability notes were corrected to refer to the right cross-referenced requirements.

If you passed v4.0, do you need to re-attest under v4.0.1?

Yes. PCI DSS attestations are dated against a specific version of the standard. An attestation that says "PCI DSS v4.0" is valid for the assessment period it covers, but the next annual assessment after 31 March 2025 has to be against v4.0.1. The SAQs (the self-assessment questionnaires for merchants who don't need a full QSA-led assessment) have all been updated to v4.0.1 versions.

For most merchants the re-attestation is straightforward because v4.0.1 didn't add anything — you're answering the same control questions with slightly different wording. The real work, where it exists, is in actually implementing 6.4.3 and 11.6.1 (which became mandatory at the same March 2025 deadline regardless of the version transition) and being able to evidence those controls during the new assessment.

Acquirer and brand timelines

Card brands and acquirers set their own deadlines on top of the PCI Council's deadlines. Visa, Mastercard, and Amex all aligned with the 31 March 2025 deadline for v4.0.1 adoption. Some acquirers gave their merchants a short additional grace period during 2025 for the new attestation document to be submitted, but the underlying controls had to be in place from 31 March 2025 regardless of when the paperwork was filed.

If your acquirer or QSA is still asking for v4.0 documents in 2026, that's a process gap on their side — push back and ask for the v4.0.1 SAQs and AOCs.

What v4.0.1 didn't change

The 12 high-level requirements are unchanged. The defined approach and the customised approach are both unchanged. The Self-Assessment Questionnaire types (A, A-EP, B, B-IP, C, C-VT, D-MER, D-SP, SPoC, P2PE) are unchanged. The validation requirements based on merchant level (1 through 4) are unchanged. The list of approved scanning vendors, qualified security assessors, and PCI-listed payment applications is unchanged. If you understood v4.0, you understand v4.0.1 — the differences are in the document, not the standard's structure.