“Our processor just said complete SAQ D.” That sentence starts more PCI projects than almost any other, and it deserves one follow-up question before you start answering: does SAQ D actually apply to you, or did it apply by default? This guide covers both versions of SAQ D, the storage rule that pulls merchants into it, and the honest ways out.
Who completes SAQ D
Four groups end up here, and they arrive by very different roads:
- You store cardholder data electronically. An orders database with card numbers in it, a spreadsheet exported from the old system, call recordings of phone orders, an application log that captured card fields. Electronic storage takes every reduced SAQ off the table.
- Your acceptance doesn’t fit any reduced SAQ. The reduced SAQs (A, A-EP, B, B-IP, C-VT, C, and P2PE) each carry strict eligibility criteria. Miss them all and SAQ D for Merchants is what’s left. The SAQ types guide walks all eight.
- You’re a service provider. You store, process, or transmit cardholder data on behalf of other businesses, or you can affect the security of their card data. If you’re eligible to self-assess, SAQ D for Service Providers is your questionnaire.
- Your bank defaulted you. When an acquirer or processor can’t confirm how you accept cards, the conservative call is the SAQ that covers everything. That’s D, and it happens to merchants who would qualify for far less.
SAQ D for Merchants vs SAQ D for Service Providers
SAQ D comes in two versions, assigned for different reasons.
SAQ D for Merchants is for any merchant not eligible for a reduced SAQ. You sell goods or services and take cards for your own business, but something about your environment, usually stored cardholder data or an acceptance channel that doesn’t meet a reduced SAQ’s criteria, means the shorter questionnaires don’t apply.
SAQ D for Service Providers is for businesses that handle cardholder data for others: you store, process, or transmit it on behalf of merchants or other entities, or your service can affect the security of their card data. Service providers that are eligible to self-assess use this version. Whether you self-assess or need a QSA-led Report on Compliance depends on your validation level, which the card brands and acquirers assign from annual card volume, and the merchants you serve will often ask to see your Attestation of Compliance.
Both versions cover the full set of PCI DSS requirements. The difference is the role you play in the card ecosystem, not a discount on depth.
The storage override: how merchants get pulled into D
Every reduced SAQ rests on one shared assumption: no electronic storage of cardholder data. The moment any system you control stores card data electronically, that assumption fails, the reduced SAQs come off the table, and SAQ D generally applies, whatever your sales channel looks like.
The word to watch is electronically, because it covers more than a payments database:
- A customer database or order table with a card-number column, even a legacy one nobody queries anymore.
- A spreadsheet someone exported for reconciliation and never deleted.
- Application or debug logs that captured card fields during a checkout error.
- Call recordings of phone orders where customers read their card aloud.
- Card numbers sitting in email inboxes or on shared drives.
This is why the honest first move in any PCI project is finding out where card data actually lives. Merchants who believe they don’t store card data are sometimes storing it in a recording or a log they’ve never inspected, and merchants dutifully completing SAQ D are sometimes storing nothing at all and never needed the full questionnaire.
Why “just complete SAQ D” happens
Acquirers and processors assign validation paperwork across enormous merchant portfolios. When the bank’s records don’t make your acceptance channels clear, mixed channels, an unusual setup, onboarding questions nobody answered, the safe answer from the bank’s side is SAQ D, because D covers any environment. It isn’t a judgment about your risk. It’s a default that guarantees nothing gets missed.
The catch: the default is conservative for the bank and expensive for you. If your environment actually meets a reduced SAQ’s eligibility criteria, completing D means answering a much larger requirement set than you owe. The fix isn’t to argue. It’s to show up with a clear, documented picture of how cards flow through your business and ask your acquirer to confirm the right questionnaire.
Assigned SAQ D? Check what you actually qualify for, free.
Answer a few questions about how you accept cards and the free check computes your likely SAQ type on screen. No email to see it, no card, nothing to install. It’s indicative, not a QSA assessment, but it turns “probably D?” into a concrete hypothesis you can take to your bank.
What you answer, at a high level
SAQ D covers the full set of PCI DSS requirements: all 12, organized under six goals:
- Build and maintain a secure network and systems.
- Protect account data.
- Maintain a vulnerability management program.
- Implement strong access control measures.
- Regularly monitor and test networks.
- Maintain an information security policy.
We don’t quote question counts because they vary by SAQ version. The qualitative picture is enough: every reduced SAQ covers fewer requirements than D, because eligibility for a reduced SAQ means part of the risk moved to a validated third party or an approved device. With D, nothing is assumed away, so the questionnaire works through the whole standard. For a plain-English walkthrough of what each requirement asks, see the 12 PCI DSS v4.0 requirements, explained.
The honest upside: scoping is the highest-leverage move you have
Here’s the part worth sitting with. For merchants, confirming eligibility for a reduced SAQ is often the single highest-leverage scoping move in all of PCI DSS. Not a new tool, not a bigger firewall. Scope. The same business, validated under the questionnaire that actually matches how card data flows, can owe a dramatically smaller body of work.
There are two honest paths out of SAQ D:
- Prove you were never in it. Verify that no system you control stores cardholder data electronically and that your acceptance channel meets a reduced SAQ’s criteria. Some merchants assigned D by default qualify for something smaller today, with no changes at all.
- Change how card data flows. Stop storing card numbers (processors can typically hold the card and hand your systems a token instead), move online checkout to a validated hosted payment page, replace unlisted terminals with a PCI-listed P2PE solution. Change the flow and a reduced SAQ, SAQ A, SAQ P2PE, or another, may honestly fit.
And the honest flip side: some businesses belong in SAQ D. If you store cardholder data for real business reasons, or you’re a service provider whose customers depend on your controls, D is yours. Then the job isn’t escaping the questionnaire; it’s sequencing the full requirement set into work you can actually finish, in an order that closes the riskiest gaps first. That’s a planning problem, and planning problems are solvable.
How to confirm which SAQ is really yours
- Map your acceptance and storage first. Every way a card reaches your business, and every place card data could rest, including logs, recordings, and old exports.
- Ask your acquiring bank to confirm. Eligibility criteria come from the PCI SSC, but your acquirer or the card brands confirm which questionnaire you submit and your validation level.
- Use a QSA when you want an assessor’s read. Especially if you’re a service provider or the storage question is murky.
- Start with the free check. It computes your likely SAQ on screen in about two minutes, no email needed to see it. Indicative, not a QSA assessment, but it gives you a defensible starting point instead of a guess.
Confirm your SAQ, then close the gaps.
The free check names your likely SAQ on screen in about two minutes. When you’re ready to act on it, the $1,495 PCI DSS v4.0 Readiness & Gap Analysis confirms your SAQ with full rationale, marks every one of the 12 PCI DSS v4.0 requirements covered, partial, or gap, and hands you a prioritized 30/60/90 remediation roadmap with the evidence an assessor will ask for. Intake-based, PDF in your inbox within hours, backed by a 7-day pre-delivery money-back guarantee. If you continue into an Aegis AI subscription at ai4ciso.ai, the $1,495 credits toward your first month.
Frequently asked questions
What is the difference between SAQ D for Merchants and SAQ D for Service Providers?
They’re two versions of the same catch-all questionnaire. SAQ D for Merchants applies to any merchant that doesn’t meet the eligibility criteria for a reduced SAQ. SAQ D for Service Providers applies to businesses that store, process, or transmit cardholder data on behalf of others and are eligible to self-assess. Both cover the full set of PCI DSS requirements.
Does storing card numbers always put me in SAQ D?
Generally, yes. Every reduced SAQ assumes no electronic storage of cardholder data, so card numbers stored in a database, spreadsheet, application log, or call recording take the reduced SAQs off the table and SAQ D generally applies. Confirm the specifics with your acquiring bank or a QSA.
My processor told me to complete SAQ D. Is that final?
Not necessarily. Banks and processors often default merchants to SAQ D when they can’t confirm how cards are accepted, because SAQ D covers every environment. If your acceptance channels actually meet the eligibility criteria for a reduced SAQ, bring your acquirer a clear picture of how card data flows through your business and ask it to confirm the smaller questionnaire.
Is SAQ D the same as a Report on Compliance?
No. SAQ D is a self-assessment you complete and sign yourself. A Report on Compliance (RoC) is a QSA-led assessment required at the highest validation levels, which your acquirer and the card brands assign based on annual card volume.
Can I move from SAQ D to a reduced SAQ?
Often, yes, if you change how card data flows. Merchants commonly get there by ending electronic storage of cardholder data and moving acceptance to a channel that meets a reduced SAQ’s criteria, such as a validated hosted payment page or a PCI-listed P2PE solution. Confirm eligibility with your acquiring bank or a QSA before switching questionnaires.
What does SAQ D cover?
The full set of PCI DSS requirements: all 12 requirements across six goals, covering secure networks and systems, protecting account data, vulnerability management, access control, monitoring and testing, and information security policy.
Related guides
This guide is general information, not a QSA assessment, a completed SAQ, an Attestation of Compliance, or legal advice. The free check is indicative, not a QSA assessment. Confirm your SAQ and obligations with your acquiring bank or a Qualified Security Assessor.