SAQ A and the script requirements
The carve-out is real and narrower than most summaries suggest. It also comes with a confirmation you should be able to support.
TL;DR
SAQ A and scripts
THE CARVE-OUT EXISTS
The January 2025 SAQ A update exempted eligible merchants from certain requirements, including the client-side pair.
IT HAS A CONDITION
You confirm your site is not susceptible to attacks from scripts that could affect your ecommerce systems. That is a statement you should be able to support.
SAQ A-EP IS NOT EXEMPT
If your site can affect the security of the payment transaction, you are probably A-EP rather than A, and the requirements apply in full.
Short on time? The most common error is assuming SAQ A applies when the correct questionnaire is SAQ A-EP.
Are SAQ A merchants exempt from 6.4.3 and 11.6.1?
Partly. Eligible SAQ A merchants were exempted from certain requirements in the January 2025 update, including the two client-side ones, on the condition that they confirm their site is not susceptible to attacks from scripts that could affect their ecommerce systems. Two things make this narrower than it first appears. The first is the condition itself: confirming you are not susceptible is an assertion, and asserting it without knowing what scripts run on your pages is uncomfortable if it is ever tested. The second is eligibility: SAQ A is for merchants who have fully outsourced payment handling and whose site cannot affect the security of the payment transaction. Many merchants who believe they are SAQ A are actually SAQ A-EP, where no exemption applies.
The exfiltration never touches your server, so a WAF never sees it. The request happens in the visitor's browser, which is the only place it can be observed.
Who actually qualifies for PCI SAQ A
PCI SAQ A is intended for card-not-present merchants who have fully outsourced all cardholder data functions, retain no electronic cardholder data, and whose website does not receive card data or affect the security of the payment transaction. Typically that means a full redirect to a provider-hosted payment page, or a payment iframe with no ability for your page to influence it.
The phrase doing the work is affect the security of the payment transaction. A page that hosts an iframe is running your own JavaScript alongside it, and that JavaScript can overlay the iframe or capture keystrokes. Whether that constitutes affecting security is a question for your assessor and your acquirer, and reasonable people read it differently.
SAQ A-EP, the one people miss
SAQ A
SAQ A-EP
Receives card data
No
No
Site can affect payment page security
No
Yes
Typical setup
Full redirect to provider
Provider iframe or fields embedded in your page
6.4.3 and 11.6.1 apply
Carve-out, with a condition
Yes, in full
A merchant who never sees a card number can still be A-EP, and A-EP carries the script requirements without exemption. If you are unsure which applies, that is a question for your acquirer rather than a judgement call to make internally.
If you are confirming your site is not susceptible to script attacks, it helps to know what is running.
The condition attached to the carve-out
The exemption asks you to confirm your site is not susceptible to attacks from scripts that could affect your ecommerce systems. Read plainly, that is a statement about scripts on your pages, which means you need some knowledge of what those scripts are and what they do in order to make it honestly. PCI SSC FAQ 1588, published in February 2025, gives two ways to support it: apply the techniques of 6.4.3 and 11.6.1 to your payment page, yourself or through a third party, or get written confirmation from your PCI DSS compliant payment provider that its solution, implemented to its instructions, protects your payment page from script attacks. A generic statement that the provider is PCI compliant is not that confirmation.
This is the part we would flag most strongly. An exemption is not an absence of risk. A skimmer on the page hosting your payment iframe can still capture card data through an overlay, and your questionnaire status will not be much comfort afterwards.
A practical position
If you qualify for SAQ A and can honestly make the confirmation, you are not obliged to implement the client-side requirements. Many merchants in that position still choose a minimal inventory, because knowing what runs on your checkout is how you make the confirmation with a straight face, and because the cost of finding out is low.
Sources and methodology
PCI DSS requirement text is quoted from PCI DSS v4.0.1 (June 2024), published by the PCI Security Standards Council, which is the current version at the time of writing. Requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. Where we describe a competitor, we describe publicly available information and say so when something should be verified with the vendor. We publish this product and that is a bias worth knowing about while you read. Primary sources: PCI SSC FAQ 1588.
ASK AN AI
Don’t just take our word for it
Ask your assistant what to look for in a tool for PCI DSS 6.4.3 and 11.6.1.
Frequently asked questions
Partly, and conditionally. The January 2025 update exempted eligible SAQ A merchants from certain requirements including these two, provided you confirm your site is not susceptible to attacks from scripts that could affect your ecommerce systems.
The deciding question is whether your website can affect the security of the payment transaction. A full redirect to a provider-hosted page usually means SAQ A. An embedded provider iframe can also be SAQ A, provided you meet the script eligibility criterion that PCI SSC FAQ 1588 explains. Payment fields or scripts served from your own site usually mean A-EP. Confirm with your acquirer, because they set the requirement.
Often, yes. PCI SSC FAQ 1588 treats an embedded provider iframe as eligible for SAQ A, as long as you can confirm your site is not susceptible to script attacks. That condition exists because your page runs JavaScript alongside the iframe, and that script can overlay it or capture keystrokes. Some assessors still land on A-EP, so confirm with yours.
Yes for now, and worth watching. It was introduced in January 2025 and reflects a judgement about relative risk for the least exposed merchants. Standards change, and the direction of travel on client-side risk has been one way for several years.
Yes, in our view, and we will declare the bias: we sell this. The stronger argument is the confirmation itself. You are asserting your site is not susceptible to script attacks, and the cheapest way to make that assertion honestly is to know what scripts are running.
Yes, you can often self-assess, and that is increasingly not the deciding factor. Your merchant level and your acquirer set the formal requirement, and a growing number of enterprise customers now ask their suppliers for a QSA-signed Attestation of Compliance regardless of what the standard would permit. If you sell to large organisations, check your customer contracts as well as your acquirer's requirements before assuming a self-assessment will be accepted.
No. PCI DSS SAQ D merchants and service providers are in scope for 6.4.3 and 11.6.1 in full, with no carve-out of any kind. SAQ D is the full questionnaire and the client-side requirements are part of it.
Yes, and they often do. Your acquirer sets your validation requirements and can be stricter than the baseline. If they ask for evidence of script controls despite an SAQ A classification, that is their call to make.
Partly. A full redirect to a provider-hosted page means the card is entered on a page you do not control, which genuinely removes most of this risk class. Your own pages can still be modified to redirect customers somewhere else entirely, which is a different attack with the same outcome.
In the SAQ A document itself and the accompanying summary of changes published by the PCI Security Standards Council in January 2025. PCI SSC FAQ 1588, published in February 2025, explains how to meet the script eligibility criterion. Read the source rather than a vendor summary, including this one.
It is the PCI Security Standards Council's February 2025 answer on how an ecommerce merchant meets the SAQ A script eligibility criterion. It applies to merchants who embed a provider's payment page or iframe, not to full redirects, and it gives two routes: protect your payment page with techniques like those in 6.4.3 and 11.6.1, or get written confirmation from your PCI DSS compliant payment provider that its solution protects your page from script attacks.
For SAQ A eligibility, it can. FAQ 1588 accepts written confirmation from your PCI DSS compliant payment provider that its solution, implemented according to its instructions, protects your payment page from script attacks. Ask for it in writing, naming the product and integration you use; a statement that the provider is PCI compliant is not the same thing.
Related articles
PCI DSS
PCI DSS compliance: a practical guide for 2026
What the standard covers, what changed in v4.0.1, and where the two client-side requirements fit.
PCI DSS
PCI DSS 4.0.1 requirements: what changed and when
The changes that matter, the dates that already passed, and the two requirements most teams missed.
PCI DSS
How to comply with PCI DSS 6.4.3 and 11.6.1
A step-by-step method, from defining payment-page scope to handing an assessor the evidence.
PCI DSS
PCI compliance cost: where the client-side line item lands
What drives the bill, which costs are one-off, and how the 6.4.3 and 11.6.1 line compares.
See every script on your own checkout.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.