SAQ D is where a merchant lands if they don't meet the eligibility criteria for any of the other, narrower SAQ types. There's no positive checklist to qualify for SAQ D — it's eligibility by elimination, and it carries the full PCI DSS requirement set (all 12 requirement categories, unabridged).
Who typically ends up here
E-commerce merchants who accept account data directly on their own website rather than fully outsourcing or redirecting.
Merchants who store account data electronically for any reason, including legacy systems or custom in-house payment applications.
Merchants who don't store data electronically but still don't meet another SAQ's criteria (multi-location setups, mixed channels, networked terminals that don't isolate cleanly).
Larger or franchise/multi-location merchants whose environment just doesn't fit a narrower box.
Requirement scope
The full set — all of Requirements 1 through 12, no exceptions. This is the largest and most detailed SAQ by far.
ASV scanning
Yes — Requirement 11 applies, so quarterly ASV scans are required.
A note on service providers
Service providers use a distinct version called "SAQ D for Service Providers" — none of the smaller SAQ types are available to service providers at all, only this one. It's the same broad scope but with its own Attestation of Compliance format.
Before defaulting to SAQ D
Walk back through SAQ A, A-EP, B, B-IP, C, C-VT, P2PE, and SPoC first — a lot of merchants assume they need SAQ D when a narrower option actually fits once you look closely at how data really flows through their environment. When it genuinely doesn't fit anywhere else, SAQ D is always a safe, valid answer.