PCI SAQ Types Explained:
Find the Right One for Your Business
Not all PCI compliance requirements are the same. Your Self-Assessment Questionnaire (SAQ) depends on exactly how your business handles card data. Choose the wrong one, and you risk an invalid compliance submission — or a failed audit.
Understanding PCI SAQs
What Is a PCI Self-Assessment Questionnaire?
A PCI SAQ (Self-Assessment Questionnaire) is the primary compliance validation tool for merchants and service providers that are not required to undergo a full on-site assessment by a Qualified Security Assessor (QSA). It was introduced by the PCI Security Standards Council to provide a structured, documented way for smaller and less complex organisations to attest to their compliance with PCI DSS without the cost and time of a full Report on Compliance (ROC).
The SAQ is not a simple yes/no checklist. Each version of the PCI compliance questionnaire corresponds to a specific type of payment environment — a particular way of accepting, transmitting, and (potentially) storing cardholder data. Answering a question incorrectly, or completing the wrong SAQ type entirely, produces an invalid compliance attestation that your acquirer or card brand can reject.
Who needs to complete a PCI SAQ? Any merchant or service provider that accepts payment cards and is not required to complete a full ROC. Your acquiring bank determines your compliance validation requirements based on your transaction volume and card brand classification. Most small to mid-size businesses — including most eCommerce stores, SaaS platforms with billing, and healthcare providers collecting co-payments — complete an SAQ rather than a ROC.
SAQ vs ROC: what's the difference? A Report on Compliance is a formal assessment conducted by a PCI QSA. It's required for Level 1 merchants (typically 6M+ Visa transactions/year) and Level 1 service providers (typically 300K+ transactions/year), and for certain entity types regardless of volume — including PayFacs and processors. A ROC involves on-site or remote review, evidence sampling, and a formal report submitted to card brands. An SAQ is a self-attestation — you answer the questions and sign an Attestation of Compliance (AOC). No external auditor is required, though you may engage a consultant to guide the process and ensure accuracy.
Why does choosing the correct SAQ matter so much? Because each PCI SAQ type covers a different subset of PCI DSS requirements. SAQ A covers 22 requirements. SAQ D covers all 329. Completing SAQ A when your environment actually requires SAQ D means you have attested compliance to 22 of the 329 controls that apply to your situation — and ignored the other 307. When an auditor, acquirer, or forensic investigator examines your environment after an incident, that gap becomes very difficult to explain.
Incorrect SAQ selection is also not protected by intent. Signing an Attestation of Compliance for the wrong SAQ type means you have submitted an inaccurate compliance declaration to your acquiring bank and potentially to card brands. This is treated as a compliance failure regardless of whether the error was deliberate or the result of misunderstanding your payment architecture.
The most common mistake in SAQ A vs SAQ D situations is that merchants believe their payment processor absorbs most of their compliance obligations. Processors reduce your scope — but they don't eliminate it. The scope that remains is determined by how your systems interact with theirs, which is exactly what the SAQ type classification process is designed to establish.
Key takeaway
The SAQ type is not a choice — it's determined by the objective characteristics of your payment environment. Getting it wrong is one of the most consequential and easily avoidable PCI compliance mistakes a business can make.
All SAQ Types
PCI SAQ Types at a Glance
Eight SAQ types cover every payment environment — from fully outsourced checkouts to complex multi-channel systems. Here's how they compare.
| SAQ Type | Best For | Requirements | Complexity | Risk Level |
|---|---|---|---|---|
| SAQ A | Fully outsourced card-not-present payments. No card data ever touches your systems. | 22 | Low | Low |
| SAQ A-EP | eCommerce merchants with their own payment page that redirects to a compliant processor. | 191 | Medium | Medium |
| SAQ B | Imprint machines or standalone dial-out terminals only. No electronic cardholder data storage. | 41 | Low | Low |
| SAQ B-IP | IP-connected standalone terminals approved under the PTS programme. No electronic storage. | 83 | Low–Medium | Low–Medium |
| SAQ C | Payment application connected to the internet. No electronic cardholder data storage. | 160 | Medium | Medium |
| SAQ C-VT | Virtual terminal accessed via a web browser. Manually keyed card data only — nothing stored. | 80 | Low–Medium | Low |
| SAQ D (Merchant) | The catch-all SAQ. All merchants that don't qualify for any other type — including those storing card data. | 329 | High | High |
| SAQ D (Service Provider) | The highest-obligation SAQ. For service providers eligible to self-assess instead of completing a full ROC. | 329 | High | High |
SAQ A
22 reqFully outsourced card-not-present payments. No card data ever touches your systems.
SAQ A-EP
191 reqeCommerce merchants with their own payment page that redirects to a compliant processor.
SAQ B
41 reqImprint machines or standalone dial-out terminals only. No electronic cardholder data storage.
SAQ B-IP
83 reqIP-connected standalone terminals approved under the PTS programme. No electronic storage.
SAQ C
160 reqPayment application connected to the internet. No electronic cardholder data storage.
SAQ C-VT
80 reqVirtual terminal accessed via a web browser. Manually keyed card data only — nothing stored.
SAQ D (Merchant)
329 reqThe catch-all SAQ. All merchants that don't qualify for any other type — including those storing card data.
SAQ D (Service Provider)
329 reqThe highest-obligation SAQ. For service providers eligible to self-assess instead of completing a full ROC.
Detailed Breakdown
Every SAQ Type, in Plain Language
Qualification requirements, real-world examples, and the most common mistakes for each PCI SAQ type.
Decision Guide
How to Determine Which PCI SAQ You Need
Work through these questions in order. Your SAQ type is determined by your actual payment architecture — not by which gateway you use or which platform you're on.
Do you store cardholder data electronically?
If yes
You are in SAQ D (Merchant) territory at minimum. Storing PANs, CVVs, or full track data places you under the full PCI DSS standard.
If no
Move to Step 2.
Does your business accept card payments in-person (not online)?
If yes
Evaluate your terminal type: standalone imprint/dial-out = SAQ B. IP-connected standalone terminal = SAQ B-IP. POS software on networked computer = SAQ C. Web-based virtual terminal only = SAQ C-VT.
If no
Your business is card-not-present (eCommerce or MOTO). Move to Step 3.
Is your payment page fully hosted by a PCI-compliant third party?
If yes
If your customers leave your site to complete payment — or your page contains zero JavaScript or content from your own server that affects the payment form — you likely qualify for SAQ A.
If no
Move to Step 4.
Does your checkout page load payment scripts (e.g., Stripe Elements, Braintree) on your own domain?
If yes
You are in SAQ A-EP. Your page is involved in the payment flow even if the card data itself is captured within a third-party iframe.
If no
If none of the above categories fit — your payment flow is complex, involves server-side card data handling, or spans multiple channels — you are in SAQ D (Merchant). Engage a PCI consultant to confirm.
Do you process payments on behalf of other businesses (your clients)?
If yes
You are classified as a PCI service provider. Depending on your transaction volume, you complete SAQ D (Service Provider) or require a full Level 1 ROC.
If no
Your classification is as a merchant under one of the SAQ types above. Confirm with Step 1–4.
Real-World Examples
Shopify store using Shopify Checkout
SAQ A
Payment page is fully hosted by Shopify (a PCI-compliant third party). You never serve any part of the checkout page. No card data touches your systems.
Custom Next.js storefront with Stripe Elements
SAQ A-EP
Your domain serves the checkout page. Stripe Elements renders card fields in a Stripe-hosted iframe, but your page loads the Stripe.js script and controls the checkout UI.
SaaS platform billing its own customers via Stripe API
SAQ A or A-EP (merchant) + potentially SAQ D SP
For billing your own customers, you may qualify for SAQ A/A-EP depending on your integration. If you also process payments for your clients' customers, add service provider obligations.
Common Mistakes
SAQ Errors That Cause Real Problems
These are the mistakes we see repeatedly — across eCommerce businesses, SaaS platforms, and healthcare providers — when they approach PCI SAQ selection without expert guidance.
Claiming SAQ A when you actually qualify for SAQ A-EP
This is the most common misclassification in eCommerce. If your checkout page is hosted on your domain and loads any JavaScript that touches the payment form — even a third-party payment widget — you are SAQ A-EP. Many merchants assume that 'using Stripe' equals SAQ A. It does not. How your checkout page is served determines your SAQ, not which processor you use.
Misunderstanding JavaScript involvement under PCI DSS v4.0
PCI DSS v4.0 Requirement 6.4.3 now explicitly requires merchants to inventory and authorise every script running on a payment page. Even scripts you didn't write — analytics tools, A/B testing platforms, chat widgets — must be documented and integrity-checked if they appear on your checkout page. This requirement alone has moved many merchants from SAQ A into SAQ A-EP without any change to their actual payment setup.
Assuming that Stripe or Braintree eliminates all PCI obligations
Payment gateways handle the most sensitive part of the card data flow — but your obligations don't disappear. How you integrate the gateway, what your checkout page looks like, whether you log API responses, and how you store customer references all affect your PCI scope. A poorly implemented Stripe integration can make you SAQ A-EP or even SAQ D despite never directly handling a card number.
Not accounting for scope creep from adjacent systems
Systems that don't directly handle card data can still be in-scope if they could be used to compromise the cardholder data environment. A CRM that communicates with a payment database, an analytics platform that has access to order records, or a support tool with access to billing history can all pull additional systems into your PCI scope if your network segmentation isn't airtight.
Treating the SAQ as a one-time annual exercise
PCI compliance is a continuous state, not an annual checkbox. Changes to your payment stack — a new payment plugin, a redesigned checkout flow, a new analytics tool on your payment page, or a cloud migration — can change your SAQ type entirely. Any significant change to your payment environment should trigger a re-assessment of your SAQ classification before the next annual cycle.
Completing SAQ D when a simpler SAQ applies
Completing SAQ D when SAQ A or SAQ C would be correct is less common than under-scoping, but it happens — usually when merchants inherit a compliance programme they didn't set up and assume 'more is safer'. Over-scoping wastes significant engineering and compliance resource and doesn't make you more compliant; it just makes compliance more expensive.
Audit Impact
Why SAQ Selection Directly Affects Your Audit
Wrong SAQ = Audit Failure
Your acquirer or a QSA reviewing your compliance submission will evaluate your SAQ choice against your actual payment environment. If the SAQ type doesn't match how you accept cards, the submission is invalid — and you face re-assessment from scratch. An invalid AOC can also trigger non-compliance fines from your acquirer while you remediate.
Wider Scope = Higher Cost
Every system that touches or could affect cardholder data is potentially in scope. Incorrect scoping — especially failing to segment the CDE from the rest of your environment — inflates the number of systems subject to PCI controls. This means more evidence to collect, more controls to implement, and significantly higher cost per audit cycle. Scope accuracy is the single biggest lever on compliance cost.
Under-scoping Creates Real Security Risk
The controls you skip by completing the wrong SAQ are not administrative inconveniences — they are security requirements. SAQ A skips 307 of the 329 PCI DSS controls. If your environment actually requires those controls, you have 307 untested security gaps. When a breach occurs in that environment, the absence of controls that should have been implemented compounds both the incident and your regulatory exposure.
The cost of getting it wrong
A business that completes SAQ A when it should be completing SAQ A-EP has attested to 22 requirements and left 169 unaddressed. When a QSA discovers this — during a breach investigation or a compliance review — the organisation faces re-assessment costs, potential card brand fines of $5,000–$100,000 per month, and the reputational exposure of a failed compliance programme. The one-time cost of getting your SAQ right the first time is a fraction of the cost of getting it wrong.
22 req
of 329 total
SAQ A covers
329 req
full PCI DSS
SAQ D covers
307 req
untested controls
Gap if misclassified A→D
$5K–$100K
per card brand
Monthly fine range
Explore Further
PCI Compliance by Industry
SAQ requirements vary by how your business accepts card payments. See how they apply to your sector.
Not Sure Which SAQ You Need?
We'll map your payment flow — how you accept cards, which systems are involved, and what your processors actually do — and tell you exactly where you stand before an auditor does.
Not sure where to start? Our SAQ assistance service covers selection, completion, and evidence documentation.