Your payment provider tells you that SAQ A still covers you. Your assessor says the rules changed last year. Both of them are reading the same standard, and both of them are partly right.
SAQ A eligibility is the single most misreported change in PCI DSS v4.0.1, and the reason is that it moved twice in four months. This article sets out what the Council actually did and the two conditions that decide whether you still qualify. It also covers the one sentence that limits all of it to iframes, and what to ask your provider so the answer is in writing.
- In October 2024 the Council added requirements to SAQ A. In January 2025 it removed them again.
- SAQ A eligibility now turns on two criteria: requirements 6.4.3, 11.6.1 and 12.3.1 came out of the questionnaire and those conditions went in.
- The script criterion applies only to merchants using embedded payment forms. Redirects and full outsourcing are outside it.
- Nothing was relaxed. The underlying PCI DSS requirements still stand. What changed is who evidences them.
What the Council actually did, in order
The sequence matters, because most summaries stop halfway through it.
- 1 15 October 2024. The Council published the SAQs for PCI DSS v4.0.1. Its own bulletin lists the changes, and one of them is “Adding a requirement to SAQ A and removing a requirement from SAQ C”. Payment page security arrived in the questionnaire.
- 2 30 January 2025. The Council removed Requirements 6.4.3, 11.6.1 and 12.3.1 from SAQ A and put two eligibility criteria in their place.
- 3 31 March 2025. The January 2025 version replaced the October 2024 one, which retired.
- 4 28 February 2025. Between the two, the Council published FAQ 1588 to explain how a merchant demonstrates the new criterion.
So anyone who read the news in late 2024 and stopped there believes 6.4.3 and 11.6.1 are questions on the form. They are not. And anyone who read only the January headline believes the work disappeared. It did not.
The two conditions that now decide SAQ A eligibility
Both have to be true. The first is about where your payment page comes from: every element of it must be delivered only by a PCI DSS compliant third-party service provider. The second is the one causing the arguments, and the Council words it like this:
“The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
Read it as what it is. It is not a questionnaire answer about a control you operate. It is a condition you have to be able to stand behind before you are allowed to use the short form at all. If you cannot confirm it, SAQ A is not your questionnaire.
The sentence that narrows all of this to iframes
Here is the part that almost never makes it into the summaries. The script criterion applies exclusively to merchants whose payment form is embedded, that is, served inside an iframe on a page you control. It does not apply to merchants who redirect the customer to the provider, and it does not apply to those who outsource payment entirely.
That single distinction decides whether this article is about you. If your checkout sends the shopper to a hosted payment page and your own page never renders the form, the criterion is not yours to meet. If your page loads an iframe and also loads your own scripts, it is.
Nothing was relaxed
It is worth being blunt, because the opposite reading is circulating. Removing 6.4.3, 11.6.1 and 12.3.1 from SAQ A does not remove them from PCI DSS. The standard still requires script inventory and authorization, still requires tamper detection on payment pages, and still requires the targeted risk analysis behind the monitoring frequency.
What changed is the evidence path. The Council accepted that when every element of the payment page comes from a compliant provider, that provider is already operating those controls, so asking the merchant the same questions again produced paperwork rather than security.
How you actually confirm it
FAQ 1588 gives two routes, and you can use either.
- Do it yourself. Implement the protective techniques described in Requirements 6.4.3 and 11.6.1, directly or through a third party. You end up doing the work you would have reported anyway, which for many merchants is the honest answer.
- Get it in writing. Obtain written confirmation from your PCI DSS compliant payment provider that its embedded payment solution includes protection against script attacks when implemented according to its guidance.
Note the condition buried in the second route: when implemented according to its guidance. A provider’s attestation covers its solution installed the way the provider documents it. If somebody on your team added a tag manager to the checkout page, that is your deviation, not theirs.
If your provider will not put the confirmation in writing, treat that as the answer. An attestation you cannot produce during an assessment is the same as one you never had.
Four questions for your payment provider
Ask them together and ask for a reply you can file with your evidence.
- 1 Is every element of our payment page delivered by you? Including fonts, analytics and anything a marketing team added later.
- 2 Does your embedded solution include protection against script attacks? You want this sentence, in writing, referencing FAQ 1588.
- 3 What does “implemented according to your guidance” exclude? Name the deviations that would void the confirmation.
- 4 Are we on a redirect or an iframe? Teams are wrong about this more often than you would expect, and it decides whether the criterion applies at all.
If you no longer qualify, which SAQ is yours
This is the question that follows thirty seconds after the SAQ A eligibility conversation, and it rarely gets a straight answer.
The usual next step is SAQ A-EP, written for e-commerce merchants whose own website can affect the security of the payment transaction without ever receiving account data. It is a substantially longer questionnaire, and the jump from SAQ A to SAQ A-EP is the real cost of failing the eligibility test. If neither fits, SAQ D is the full questionnaire for merchants.
Do not pick by guesswork. The Council publishes a SAQ Instructions and Guidelines document that sets out the eligibility criteria for every questionnaire, and your acquirer is the one who tells you which it will accept. Confirm both before you start filling anything in, because discovering halfway through that you were on the wrong form costs a quarter.
Where we fit
SAQ A eligibility decides which questionnaire you fill in. It does not remove the quarterly external scan, which is a separate obligation under Requirement 11.3.2 and which only a listed Approved Scanning Vendor can attest. Nordstern is listed by the PCI Security Standards Council as an ASV with global scope, certificate 50955001-01. And that scan has its own pass criteria, which catch people out independently of any of this.
Before any of it there is the question of which level you are, and therefore what you owe at all. That one is set by the card brands rather than by the Council. If you want the scope and the questionnaire settled properly rather than argued about every year, that is what our PCI DSS consulting and PCI DSS practice are for. Talk to the team.
Sources
- PCI Security Standards Council, bulletin of 15 October 2024: publication of the v4.0.1 SAQs and the change list, including the requirement added to SAQ A.
- PCI Security Standards Council, updates for merchants validating to SAQ A: removal of Requirements 6.4.3, 11.6.1 and 12.3.1 and the new eligibility criterion.
- PCI Security Standards Council, FAQ 1588 explained: the two ways to confirm the criterion and its limitation to embedded payment forms.
