PCI FAQ 1331 Revised (Aug 2026): The SAQ A Shortcut for 6.4.3 and 11.6.1 in Your ROC Is Gone

PCI FAQ 1331 was revised in August 2026, and it closes a quiet shortcut. Merchants assessed through a Report on Compliance (ROC) can no longer agree with their QSA alone to use SAQ A eligibility as the reason Requirements 6.4.3 and 11.6.1 are “not applicable”. That reasoning now needs explicit sign-off from your acquirer or payment brand, or the requirements get assessed on their own terms.

If you run PCI compliance for a UAE merchant, PSP or marketplace that goes through a ROC, this one is worth an hour of your time before your next assessment window opens. If you file SAQ A, keep reading too, because the change shows how the Council wants applicability decisions made, and your acquirer may start asking the same questions.

What does the revised PCI FAQ 1331 actually say?

FAQ 1331 asks: “Can SAQ eligibility criteria be used as a guide for determining applicability of PCI DSS requirements for merchant assessments documented in a Report on Compliance?” The Council’s page now dates the answer August 2026. Secondary write-ups disagree on the exact day (some say 4 August, others 31 August), so we’ll stick to the month the Council shows.

The core of the new answer: SAQs are reporting tools, and they “should not be used as a ‘guide’ for determining the applicability of PCI DSS requirements” unless that approach has been explicitly reviewed, discussed and agreed with the merchant’s compliance accepting entity, meaning the payment brands and acquirers. The FAQ points merchants to those entities to confirm their validation and reporting requirements.

Here’s what moved, side by side:

The phrase that matters for your QSA is the shift in who owns the decision. A QSA agreeing with you is no longer enough.

Why did merchants use SAQ A to skip 6.4.3 and 11.6.1?

Some history helps here. Requirement 6.4.3 (inventory, authorize and justify every script on the payment page) and Requirement 11.6.1 (detect unauthorized changes to payment page content and HTTP headers) arrived with PCI DSS v4.0 and became mandatory on 31 March 2025. They target Magecart-style skimming, where a compromised script steals card data in the browser.

Then, in January 2025, the Council published a revised SAQ A that removed 6.4.3, 11.6.1 and the related targeted risk analysis in 12.3.1 as line items. In their place came a new eligibility criterion: the merchant has to confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s). A later FAQ (1588) clarified that merchants can meet this by using techniques like those in 6.4.3 and 11.6.1, or by relying on assurance from their payment provider.

Larger merchants assessed through a ROC noticed the gap. If an SAQ A merchant with an embedded payment iframe doesn’t have to answer 6.4.3 and 11.6.1, why should a ROC merchant with the same checkout design? The May 2025 wording of FAQ 1331 seemed to allow exactly that argument if merchant and QSA agreed. The Council’s August revision notes the earlier wording may have led to misinterpretation of compliance responsibilities, and closes it.

Who is affected by the FAQ 1331 change?

Not everyone equally. Here’s a practical way to sort yourself:

For UAE banks and PSPs there’s a second reason to care. As we covered in our CBUAE Notice 3057 explainer, the Central Bank already expects client-side script controls on payment and login pages. If you are regulated by CBUAE, marking 6.4.3 and 11.6.1 N/A in your ROC while your supervisor expects equivalent controls is an awkward position to defend.

What should ROC merchants do before the next assessment?

You have two clean options and one messy one. The messy one is hoping your QSA doesn’t raise it.

1. Find out what you actually claimed. Pull last year’s ROC and check how 6.4.3, 11.6.1 and 12.3.1 were reported. If the N/A justification references SAQ A eligibility, you’re in scope for this change.
2. Decide: argue or implement. If your payment page is a fully hosted redirect and nothing on your site touches the payment flow, there may be a legitimate applicability argument that doesn’t lean on SAQ criteria. If you embed an iframe on your own page, assume the requirements apply.
3. If you argue, get it in writing. Ask your acquirer for an explicit statement that they accept SAQ eligibility criteria as the basis for applicability in your ROC, naming the requirements and the assessment period. Hand it to your QSA before fieldwork.
4. If you implement, scope it tightly. Build the script inventory and justification register for the payment page, set a Content Security Policy with reporting and Subresource Integrity where possible, and deploy change detection that alerts on unauthorized script or header changes.
5. Document once, reuse twice. The same evidence satisfies 6.4.3 and 11.6.1 in a ROC, supports the SAQ A script-attack criterion if your status changes, and helps with CBUAE client-side expectations.

Option two (just implement) is often cheaper than it looks. A typical merchant payment page has far fewer scripts than the marketing site, and the inventory is often the hardest part.

Does this mean SAQ A merchants are safe?

For now, FAQ 1331 doesn’t change your questionnaire. But don’t confuse “not directly affected” with “no work”. You still sign an attestation that your site isn’t susceptible to script attacks, and you need something behind that statement: your provider’s assurance documentation, a CSP and SRI setup, a monitoring tool, or a test showing script injection isn’t feasible.

Two things to watch. First, the Council has been tightening SAQ A language step by step, including a recent FAQ (1604) on whether ASV scans apply to merchants with redirect or iframe pages. Second, your acquirer is the one who decides whether you’re even allowed to use SAQ A. If you’re unsure which questionnaire fits, our guide to SAQ types walks through the differences.

How does this connect to agentic commerce and new checkout flows?

The thread running through this change is that applicability decisions belong to the acquirer and brand, not to a convenient reading of a self-assessment form. That matters even more as checkouts get stranger. If an AI agent is about to fill in your payment page or hold a delegated card token, “which requirements apply?” is exactly the question you’ll need your acquirer to agree with. We work through that scoping problem in PCI DSS Scope for Agentic Commerce.

Get a payment-page script gap assessment before your QSA does

If FAQ 1331 just turned two N/A lines in your ROC into open questions, we can help you close them quickly. Our payment-page script gap assessment is a fixed-scope engagement: we inventory every script and header on your payment pages, test your 6.4.3 and 11.6.1 position against the revised FAQ, and tell you plainly whether to argue applicability or implement. If arguing makes sense, we draft the acquirer approval request and the rationale your QSA needs. If implementing makes sense, you get a short remediation plan you can ship before fieldwork.

It plugs straight into our PCI DSS gap analysis and QSA-readiness and ROC support work. Book a scoping call and bring last year’s ROC.