Which PCI SAQ do you need? How to pick the right one

Why does choosing the right SAQ matter?

Because the questionnaire defines which PCI DSS requirements you attest to, and an attestation on the wrong one does not reflect your real environment. A self-assessment questionnaire (SAQ) is the form most smaller merchants use each year to validate PCI DSS compliance. Each SAQ covers a different subset of the standard, from a short list for fully outsourced payments to the full standard in SAQ D.

Every SAQ starts with eligibility criteria, and a merchant has to meet all of them for that payment channel. The SAQ A-EP form puts it plainly: if a merchant has applicable requirements the SAQ does not cover, "it may be an indication that this SAQ is not suitable for the merchant's environment." For a law firm taking retainers online, a nonprofit running a donation page, or a practice with a client payment portal, the questionnaire choice is the first compliance decision of the year, and the one most often made out of habit.

Who decides which SAQ your firm uses?

Your acquirer, or whoever you submit the SAQ to, has the final say. When the PCI Security Standards Council released the SAQs for PCI DSS v4.0.1, it encouraged every entity "to first contact the entity to which the SAQ will be submitted" and to confirm it meets all eligibility criteria before starting.

In practice, the acquirer is the bank or processor that handles your card transactions. Many processors assign an SAQ type in their compliance portal based on a short questionnaire. That assignment is only as good as your answers, so it is worth checking against how payments actually flow today, especially if you have added a website form, a phone payment process or a new vendor since last year.

Which PCI SAQ do you need for each way you take cards?

Match the questionnaire to each channel through which your firm accepts cards. The main PCI SAQ types for merchants:

• SAQ A: e-commerce or mail and telephone order where all card processing is outsourced to a PCI DSS compliant provider, for example a website that redirects customers to the processor's page or embeds the processor's payment form.
• SAQ A-EP: e-commerce only, where your website "does not receive account data but controls how customers, or their account data, are redirected" to a compliant provider. This is for partially outsourced websites.
• SAQ B: merchants that use only imprint machines or standalone dial-out terminals not connected to other systems or to the internet (SAQ B).
• SAQ B-IP: standalone, PCI-approved payment terminals that connect over IP.
• SAQ C-VT: payments keyed into a virtual terminal "accessed by an Internet-connected web browser," hosted by a compliant provider, on a computer with no attached card readers (SAQ C-VT).
• SAQ C: merchants with a payment application system connected to the internet that do not store card data electronically.
• SAQ P2PE: all payments through "a validated PCI-listed P2PE solution," with the terminals as the only systems that handle card data (SAQ P2PE). It does not apply to e-commerce.
• SAQ SPoC: card acceptance on a commercial phone or tablet with a secure card reader, using a solution on the Council's validated list (PCI SSC).
• SAQ D for Merchants: anyone who does not meet the criteria of a narrower SAQ. SAQ D for Service Providers is the only SAQ for eligible service providers.

A firm with more than one channel, such as a website form and a front-desk terminal, needs to confirm with its acquirer whether one SAQ covers all of them or whether more than one applies.

What changed for SAQ A in 2025?

Two things: two technical requirements came out, and a new eligibility criterion came in. In January 2025 the Council revised SAQ A, removing Requirements 6.4.3 and 11.6.1, which deal with scripts on payment pages, along with the related targeted risk analysis in Requirement 12.3.1. The revised SAQ A took effect on 31 March 2025, when the October 2024 version was retired.

In their place, a merchant must now confirm that its site "is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)." PCI FAQ 1588 explains two ways to meet it: protect the page using techniques such as those in Requirements 6.4.3 and 11.6.1, applied by the merchant or a third party, or obtain confirmation from a PCI DSS compliant provider that its embedded payment page or form includes script attack protections when implemented according to its instructions. The FAQ says this criterion applies to merchants that embed a provider's payment form, such as an iframe. It does not apply to merchants that redirect customers to the provider or fully outsource payments.

What should you confirm before signing this year's attestation?

Confirm how card data actually moves, then confirm the evidence behind each eligibility box you check. A practical checklist for this quarter:

• Map every payment channel: website, email or phone payments, terminals, mobile readers and any recurring billing.
• For each channel, read the eligibility criteria of the SAQ you plan to use, and note any criterion you cannot confirm.
• If you embed a payment form, request written confirmation of script attack protections from your provider, or document the protections you run yourself.
• Collect current Attestations of Compliance from each payment provider and website host, and check that they cover the services you use.
• Confirm that staff do not receive card numbers by email, chat or text, and that any paper records are stored and destroyed securely.
• Check your acquirer's portal for the SAQ type it has assigned, and raise any mismatch before you sign.

If a channel does not fit any narrower SAQ, the fastest route to a lighter questionnaire is often to change the process, for example by moving phone payments to a provider-hosted payment link.

How does s90 help?

s90 offers PCI DSS support as a standalone add-on for firms in Los Angeles and Orange County that take cards. We map your payment channels, help you confirm the right SAQ with your acquirer, gather the provider evidence, and keep the systems in scope configured and documented. If your attestation is coming up, we are happy to review it with you.