A PCI DSS Self-Assessment Questionnaire (SAQ) is the form a merchant uses to attest compliance; its type depends on how much of the payment page and cardholder data the merchant touches. For PayFacs, PSPs and ISVs, checking whether each merchant qualifies for SAQ A, A-EP or D belongs in onboarding, since a certified provider never makes a merchant compliant alone.
Many merchants believe that using a certified PSP or cloud provider makes them compliant by default. This article, first written by Damien Fleuriot and updated in October 2026 for PCI DSS v4.0.1, explains what an SAQ is, why provider certification is not enough, who qualifies for SAQ A, A-EP and D, what follows a card data breach, and how operators should check their merchants' scope at onboarding.
What is a PCI DSS SAQ and who has to fill one?
The PCI Security Standards Council publishes several self-assessment questionnaires so that merchants not required to undergo an on-site assessment can validate their compliance. Each SAQ lists the requirements that apply to a specific way of accepting cards, from fully outsourced e-commerce to merchants that store card data.
Which SAQ applies, and whether an assessor must countersign it, is set by the merchant's acquirer or payment provider according to card scheme rules, volume and channel.
Why does a PCI DSS certified PSP or hosting provider not make a merchant compliant?
Because compliance is shared. A validated PSP covers the systems it operates; a validated cloud provider covers its infrastructure. The merchant remains responsible for everything it controls: its website, the scripts on its pages, its staff, its change management and its own systems.
Providers say so themselves: Google Cloud's PCI DSS guidance and similar documents from other providers describe shared responsibility matrices, where the provider helps the customer meet requirements rather than meeting them on its behalf.
Who qualifies for SAQ A?
Merchants whose card data functions are entirely outsourced to validated third parties. For e-commerce, every element of the payment page delivered to the shopper's browser must come only and directly from a PCI DSS validated provider, through a redirect or an iframe, and the merchant must not store, process or transmit card data.
In January 2025, the PCI Security Standards Council removed requirements 6.4.3 and 11.6.1 on payment page scripts from SAQ A, and replaced them with an eligibility criterion: the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems, as URM Consulting summarizes. SAQ A still includes requirements on passwords, patches, vendor management and incident response.
When does a merchant fall into SAQ A-EP?
When its website does not receive card data itself but can affect the security of the payment transaction or the integrity of the payment page. Typical cases are a merchant page that hosts the payment form fields through direct post or JavaScript, or that controls how the shopper reaches the provider's page.
That is the point many merchants overlook: hosting the page that leads to payment can be enough to move from SAQ A to SAQ A-EP, which covers a large part of the full standard, from network security to vulnerability management and testing.
What does SAQ D require from an e-commerce merchant?
Nearly everything. SAQ D for merchants applies to those that do not meet the criteria of any other SAQ, such as e-commerce merchants that accept card data on their own website or store card data electronically. It covers requirements 1 to 12 of PCI DSS: networks, configurations, encryption, storage and deletion of card data, patching, access control, logging, testing and policies.
At that level, PCI DSS becomes a strategic program rather than a form, and most merchants are better served by redesigning their checkout to reduce scope.
What happens after a cardholder data breach?
A forensic investigation by a PCI Forensic Investigator, notification to acquirers and card schemes, possible fines and compensation claims from the schemes, and often a move to stricter validation, such as an annual on-site assessment regardless of volume.
Costs go well beyond fines: incident response, legal work, lost revenue and damaged trust with customers, partners and investors. Investigations frequently trace breaches to a compromised payment page or an unpatched content management system on the merchant side.
How should a PayFac or PSP check its merchants' PCI DSS scope at onboarding?
By asking how each merchant will accept payments before approving it: hosted page, iframe, hosted fields or direct integration, who hosts the pages and which scripts run on them. The answers determine the SAQ type, which the operator records and renews every year.
On NORBr, operators collect these answers in KYB forms and questionnaires and track documents through document review and compliance, while hosted payment pages in Smart Checkout help merchants stay in the simplest scope. The PCI DSS compliance cost article covers the operator's own obligations.
_%2520a%2520game%2520changer%2520for%2520digital%2520transactions_-Cover.webp){kind=spacer}
