Which SAQ applies to you: 14, 27, 139, or all of them

Your SAQ is decided by how account data reaches your processor — not by your revenue, your industry or your headcount. For an e-commerce merchant the whole decision reduces to one question about the checkout: does any element of the payment page originate from your own website?

PCI SSC answers it in a single sentence: “If any element of a payment page delivered to consumers’ browsers originates from the merchant’s website, SAQ A does not apply; however, SAQ A-EP may be applicable.” The gap between those two answers is 27 requirements against 139.

The e-commerce table

Reproduced from the PCI DSS Self-Assessment Questionnaire Instructions and Guidelines, v4.0.1 Revision 1 (April 2025), page 10.

Two notes attached to that table matter. The SAQ A counts carry an asterisk in the source — “Applicable requirements are identified via explanatory notes in SAQ A” — because SAQ A is published as one document, and notes inside it identify which of its requirements apply to a merchant with no access to its own webpage. And the table covers e-commerce only: “Criteria for SAQ A mail/telephone order (MOTO) channels are not included in this table.”

How to tell which row you are on

Open your own checkout and find where the card number field comes from.

• The customer leaves your domain for the processor’s, or the field sits in an iframe served by the processor and nothing of yours is inside it — SAQ A.
• The field is in your page’s own DOM and the value is posted from the customer’s browser straight to the processor — SAQ A-EP. This is the Direct Post row.
• Your page loads a script that then builds the payment interface: an in-page overlay, a drop-in widget, a hosted-fields library your page calls — SAQ A-EP. The script does not have to touch the card number. It only has to provide “functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor”.
• Account data reaches a server you run, or is stored anywhere in your systems — SAQ D for Merchants, and all of PCI DSS.

The third bullet is where merchants arrive without noticing. A redirect checkout gets replaced by an in-page one because it converts better; a front-end team ships it in a sprint; the merchant moves from 27 applicable requirements to 139. Nothing about that change looks like a compliance decision, and the SAQ filed the following year is usually the same one filed the year before. The reverse move is the cheapest scope reduction available to an e-commerce merchant, and it is a front-end change, not a security project.

The nine SAQ types

Six of the short-form SAQs — B, B-IP, C-VT, C, P2PE and SPoC — share one disqualifier: the merchant does not store account data in electronic format. A and A-EP go further. Any account data retained must be on paper, and “these documents are not received electronically”. A file containing card data arriving by email ends eligibility on its own. Which SAQ you are on settles which requirements apply; what you have to hold as evidence against each of them is the next question and a longer one.

Three things that decide eligibility and are routinely got wrong

Eligibility is per payment channel, not per company

Every one of the eight short-form eligibility lists ends the same way: the merchant confirms it meets the criteria “for this payment channel”. A retailer with a website and dial-out terminals in its stores has two channels, and may complete more than one SAQ. Choosing a single questionnaire for the whole organisation because one channel fits it is not what the criteria ask for.

Service providers have exactly one

The guidance is flat about it: “For service providers eligible to conduct a self-assessment, the only applicable SAQ is SAQ D for Service Providers.” All eight short-form SAQs carry the line “not applicable to service providers” on their own face. There is no SAQ A for a hosting provider, a payment aggregator or a contact centre, however little card data passes through it. Two consequences follow: service providers pick up requirements no merchant SAQ contains, 11.4.7 among them, and in India a regulated payment aggregator is carrying an RBI obligation layered on top of the PCI one.

Your acquirer decides whether you may file an SAQ at all

Being “SAQ-eligible” is two tests, not one. The entity must be “eligible to conduct self-assessments to validate their PCI DSS compliance, according to payment brand compliance programs”, and it must meet “the SAQ Eligibility Criteria specified in the chosen SAQ”. Only the second is yours to apply. The SAQs are the alternate validation tool for entities “that are not required by an acquirer or payment brand(s) to submit a PCI DSS Report on Compliance (ROC)” — meeting SAQ A’s criteria exactly does not help if your acquirer has put you on a ROC. What each of those two routes produces, and who signs it, is a separate question. Both end in an Attestation of Compliance.

What v4.x added to SAQ A, and why

SAQ A grew between v3.2.1 and v4.x, and the guidance names the reason: “SAQ A for PCI DSS v4.x includes additional security controls needed to address common breaches that are targeting SAQ A merchants, specifically to secure webpages that 1) redirect payment transactions to a PCI DSS compliant TPSP or 2) include a PCI DSS compliant TPSP’s embedded payment page/form. To mitigate these common breaches, Requirements 11.3.2 and 11.3.2.1 are included in SAQ A.”

Those two look like one obligation. They are not.

• 11.3.2 — external vulnerability scans “at least once every three months”, “by a PCI SSC Approved Scanning Vendor (ASV)”, with vulnerabilities resolved and “ASV Program Guide requirements for a passing scan” met. The standard adds that this requirement “is not eligible for the customized approach”.
• 11.3.2.1 — external vulnerability scans “performed after any significant change”, with vulnerabilities scored 4.0 or higher by CVSS resolved and rescans conducted as needed. Its final bullet reads: “Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).”

So the smallest merchant the standard describes — fully outsourced, 14 or 27 applicable requirements, no card data anywhere in its systems — runs on two external scanning clocks. One is quarterly and closed to everyone except an ASV. The other is triggered by change rather than by the calendar, and the requirement text itself says who may perform it. Neither is a penetration test, and none of the three substitutes for another.

Read the current revision

Revision 1 of the guidance, April 2025, exists partly because the counts in the first table were wrong before it. Its own change log: “Corrected table (Common e-commerce methods and applicable SAQs) to accurately reflect the number of applicable PCI DSS requirements.” The same revision made two edits that belong together. It “Removed Requirements 6.4.3 and 11.6.1 from section ‘Importance of new requirements added to SAQ A for PCI DSS v4.x’”, and it added a new SAQ A eligibility criterion for e-commerce merchants: “The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” Read together, the payment-page script question moved out of the questionnaire and into the gate in front of it. A merchant who cannot make that confirmation is not eligible for SAQ A, whatever its checkout looks like.

Version discipline is cheap here and worth having. PCI DSS v3.2.1 retired on 31 March 2024 and v4.0 on 31 December 2024; v4.0.1 is the sole active version, and its own Table 6 records both dates. The v4.x SAQs were published on 15 October 2024 and the guidance reached Revision 1 in April 2025. Keep the guidance’s own warning: “Merchants should not assume that a particular SAQ for both PCI DSS v3.2.1 and v4.x are the same.”

Both documents — the SAQ Instructions and Guidelines, and each SAQ with its eligibility criteria and Attestation of Compliance — are free from the PCI SSC Document Library. Read the criteria in the SAQ you think applies before you start filling it in, and then do the thing the guidance asks for first: entities completing SAQs are “encouraged to contact the organizations that manage compliance programs and to which the SAQ will be submitted — for example, an acquirer (merchant bank) or the payment brands — to confirm they are eligible to complete an SAQ to validate PCI DSS compliance, and to understand any specific requirements or instructions.” The eligibility criteria tell you which questionnaire fits your architecture. Your acquirer tells you whether you may file one.