SAQ A Got Stricter by Getting Shorter

The PCI Security Standards Council made SAQ A shorter and harder in the same revision. Its announcement lists the "Removal of PCI DSS Requirements 6.4.3 and 11.6.1 for payment page security, and Requirement 12.3.1 for a Targeted Risk Analysis to support Requirement 11.6.1," and in their place adds an eligibility criterion: merchants must "confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)." The Council's blog post dates the revised questionnaire to January 2025 and says "The SAQ A version that was published in October 2024 will be retired on 31 March 2025." A requirement is something you answer inside a questionnaire. A criterion is something you satisfy before you are allowed to use the questionnaire at all, and that is a different kind of obligation.

This article is the verbatim wording, who it applies to, the two ways the Council says you can meet it, and what did not change. For which questionnaire you should be filing in the first place, start with our PCI SAQ decision guide.

Key takeaways

• The Council removed 6.4.3, 11.6.1 and the 12.3.1 targeted risk analysis supporting 11.6.1 from SAQ A, and added an eligibility criterion in their place.
• The criterion in PCI DSS v4.0.1 SAQ A r1 reads: "The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."
• FAQ 1588 limits it to merchants with embedded payment pages or forms. It does not apply to merchants who redirect, or who link out to the payment page.
• You may satisfy it yourself using techniques such as those in 6.4.3 and 11.6.1, or by obtaining confirmation from your PCI DSS compliant processor that its embedded solution includes those protections.
• Nothing was removed from PCI DSS itself. 6.4.3 and 11.6.1 remain in the standard for entities whose validation includes them.

What the Council actually changed

Take the removal first, because it is the part that generated the headlines and the part that misleads.

Three items left the SAQ A document: Requirement 6.4.3, which governs the management of scripts loaded and executed on payment pages, Requirement 11.6.1, which governs detection of unauthorised changes to payment page content as received by the consumer browser, and Requirement 12.3.1, the targeted risk analysis that supported 11.6.1. All three had become mandatory on 31 March 2025 as part of the v4 future-dated set, which our guide to the v4 future-dated requirements walks through in full.

Then take the addition. In place of those questions, the questionnaire gained an eligibility criterion, and the Council's own FAQ quotes the v4.0.1 SAQ A r1 wording exactly: "The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."

The dates matter for anyone reconciling old paperwork. The revised questionnaire was published in January 2025. The October 2024 version was retired on 31 March 2025.

Why removing three requirements made the document stricter

Inside a questionnaire, a requirement has degrees. You can answer it "in place with a compensating control," you can answer it "not applicable" with a justification, and an assessor or an acquirer can discuss it with you. It sits within the document, and the document is your validation.

An eligibility criterion sits before the document. If you do not meet it, you are not an SAQ A merchant, and the questionnaire you completed is the wrong one. There is no partial credit and no compensating control for eligibility, because eligibility is the test for whether you may use this validation route at all. A merchant who fails it does not owe two more requirements; they owe a different and substantially heavier questionnaire, with the scanning obligations that come with it.

So the shorter document is the harder one. The reader who skimmed the announcement and concluded that payment page security had been relaxed for small merchants read it exactly backwards.

The line FAQ 1588 draws: iframes yes, redirects no

The Council maintains an FAQ, numbered 1588 and titled "How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?", specifically because the criterion does not apply to everyone using SAQ A.

It applies to merchants whose own page hosts an embedded payment page or form, which in practice means an iframe served by the processor. It does not apply to merchants who send the customer to the processor by an HTTP 30x redirect, a meta redirect or a JavaScript redirect, nor to merchants who have fully outsourced payment functions to a third-party service provider without embedding anything.

The reason is mechanical rather than bureaucratic, and it is a statement about where the card number gets typed rather than a statement that your page is safe. A redirect sends the customer to the processor before any card data is entered, so no script on your page is sitting between the customer and the card number at the moment it is typed. An iframe keeps the customer on your page throughout. The script cannot read inside the frame, but it can rewrite the page around it, overlay it, replace it, or move the customer somewhere else entirely, which is how payment page skimming actually works. The criterion exists because the surrounding page is still yours.

Be careful with the inverse reading, because it is the one that gets merchants hurt. A compromised redirect page is still a compromised page. A script that runs there can change where the redirect points, or draw a convincing card form of its own before the customer ever leaves. What FAQ 1588 tells a redirect merchant is that this eligibility criterion is not part of their questionnaire. It does not tell them their checkout cannot be attacked, and 6.4.3 and 11.6.1 remain in PCI DSS for entities whose validation type includes them.

If your checkout embeds a processor's iframe, FAQ 1588 and the eligibility section of the current SAQ A are the two documents that decide your answer, and they are short. Read them in the original. Most of the secondary commentary on this change was written for assessors, not for the merchant who quietly stopped qualifying.

The two ways to satisfy it

The Council gives two routes, and they are not equally hard.

