There are ten Self-Assessment Questionnaires in PCI DSS v4.0.1 and only one of them describes your environment correctly. This guide follows the official PCI SSC decision flow — storage first, then P2PE and SPoC, then payment channel — and sets out the complete eligibility criteria for every SAQ so you can check yourself against them before you commit.
Service providers have exactly one option: SAQ D for Service Providers, and only when their compliance-accepting entity has determined they are eligible to self-assess. Level 1 service providers, designated entities under PCI DSS Appendix A3, and anyone with an acquirer-mandated Report on Compliance must engage a QSA instead.
Merchants continue through the flow below. The same gate applies: Level 1 merchants and anyone whose acquirer has mandated a ROC cannot self-assess, regardless of how simple the environment looks.
Step 2 — the official merchant decision flow
The PCI SSC chart “Which SAQ Best Applies to My Environment?” asks three questions before it asks anything about your payment channels. Most incorrect SAQ selections happen because merchants skip straight to the channel question.
1
Do you store account data electronically?
Any electronic storage of PAN, cardholder name, service code, expiration date, or sensitive authentication data — including legacy data sitting in an old database — means SAQ D for Merchants. Paper receipts and printed reports are fine.
2
Do you use a PCI-listed P2PE solution?
If all payment processing runs through a solution on the PCI SSC list of validated P2PE Solutions and you have implemented the P2PE Instruction Manual, SAQ P2PE applies — whether the channel is card-present or MOTO.
3
Do you use a PCI-listed SPoC solution?
A validated SPoC solution — a PCI-listed SCRP paired with your own phone or tablet — points to SAQ SPoC, for attended card-present acceptance only.
4
Which payment channels do you accept?
Only now does the flow branch by channel: e-commerce, MOTO, and card-present. Each channel is evaluated on its own criteria.
Step 3 — branch by channel
E-commerce
Every payment-page element delivered only and directly by a compliant provider → SAQ A. Your site delivers any element, or controls the redirect → SAQ A-EP. Your systems touch the account data → SAQ D.
MOTO
Fully outsourced to a compliant provider (IVR or provider-run call centre) → SAQ A. Dial-out terminals → SAQ B. IP terminals → SAQ B-IP. Virtual terminal → SAQ C-VT. Payment application → SAQ C.
Card-present
Imprint or dial-out terminals → SAQ B. Standalone IP-connected PTS POI → SAQ B-IP. Virtual terminal on an isolated PC → SAQ C-VT. Payment application on a single-site LAN → SAQ C.
Multi-channel merchants: each channel must independently meet the eligibility criteria of the SAQ used for it, so you may need more than one SAQ. PCI SSC advises merchants with more than one payment channel to consult their payment brands and acquirer about validation and reporting requirements. Where channels cannot each satisfy the same criteria, SAQ D for Merchants covers the remainder.
SAQ comparison at a glance
Comparison of PCI DSS v4.0.1 Self-Assessment Questionnaires and who each one applies to
All account-data functions are fully outsourced to PCI DSS compliant third-party service providers, and every element of the payment page delivered to the customer's browser comes only and directly from that provider (a full redirect or a provider-hosted iframe).
Your website does not receive account data, but it controls how the customer or their account data is redirected to a compliant provider — Direct Post, JavaScript-created payment forms, or hosted fields your page assembles.
Card-present and MOTO merchants using imprint machines or dial-out terminals
Only imprint machines and/or standalone dial-out terminals connected to your processor over a phone line, with no Internet connectivity and no electronic storage of account data.
Merchants using standalone IP-connected PTS POI terminals
Only standalone PCI-listed approved PTS POI devices connected via IP to the payment processor, isolated from other systems, with no electronic storage of account data.
Merchants with a payment application connected to the Internet
A payment application on the same device or LAN as an Internet connection, at a single location, segmented from other systems, with no electronic storage of account data.
Merchants using a validated PCI-listed P2PE solution
All payment processing runs through a solution on the PCI SSC list of validated P2PE Solutions, with every control from the P2PE Instruction Manual (PIM) implemented.
Attended card-present merchants using a validated PCI-listed SPoC solution
A PCI-listed SCRP paired with your own commercial phone or tablet, from a solution on the PCI SSC list of validated SPoC Solutions, used for attended card-present acceptance only.
Any merchant that stores account data electronically, mixes channels that cannot each meet the same criteria, or otherwise fails a short-form SAQ's eligibility criteria.
Service providers whose compliance-accepting entity has determined they may self-assess rather than undergo a QSA-led Report on Compliance.
Eligibility criteria, SAQ by SAQ
These are the criteria our selector checks, mirrored from the PCI SSC Self-Assessment Questionnaire Instructions and Guidelines v4.0.1 r1. Every criterion must be true — a single “no” removes eligibility for that SAQ.
SAQ A
Card-not-present merchants (e-commerce and MOTO)
All account-data functions are fully outsourced to PCI DSS compliant third-party service providers, and every element of the payment page delivered to the customer's browser comes only and directly from that provider (a full redirect or a provider-hosted iframe).
We accept only card-not-present (e-commerce) transactions on this channel.
All processing of account data is entirely outsourced to a PCI DSS compliant TPSP / payment processor.
We do not electronically store, process, or transmit any account data on our systems or premises — we rely entirely on the TPSP.
We have confirmed that our TPSP(s) are PCI DSS compliant for the services we use.
Any account data we retain is on paper only (printed reports/receipts) and is not received electronically.
Every element of the payment page(s)/form(s) delivered to the customer's browser originates only and directly from a PCI DSS compliant TPSP.
We have confirmed that our site is not susceptible to attacks from scripts that could affect our e-commerce systems.
Watch out: v4.0.1 adds an explicit script criterion: you must confirm your site is not susceptible to attacks from scripts that could affect your e-commerce systems (Requirements 6.4.3 and 11.6.1 sit behind this).
SAQ A-EP
Partially outsourced e-commerce merchants
Your website does not receive account data, but it controls how the customer or their account data is redirected to a compliant provider — Direct Post, JavaScript-created payment forms, or hosted fields your page assembles.
We accept only e-commerce transactions on this channel.
All processing of account data, with the exception of the payment page, is entirely outsourced to a PCI DSS compliant TPSP / payment processor.
Our e-commerce website does NOT receive account data but controls how customers, or their account data, are redirected to a PCI DSS compliant TPSP / payment processor.
If our website is hosted by a TPSP, that TPSP is compliant with all applicable PCI DSS requirements (including PCI DSS Appendix A if it is a multi-tenant hosting provider).
Each element of the payment page(s) delivered to the customer's browser originates from either our website or a PCI DSS compliant TPSP.
We do not electronically store, process, or transmit any account data on our systems or premises — we rely entirely on the TPSP.
We have confirmed the TPSP(s) are PCI DSS compliant for the services we use.
Any account data we retain is on paper only (printed reports/receipts) and is not received electronically.
Watch out: If any element of your payment page is delivered by your own site, SAQ A is not available to you no matter how little data you touch.
SAQ B
Card-present and MOTO merchants using imprint machines or dial-out terminals
Only imprint machines and/or standalone dial-out terminals connected to your processor over a phone line, with no Internet connectivity and no electronic storage of account data.
We use only imprint machines and/or only standalone dial-out terminals (connected via a phone line to our processor) to take card details.
The standalone dial-out terminals are NOT connected to any other systems within our environment.
The standalone dial-out terminals are NOT connected to the Internet.
We do not store account data in electronic format.
Any account data we retain is on paper only (printed reports/receipts) and is not received electronically.
Watch out: The moment a terminal reaches the processor over IP, SAQ B stops applying and SAQ B-IP (or SAQ D) becomes the path.
SAQ B-IP
Merchants using standalone IP-connected PTS POI terminals
Only standalone PCI-listed approved PTS POI devices connected via IP to the payment processor, isolated from other systems, with no electronic storage of account data.
We use only standalone, PCI-listed approved PTS POI devices (excluding SCRs and SCRPs) connected via IP to our payment processor.
The standalone IP-connected POI devices are validated to the PTS POI program as listed on the PCI SSC website (an expired listing is not validated — check with your acquirer).
The standalone IP-connected PTS POI devices are NOT connected to any other systems within our environment (segmentation is acceptable).
The only transmission of account data is from the approved PTS POI devices to the payment processor.
The PTS POI device does NOT rely on any other device (computer, mobile phone, tablet) to connect to the processor.
We do not store account data in electronic format.
Any account data we retain is on paper only (printed reports/receipts) and is not received electronically.
Watch out: Secure Card Readers (SCR) and SCRPs are explicitly excluded from SAQ B-IP, and the device must not rely on a computer, phone, or tablet to reach the processor.
SAQ C-VT
Merchants keying transactions into a third-party virtual terminal
A single isolated computer with a keyboard and a browser, used one transaction at a time against a provider-hosted virtual payment terminal.
The only payment processing on this channel is via a virtual payment terminal accessed by an Internet-connected web browser.
The virtual payment terminal solution is provided and hosted by a PCI DSS compliant TPSP.
We access the virtual terminal via a computer that is isolated in a single location (not connected to other locations or systems).
The computer does NOT have software installed that causes account data to be stored (no batch processing or store-and-forward).
The computer does NOT have any attached hardware (e.g. card readers) that captures or stores account data.
We do not otherwise receive, transmit, or store account data electronically through any channel.
Any account data we retain is on paper only (printed reports/receipts) and is not received electronically.
Watch out: Any attached card reader, any store-and-forward or batch capability, or any other electronic acceptance channel removes eligibility.
SAQ C
Merchants with a payment application connected to the Internet
A payment application on the same device or LAN as an Internet connection, at a single location, segmented from other systems, with no electronic storage of account data.
We have a payment application system and an Internet connection on the same device and/or same local area network (LAN).
The payment application system is NOT connected to any other systems within our environment (segmentation is acceptable).
The physical location of the POS environment is NOT connected to other premises or locations, and any LAN is for a single store only.
We do not store account data in electronic format.
Any account data we retain is on paper only (printed reports/receipts) and is not received electronically.
Watch out: The POS location must not be connected to other premises or locations — multi-site shared networks push you to SAQ D.
SAQ P2PE
Merchants using a validated PCI-listed P2PE solution
All payment processing runs through a solution on the PCI SSC list of validated P2PE Solutions, with every control from the P2PE Instruction Manual (PIM) implemented.
All payment processing is via a validated PCI-listed P2PE solution (a solution with an expired validation is not ‘validated’ — check with your acquirer).
The only systems in our environment that store, process, or transmit account data are the payment terminals from that validated PCI-listed P2PE solution.
We do not otherwise receive, transmit, or store account data electronically.
Any account data we retain is on paper only (printed reports/receipts) and is not received electronically.
We have implemented all controls in the P2PE Instruction Manual (PIM) provided by the P2PE Solution Provider.
Watch out: An expired listing is not a validated solution. "Encrypting terminals" that are not PCI-listed P2PE do not qualify.
SAQ SPoC
Attended card-present merchants using a validated PCI-listed SPoC solution
A PCI-listed SCRP paired with your own commercial phone or tablet, from a solution on the PCI SSC list of validated SPoC Solutions, used for attended card-present acceptance only.
All payment processing is via an ATTENDED card-present channel (no unattended terminals, no MOTO, no e-commerce).
All cardholder data entry is via an SCRP that is part of a validated SPoC solution approved and listed by PCI SSC (non-PTS-listed magnetic-stripe readers are not eligible).
The only systems in our SPoC environment that store, process, or transmit account data are those used as part of that validated SPoC solution.
We do not otherwise receive, transmit, or store account data electronically.
This payment channel is NOT connected to any other systems / networks within our environment.
Any account data we retain is on paper only (printed reports/receipts) and is not received electronically.
We have implemented all controls in the SPoC user guide provided by the SPoC Solution Provider.
Watch out: SPoC is not available for unattended terminals, MOTO, or e-commerce, and the channel must not be connected to your other systems.
SAQ D for Merchants
All other SAQ-eligible merchants
Any merchant that stores account data electronically, mixes channels that cannot each meet the same criteria, or otherwise fails a short-form SAQ's eligibility criteria.
Watch out: SAQ D is not a failure state — it is the honest answer for most merchants who store data or run their own payment applications.
SAQ D for Service Providers
Service providers eligible to self-assess
Service providers whose compliance-accepting entity has determined they may self-assess rather than undergo a QSA-led Report on Compliance.
Our organisation is a service provider as defined by the payment brands.
Our compliance-accepting entity (acquirer or payment brand) has determined we are eligible to self-assess and are not required to undergo a QSA-led Report on Compliance.
Watch out: It is the only SAQ available to service providers. Level 1 service providers cannot use it.
Frequently asked questions
Who decides which SAQ I complete?
You do, but your acquirer or payment brand is the compliance-accepting entity. PCI SSC publishes the eligibility criteria; the payment brands and your acquirer set validation and reporting requirements. Confirm your chosen SAQ with them before you submit.
What is the difference between SAQ A and SAQ A-EP?
SAQ A applies when every element of the payment page comes only and directly from a PCI DSS compliant third-party provider — typically a full redirect or a provider-hosted iframe. SAQ A-EP applies when your own website delivers part of the payment page or controls how the customer or their account data is redirected, such as Direct Post or JavaScript-created payment forms.
I accept payments through more than one channel. Do I need more than one SAQ?
Possibly. Each payment channel must independently meet the eligibility criteria of the SAQ used for it. PCI SSC advises merchants with more than one channel to consult their acquirer and payment brands about validation and reporting. Where channels cannot each satisfy the same criteria, SAQ D for Merchants covers the remainder.
Does storing card data electronically rule out a short-form SAQ?
Yes. Every short-form SAQ requires that no account data is stored in electronic format, including legacy data. If you store account data electronically, SAQ D for Merchants applies.
Are Secure Card Readers eligible for SAQ B-IP?
No. SAQ B-IP is limited to standalone PCI-listed approved PTS POI devices and explicitly excludes SCRs and SCRPs. The device must also not rely on another device, such as a computer or phone, to connect to the processor.
Is an SAQ enough, or do I need a QSA?
Level 1 merchants, Level 1 service providers, designated entities subject to PCI DSS Appendix A3, and anyone whose acquirer has mandated a Report on Compliance cannot self-assess. Everyone else may be eligible for an SAQ, subject to their acquirer's acceptance.
Check your answer against the official flow
Our free SAQ selector walks the same decision flow, records every answer, and re-derives the recommendation server-side with a confidence score — so you get a defensible record of why a given SAQ was chosen, not just a label. Your acquirer remains the compliance-accepting entity.
Source: PCI Security Standards Council, Self-Assessment Questionnaire Instructions and Guidelines for PCI DSS v4.0.1 r1. This guide is an independent summary and is not endorsed by PCI SSC.