SAQ D-Merchant walkthrough: when none of the others fit
By Sam Rivera, Founder, SentinelPanda · June 3, 2026 · 3 min read · PCI DSS
SAQ D-Merchant is the comprehensive SAQ. If you do not qualify for A through P2PE, this is where you land — closest to a full ROC in coverage.
Who SAQ D-Merchant is for
SAQ D-Merchant is the catch-all merchant SAQ. It applies to any merchant whose card acceptance environment does not meet the eligibility criteria of SAQ A, A-EP, B, B-IP, C, C-VT, or P2PE. In practice that means: merchants who store cardholder data on their own systems; merchants who use a mix of acceptance channels that span multiple SAQ types; merchants whose e-commerce setup falls outside both A and A-EP; merchants with custom payment integrations.
If you have ever asked yourself "but what if I do BOTH e-commerce and in-store?" or "we hold tokenised card data but also raw PANs in a vault for refunds," you are SAQ D-Merchant.
The eligibility checklist
- You are a merchant (use SAQ D-Service Provider if a service provider).
- You do not meet the eligibility for SAQ A, A-EP, B, B-IP, C, C-VT, or P2PE.
- You accept and process card payments and are below the Level 1 threshold that would require a QSA-led ROC.
- You confirm scope, segmentation, and channel coverage in a Scope Statement.
The requirement subset
SAQ D-Merchant covers all 12 requirements and is the longest SAQ — typically 300+ control questions. Every one of the network, cryptography, vulnerability management, secure-development, access control, monitoring, logging, physical security, incident response, and programme-management requirements applies.
In practice, the requirements track a ROC closely. The differences are in attestation (self-attested by an executive rather than QSA-signed) and in the lack of an on-site assessment. The evidence collection, the controls, and the maturity expected are essentially the same.
Many SAQ-D merchants engage a QSA for advisory even though they are not required to — to de-risk the scope decision, to satisfy a customer that asked for QSA-issued evidence, or to prepare for a move to the ROC path next year. SentinelPanda supports that without extra setup: the QSA joins your workspace as an auditor-layer seat, sees the evidence in place, and signs off in the same audit log your executive will attest from.
Common SAQ D-Merchant pitfalls
- Treating SAQ D as a longer SAQ A — it is a different programme. Plan it like a ROC.
- Storing card data "for refunds" — formally, full PAN must be protected with strong cryptography and tokenisation is strongly preferred. CVV/CVC/CID/CAV2 must NEVER be stored after authorisation.
- Mixed scope — keeping in-store, MOTO, and e-commerce on the same network without segmentation. Each channel's controls bleed into the others.
- Skipping the Customised Approach and the Targeted Risk Analyses, then trying to justify entity-defined frequencies anyway.
- Insufficient logging on systems handling cardholder data — Req 10 fails are common.
A worked example
A multi-channel retailer accepts e-commerce, in-store (integrated POS), and MOTO payments. Card data is tokenised; full PANs are held briefly in a vault for chargeback handling and protected with HSM-backed encryption. The Cardholder Data Environment is segmented into PCI VLANs separated from corporate IT.
Their SAQ D-Merchant walks every requirement, including Req 3 (encryption of stored PAN, key management), Req 4 (TLS for the channels that transmit cardholder data), Req 5/6 (anti-malware, secure SDLC, patching), Req 10 (full logging into a SIEM), Req 11 (quarterly ASV scans, internal scans, annual pentest, segmentation testing). Plus Targeted Risk Analyses for entity-defined frequencies. Total: 12-16 weeks first cycle, 4-6 weeks revalidation, ongoing operational disciplines maintained continuously.