Note: This is educational guidance, not a formal compliance determination — always confirm your SAQ with your acquirer or a Qualified Security Assessor. This guide also contains affiliate links; if you buy through them Oreaxe may earn a commission at no extra cost to you, and it never affects our guidance. See How We Evaluate.
Choosing the right PCI SAQ is one of the most consequential decisions a small merchant makes about compliance — and one of the easiest to get wrong. Pick the wrong Self-Assessment Questionnaire and you either drown in controls that don’t apply to you, or, far worse, skip a hundred controls that do. This guide explains every PCI SAQ type, how to tell which one fits how you actually take payments, and the 2025 change to SAQ A that older guides still get wrong.
What is a PCI SAQ?
A PCI SAQ (Self-Assessment Questionnaire) is a validation tool that lets eligible merchants assess their own PCI DSS compliance instead of undergoing a full on-site assessment by a Qualified Security Assessor. Each SAQ is a different subset of the full PCI DSS, scoped to a specific way of accepting and handling card payments. The fewer ways your business touches cardholder data, the shorter your SAQ — which is exactly why correctly identifying yours matters so much.
One caveat before anything else: your acquiring bank or the relevant card brand has the final say on which SAQ (or full assessment) you must complete, and your transaction volume determines whether you’re even eligible to self-assess at all. Treat this guide as the map; confirm the route with your acquirer.
Why choosing the right PCI SAQ matters
Here’s the stark example that makes this real. SAQ A contains roughly 30 requirements. SAQ A-EP contains around 150. They both apply to e-commerce merchants — and merchants routinely confuse the two. A business that wrongly self-certifies under SAQ A when it should be using SAQ A-EP can fail to implement over a hundred security controls, including vulnerability scanning, penetration testing, and change management. If a breach follows, that misclassification turns a compliance gap into a liability problem. Getting the SAQ right isn’t paperwork — it’s the difference between real coverage and a false sense of security.
The PCI SAQ types, explained
| SAQ | Who it’s for | Rough size |
|---|---|---|
| SAQ A | E-commerce or mail/telephone-order merchants who fully outsource all card handling to PCI DSS compliant providers (redirect or iframe); no card data touches your systems | ~30 reqs |
| SAQ A-EP | E-commerce merchants whose website affects the security of the payment transaction but doesn’t directly receive card data | ~150 reqs |
| SAQ B | Merchants using only imprint machines or standalone dial-out terminals; no electronic cardholder data storage | Small |
| SAQ B-IP | Merchants using standalone, PTS-approved payment terminals with an IP connection to the processor; no electronic storage | Small |
| SAQ C-VT | Merchants keying transactions one at a time into a web-based virtual terminal; no electronic storage | Medium |
| SAQ C | Merchants with payment application systems connected to the internet; no electronic storage | Medium |
| SAQ P2PE | Merchants using a validated PCI point-to-point encryption (P2PE) solution; no electronic storage | Small |
| SAQ SPoC | Merchants using a validated software-based PIN-entry-on-COTS (SoftPOS) solution | Small |
| SAQ D – Merchant | Every merchant not eligible for another SAQ, and any merchant who stores cardholder data electronically | All of PCI DSS |
| SAQ D – Service Provider | Service providers eligible to self-assess | All applicable |
How to find your PCI SAQ: a decision framework
Work down this list and stop at the first match that describes how you take payments:
- Do you store cardholder data electronically, or does none of the below fit? → SAQ D. Storing card data puts you in the deepest scope, full stop.
- E-commerce, and card data never touches your systems (customer is redirected to your processor, or pays via a third-party iframe)? → SAQ A.
- E-commerce, but your own website shapes how the payment page behaves (you control elements that affect the transaction, without receiving the card data directly)? → SAQ A-EP.
- Software-based PIN entry on a phone or tablet (SoftPOS)? → SAQ SPoC.
- A validated P2PE solution for all card handling? → SAQ P2PE.
- A standalone, internet-connected (IP) payment terminal, nothing stored? → SAQ B-IP.
- A standalone dial-out terminal or imprint machine, nothing stored? → SAQ B.
- Keying transactions into a web-based virtual terminal by hand? → SAQ C-VT.
- A payment application connected to the internet, nothing stored? → SAQ C.
If two seem to fit, choose the more comprehensive one and confirm with your acquirer. Under-scoping is the costly mistake.
The 2025 SAQ A change older guides miss
This is where a lot of online advice is now out of date. In January 2025, ahead of the PCI DSS v4.0.1 mandatory date of March 31, 2025, the PCI Security Standards Council revised SAQ A. It removed Requirements 6.4.3 and 11.6.1 (the payment-page script-security and change-detection controls) and Requirement 12.3.1 — and added a new eligibility criterion: the merchant must confirm that their entire site is not susceptible to script attacks that could affect their e-commerce systems.
The nuance matters. The old controls applied only to the payment page; the new eligibility bar is broader — it concerns your whole website. So SAQ A became simpler on paper but demands holistic protection against e-skimming, not just payment-page controls. If you can’t confirm your site is protected against malicious scripts, you may not qualify for SAQ A at all and could fall into SAQ A-EP — with its ~150 requirements. Note too that A-EP and SAQ D merchants, and service providers, still must meet 6.4.3 and 11.6.1.
Where your SAQ meets real security controls
Identifying your SAQ is step one; the controls behind it are the real work — and several of them are where small businesses stumble. Strong authentication is a recurring theme across SAQ types: our guide to PCI DSS 4.0.1 authentication requirements breaks down the MFA and credential rules an assessor actually checks. Credential hygiene specifically — unique passwords, no shared logins, MFA on access — is exactly where a managed password manager like Proton Pass helps a small team enforce what Requirement 8 demands. The SAQ tells you what you’re accountable for; tools and process are how you meet it.
Common PCI SAQ mistakes to avoid
- Confusing SAQ A with SAQ A-EP — the single most expensive misclassification, as above.
- Assuming a smaller SAQ means you’re “less” obligated — you’re still fully responsible for every control in your SAQ.
- Forgetting your acquirer has the final word — self-identifying without confirming can invalidate your attestation.
- Using outdated SAQ A guidance that still references the removed 6.4.3 / 11.6.1 controls.
- Ignoring transaction volume — your merchant level may require a full QSA assessment regardless of SAQ eligibility.
Frequently asked questions
What is a PCI SAQ? A Self-Assessment Questionnaire that lets eligible merchants validate their own PCI DSS compliance instead of a full on-site assessment, scoped to how they handle card payments.
How many PCI SAQ types are there? Nine core types for merchants and service providers (SAQ A, A-EP, B, B-IP, C, C-VT, P2PE, SPoC, and D), each matching a different payment setup.
Which PCI SAQ is the smallest? SAQ A, with roughly 30 requirements, for merchants who fully outsource card handling — but only if you meet its updated 2025 eligibility criteria.
Who decides which SAQ I use? Your acquiring bank or card brand has final say, and your transaction volume determines whether you can self-assess at all. Always confirm with them.
Did SAQ A change recently? Yes — in 2025 the PCI SSC removed Requirements 6.4.3, 11.6.1, and 12.3.1 from SAQ A and added a new whole-site script-security eligibility criterion.
Bottom line
Your PCI SAQ is determined by one thing above all: how your business takes payments and whether card data ever touches your systems. Most small merchants who fully outsource fall under SAQ A — but the 2025 changes mean qualifying now depends on protecting your whole site against script attacks, not just your payment page. Work down the decision framework above, lean toward the more comprehensive SAQ when in doubt, and confirm your answer with your acquirer or a Qualified Security Assessor before you self-certify. The right SAQ is the foundation everything else rests on; getting it wrong is the one mistake that’s genuinely hard to undo.
Going deeper on SAQ A? Read our complete PCI SAQ A guide — eligibility, the redirect-vs-iframe distinction, and the 2025 change.
Muhammad Saqlain is the founder of Oreaxe and a digital transformation and cybersecurity consultant. He helps small and mid-sized businesses modernise their operations and meet real security and compliance requirements — PCI DSS, ISO 27001, and SOC 2 — without the jargon or the fear-selling.
Mubbashir Ali has spent 17+ years in the engine room of enterprise IT — running multi-cloud infrastructure, hardening Linux fleets, and hunting vulnerabilities with OpenVAS and Nessus. A Certified Ethical Hacker (CEH v12) and AWS Solutions Architect, he leads IT operations by day and brings the hands-on technical depth — the actual scanning, hardening, and incident response — to Oreaxe's security coverage.