SAQ A, Requirements 6.4.3 & 11.6.1: What the Eligibility Change Means

A question has been coming up recently among people who work with e-commerce merchants, and it can be a real head-scratcher the first time you hit it. A small merchant qualifies for SAQ A and notices that Requirements 6.4.3 and 11.6.1 are simply gone from the form. A larger merchant with a broadly similar setup still appears to owe controls for those same two requirements. On top of that, the current SAQ A includes an eligibility statement that reads almost like an honor system: the merchant confirms that their site is not susceptible to attacks from scripts that could affect their e-commerce systems. If the requirements are gone, and the merchant can simply attest that they are not susceptible, what stops this from becoming a checkbox with nothing behind it?

It is a question we have been hearing lately, so here is how our QSAs read it.

What Actually Changed in SAQ A Requirements

6.4.3 and 11.6.1 did not disappear from PCI DSS. They still live in the standard, and they are still line items in SAQ A-EP, SAQ D for Merchants, SAQ D for Service Providers, and the Report on Compliance (ROC) template. What changed is narrow. The PCI Security Standards Council removed those two requirements from the SAQ A line items and replaced them with a single eligibility criterion. The requirements themselves are unchanged. Only their treatment inside one specific self-assessment questionnaire moved.

That distinction matters, because it is easy to read “removed from SAQ A” as “no longer relevant to SAQ A merchants.” That is not the case. The obligation moved location within the document. It did not vanish.

The Eligibility Gate Only Applies to iframe Merchants

The Council's FAQ on the new SAQ A eligibility criteria clarifies something important. The script susceptibility gate applies only to merchants who embed a payment form using an iframe. Full redirects and fully outsourced payment flows never reach this criterion at all, because in those setups the merchant's own page never renders or interacts with anything script-related that touches account data. The customer leaves the merchant environment entirely to enter their card details, so the script attack surface that 6.4.3 and 11.6.1 are designed to address is not present on the merchant page.

This is why the small redirect merchant and the iframe merchant end up in different places even when both are pointed at SAQ A. The redirect merchant has nothing to confirm here. The iframe merchant does. It is less about company size than about how the payment page is delivered.

Worth noting: the size framing in the opening example is usually a red herring. Architecture doesn't track with company size; a large merchant and a small merchant are equally likely to use either a redirect or an iframe. If a larger merchant is stuck with the full controls despite a setup that looks similar to a smaller merchant's, the more common explanation isn't technical eligibility at all. It's that the compliance-accepting entity, the acquirer or card brand, is requiring the fuller SAQ D or a full ROC outright, independent of whether the merchant would technically qualify for SAQ A. That's common for higher-volume merchants regardless of how their payment page is architected.

“Not Susceptible” Is Not a Free Checkbox

Here is the part that trips people up. For an iframe merchant, confirming that the site is not susceptible is a factual claim, and a factual claim needs something to back it up. The Council's guidance, along with its best-practices materials for small merchants, lays out two acceptable ways to get there.

The first path is to implement the protections yourself. That means the same categories of control described in 6.4.3 and 11.6.1: a Content Security Policy (CSP) to constrain what scripts can run, Subresource Integrity (SRI) to detect altered scripts, and tamper-detection or change-detection monitoring on the payment page, supported by an inventory of the scripts in use and a record of why each is authorized. In other words, you do the work, even though you are not completing those requirements as formal line items on the form.

The second path is to obtain confirmation from your third-party service provider (TPSP) that, when implemented according to their instructions, their solution already includes techniques to protect the payment page from script attacks. This route relies on the TPSP knowing what it is doing and being willing to put that assurance in a form you can actually point to in practice, that means documented in writing, since a verbal assurance won't hold up as evidence. If your provider cannot or will not confirm it, you do not have a defensible basis for the attestation, and you should not be signing it.

Either way, “not susceptible” is earned. It is not a phrase you get to type simply because the form stopped asking for the detail.

What if You Implemented the Controls but the Form Has Nowhere to Record Them

There is an understandable point of frustration here. If you are an iframe merchant who has genuinely implemented these protections, the current SAQ A gives you no line item to describe them. That can feel backward, because you have done more than the shortened form asks and have nowhere obvious to show it. The resolution is that the SAQ is not the place to record that detail. The evidence lives in your assessment workpapers and in the supporting file behind your Attestation of Compliance, not in a requirement response. The form captures that you are eligible. Your documentation captures why you are eligible.

Why Remove the Line Items at All

A fair question is why the Council pulled the requirements out of the SAQ rather than simply noting, as it already does elsewhere, that they do not apply to redirect setups. Per the Council's own announcement, the change was driven by industry feedback about the burden of standing up full 6.4.3 and 11.6.1 tooling across every SAQ A merchant. Building script inventories, script authorization workflows, and weekly tamper-detection monitoring is a real program of work, and for merchants using a redirect, that specific risk doesn't exist in the first place.

Rather than create a whole new intermediate SAQ tier for the narrow case of “SAQ A but with an iframe,” the Council collapsed the expectation into a single threshold attestation. The full, formally tested version of these controls still sits in SAQ A-EP, SAQ D, and the ROC template for anyone who is not fully outsourced. So this is a reporting-burden simplification for the common case, not a security carve-out for the iframe case. The risk did not go away for iframe merchants. The paperwork was consolidated.

What This Means When You Assess or Attest

For anyone signing an attestation or reviewing one, the practical guidance is straightforward. Do not let “N/A, removed from SAQ A” be the end of the workpaper trail for an iframe merchant. Treat the eligibility criterion the way you would treat any other eligibility criterion, and go collect evidence for it. That evidence is either a TPSP confirmation letter or the merchant's own documented script protection configuration, such as CSP and SRI settings together with tamper-detection output.

This is the same instinct many experienced practitioners have arrived at on their own: keep collecting the evidence, even though you are no longer testing 6.4.3 and 11.6.1 as formal line items. No one in a security or compliance role should attest to “not susceptible” without understanding the attack it refers to, because understanding that attack usually reveals whether the exposure is actually present. Removing the control testing from the form did not remove the need for a defensible basis: a review of the payment setup, a script inventory, change control, and evidence that the checkout page cannot be quietly tampered with. Not vibes, and not a shrug.

The Bottom Line

The short version is this. Requirements 6.4.3 and 11.6.1 are still in PCI DSS, and they are effectively still in SAQ A, just relocated into the eligibility section instead of the requirement list. If you use a full redirect, the script eligibility criterion does not apply to you. If you use an iframe, it does, and you meet it either by implementing the protections yourself or by obtaining written assurance from a PCI DSS compliant TPSP. If you have neither, you are not eligible for SAQ A in the first place, and you should be looking at a different questionnaire.

And if you are the one putting your name on the attestation, document the basis for it the same way you would document any other eligibility decision. The form asks for less detail than it used to. The diligence behind it should not shrink to match.

If you are wrestling with where your e-commerce environment lands under SAQ A, whether an iframe setup obligates you under 6.4.3 and 11.6.1, or how to build a defensible basis for the script susceptibility attestation, the QSA team at Compass IT Compliance can help. We work with merchants and service providers every day to scope PCI DSS obligations correctly, gather the right evidence, and complete assessments with confidence. Contact us to walk through your specific payment setup.