The PCI Security Standards Council's FAQ 1331 is the answer to a practical question: can a merchant that is required to produce a Report on Compliance use the eligibility criteria of a Self-Assessment Questionnaire as a guide to which PCI DSS requirements apply to it? Until this summer the answer was a qualified yes, and the qualification ran through the merchant's assessor. In August 2026 the Council replaced the FAQ, and the qualification now runs through the entity that accepts the merchant's compliance instead. The Council's own text gives the payment brands and acquirers as its examples of that entity.
The change is small in words and specific in effect. Visa makes the acquirer responsible for ensuring its merchants validate at the right level and for collecting the evidence; Mastercard says an acquirer must build and maintain a PCI compliance program. Where an ISO or payment facilitator runs that program for its sponsor bank, a decision the Council has just moved off the QSA's desk lands on yours. Here are the old text, the new text, the FAQ the new one points to, and two other 2026 FAQs that reach the small end of a portfolio, as of September 2026.
What FAQ 1331 Said in May 2025, and What It Says Now
The version dated May 2025, as captured by the Internet Archive that September, said that merchants should work with their QSA to fully understand the merchant's environment, and that if they were able to reach agreement that applying only the requirements included in an SAQ was an acceptable approach to secure that environment, then that SAQ could be used as a relevant guide for applicability of PCI DSS requirements. It gave an example: an e-commerce merchant whose web server used a server-side redirect, an HTTP 301 or 302, to a PCI DSS compliant third-party payment processor, where the assessor could consider Requirements 6.4.3 and 11.6.1 not applicable because the redirect is not susceptible to script-based attacks. The approach had to be documented by the QSA in section 3.1 of the ROC, the assessor had to test and verify the non-applicability of each requirement, and the requirements were then reported as Not Applicable.
That text also told merchants to consult the payment brands and acquirers to confirm their validation method and that the approach was acceptable. The agreement that mattered, though, was the one between merchant and QSA.
The version now on the Council's site is dated August 2026; a GuidePoint Security post of 3 September puts the change on 31 August. SAQs, it now says, are compliance reporting tools intended to help merchants document compliance under appropriate conditions, for designated use cases, and subject to the rules of the organisations responsible for managing compliance programs. Then the operative line: 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, for example the payment brands and acquirers. The worked example, the section 3.1 instruction and the QSA's role in reaching the agreement are gone. The FAQ now refers the reader to FAQ 1473 for the rest.
FAQ 1473: What a Compliance-Accepting Entity Decides, and How the ROC Records It
FAQ 1473, dated March 2023, is the framework the new 1331 defers to. Compliance-accepting entities, typically payment brands and acquirers, are responsible for determining the validation and reporting methods of their merchants and service providers, including whether compliance is evidenced by a ROC or an SAQ. They may also direct which requirements go into the assessment; the FAQ's own example is requiring that only a specific subset, such as those in an SAQ, be tested and documented in a ROC.
The FAQ then separates two results that look alike on the page. An assessor may report a requirement as Not Applicable only after confirming through testing that it truly does not apply to the environment, and that confirmation must be performed and documented for every Not Applicable response before a compliant result can be considered. A Not Tested response means the requirement was excluded from the assessment without any consideration of whether it applies. And the sentence that connects the two FAQs: if a compliance-accepting entity directs an assessed entity or its assessor to exclude any requirement from an assessment, that requirement must be marked Not Tested. Whether a Not Tested response can still produce a compliant result, the FAQ adds, is treated differently between PCI DSS v3.2.1 and v4.0; it sends QSAs to the ROC Template for the version in use.
Put the two together and a trimmed ROC works differently. Under the old 1331 the trimming was the assessor's finding, tested and reported as Not Applicable. Under the new one it is either your direction, in which case the excluded requirements are Not Tested, or an assessor finding you have explicitly reviewed and agreed to in advance. Either way there is a decision with your name on it, and a ROC that shows which kind it was.
Who the Compliance-Accepting Entity Is
The Council's FAQs name payment brands and acquirers; the brands' public pages say who does the work. Visa's Account Information Security program page states that issuers and acquirers are responsible for ensuring that all their service providers, merchants and merchants' service providers comply with PCI DSS, that a merchant's total Visa volume over a 12-month period determines its level and validation requirements, and that acquirers must ensure their merchants validate at the appropriate level and obtain the required documentation from them. It cites Visa Core Rules sections 0002228 and 0008031 for the duty and 0001054 for the consequence: if a merchant or service provider does not comply or fails to rectify a security issue, Visa may assess a non-compliance assessment on the acquirer, which pays it and must not represent that Visa imposed it on the merchant. An assessment may be waived where a forensic investigation finds no evidence of non-compliance before and at the time of a breach.
Mastercard's Site Data Protection page is more procedural. Merchants determine their level from Mastercard volume over the most recent 52-week period and submit their validation documents to their acquiring bank, which oversees compliance and, when required, reports status to Mastercard. Acquirers are responsible for building and maintaining a PCI compliance program: helping merchants set their level, setting deadlines for validation documents, and submitting the SDP Acquirer Submission and Compliance Status Form semi-annually for Level 1 and Level 2 merchants. Mastercard does not require Level 3 and Level 4 merchants to validate, but an acquirer must validate to Mastercard that it has a risk management program in place for those portfolios.
Its levels show where the new FAQ bites. Level 1 is any merchant with more than six million combined Mastercard and Maestro transactions a year, any merchant meeting Visa's Level 1 criteria, or any merchant Mastercard decides in its sole discretion should be there; it needs an annual ROC. Level 2, more than one million and up to six million, files an annual SAQ, but if it completes SAQ A, A-EP or D it must also engage a QSA or ISA. Level 3 is more than 20,000 and up to one million e-commerce transactions, and Level 4 is everyone else; both are listed against an annual SAQ, though as above Mastercard does not require either to validate to it, and either may choose a QSA-led ROC instead. A merchant required to produce a ROC, and hoping to produce a smaller one, is the case FAQ 1331 governs.
None of this puts the compliance-accepting role on an ISO or a payment facilitator. The obligation reaches you the way most acquirer obligations do, through the sponsorship agreement: if that contract makes you responsible for your merchants' PCI validation, the explicitly-reviewed-and-agreed step in the new FAQ is a step in your queue, and the decision should be one your sponsor would recognise as its own. Payment facilitators carry a second file besides: Mastercard classes a payment facilitator with more than 300,000 combined Mastercard and Maestro transactions a year as a Level 1 service provider, validating by annual ROC, and one at or below that figure as Level 2, validating by SAQ.
Two Other 2026 FAQs That Reach the Small End of the Portfolio
The new 1331 is about merchants big enough to need a ROC. Two other recent FAQs are about the SAQ A population, and they are worth handling in the same pass.
FAQ 1604, dated June 2026, answers whether the ASV scanning in SAQ A applies to merchants whose pages redirect to a third-party service provider or embed its iframe. Yes: SAQ A for PCI DSS v4.x includes external vulnerability scanning by a Council-approved scanning vendor for merchant e-commerce web pages even where payment processing is fully outsourced, because Requirements 11.3.2 and 11.3.2.1 were added to SAQ A to cover the case where the merchant's page is compromised and the payment process with it. That covers pages that redirect to a TPSP, directly or via another redirection server, and pages that include a TPSP's iframe or an iframe nested in one. The scan must be performed by a vendor on the Council's ASV list, using that vendor's solution. A merchant that says its checkout is entirely the processor's problem still owes the scan.
FAQ 1588, dated February 2025, explains the eligibility criterion the January 2025 revision of SAQ A added. That revision, published on 30 January 2025 and effective 31 March 2025, removed Requirements 6.4.3 and 11.6.1 for payment-page security, and 12.3.1, from SAQ A in response to stakeholder feedback about the complexity of implementing them, and instead required the merchant to confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The FAQ narrows where that applies: only to merchants whose page embeds the processor's payment form, such as an iframe, and not to merchants that redirect the customer to the processor or outsource payment entirely. An iframe merchant can meet it with techniques such as those in 6.4.3 and 11.6.1, deployed by the merchant or a third party, or with confirmation from its PCI DSS compliant processor that, implemented according to the processor's instructions, the processor's solution protects the page from script attacks. The FAQ closes by sending merchants to their compliance-accepting entity, typically the acquirer, on whether they must submit an SAQ and which one.
The baseline under all of this has not moved. PCI DSS v4.0.1 was published on 11 June 2024 as a limited revision with no requirements added or deleted, v4.0 was retired on 31 December 2024, and the future-dated requirements became mandatory on 31 March 2025. What has moved in 2026 is the FAQ layer, and it has moved toward the acquirer.
What to Put in Place
- Decide who at your business is the compliance-accepting voice, and write it down. If the sponsorship agreement gives you the PCI program, the reviewed-discussed-and-agreed step in the new FAQ 1331 is yours to perform; if it does not, it is the sponsor's, and your job is to route the request rather than answer it.
- Give the decision a record. For any ROC merchant that proposes to narrow its assessment on SAQ criteria, capture the merchant, its QSA, the SAQ relied on, the requirements to be excluded, whether they will be reported Not Tested on your direction or Not Applicable on the assessor's tested finding, the date, and who agreed. FAQ 1473 is what the file will be held against.
- Re-check ROCs in progress. An assessment begun under the May 2025 text, with 6.4.3 and 11.6.1 treated as not applicable on the redirect example, now needs your explicit agreement before it closes.
- Keep the level calculation in the merchant record: Mastercard's most recent 52 weeks, Visa's 12 months, and the date you ran it. Level 1 and 2 merchants are the ones you report on semi-annually to Mastercard, and the ones the new FAQ concerns.
- For the SAQ A book, add a field that says whether the checkout is a redirect or an embedded iframe. The script-attack criterion applies only to the iframe case, and the processor's confirmation is the easiest way to satisfy it; the ASV scan applies to both.
- Ask for the Attestation of Compliance rather than a screenshot of a portal. FAQ 1568 says the AOC is intended to be shared with requesting entities, subject to brand rules.
- Do not forget your own document. A payment facilitator above 300,000 annual Mastercard and Maestro transactions is a Level 1 service provider on Mastercard's page, with an annual ROC of its own.
The One-Line Version
The Council did not change what PCI DSS requires of a merchant. It changed who gets to say that less of it applies. Until August a merchant and its QSA could settle that between themselves and document it in the ROC; now a ROC is not narrowed on SAQ criteria unless the entity accepting the merchant's compliance has explicitly reviewed and agreed. The card brands say that entity is the acquirer, and if you run the acquirer's PCI program for your portfolio, the next such request is a decision, not a notification.
Tags
About the author
Kyle Hall
Founder
Kyle Hall is a fintech entrepreneur, software engineer, and marketing strategist with over a decade of experience in high-risk payment processing and SaaS development. He is the CEO of PayKings, a leader in high-risk merchant services, and the founder of PulseCRM, a purpose-built CRM platform for the payments industry. Kyle specializes in building custom payment processing systems and growth strategies that empower merchant services providers to scale and succeed in the digital marketplace.