Selector
Which PCI SAQ do I need?
Answer the questions in order. The first "yes" is usually the right SAQ. Then confirm with your acquirer, which decides what it accepts.
1. Are you a service provider to other businesses' card payments?
If you store, process or transmit card data for others, or manage systems that can affect its security (as many MSPs do), you are a service provider: SAQ D for Service Providers (if your volume and card brand rules allow self-assessment). Otherwise, continue.
2. Do you store card numbers electronically anywhere?
Spreadsheets, databases, email, call recordings or a payment application's local store all count. Yes: SAQ D for Merchants. No: continue.
3. Do you take payments online?
If the whole payment page or form is served by your provider (a redirect or an iframe), and nothing on your site can change it: SAQ A, provided all other channels are also fully outsourced. If your own site posts card data to the provider or builds the payment form: SAQ A-EP.
4. Do you take card-present payments?
Only a PCI-listed P2PE solution's terminals: SAQ P2PE. Only standalone PTS-approved terminals connected over IP: SAQ B-IP. Only imprint machines or dial-out terminals: SAQ B. A PCI-listed SPoC app on a phone or tablet: SAQ SPoC. A POS system connected to the internet: SAQ C.
5. Do you key in phone or mail orders?
Into a provider's virtual terminal in a browser, one at a time, on an isolated computer: SAQ C-VT. Otherwise, usually SAQ C or SAQ D.
Several channels?
A merchant with more than one channel usually completes the SAQ that covers all of them, often the more demanding one, or separate SAQs if the acquirer allows. Ask the acquirer.
All PCI DSS v4.0.1 SAQ types at a glance
| SAQ | Who it's for |
|---|---|
| SAQ A | Card-not-present (e-commerce, mail or phone) merchants that fully outsource all card data functions to PCI DSS compliant providers. E-commerce payment pages come entirely from the provider (redirect or iframe). A merchant that embeds the provider's form also confirms its site isn't susceptible to script attacks. |
| SAQ A-EP | E-commerce merchants that outsource payment processing but whose own website controls how card data reaches the provider, for example a direct post or a form built by the merchant's JavaScript. |
| SAQ B | Merchants using only imprint machines or standalone dial-out terminals, with no electronic card data storage. |
| SAQ B-IP | Merchants using only standalone, PTS-approved payment terminals with an IP connection to the processor, with no electronic card data storage. |
| SAQ C-VT | Merchants that key in one transaction at a time into a provider's internet-based virtual terminal on an isolated computer, with no electronic card data storage. |
| SAQ C | Merchants with payment application systems connected to the internet, with no electronic card data storage. |
| SAQ P2PE | Merchants using only hardware terminals managed through a PCI-listed point-to-point encryption (P2PE) solution, with no electronic card data storage. |
| SAQ SPoC | Merchants accepting card-present payments on a commercial off-the-shelf device (like a phone) using a PCI-listed Software-based PIN entry on COTS (SPoC) solution. |
| SAQ D for Merchants | Every merchant that doesn't fit another SAQ, including any that store card data electronically. |
| SAQ D for Service Providers | Service providers eligible to self-assess, including MSPs whose services can affect the security of a client's cardholder data environment. |
For the reasoning behind each type and what changed in v4.0.1, read which PCI SAQ do I need? and SAQ A under PCI DSS 4.0.1. The official eligibility criteria are in each SAQ on the PCI SSC document library.
This selector is a guide, not an assessment. Your acquirer (the bank that processes your card payments) decides which SAQ you complete.
Running SAQs for many merchants? CardSecurity is building for that.
PCI compliance management is in early access for MSP pilot partners.