The first is to protect the page yourself, using techniques such as, but not limited to, those detailed in Requirements 6.4.3 and 11.6.1, deployed either by you or by a third party on your behalf. That is script inventory and authorisation, integrity monitoring of what the browser actually receives, and the operational discipline to keep both current as your site changes.

The second is to obtain confirmation from your PCI DSS compliant third-party service provider or payment processor that, when implemented according to that provider's instructions, its embedded payment solution includes techniques that protect the merchant's payment page from script attacks.

Note the conditional in the second route. The protection is confirmed for the solution when implemented according to the provider's instructions. If your team has customised the integration, injected analytics or tag managers onto the checkout page, or deviated from the documented pattern, you have quietly moved outside the scope of the confirmation you are relying on. Get the confirmation in writing, keep it with your attestation, and keep a note of the integration pattern it was given against.

For most merchants the second route is a procurement task that takes a week. The first is an engineering programme. Ask your processor before you scope a project.

What did not change

Two things, both worth stating plainly because the removal is so easy to over-read.

PCI DSS did not change. Requirements 6.4.3 and 11.6.1 remain in the standard, and entities whose validation type includes them still owe them. Only their presence in one questionnaire changed.

And the underlying threat did not change. E-skimming works by compromising or injecting a script on a merchant page, which is precisely why the criterion replaced the requirements rather than simply vacating them. Merchants who dropped their script monitoring on the strength of the announcement removed a control while keeping the exposure that the control existed to address.

Who can stop reading here

Against our own interest, because this is the majority of merchants who will find this page.

If your checkout is a full redirect or a link out to a hosted payment page, this change does not apply to you. FAQ 1588 says so directly. Confirm your integration is genuinely a redirect rather than an embed, note the answer in your file, and move on from the criterion. Moving on from the criterion is not the same as concluding the page is safe: keep whatever script hygiene you already run on the checkout page, because the exemption decides which questionnaire you complete, not whether the page in front of the redirect can be tampered with.

If your checkout embeds an iframe and your processor publishes a confirmation covering its embedded solution, you may well be done in an afternoon. Read the confirmation, verify it covers your integration pattern, save it, and answer the criterion honestly.

You need help when the answer is genuinely uncertain: when the checkout page carries scripts nobody owns, when the integration was customised years ago by people who have left, or when nobody can produce a current inventory of what executes on that page. That is a real engineering problem, and it is the only version of this that is worth paying anyone for.

Where Top Floor fits

Under our PCI DSS practice the relevant work is inventory and evidence: establishing what actually executes on the payment page, whether the integration matches the pattern your processor's confirmation assumes, and what you can honestly attest to. Where the question is whether the page can be manipulated in practice rather than in theory, that is penetration testing work and scoped separately. We are not a Qualified Security Assessor and do not sign attestations.

How to decide this week

Open your checkout in a browser and determine whether the payment form is embedded in your page or served after a redirect. That single fact decides whether the criterion applies to you at all.

If it is embedded, email your processor and ask whether it publishes confirmation that its embedded payment solution includes protections against script attacks, and against which integration pattern. Save the reply with your attestation.

Then list every script on the checkout page and name an owner for each. If any line on that list has no owner, you have found the work, and you found it before an assessor or an attacker did.

Frequently asked questions

What changed in SAQ A in 2025?

The PCI Security Standards Council removed Requirements 6.4.3 and 11.6.1 for payment page security, and Requirement 12.3.1 for the targeted risk analysis supporting 11.6.1, and added an eligibility criterion in their place. The revised questionnaire was published in January 2025, and the October 2024 version was retired on 31 March 2025. The criterion states that the merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce systems.

Does the new SAQ A eligibility criterion apply to redirect merchants?

No. Per PCI SSC FAQ 1588, the criterion applies to merchants whose own page hosts an embedded payment page or form, such as an iframe. It does not apply to merchants who send customers to the payment page by HTTP 30x redirect, meta redirect or JavaScript redirect, nor to merchants who have fully outsourced payment functions without embedding anything. If your customer leaves your page before entering card data, this change is not yours to act on.

How do we confirm our site is not susceptible to script attacks?

The Council describes two routes. You can deploy protections yourself, using techniques such as but not limited to those detailed in PCI DSS Requirements 6.4.3 and 11.6.1, either directly or through a third party. Or you can obtain confirmation from your PCI DSS compliant payment processor that, when implemented according to its instructions, its embedded payment solution includes techniques that protect the merchant's payment page from script attacks. The second route is conditional on following the documented integration, so a customised checkout may fall outside the confirmation you are relying on.

Were requirements 6.4.3 and 11.6.1 removed from PCI DSS?

No. They were removed from the SAQ A document only. Both remain in PCI DSS, and entities whose validation type includes them still owe them in full. The threat they address, script-based attacks on payment pages, is also unchanged, which is why the Council replaced them in SAQ A with an eligibility criterion rather than simply dropping the subject.