What Is an SAQ and Who Needs One?
If your business accepts, processes, stores, or transmits payment card data, you need to comply with the Payment Card Industry Data Security Standard (PCI DSS). For most merchants — those who aren't large enough to require a full Qualified Security Assessor (QSA) audit — the path to compliance is a Self-Assessment Questionnaire (SAQ).
An SAQ is a validation tool made up of yes/no questions that map to PCI DSS v4.0.1 requirements. Completing it accurately, and fixing any gaps it reveals, is how most small and mid-size merchants demonstrate compliance to their acquiring bank.
The challenge? There are 10 different SAQ types, and picking the wrong one wastes time — or worse, leaves you with a false sense of security.
The 10 SAQ Types at a Glance
Each SAQ applies to a specific combination of how you accept cards and how your systems handle cardholder data. Here's a plain-English breakdown:
SAQ A — Fully Outsourced Card-Not-Present
Who it's for: E-commerce or mail/telephone-order merchants who have fully outsourced all cardholder data functions to PCI DSS-compliant third parties. Your website never directly receives card data — it's handled entirely by an iframe or redirect to a third-party payment page.
Examples: Shopify stores using Shopify Payments, WooCommerce with Stripe Elements (hosted fields), any merchant using a fully hosted payment page.
Requirement count: ~27 requirements — the shortest SAQ by far.
Bottom line: If you never touch card data and outsource everything, this is you. It's the easiest path to compliance.
SAQ A-EP — E-commerce with Partial Outsourcing
Who it's for: E-commerce merchants who outsource payment processing but whose website directly affects the security of the payment transaction. This typically means your checkout page is served from your own domain and calls a third-party API — card data passes through your server or your JavaScript has some control over the payment flow.
Examples: Merchants using a direct API integration (rather than a hosted payment page), where your checkout JS could be modified to intercept card data.
Requirement count: ~191 requirements — significantly more than SAQ A.
Bottom line: If you're unsure whether you qualify for SAQ A, you probably need SAQ A-EP. The dividing line is whether your web environment can affect the payment page.
SAQ B — Imprint Machines or Standalone Dial-Up Terminals
Who it's for: Brick-and-mortar merchants who only use imprint machines (manual card imprinters) or standalone dial-up POS terminals that are not connected to the internet or any other network.
Examples: A small shop using an old-fashioned card imprinter, or a standalone terminal that dials out over a phone line.
Requirement count: ~41 requirements.
Bottom line: If your terminal never touches the internet, this is your SAQ.
SAQ B-IP — Standalone IP-Connected Terminals
Who it's for: Merchants using standalone, IP-connected POS terminals (not integrated into a POS system) that connect to the internet to process payments. The terminal is a standalone device but communicates over a network.
Examples: A restaurant using a countertop terminal that connects via Wi-Fi or Ethernet, but is not part of a larger POS system.
Requirement count: ~83 requirements.
Bottom line: The networked equivalent of SAQ B. More requirements because internet connectivity introduces more risk.
SAQ C-VT — Web-Based Virtual Terminals
Who it's for: Merchants who process card payments by manually keying data into a web-based virtual terminal provided by a third-party payment processor. The computer used for the virtual terminal is isolated and not connected to other systems.
Examples: A call centre agent manually entering card numbers into a payment processor's web portal on a dedicated, isolated computer.
Requirement count: ~79 requirements.
Bottom line: The key qualifier is isolation — the computer used must only be used for the virtual terminal, with no other software or internet browsing.
SAQ C — Payment Application Systems Connected to the Internet
Who it's for: Merchants with a payment application system (e.g., a full POS system) connected to the internet. Unlike SAQ B-IP, this involves a complete POS application — not just a standalone terminal.
Examples: A retail store running a POS application on a local computer that's also connected to the internet for inventory management.
Requirement count: ~160 requirements.
Bottom line: If you run a POS application (not just a terminal) and it touches the internet, this is your SAQ.
SAQ P2PE — Validated Point-to-Point Encryption
Who it's for: Merchants using hardware payment terminals within a PCI-validated Point-to-Point Encryption (P2PE) solution. With P2PE, card data is encrypted at the terminal before it ever reaches your network.
Examples: Merchants using payment hardware from a provider on the PCI SSC's list of validated P2PE solutions.
Requirement count: ~35 requirements — very short because P2PE removes most risk from your environment.
Bottom line: P2PE is one of the most powerful scope-reduction tools available. If your hardware vendor offers a validated P2PE solution, it's worth investigating.
SAQ SPOC — Software-Based PIN Entry on Commercial Off-the-Shelf Devices
Who it's for: Merchants using a software-based PIN entry application on a commercial off-the-shelf (COTS) device — like accepting PIN payments on a smartphone or tablet using an approved app.
Examples: A food truck using a smartphone-based POS app that accepts contactless PIN payments via an approved SPOC solution.
Requirement count: ~41 requirements.
Bottom line: A relatively new SAQ type reflecting the rise of mobile payments. Only applicable when using a PCI-listed SPOC solution.
SAQ D (Merchants) — All Other Merchants
Who it's for: Any merchant who doesn't fit into one of the above categories. This is the catch-all — and it's comprehensive.
Examples: Merchants who store cardholder data electronically, merchants with complex e-commerce environments, or anyone whose payment flow doesn't cleanly fit another SAQ type.
Requirement count: ~329 requirements — the full PCI DSS requirement set.
Bottom line: Avoid SAQ D if you can. Redesigning your payment flow to qualify for a more targeted SAQ is almost always worth the effort.
SAQ D (Service Providers) — Service Providers
Who it's for: Service providers that are eligible to complete an SAQ (rather than a full QSA audit). This includes hosting companies, managed service providers, and others that store, process, or transmit cardholder data on behalf of merchants.
Requirement count: 329+ requirements — even more extensive than the merchant version.
Bottom line: If you're a service provider handling cardholder data for clients, this is your path. Many service providers eventually need a full QSA Report on Compliance (ROC) instead.
Quick Selection Guide
Use this decision flow to find your SAQ:
- Do you store electronic cardholder data? → You likely need SAQ D (Merchants). Work with a QSA to reduce scope first.
- Are you a service provider? → SAQ D (Service Providers).
- Do you use a validated P2PE solution? → SAQ P2PE.
- Do you use a SPOC solution on a mobile device? → SAQ SPOC.
- Is your only card acceptance via a fully hosted, redirected payment page (no card data on your server)? → SAQ A.
- Do you have an e-commerce site where your JS or server could affect the payment flow? → SAQ A-EP.
- Do you use a standalone dial-up terminal (no internet)? → SAQ B.
- Do you use a standalone internet-connected terminal (not a full POS app)? → SAQ B-IP.
- Do you manually key card data into a web-based virtual terminal on an isolated computer? → SAQ C-VT.
- Do you run a POS application connected to the internet? → SAQ C.
When in doubt, go up. If two SAQ types could apply, use the more comprehensive one. Your acquiring bank may also specify which SAQ they require.
SAQ vs. Full QSA Audit
SAQs are self-assessments — you're validating your own compliance. Large merchants (typically Level 1, processing over 6 million Visa/Mastercard transactions per year) are required to undergo an annual on-site assessment by a Qualified Security Assessor instead. If you're unsure which merchant level applies to you, check with your acquiring bank.
How PCI DSS Dashboard Simplifies the SAQ Process
Once you know which SAQ applies, the real work begins: actually working through every requirement, gathering evidence, and producing a signed attestation. That's exactly what PCI DSS Dashboard is built for.
Our SAQ-A Wizard walks you through all 27 SAQ-A requirements in plain English, captures your responses, and generates a signed, downloadable PDF attestation — the document your acquiring bank actually needs. No spreadsheets, no guesswork.
Support for additional SAQ types is coming soon. Create a free account to get started with SAQ-A today.
