PCI SSC revised FAQ 1331: who now agrees SAQ-based scoping

PCI SSC revised FAQ 1331 in August 2026. Nothing announced it. The page carries a month rather than a date, sitting immediately above its article number. An earlier copy of the same page carries May 2025 in that position, with different text underneath it.

The question is unchanged: 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 answer is not.

What the FAQ now says

It opens with a definition, and the definition is doing work. SAQs are described as "compliance reporting tools" intended to help merchants document compliance with PCI DSS requirements "under appropriate conditions, for designated use cases", and subject to the rules and requirements of the organisations responsible for managing compliance programmes, with payment brands and acquirers given as the examples.

Three qualifiers there: appropriate conditions, designated use cases, and somebody else's rules. The next paragraph says what follows from them.

SAQs should not be used as a "guide" for determining the applicability of PCI DSS requirements unless explicitly reviewed, discussed and agreed upon with the merchant's compliance accepting entity (e.g., payment brands and acquirers).

The FAQ adds that merchants should always consult the organisations responsible for managing compliance programmes to confirm their PCI DSS validation and reporting requirements. It then points to two other FAQs: 1473, on the role of compliance-accepting entities and assessors in determining applicability, and 1142, for payment brand contacts.

The condition is the whole sentence

"Explicitly reviewed, discussed and agreed upon" is three verbs rather than one, and together they describe a process with another party in it.

Explicitly rules out a position that is implied by a scope document, carried forward from last year, or inferred from an acquirer's silence.

Reviewed and discussed puts the specific environment in front of that party. A general policy statement is not a review of your redirect architecture.

Agreed upon produces something you can point to afterwards, which means it needs to exist in writing.

And the party is named. It is the merchant's compliance accepting entity, with payment brands and acquirers offered as the examples. A QSA is not that party, and neither is the merchant.

The consequence is about sequencing

The practical effect is on the order of operations rather than on any single requirement.

An applicability position now has a prerequisite that sits outside both the merchant and the assessor. Acquirers do not turn these conversations around in an afternoon. Where the shape of a ROC depends on such a position, the conversation belongs at the start of assessment planning, next to the annual scope confirmation, rather than at the point a QSA is drafting the scope-of-work section.

Testing inherits the same dependency. Penetration testing scope, scanning scope and segmentation testing scope all follow from what the assessment covers. Where the assessment's shape depends on an agreed position, the testing scope cannot be fixed until that agreement exists. Booking the testing first and opening the conversation second is the sequence that produces a re-scope halfway through.

What to do now

Re-read the scope-of-work section of your last ROC. Any applicability position reached between you and your QSA is one to take to the compliance accepting entity before the next assessment begins.

Keep the agreement with the ROC. "Agreed upon" is an evidentiary standard, and an email thread from the acquirer is the cheapest way to meet it.

Read FAQ 1473 next to this one. FAQ 1331 now points at it for the roles of compliance-accepting entities and assessors, so the two are written to be read together.

Diff the FAQs you rely on. This one changed without an announcement, and the only signal on the page was a month above an article number. Any FAQ your scope depends on is worth a periodic check against a saved copy.

Security Brigade has been CERT-In empanelled since 2008 and runs the testing a PCI DSS assessment consumes: Requirement 11.4 penetration testing, segmentation testing, application and API testing, and source code review, alongside your QSA.