SAQ Eligibility Is Not a Scoping Tool for Your ROC: PCI SSC FAQ 1331 Explained

Here is a conversation we have more often than you might expect. An organisation is preparing for a full PCI DSS assessment producing a Report on Compliance, and someone senior asks a reasonable-sounding question: “If our setup would qualify for SAQ A, can we just assess against the SAQ A requirements and skip the rest?”

It sounds efficient. It is also incorrect, and the PCI Security Standards Council has addressed it directly in FAQ 1331. Getting this wrong is expensive, because it usually surfaces late, after an assessment has been scoped and budgeted on a false assumption.

What FAQ 1331 asks and answers

The question the Council answers is precise: can SAQ eligibility criteria be used as a guide for determining the applicability of PCI DSS requirements for merchant assessments documented in a Report on Compliance?

The answer, in substance, is no. Self-assessment questionnaires are compliance documentation tools for specific use cases under specific circumstances. They are not a guide for deciding which PCI DSS requirements apply in a ROC, unless the entity that accepts your compliance, typically your acquirer or a payment brand, has explicitly reviewed, discussed and approved that approach.

The Council goes further and puts the responsibility somewhere specific: merchants must consult the organisation that manages their compliance to confirm their validation and reporting obligations. That is not a formality. It is the mechanism by which your obligations are actually set.

Why an SAQ and a ROC are not two sizes of the same thing

The intuition behind the mistake is that an SAQ is simply a shorter version of the full standard, so a shorter subset should be portable into any assessment. That is not what an SAQ is.

Each SAQ was constructed for a narrowly defined payment scenario, and its abbreviated requirement set only holds while every one of that scenario’s eligibility conditions is true. SAQ A, for instance, exists for merchants who have entirely outsourced their cardholder data functions, with additional conditions about how payment pages are delivered. The short list of requirements is a consequence of those conditions, not a standalone judgement that the omitted requirements do not matter.

A Report on Compliance is a different instrument entirely. It documents an assessment of all PCI DSS requirements applicable to the entity’s actual environment, determined by scope: where cardholder data is stored, processed or transmitted, which systems are connected to or could affect the security of the cardholder data environment, and which controls are genuinely in place. Applicability in a ROC is driven by what your environment is, not by which questionnaire you might have been eligible for in a different validation route.

Put simply: an SAQ’s brevity is earned by constraints on the environment. A ROC does not inherit those constraints just because the environment might qualify for them.

Where this goes wrong in practice

Three patterns account for most of the trouble we see.

Scoping backwards from the questionnaire. A team decides which SAQ they would fit, then treats that list as the assessment scope. This inverts the correct order. Scope is established by following the cardholder data, as we set out in our guide to PCI DSS scoping and segmentation. Requirements then follow from scope.

Assuming outsourcing removes requirements from a ROC. Outsourcing genuinely reduces obligations, which is why we often recommend it. But the requirements that remain in a ROC are determined by assessment of the environment, including third-party management obligations and anything the merchant still controls. Related to this, plenty of merchants are surprised that even a fully outsourced payment page does not remove their ASV scanning obligations, which the Council also had to clarify separately.

Discovering the gap mid-assessment. When scope has been built on the SAQ assumption, the shortfall appears once testing begins. At that point the options are unattractive: expand the engagement, delay, or produce a report that does not cover what it should.

The part organisations skip: ask your acquirer

The most actionable sentence in FAQ 1331 is the one telling merchants to consult the organisation that manages their compliance. The Council does not set your validation route. Your compliance-accepting entity, generally your acquiring bank or the relevant payment brand, decides how you must validate and what you must report. The Council reinforces this in its related guidance on the role of compliance-accepting entities in determining requirement applicability.

This matters because the answer varies. Two merchants with similar transaction volumes and similar architectures can receive different instructions from different acquirers. If you have never asked yours, in writing, what they require, you are guessing at an obligation someone else defines.

The question worth sending is short: what validation method do you require from us, for which entities, and is any deviation in requirement applicability approved in writing?

What to do instead

The correct sequence is not complicated, it is simply the reverse of the common mistake.

1. Confirm your validation route with your acquirer or payment brand in writing. This determines whether you are producing a ROC or an SAQ at all.
2. Scope the environment properly, following the data rather than the questionnaire. Requirement 12.5.2 makes documented scope confirmation an obligation in its own right.
3. Derive applicability from that scope with your assessor. Requirements that genuinely do not apply are documented as such, with reasoning, in the report.
4. If you believe an SAQ-style reduction should apply within a ROC, obtain explicit approval from your compliance-accepting entity before the assessment is scoped, not after.

None of this makes an assessment larger than it needs to be. It makes it the right size, established for defensible reasons, and it removes the risk of a report that does not survive scrutiny from the people who will rely on it.

Frequently asked questions

Can we use SAQ eligibility criteria to decide which requirements apply in our ROC?

No, not on your own initiative. PCI SSC FAQ 1331 states that SAQs are compliance documentation for specific use cases and should not be used as guidance for determining PCI DSS requirement applicability in a Report on Compliance, unless your compliance-accepting entity has explicitly reviewed, discussed and approved that approach.

What determines which requirements apply in a Report on Compliance?

The scope of the assessment, which is established by where cardholder data is stored, processed or transmitted, which systems connect to or can affect the security of the cardholder data environment, and what controls exist. Requirements follow from the environment, not from which questionnaire the entity might have qualified for.

Who decides how we have to validate PCI DSS compliance?

Your compliance-accepting entity, which is usually your acquiring bank or the relevant payment brand. The PCI Security Standards Council maintains the standard, but it does not set individual validation obligations. Ask your acquirer in writing what they require, because the answer can differ between acquirers for similar merchants.

Does outsourcing our payment processing shrink our ROC?

Outsourcing meaningfully reduces your PCI DSS footprint, which is usually worth doing. It does not automatically remove requirements from a Report on Compliance, because applicability is assessed against your actual environment and still includes obligations such as managing third-party service providers and securing whatever remains under your control.

Get the scope right before the assessment starts

Cianaa is an independent PCI QSA and PCI 3DS Assessor serving New Zealand and Australia. We scope assessments from the data rather than the questionnaire, and we will tell you plainly what your environment requires before the engagement is fixed. Talk to our assessors, use our SAQ Selector if you are working out your validation route, or read our walkthrough of what a QSA assessment involves.