Vigilant
Just explore Start now

Payments Glossary · Risk & Compliance

PCI DSS 4.0.1

Also called PCI DSS v4.0.1, PCI 4.0

The current version of the card data security standard, whose future-dated requirements became mandatory on March 31, 2025.

What it is

PCI DSS v4.0 was published in 2022 with an unusual structure: dozens of new requirements were designated best practice until a future date, giving merchants and service providers a runway. Version 4.0.1, a limited revision published in 2024, corrected and clarified v4.0 without changing its deadlines. Version 3.2.1 retired March 31, 2024. The date that matters is March 31, 2025. On that date the future-dated requirements stopped being optional and became mandatory, applying to any assessment performed on or after April 1, 2025. There is no further grace period and no small-merchant carve-out from the standard itself, though the applicable questionnaire determines which requirements you validate against. For small merchants, two of the new requirements dominate: 6.4.3, which requires you to inventory, justify and authorize every script running on your payment page and assure its integrity, and 11.6.1, which requires a change and tamper detection mechanism that alerts on unauthorized modification of payment page content and HTTP headers, evaluated at least weekly. Both exist because of Magecart-style skimming, in which malicious JavaScript is injected through a third-party tag and lifts card data in the customer's browser before it ever reaches the processor. Version 4.0.1 also brought a consequential change to SAQ A eligibility. The Council removed 6.4.3, 11.6.1 and the related targeted risk analysis from SAQ A itself, but added an eligibility criterion requiring the merchant to confirm that its site is not susceptible to script-based attacks affecting its e-commerce systems.

Why it matters to your business

If you sell anything online, the March 31, 2025 date already passed and your answers on this year's questionnaire have to reflect it. The honest first step is not buying software; it is finding out whether your checkout is a redirect or an embedded form, because that single fact determines whether you owe anything new at all. This is education, not legal advice. Your validation obligations come from your acquirer and your specific environment; confirm them with your processor and, where a breach or contractual liability is in play, with counsel.

Where it gets contested

The industry argument is about scope creep versus reality. Vendors selling client-side monitoring have an obvious interest in a broad reading of 6.4.3 and 11.6.1. Merchants and some assessors argue that a small shop with a fully redirected checkout page has no meaningful script-injection exposure and should not be sold a monitoring subscription. The Council largely settled the boundary through FAQ 1588 and the revised SAQ A eligibility language, but the practical dispute persists because the answer depends on an architectural detail most merchants cannot self-diagnose: whether their checkout uses a full redirect, an embedded iframe with hosted fields, or a form on their own page. Many merchants have been told they are fully outsourced when they are not. The gray area is enforcement. Nobody audits a Level 4 merchant's payment page weekly. The requirement is real, the validation path is real, and the practical consequence usually only arrives after a breach, when the forensic investigator asks what integrity controls existed.

How to check it yourself

Open your own checkout page, right-click, choose view page source, and search for iframe. If the card fields sit inside an iframe served by your processor, you are in the embedded category and need either the script controls or a written attestation from your processor. If clicking pay sends the customer to a different domain entirely, you are on a full redirect and the new script criterion does not apply to you.

Receipts

Claims above that are checkable, with where to check them. Published so you do not have to take anyone's word for it.