A self-assessment questionnaire (SAQ) is only as good as the choice behind it. Pick one whose eligibility criteria you do not meet, and the attestation you sign describes an environment you do not have. That is worse than a long SAQ done properly, because it fails the first time anyone looks closely.
The choice turns on how card data moves through your business: which channels you accept payments in, who serves the payment page, and whether account data ever touches a system you control. Company size does not enter into it. Size affects a different question, which is whether you may self-assess at all.
This article settles both questions. It covers who decides whether you can use an SAQ, what each SAQ is for, how to read the eligibility criteria, and the mistakes that lead to the wrong form.
Who decides whether you can self-assess
The PCI Security Standards Council writes the SAQs. It does not decide who may use them. That decision belongs to the card brands and, for merchants, to your acquirer, the bank that processes your card transactions.
Each card brand defines merchant and service provider levels, usually by transaction volume and sometimes by risk or past compromise. The brand rules then say which levels may validate with an SAQ and which need a report on compliance from an assessor. The thresholds differ between brands and change from time to time, so do not rely on a number from a blog post or an old contract. Ask your acquirer what validation it expects from you, in writing.
Service providers have one option if they are allowed to self-assess: SAQ D for Service Providers. The shorter SAQs are for merchants only.
The SAQs and what each one is for
Each SAQ is a subset of the PCI DSS requirements, chosen to match a specific way of accepting cards. The descriptions below summarize the eligibility criteria in the PCI DSS 4.0.1 SAQs. They are a guide to which documents to read, not a substitute for reading them.
| SAQ | Fits when |
|---|---|
| A | Card-not-present (e-commerce, mail or telephone order) with all account data functions fully outsourced to PCI DSS compliant third parties. For e-commerce, every element of the payment page comes from the third party |
| A-EP | E-commerce where your website does not receive account data but controls how the customer or the data reaches the processor, such as a page you serve that posts directly to the processor |
| B | Imprint machines or standalone dial-out terminals only, with no electronic storage of account data |
| B-IP | Standalone, PTS-approved payment terminals with an IP connection to the processor, with no electronic storage |
| C-VT | Card numbers keyed manually, one transaction at a time, into a virtual terminal hosted by a PCI DSS compliant third party |
| C | Payment application systems connected to the internet, with no electronic storage of account data |
| P2PE | Payment terminals that are part of a validated point-to-point encryption solution listed by the Council |
| SPoC | Card acceptance on a commercial off-the-shelf mobile device using a solution listed by the Council for software-based PIN entry |
| D for Merchants | Every merchant that is not eligible for any other SAQ |
| D for Service Providers | Every service provider that its card brands allow to self-assess |
Most of the merchant SAQs other than D share a condition: you do not store account data electronically. Several allow paper records, such as receipts, provided they are not received electronically.
Reading the eligibility criteria
Each SAQ opens with a list of eligibility criteria. You must meet every one of them. If a single criterion is false for any channel the SAQ covers, that SAQ is the wrong one. A few distinctions cause most of the disputes.
SAQ A or SAQ A-EP
The question is who delivers the payment page to the customer's browser. If the entire payment form comes from your payment provider, through a redirect or an inline frame, SAQ A is the candidate. If your server delivers the page and your code renders the form, even when the card number goes straight from the browser to the processor, SAQ A-EP is the candidate. Your web server can change what the customer sees and where their data goes, so it is in scope.
The Council revised SAQ A in early 2025. The revision removed requirements 6.4.3 and 11.6.1 from it and added an eligibility criterion: the merchant confirms its site is not susceptible to attacks from scripts that could affect its e-commerce systems. Check the current SAQ A and the Council's guidance on that criterion before you sign, because it is newer than most advice you will find.
SAQ P2PE
Only a validated solution on the Council's list of point-to-point encryption solutions qualifies. A terminal vendor's own description of its encryption does not, however strong that encryption is. If your solution is not listed, your assessor or acquirer may still recognize its effect on risk, but you are not eligible for SAQ P2PE.
SAQ B-IP, C-VT or C
These three separate on the device that touches the card number. A standalone approved terminal connected over IP points to B-IP. A browser on a computer keying transactions into a hosted virtual terminal points to C-VT. A payment application running on your own systems points to C. The criteria include conditions about how those devices are segmented from the rest of your network, and those conditions are the ones people skip.
When you accept cards in more than one way
Many merchants have more than one channel: a website, a phone line, a counter. The SAQs do not combine neatly. Depending on your acquirer, you may complete a separate SAQ for each channel or a single SAQ that covers all of them, which in practice is often SAQ D. Ask your acquirer which it wants before you start, since the answer changes how much work you have.
Watch for channels nobody thinks of as a channel. A support agent who types a caller's card number into your e-commerce checkout on the caller's behalf has created a card-not-present channel through your own workstation. That can remove your eligibility for SAQ A even though the website itself qualifies.
What the completed SAQ contains
An SAQ is more than a list of yes or no answers. It has three sections: assessment information about your business and its payment channels, the questionnaire itself, and validation and attestation details. The last section is your Attestation of Compliance, the signed statement your acquirer or customer actually receives.
For each requirement you record a response, such as in place, in place with a compensating control, not applicable, or not in place. Appendices hold the compensating controls worksheet and your explanation for every requirement you marked not applicable. An unexplained "not applicable" is the first thing an acquirer's reviewer questions.
Choosing, step by step
Map every payment channel. For each, write down how a card number enters your business, which systems it passes through, and where it leaves.
Identify who touches the PAN. For each channel, name the system or third party that receives the primary account number and, for e-commerce, the party that serves the payment page.
Read the candidate SAQ's eligibility criteria. Answer each one honestly. One "no" sends you to the next candidate.
Confirm with your acquirer. Send the channel map and your proposed SAQ. A short written confirmation avoids a dispute at renewal.
Keep the reasoning. Record why you chose the SAQ and which criteria you confirmed. Next year, someone will need to check whether any of it changed.
The PCI DSS framework page summarizes the requirements the SAQs draw from, and the changes in PCI DSS 4.0 explain why some SAQs grew longer under the new version. Terms such as PAN and account data are defined in the glossary.
How TrustLynce helps
TrustLynce maps the requirements in your chosen SAQ to your controls and collects the supporting evidence on a schedule through evidence collection, so next year's questionnaire starts from records rather than memory. Third parties that handle your payments sit in the vendor inventory with their review dates.