PCI DSS 4.0.1: what changed and what small merchants must do
PCI DSS 4.0.1 added no new requirements; it is a clarifying revision of 4.0, which it replaced at the end of 2024. What changed for small merchants is that the requirements 4.0 had marked as future-dated became mandatory after 31 March 2025, most visibly the controls on scripts running on payment pages. And SAQ A was revised: a merchant that embeds a provider’s payment form must now confirm its site is not open to script attacks.
What did PCI DSS 4.0.1 change?
PCI SSC published 4.0.1 in June 2024 as a limited revision with no additional or deleted requirements. Version 4.0 was retired on 31 December 2024, and the revision did not move the 31 March 2025 date for the new requirements. If your last self-assessment predates that date, the next one is the first that tests whichever of them your SAQ includes. SAQ A treats the payment page script requirements differently; see below.
Which SAQ applies to you?
A self-assessment questionnaire (SAQ) is chosen by how card data moves, not by how big you are. The common ones for small merchants:
| SAQ | Fits when |
|---|---|
| A | Card-not-present only, all card processing outsourced to a PCI DSS compliant provider, and no card data stored, processed or transmitted electronically on your systems |
| A-EP | E-commerce only, payment partly outsourced; your site does not receive card data itself but can affect the security of the payment transaction or the page that takes the card |
| B-IP | Only standalone, PCI-listed payment terminals connected to your processor over IP, and not connected to any other system in your environment |
| D | You may self-assess but fit no other SAQ |
Do small merchants have to comply at all? Yes. PCI DSS applies to every organization involved in card payments, whatever its size. Whether and how a small merchant has to validate compliance is set by the payment brands and your acquirer, so your acquirer is the first call.
What do 6.4.3 and 11.6.1 require on a payment page?
Both requirements target e-skimming: a script injected into a checkout page that copies card numbers as customers type them.
- 6.4.3 — keep an inventory of every script on the payment page, with a written reason for each, confirm each is authorized, and assure its integrity.
- 11.6.1 — run a mechanism that alerts on unauthorized changes to security-impacting HTTP headers and script contents of the payment page, as the customer’s browser receives them.
PCI SSC’s guidance is its information supplement Payment Page Security and Preventing E-Skimming.
Who does the SAQ A change affect?
In January 2025 PCI SSC removed 6.4.3, 11.6.1 and the supporting risk analysis (12.3.1) from SAQ A, and added an eligibility criterion, which is still the position as of September 2026: the merchant has confirmed its site is “not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
Does the criterion reach a merchant that redirects to its processor? No. PCI SSC has clarified that the new criterion applies only to pages that embed a provider’s payment form, for example in an iframe. A redirect to the provider’s own page, or an emailed payment link, is outside it. Under FAQ 1588, an iframe merchant can confirm it either by applying techniques like those in 6.4.3 and 11.6.1, or by obtaining confirmation from its PCI DSS compliant provider that the provider’s solution, implemented to their instructions, protects the page.
The myth to drop: SAQ A does not make scripts irrelevant. In the same post, PCI SSC states the change does not remove or diminish the underlying requirements. For most small merchants the practical route is the provider’s written confirmation, an integration that follows their instructions exactly, and both kept with the SAQ.
What should a small merchant do first?
- Ask your acquirer what validation they require and which SAQ they expect.
- Draw every way a card reaches you: website, phone, terminal, email.
- Remove card data from your own systems wherever a provider can hold it instead. Scope you do not have is scope you do not defend.
- For an embedded form, get the provider’s confirmation or put script controls in place.
- Keep the evidence: each provider’s proof of PCI DSS compliance, the confirmation, and a dated diagram.
Assessing a payment provider is ordinary supplier due diligence, covered in vendor risk questionnaires that work; if you ever find a skimmer, start with the first 24 hours of an incident.
Who signs off on PCI compliance?
Can we sign it off for you? No. You sign your own self-assessment questionnaire, and a Report on Compliance comes from an assessor qualified or trained by the PCI Security Standards Council, such as a Qualified Security Assessor. We help you get ready for either: scope, evidence and the gaps. Readiness for payment and other regulated obligations is our regulated-sector readiness work.
How the work is bounded
The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.
SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.
Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.
Questions we are asked
Did PCI DSS 4.0.1 add new requirements?
No. PCI DSS 4.0.1 is a limited revision that corrected and clarified 4.0 without adding or deleting requirements. The change merchants actually feel is that the future-dated requirements in 4.0 became mandatory after 31 March 2025.
Does the SAQ A script criterion apply if we redirect to our processor?
No. PCI SSC has clarified that the new criterion applies only to pages that embed a provider’s payment form, for example in an iframe. A redirect to the provider’s own page, or an emailed payment link, is outside it.
Do small merchants have to comply at all?
Yes. PCI DSS applies to every organization involved in card payments, whatever its size. Whether and how a small merchant has to validate compliance is set by the payment brands and your acquirer, so your acquirer is the first call.
Can you assess or sign off our PCI compliance?
No. You sign your own self-assessment questionnaire, and a Report on Compliance comes from an assessor qualified or trained by the PCI Security Standards Council, such as a Qualified Security Assessor. We help you get ready for either: scope, evidence and the gaps.
Getting your SAQ right
Send us how you take payments and what your acquirer asked for. The reply says which SAQ fits and what is missing. More of our writing is indexed at writing.