PCI DSS 6.4.3 and 11.6.1 for SAQ A, SAQ A-EP and SAQ D merchants

Important: this is general information

Which questionnaire you complete, and whether a requirement applies, is decided between you, your acquirer or the payment brands (the compliance-accepting entities) and, if you use one, your Qualified Security Assessor. The PCI SSC does not enforce compliance itself. The summary below follows PCI SSC publications as of the review date at the foot of this page; check the current documents before relying on it.

Three ways to accept card payments online

Merchants that store, process or transmit card data themselves, or that do not fit the simpler questionnaires, complete SAQ D, which contains all the requirements that apply to merchants.

SAQ A: from line items to an eligibility criterion

SAQ A covers card-not-present merchants that fully outsource payment functions to PCI DSS compliant providers. According to the PCI SSC, the recent revision of SAQ A removed requirements 6.4.3, 11.6.1 and 12.3.1 (the targeted risk analysis that existed to support 11.6.1) from the questionnaire's requirement list, and added an eligibility criterion: the merchant confirms that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The requirements remain in PCI DSS itself; only SAQ A changed.

What PCI SSC FAQ 1588 says about the criterion

• It applies to merchants whose site embeds a third-party payment page or form, such as an iframe. It does not apply to sites that redirect customers to a provider.
• A merchant can meet it in one of two ways: by using script-protection techniques, which the merchant or a third party may operate (requirements 6.4.3 and 11.6.1 are given as examples of such techniques), or by obtaining written confirmation from its PCI DSS compliant provider that the embedded payment page, when implemented as the provider instructs, includes protections against script attacks.
• A provider of scripts unrelated to payment, which cannot affect cardholder data, is not treated as a third-party service provider for SAQ A purposes.
• Merchants should confirm with their compliance-accepting entity which SAQ, if any, applies to them.

A related FAQ, number 1331, was revised in August 2026. It says that SAQ eligibility criteria should not be used as a guide to which requirements apply in a Report on Compliance unless the merchant's compliance-accepting entity has reviewed and agreed to that approach. If you are assessed with a Report on Compliance rather than an SAQ, ask your acquirer before treating 6.4.3 or 11.6.1 as not applicable.

SAQ A-EP and SAQ D

Because an A-EP merchant's own page affects how card data reaches the provider, 6.4.3 and 11.6.1 stay in SAQ A-EP: the scripts on that page and the headers and content it delivers are exactly what the requirements concern. SAQ D contains the full set of PCI DSS requirements for merchants, so both apply in full. For these merchants the practical work is a script inventory, authorization and integrity methods (6.4.3) and a detection mechanism with its evidence (11.6.1).

Even when the requirement is not listed, the risk is the same

An attacker does not care which questionnaire you complete. With a redirect, a compromise of the page before the redirect can send customers to a look-alike page. With an iframe, a compromise of the parent page can replace or surround the form. Many SAQ A merchants therefore still choose to keep a short script inventory, restrict what loads on the page that frames the provider's form, and watch it for change. The cost is small compared with the harm, and the PCI SSC's own FAQ names these techniques as a way to meet the criterion.

Questions to ask your acquirer or assessor

• Which SAQ or report type do you expect from us, and why?
• How do you want us to evidence the SAQ A script criterion: our own techniques, or written confirmation from our payment provider?
• Which pages count as payment pages in our flow?
• Do you accept our chosen monitoring frequency and risk analysis?