PCI FAQ #1331: SAQ Eligibility Criteria Can No Longer Set Your ROC Scope

The PCI Security Standards Council just made scoping worse.

FAQ #1331 was updated this month. If you're not familiar with it, it's the one that let a QSA performing a merchant Report on Compliance reference the control set from the SAQs when the merchant met the eligibility criteria. So if a channel was just an iframe to a compliant payment processor, it was clear which controls should be tested. That clarity is what's gone.

The question the FAQ answers is one that every QSA and every Level 1 merchant assessment team has relied on for years:

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 updated answer:

Self-Assessment Questionnaires are compliance tools designed for merchants under specific conditions and use cases. They should not serve as a "guide" for determining PCI DSS requirement applicability unless the merchant's compliance-accepting entity (such as payment brands or acquirers) explicitly reviews and agrees to this approach.

Scope is now a negotiation. And it creates two problems the Council hasn't addressed.

🎯 What Actually Changed (and What Didn't)

Let's be precise, because this update is getting summarized badly.

What didn't change: whether you file an SAQ or a Report on Compliance was never your call. That's always been determined by your acquirer or payment brand based on transaction volume and merchant level. Nobody lost that freedom, because nobody had it.

What changed: using SAQ eligibility criteria as a scoping reference inside a ROC. This is how a lot of e-commerce merchants with a redirect or a hosted iframe ended up with a ROC that, functionally, looked like SAQ A. The SAQ told you which requirements were "in play." The ROC followed along. The assessor documented the rest as Not Applicable and everyone moved on.

That door is now closed unless the compliance-accepting entity has explicitly reviewed, discussed, and agreed to the approach.

Worth being honest about what that practice was actually delivering: consistency. Two assessors looking at the same iframe-to-a-compliant-processor channel would land in roughly the same place, because they were both reasoning from the same published control set. That's the thing being removed. Not a loophole — a shared reference point.

The Council also points to FAQ #1473, which is the more consequential half of the story. Read them together and the division of labor is unambiguous: compliance-accepting entities determine validation and reporting methods and may direct which specific requirements are included. Assessors are responsible for validating that scope and applicability are accurately defined — and must confirm through testing that a requirement genuinely doesn't apply before marking it Not Applicable.

⚠️ The "Not Tested" Trap Nobody Is Talking About

Here's the part that will bite programs in the next assessment cycle.

Under FAQ #1473, if a compliance-accepting entity directs that requirements be excluded from the assessment, the assessor does not mark them Not Applicable. They mark them Not Tested.

Those are not the same thing on an Attestation of Compliance. Not Applicable means the assessor tested and confirmed the requirement legitimately doesn't apply to this environment. Not Tested means nobody looked. An Attestation of Compliance carrying Not Tested entries is a materially weaker document — and one that a customer's third-party risk team, a downstream service provider, or a future acquirer will read very differently.

So the "win" of getting your acquirer to agree to a narrowed scope may hand you an AOC with visible holes in it. Meanwhile, "SAQ A doesn't include Requirement 6" is not evidence that Requirement 6 is inapplicable. It's evidence that a different document, built for a different validation path, didn't ask. Your assessor still owes a testing rationale.

That distinction is the whole ballgame, and almost nobody has priced it into their program yet.

🤔 Problem One: Why Is a Control Set Acceptable for One Merchant and Not Another?

Take two e-commerce merchants. Same redirect to a third-party payment page. Same architecture. Same cardholder data footprint, which is to say essentially none. One does 500 transactions a year and files SAQ A. The other does 8 million and gets a ROC.

SAQ A does not ask the small merchant to demonstrate a secure development lifecycle. Its entire Requirement 6 coverage in v4.0 was three items — 6.3.1, 6.3.3, and 6.4.3 — and 6.4.3 was pulled out in the January 2025 revision. Nothing from 6.2 (secure software development, secure coding training, code review). Nothing from 6.5 (change management). Twenty-odd questions in total, against a standard that runs to hundreds of requirements. The Council has effectively said: for this payment channel, those controls don't move the needle on cardholder data risk.

So is development in scope for the big one?

Not according to the model. Maybe according to the acquirer. Definitely according to whoever is feeling cautious that quarter.

Either the SAQ A control set is a risk-based statement about what matters for that payment channel — in which case a Level 1 merchant with the identical channel should be able to reason from it — or it isn't, and we are quietly telling small merchants that a thinner control set is good enough for them because nobody is watching.

It can't be both. Volume should drive validation rigor: who assesses, how much evidence, how deeply it's tested. It shouldn't silently redefine which controls are relevant to the same risk.

The Council Already Made Eligibility Criteria Do Control Work

If you think that's an unfair reading, look at what happened to SAQ A in January 2025.

The Council removed Requirements 6.4.3, 11.6.1, and 12.3.1 from SAQ A — the payment page script management, tamper detection, and supporting targeted risk analysis items — and replaced them with an eligibility criterion: the merchant confirms their site is not susceptible to attacks from scripts that could affect their e-commerce systems.

Read that again. Three PCI DSS requirements were converted into a self-attested eligibility condition. The eligibility criteria are not a neutral gate that sits outside the control set; in SAQ A they are part of how the Council decided script risk gets addressed for that channel.

Which makes FAQ #1331's position awkward. Eligibility criteria are apparently substantive enough to stand in for three requirements when a small merchant self-assesses, but not substantive enough to inform an applicability discussion when a QSA assesses the same architecture at scale.

🏦 Problem Two: Why Is This the Acquirer's Call at All?

If the merchant meets the eligibility criteria, the criteria are the criteria. They were published by the Council, not invented by the assessor.

Requiring acquirer sign-off doesn't add technical rigor. Most acquirers are not staffed to make architecture-level scoping determinations — their PCI function is a portfolio compliance-tracking operation, not a payments security engineering group. The ones that can engage at that level will take months to do it. What you get back is a signature, not an answer.

For the veteran QSAs reading this: how many times have we been on that call and heard, "What does your QSA think?"

That's the part the FAQ doesn't reckon with. Acquirers routinely defer to the assessor on-site, because the assessor is the one who has seen the network diagrams, walked the data flows, and knows the specific conditions in the environment. The acquirer hasn't. Naming them the deciding party in an FAQ does not give them that knowledge, and it does not change the dynamic on the call. The question comes right back to the QSA — except now with a formal expectation attached to it.

There's also a structural asymmetry. The acquirer bears the fine risk, so their rational move on any ambiguous scoping question is to say "assess everything" or to say nothing at all. Neither response is a risk determination. One is a cost transfer to the merchant; the other is silence that the merchant has to interpret.

🧩 Where This Actually Lands: Division

Push a decision to a party that can't or won't make it, and the decision doesn't disappear. It gets made anyway, less visibly, by whoever is holding the pen.

Here's how this plays out. A QSA will do one of three things:

Agree with the merchant and scope to the SAQ control set. Defensible if the acquirer signs off. A problem if the merchant never got that in writing.
Disagree and push essentially the full ROC where applicable. The defensible-by-default posture. Expensive, slow, and it generates evidence for controls with no bearing on the merchant's actual card data risk.
Pick and choose a smattering of controls they think apply. No consistent rationale, no published reference point. I've seen all three of these implemented by QSAs firsthand — and the third was already happening before this update. The FAQ change doesn't fix it. It removes the one shared reference the other two were anchored to.

And now the merchant has to go to their processor to clear scope if they want to use the controls in an already defined and approved SAQ. So they're left with two real options: chase an approval from an acquirer who may never respond, or accept whatever scope their QSA decided on.

Most will take option two. Which means the decision didn't move up a level. It moved out of sight.

So we end up with division. Some Level 1 merchants will test every applicable control in the ROC. Some will get approval and test the SAQ-scoped set. Some will get whatever their QSA decided was applicable that week. Two merchants with identical architecture, materially different assessments — depending on which QSA they hired and how engaged their acquirer happens to be.

That's worse for comparability, worse for merchants trying to budget, and — the part that should bother the Council most — worse for actual security, because effort gets allocated by liability anxiety instead of by risk.

✅ What to Do About It This Quarter

Setting aside whether the policy is right, it's the policy. Here's the practical response.

If you have a ROC in flight that leaned on SAQ criteria to narrow requirements:

Raise it with your acquirer now, not at report writing. Scoping questions that arrive alongside a draft ROC get answered with "assess everything."
Ask specifically whether they will agree to the approach in writing, and whether excluded requirements will be documented as Not Applicable (with assessor testing) or Not Tested (at their direction). Make sure you understand which AOC you're going to end up holding.
If they won't engage, get their non-response documented and make a deliberate, defensible applicability decision with your assessor — with a written rationale tied to your actual cardholder data environment, not to an SAQ table of contents.

If you're scoping next year's assessment:

Build your applicability position from first principles. Data flows, system component inventory, segmentation boundaries, and a documented rationale per requirement. That work survives any FAQ revision. See our guide to PCI scope reduction for how to shrink the environment rather than argue about it.
Open the acquirer conversation early in the cycle, not 60 days out. Budget real calendar time for it.
Assume your applicability rationale will be re-litigated by the next QSA you hire. Write it so it holds up without you in the room.
Genuinely reduce scope where you can. Tokenization and hosted payment fields don't just narrow requirements — they narrow the argument, which is now the expensive part.

If you're a QSA:

Stop treating "the merchant qualifies for SAQ A" as a scoping input. It's an interesting data point about architecture, not a determination.
Get the compliance-accepting entity's position in the ROC, in writing, including silence. Document what you asked and when.

🛠️ How episki Helps

The uncomfortable truth of this update is that your applicability rationale is now a first-class deliverable, not an implicit byproduct of picking the right questionnaire. It has to be written down, defended per requirement, and durable across assessor changes.

episki is built for that: requirement-level applicability status with a documented rationale and full audit trail, evidence linked to the specific requirement it supports, and a shared workspace where your assessor and your team see the same scoping decisions instead of reconstructing them from email. When a control is scoped out, the reason is recorded next to it — so next year's assessor reads your reasoning rather than inventing their own.

Explore the PCI DSS framework on episki to see how requirements, applicability, and evidence connect, or read our breakdown of SAQ types and what changed in v4.

📝 Key Takeaways

FAQ #1331 (updated August 2026) closes the practice of using SAQ eligibility criteria to determine requirement applicability in a ROC without explicit acquirer or payment brand agreement.
Read it with FAQ #1473. Requirements excluded at the compliance-accepting entity's direction are marked Not Tested, not Not Applicable — a visibly weaker AOC.
The inconsistency is real. The same architecture gets a thinner control set at 500 transactions than at 8 million. Volume should drive validation rigor, not which risks are considered relevant.
Eligibility criteria already do control work. SAQ A's January 2025 revision replaced 6.4.3, 11.6.1, and 12.3.1 with a self-attested eligibility criterion.
Acquirer sign-off adds a signature, not a determination. Most aren't staffed for architecture-level scoping, their incentive is to say "everything" or nothing, and on the call they'll ask what your QSA thinks.
Practice will divide. Some Level 1 merchants will test everything, some will get approval and test the SAQ-scoped set, some will get whatever their QSA decided that week.
Do the work anyway. A first-principles, documented applicability rationale is the only artifact that holds up regardless of how the Council words this next.

Curious on thoughts from my QSA peeps and the broader community. Am I right that this is going in the wrong direction, or am I missing something?

Sources: PCI SSC FAQ #1331 · PCI SSC FAQ #1473 · Important Updates Announced for Merchants Validating to SAQ A · FAQ Clarifies New SAQ A Eligibility Criteria for E-Commerce Merchants