PCI SSC has revised FAQ 1331 again. The latest wording makes the compliance-accepting entity an explicit part of any decision to use SAQ eligibility criteria as a guide inside a merchant Report on Compliance. For merchants and QSAs, that changes when the conversation needs to happen and who needs to be at the table.
|
IN
SHORT |
A Level 1 merchant is required to submit a Report on Compliance. Its e-commerce channel sends customers to a PCI DSS compliant payment processor and, at first glance, looks like an SAQ A environment. The merchant asks a familiar question: if the payment model resembles an SAQ, can the QSA use that SAQ to decide which PCI DSS requirements need to be assessed in the ROC?
Until this week, the answer was usually discussed in terms of the merchant, the QSA and the technical evidence. The August 2026 revision changes the governance around that decision. The organisation accepting the compliance result now has an explicit role before an SAQ is used as a guide.
Yes, this is a recent PCI SSC update
PCI SSC currently dates FAQ 1331 as August 2026 and lists it among its most recently updated FAQs. The live wording is materially different from the May 2025 version. It is shorter, but it adds a clear condition: the use of an SAQ as a guide must be explicitly reviewed, discussed and agreed with the merchant's compliance-accepting entity.
The previous version, published after a PCI SSC bulletin on 23 May 2025, focused more heavily on the merchant and QSA agreeing that an SAQ was a suitable guide, with the merchant also told to confirm the validation and reporting method with the organisations managing its compliance programme. The August 2026 wording moves that external agreement into the core rule itself.
What changed from May 2025 to August 2026?
|
Area |
May 2025 position |
August 2026 position |
|
Who must be
involved |
Merchant and QSA agreement was central, with consultation
with the compliance programme owner also required. |
The compliance-accepting entity must explicitly review,
discuss and agree to use of the SAQ as a guide. |
|
Focus of the FAQ |
Contained more detail on QSA testing, partial eligibility,
ROC documentation and examples. |
The wording is deliberately narrower and focuses on who
can approve the approach, with FAQ 1473 used for the wider roles of assessors
and compliance-accepting entities. |
|
Operational effect |
There was more room for the acquirer or payment brand
discussion to happen after the technical approach had already taken shape. |
The safer workflow is to involve the compliance-accepting
entity during scoping, before the ROC approach is fixed and before
substantial fieldwork is completed. |
RedSecLabs view: the change is small in word count but significant in assessment governance. It reduces the chance that a merchant and QSA spend weeks working to one applicability model only for the acquirer or payment brand to reject that reporting approach at the end.
What FAQ 1331 now says
The current FAQ describes SAQs as compliance reporting tools intended for defined merchant use cases and subject to the rules of the organisations that manage compliance programmes. It then draws a firm line: SAQs should not be used as a guide for determining the applicability of PCI DSS requirements unless the approach has been explicitly reviewed, discussed and agreed with the merchant's compliance-accepting entity.
A compliance-accepting entity is normally the payment brand or acquirer to which the merchant submits its assessment result. PCI SSC FAQ 1536 uses that definition, while FAQ 1473 makes clear that these organisations determine the validation and reporting methods expected of merchants and service providers.
The merchant still does not get to choose its own control set
The August revision should not be read as permission to negotiate PCI DSS requirements away. It addresses the reporting approach, not the underlying security facts. PCI SSC FAQ 1473 keeps the technical responsibility with the assessor: the QSA is responsible for validating that assessment scope and requirement applicability have been accurately defined and documented.
That distinction matters. The compliance-accepting entity can determine which validation or reporting method it will accept. The assessor still has to establish whether a requirement genuinely applies to the environment. An acquirer's agreement cannot turn an unsupported Not Applicable conclusion into a technically valid one.
Scope and applicability are different questions
In PCI DSS conversations, "using an SAQ as a guide" is often described as reducing scope. That is imprecise. Assessment scope and requirement applicability are related, but they are not the same thing.
Assessment scope asks which people, processes, technologies and locations can affect the security of account data. Requirement applicability asks which PCI DSS requirements apply to the systems and processes inside that assessment. A narrower requirement set does not automatically make a system disappear from scope.
For an e-commerce merchant, for example, outsourcing payment entry does not remove the need to understand how the merchant website influences the payment flow, what third parties are involved and whether the merchant can affect the security of the transaction. The architecture and data flow must be understood first. The applicable requirements follow from that analysis and the agreed reporting method.
Who decides what in a merchant ROC?
|
Party |
Primary responsibility |
What that means in practice |
|
Merchant |
Describe the environment accurately. |
Provide current payment flows, systems, third-party
dependencies and the facts relied on for any proposed SAQ-based approach. |
|
QSA |
Validate scope and applicability. |
Test the environment, support Not Applicable conclusions
with evidence and document the assessment approach in the ROC. |
|
Compliance-accepting
entity |
Set or accept the validation and reporting method. |
Explicitly review, discuss and agree to the use of an SAQ
as a guide before that approach is relied on. |
This separation of responsibilities is one of the most useful ways to read the August change. Commercial acceptance and technical validation are connected, but they are not the same approval.
Not Applicable is still not the same as Not Tested
FAQ 1473 remains important when a merchant ROC does not test the full PCI DSS requirement set. PCI SSC distinguishes between a requirement that the assessor has verified as Not Applicable and one that has simply been excluded from testing.
|
Not Applicable |
Not Tested |
|
The assessor has considered the requirement and performed
enough work to verify that it genuinely does not apply to the environment. |
The requirement, or a specific aspect of it, is excluded
from testing. No conclusion is being made about whether it could apply or
whether it is compliant. |
PCI SSC specifically states that where a compliance-accepting entity directs that a requirement be excluded from an assessment, that requirement must be reported as Not Tested. That prevents a reduced testing instruction from being presented as though the QSA had independently established non-applicability.
What merchants should do now
If a merchant ROC may rely on SAQ eligibility criteria to guide requirement applicability, the August update makes the sequence of work more important. The following should be settled before substantial fieldwork is completed:
1. Map each payment channel separately. Document how account data enters, moves through and leaves the environment, including e-commerce, call-centre, recurring billing, mobile, payment terminals and third-party processor flows.
2. Identify the SAQ model being considered. Do not start from the smallest questionnaire. Start from the real payment architecture and determine whether a particular SAQ genuinely represents that channel.
3. Prepare the technical rationale. Record the systems, third parties, data flows and requirement-applicability assumptions that the QSA expects to rely on.
4. Engage the compliance-accepting entity early. Ask the acquirer or payment brand to review, discuss and agree to the proposed use of the SAQ as a guide. Retain written evidence of the decision where possible.
5. Let the QSA validate the final position. The QSA should test the actual environment and support every Not Applicable conclusion independently. Approval of the reporting method is not a substitute for assessment evidence.
The main risk is late-stage rework. If the compliance-accepting entity is brought in only when the ROC is close to completion, it may ask for a different reporting method or additional testing. Early agreement gives the merchant and QSA time to resolve that before the reporting deadline is under pressure.
Questions merchants and PCI teams are likely to ask
Q1: Is FAQ 1331 really a recent update?
Yes. PCI SSC currently dates FAQ 1331 as August 2026 and lists it among its most recently updated FAQs. The May 2025 version was the previous published position.
Q2: Does the August update ban the use of SAQ criteria in a ROC?
No. It adds an explicit governance condition. If an SAQ is to be used as a guide for requirement applicability, the approach must be explicitly reviewed, discussed and agreed with the merchant's compliance-accepting entity.
Q3: Can the merchant and QSA agree the approach without the acquirer?
Not under the current FAQ wording where the acquirer is the compliance-accepting entity. The accepting entity must be part of the agreement.
Q4: Does acquirer approval make a requirement Not Applicable?
No. The QSA remains responsible for validating scope and applicability. A requirement should be reported as Not Applicable only when the assessor has performed enough work to support that conclusion.
Q5: What if the acquirer tells us not to test a requirement?
FAQ 1473 says a requirement excluded from testing at the direction of the compliance-accepting entity is reported as Not Tested, not Not Applicable.
Q6: Does the same approach apply to service providers?
Merchant SAQs should not be used by service providers to determine their applicable PCI DSS requirements. PCI SSC FAQ 1578 states that SAQ D for Service Providers is the only SAQ for SAQ-eligible service providers.
The real change is governance, not a new shortcut
The August 2026 revision does not create a new way to reduce PCI DSS obligations. It makes the decision path clearer. A merchant can propose an SAQ-based applicability model. The QSA can assess whether the technical position is supportable. The compliance-accepting entity must now explicitly agree to the use of that SAQ as a guide.
For Level 1 merchants, this should move a conversation that was sometimes treated as a reporting detail into the initial scoping phase. That is a sensible place for it. The earlier the payment architecture, QSA interpretation and acquirer expectations are aligned, the less likely the ROC is to be reopened late in the assessment.
|
PLANNING A MERCHANT ROC? |
