Ask ten small businesses which PCI DSS Self-Assessment Questionnaire they’re supposed to fill out and you’ll get ten shrugs. The SAQ system is one of the most misunderstood parts of the whole standard, and getting it wrong costs you either way — pick one that’s too light and you’re not actually compliant, pick one that’s too heavy and you’ve buried your team in controls you don’t need.
The two that cause the most confusion sit at opposite ends: SAQ A, the shortest, and SAQ D, the longest. Here’s how to tell which one is actually yours.
It comes down to one question: does card data touch your systems?
That’s the whole thing, stripped down. The SAQ you qualify for depends on how much of the cardholder data you see, store, process, or transmit — and how much you’ve handed off to someone else.
SAQ A is for merchants who have fully outsourced payments. Card data never touches your environment. Think of an e-commerce store that redirects to a hosted payment page, or embeds an iframe from a PCI-compliant processor. The customer types their card number into the processor’s system, not yours. You never see it. Because your exposure is tiny, SAQ A is short — a couple dozen questions, mostly about confirming your third parties are compliant and your redirects haven’t been tampered with.
SAQ D is the catch-all at the other end. It’s for everyone who doesn’t fit a neater category — merchants who store card data, handle it directly, or have it flowing through their own servers, plus every service provider. SAQ D runs to hundreds of requirements. It’s essentially the full PCI DSS standard in questionnaire form.
The trap in the middle
Most businesses want to be SAQ A. It’s the easy one, and I understand the temptation. But the moment card data touches your systems — even for a second, even if you don’t store it — you fall out of SAQ A eligibility. A custom checkout form that posts card data through your own server before forwarding it? Not SAQ A. A call centre where staff key in card numbers? Not SAQ A. That’s how businesses end up thinking they’re done in an afternoon when they actually owe a SAQ D.
There are in-between questionnaires too — A-EP for e-commerce sites that manage the payment page but don’t touch the data directly, B and C for specific terminal and application setups. But the A-versus-D question is the one that reframes how most owners think about their real scope.
Why service providers don’t get a choice
If you’re a service provider — a SaaS platform, a hosting company, anything that handles or affects other people’s card data — assume SAQ D. Service providers are held to the full standard because their exposure ripples out to every client they serve. There’s no light-touch version for you.
How to actually decide
Map the flow. Draw exactly where card data enters, where it goes, what systems it passes through, and where it lands. Most businesses have never done this, and it’s the single most clarifying exercise in the whole process. The diagram tells you your scope, and your scope tells you your SAQ.
Then be honest about outsourcing. “We use Stripe” doesn’t automatically make you SAQ A — how you integrate Stripe is what decides it. A redirect or iframe keeps you light. A server-side integration that handles the raw card number pulls you toward SAQ D.
Getting the SAQ right is really about getting your scope right, and scope is where a real PCI DSS compliance program starts. The businesses that struggle usually picked their questionnaire based on what they hoped was true instead of tracing where the data actually goes. Trace the data first. The right SAQ falls out of the answer — and if it turns out to be D, the smart move is to automate the evidence collection rather than hand-fill hundreds of controls every year.
If you’re still not sure where you land, it’s worth a short conversation with an assessor before you commit — an hour of scoping now saves a mis-scoped audit later.
