PCI Council Revises FAQ 1331: The N/A Path for 6.4.3 and 11.6.1 Just Got Narrower

On August 4, 2026, the PCI Security Standards Council (PCI SSC) published a revised version of FAQ 1331, the guidance that governs whether merchants completing a Report on Compliance (ROC) can use SAQ eligibility criteria to determine which PCI DSS requirements apply to their environment. The previous version, published in May 2025, let a merchant and QSA jointly decide that SAQ A eligibility justified marking requirements 6.4.3 and 11.6.1 as not applicable. The revised version states that this guidance was open to misinterpretation, and that merchants must always consult their Compliance Accepting Entities, meaning acquirers and payment brands, to confirm their PCI DSS validation and reporting requirements.

In practice, the decision to exclude client-side security requirements from a ROC no longer sits with a merchant and QSA alone. The acquirer now has to be part of that conversation.

How We Got Here: A Short Timeline

What the May 2025 Version Allowed

The May 2025 FAQ 1331 created what many in the industry treated as an escape hatch. A Level 1 or Level 2 merchant completing a full ROC could, with QSA agreement, apply the reduced requirement set of SAQ A to a fully outsourced ecommerce channel. Since the January 2025 revision of SAQ A no longer lists 6.4.3 and 11.6.1 as line items, some merchants and assessors concluded that both requirements could be marked not applicable in the ROC.

Several QSA firms flagged the tension at the time. The Council had moved script security from a requirement into an eligibility criterion, then allowed that eligibility logic to flow into ROC assessments. The result was inconsistent interpretation across assessors, acquirers, and payment brands.

What the August 2026 Revision Changes

The new bulletin is short, but its implications are not. Three things stand out.

1. The Council acknowledges the problem. The bulletin states that the May 2025 version may have caused misinterpretations about compliance adherence responsibilities.
2. The decision authority shifts. Merchants must now consult their Compliance Accepting Entities before relying on SAQ eligibility criteria in a ROC. A QSA sign-off is a necessary input, not a sufficient one.
3. The Council points to the chain of accountability. The revised FAQ references related guidance on the role of Compliance Accepting Entities and how to reach the payment brands.

Who This Affects

What You Should Do Now

• If you marked 6.4.3 or 11.6.1 not applicable in a current or upcoming ROC: contact your acquirer before your next assessment cycle. Do not assume the prior QSA agreement carries forward.
• If you are mid-assessment: raise the revised FAQ with your QSA now.
• If you rely on a TPSP attestation for SAQ A eligibility: verify the attestation covers script attacks against the full site, not just the payment page.
• If you want to avoid the debate entirely: implement 6.4.3 and 11.6.1. Merchants that authorize and justify their payment page scripts and run tamper detection meet the requirements outright, with no eligibility argument and no acquirer negotiation.

That last point is the pattern worth noticing. Since January 2025, the Council has revised this area three times, and every revision has moved in the same direction: away from exemptions, toward accountability. Building a compliance position on an FAQ is building on ground that keeps moving. Building it on implemented controls is not.

How Reflectiz Helps

Reflectiz gives you continuous, agentless coverage of both requirements:

• Requirement 6.4.3: a complete, continuously updated inventory of every script on your payment pages, with authorization workflows and written justification for each one.
• Requirement 11.6.1: tamper and change detection on the security-impacting HTTP headers and content of payment pages, with alerting at the frequency your risk analysis defines.
• Acquirer-ready evidence: exportable reports documenting script inventories, approvals, and change history, so the conversation with your Compliance Accepting Entity is short.

The requirements were never the hard part. Proving them continuously, without deploying agents or slowing your site, was. That is the part Reflectiz solves.