The right SAQ depends on how you accept card payments and in what capacity. It does not depend on your size, your revenue, or what your payment provider’s onboarding email asked for. The picker below gives you the usual answer. The four stories after it are the exceptions we meet most.
SAQ picker
Which SAQ fits how you take payments?
A few questions about one payment channel. About a minute.
Who is completing the assessment?
Do you store card data electronically?
Anywhere on your systems: databases, spreadsheets, call recordings, logs, backups. Paper records do not count here.
Which payment channel are you checking?
Run the picker once per channel. If you use several, your acquirer decides whether you submit one SAQ per channel or SAQ D.
How does your website take the payment?
How do card details reach you by mail or phone?
What kind of payment terminals do you use?
Likely questionnaire
SAQ A
Card-not-present merchants who have outsourced every card data function to PCI DSS compliant providers.
Confirm in the SAQ’s eligibility criteria
- Your systems and premises never store, process or transmit card data.
- For e-commerce, every element of the payment page comes directly from the compliant provider.
- For e-commerce, your site is protected against scripts that could affect the payment process.
Likely questionnaire
SAQ A-EP
E-commerce merchants whose website does not receive card data but controls how it reaches the provider.
Confirm in the SAQ’s eligibility criteria
- Your website does not receive card data, but serves the payment page or controls how data is sent.
- All payment processing is done by a PCI DSS compliant provider.
- You do not store card data electronically.
Likely questionnaire
SAQ B
Merchants using only imprint machines or standalone, dial-out terminals.
Confirm in the SAQ’s eligibility criteria
- Terminals connect to the processor over a phone line, not the internet.
- Terminals are not connected to any other system in your environment.
- You do not store card data electronically.
Likely questionnaire
SAQ B-IP
Merchants using only standalone, PTS-approved terminals with an IP connection to the processor.
Confirm in the SAQ’s eligibility criteria
- Terminals are PTS-approved and listed by the PCI SSC.
- They connect only to the processor, not to other systems in your environment.
- You do not store card data electronically.
Likely questionnaire
SAQ C-VT
Merchants who key transactions one at a time into a provider’s web-based virtual terminal.
Confirm in the SAQ’s eligibility criteria
- The virtual terminal is provided and hosted by a PCI DSS compliant provider.
- It is used on a computer isolated from other systems, with no card reader attached.
- You do not store card data electronically.
Likely questionnaire
SAQ C
Merchants with payment application systems connected to the internet, and no electronic storage.
Confirm in the SAQ’s eligibility criteria
- The payment system and its internet connection are segmented from the rest of your environment.
- The payment environment is at a single location.
- You do not store card data electronically.
Likely questionnaire
SAQ P2PE
Merchants using only hardware terminals from a validated, PCI-listed P2PE solution.
Confirm in the SAQ’s eligibility criteria
- Every terminal belongs to the listed P2PE solution and is managed through it.
- Card data is entered only through those terminals, following the solution’s instruction manual.
- You do not store card data electronically.
Likely questionnaire
SAQ D for Merchants
Every merchant the shorter SAQs do not cover, including any electronic storage of card data.
Confirm in the SAQ’s eligibility criteria
- All applicable PCI DSS requirements are in scope.
- Depending on your volumes, your acquirer may require a QSA assessment and a Report on Compliance instead.
Likely questionnaire
SAQ D for Service Providers
The only SAQ for service providers the payment brands allow to self-assess.
Confirm in the SAQ’s eligibility criteria
- The payment brands decide whether you may self-assess; higher-volume providers need a Report on Compliance from a QSA.
- Your customers will ask for your Attestation of Compliance.
Map your data flows first
If you do not know where card data is stored, no SAQ can be chosen safely yet.
Where to start
- Trace every place card data enters, travels and rests.
- Include call recordings, logs, spreadsheets and backups.
This is a starting point, not a determination. Your acquirer decides which SAQ you submit, and the eligibility criteria in the SAQ itself are what count.
Check it with a QSAEvery SAQ at a glance
| Questionnaire | For |
|---|---|
| SAQ A | Card-not-present merchants who have outsourced every card data function to PCI DSS compliant providers. |
| SAQ A-EP | E-commerce merchants whose website does not receive card data but controls how it reaches the provider. |
| SAQ B | Merchants using only imprint machines or standalone, dial-out terminals. |
| SAQ B-IP | Merchants using only standalone, PTS-approved terminals with an IP connection to the processor. |
| SAQ C-VT | Merchants who key transactions one at a time into a provider’s web-based virtual terminal. |
| SAQ C | Merchants with payment application systems connected to the internet, and no electronic storage. |
| SAQ P2PE | Merchants using only hardware terminals from a validated, PCI-listed P2PE solution. |
| SAQ D for Merchants | Every merchant the shorter SAQs do not cover, including any electronic storage of card data. |
| SAQ D for Service Providers | The only SAQ for service providers the payment brands allow to self-assess. |
The Level 1 merchant that did not need 300 requirements
A vending operator takes roughly a million card transactions a week, which makes it a Level 1 merchant, which means a Report on Compliance signed by a QSA. Everyone assumed that meant the full standard. The only path a card takes in that business is through terminals leased from the acquirer, approved under the Council’s terminal standard with encryption at the reader, where the vending machine’s controller does nothing more than pass the traffic along.
The merchant level decides the form of the validation: a report rather than a questionnaire. It does not decide the depth. The scope decides which requirements apply. We wrote to the acquirer under the Council’s published guidance for exactly this case and asked it to agree that the report could focus on the requirements of SAQ B-IP, the questionnaire for standalone terminals on a network. It agreed, on conditions: approved terminals only, no card data anywhere beyond the terminal, and a reassessment on any change. The work then moved to where the risk actually is: the terminal inventory, tamper inspections, staff training, and the responsibility matrix with the acquirer.
Same website, two different SAQs
A digital agency built and hosted a gift-card site for a large retailer. Payments went through a payment provider’s iFrame; all processing was outsourced to a compliant third party. The agency started filling in SAQ A.
Only merchants can use SAQ A. Every questionnaire except SAQ D is for merchants only. Here the retailer was the merchant, and the agency was its service provider. For exactly the same environment, the retailer would validate with a short SAQ A, while the agency, running that same site on the retailer’s behalf, had to take the SAQ D path for service providers, including the requirements about protecting the integrity of the page that carries the payment form. The work is the same. The role, and therefore the form, is different. Before you choose an SAQ, ask “in what capacity?”. Most people stop at “we use an iFrame”.
The hotel that had been filling in SAQ D for nothing
A large hotel validated with SAQ D every year, the longest questionnaire, with all the requirements. Its terminals were part of a point-to-point encryption solution listed by the Council, and its property management system had been tokenised. Card numbers never reached anything the hotel ran. The only thing left touching card data was the handful of PCs where agents keyed numbers into a virtual terminal for phone bookings, which points at SAQ C-VT, a fraction of the length. The team had been answering two hundred questions a year about systems that were no longer in scope, because nobody had re-asked the question after the terminals changed.
The provider asked for SAQ A, so it must be SAQ A
A healthcare platform received a request from its payment provider for an SAQ A, and asked us to help fill it in. In the first conversation the client mentioned that it stored card data. That single fact rules SAQ A out until it is cleared up: SAQ A exists for merchants that never touch the card. The provider’s request was a default, sent to every merchant on that integration. It was not an assessment of this one.
What people get wrong
They let the level decide the depth. The level decides whether you file a questionnaire or a report. Scope decides what is in it.
They let outsourcing decide the form. Outsourcing the payment page takes most requirements away from a merchant. It takes nothing away from a service provider, because the service provider is the one being outsourced to.
They let the provider’s email decide. Your acquirer and your payment provider send the questionnaire they expect for a typical customer. You are the only one who knows whether you are typical.
They never re-ask. Terminals change, systems get tokenised, a new channel appears. The questionnaire that was right three years ago describes an environment that no longer exists, in either direction.
The level decides whether you file a questionnaire or a report. Scope decides what is in it.