What SAQ D Actually Is
SAQ D is the Payment Card Industry Data Security Standard's catch-all self-assessment questionnaire. It's meant for merchants and service providers who can't fit into any of the narrower SAQ categories. If your payment environment has cardholder data flowing through multiple systems, or you run e-commerce alongside point-of-sale terminals, or your network architecture is complicated enough that nothing else fits, SAQ D is where you end up. The questionnaire is structured around the PCI DSS requirements. There are roughly 200 individual questions broken into sections that map directly to the 12 PCI DSS requirement groups. You go through each one and mark whether you comply, partially comply, or don't comply, then document evidence for each answer. That's the surface-level version of it.
Pci Self Assessment Questionnaire D
The current version circulating is SAQ D 4.0, released in late 2022. It replaced the older SAQ D 3.2.1 format. If you're looking for the official document, the PCI Security Standards Council publishes it at pcisecuritystandards.org/assessors_and_qpas/download_saqs. The PDF is usually labeled "SAQ D 4.0" and comes in two parts: the questionnaire itself and a companion guidance document that explains each question. I filled out SAQ D for a mid-market retailer once. They had an e-commerce site, three brick-and-mortar locations with POS systems, and a warehouse that processed returns over the phone. Every single channel collected cardholder data in a slightly different way. They didn't qualify for SAQ EP because they weren't purely e-commerce. They didn't qualify for SAQ P2PE because their POS terminals weren't all point-to-point encrypted. SAQ D was their only option. Here's what that process actually looked like. First, you map your cardholder data environment. Not just where the data lives, but where it touches. Every system that stores, processes, or transmits cardholder data needs to be identified. In my client's case, that meant their POS system, their payment gateway, their billing platform, the call center's CRM, and the warehouse management system that printed return receipts with full card numbers on them.
Then you go through each requirement. Requirement 1, for example, is about firewalls and network segmentation. You don't just say yes or no. You document your network diagram, list every firewall rule that permits cardholder data flow, and note where segmentation exists and where it doesn't. If you have a VLAN that separates the POS network from the corporate Wi-Fi, that's a compliance point. If the same switch handle both and there's no VLAN separation, that's a gap you have to address before you can credibly check yes. Requirement 2 is about default passwords and system configurations. This is where most people fail. Not because they don't know the requirement, but because they actually have default credentials on something they forgot about. An IP camera. A network printer. A legacy database server that someone set up three years ago and never documented. The SAQ asks you to confirm there are no vendor-default passwords. If you can't confirm that, you can't check the box. I spent an afternoon running a script against our client's network looking for default credentials on anything that had an IP address. Found seven devices. Four were IoT sensors in the warehouse that nobody knew were on the same subnet as the payment systems. That alone was a segmentation failure under Requirement 1.
Get the Full Details
Common Mistakes People Make
The biggest issue I see is treating the SAQ like a checklist you fill out once a year and shove to your QSA. That doesn't work. PCI requires that you maintain compliance continuously, not just on assessment day. If you check yes on a question in January and your environment changes in March, your SAQ is now inaccurate. I've seen merchants get flagged during a reassessment because their network diagram from six months prior didn't reflect a new server that was handling transaction data. Another common mistake is incompletely documenting evidence. The SAQ itself doesn't ask for attachments, but the ROC (Report on Compliance) that accompanies it does if you're working with a QSA. Even if you're doing a pure self-assessment without a QSA, your internal auditors or your acquiring bank will ask for proof. Screenshots of firewall rules. System configuration files. Password policy documents. Each "yes" answer should have at least one piece of evidence you can produce within a few hours. Then there's the question about remote access. Requirement 8 asks about authentication for remote administrative access. If you use a VPN to access your payment systems, you need to document how that VPN is secured. Multi-factor authentication, logging of all admin sessions, restricted source IPs. If your remote access is just a password-protected VPN with no MFA, you're non-compliant and you need to fix that before you sign the SAQ. I've seen people miss this because they assumed their VPN provider handled it. It didn't.
Where SAQ D Falls Short
SAQ D is comprehensive but it's also unwieldy. For a small business with a relatively simple environment, it's overkill and it takes too long. I've heard from merchants who spent 40 to 60 hours on their first SAQ D cycle, mostly because they didn't have good documentation to start with. If you're a small operation, check whether you actually need SAQ D before you commit to it. There's a chance you qualify for SAQ A-EP or SAQ P2PE and don't know it. Another limitation is that SAQ D doesn't automatically update when the underlying PCI DSS standard updates. The 4.0 version aligned with PCI DSS v4.0, but if the Council releases v4.1 or v5.0, there's a lag before the SAQ catches up. During that gap, you're technically assessing against an outdated questionnaire even though your environment should meet the newer requirements. The Council usually publishes guidance notes during transitions, but they're not always clear about what to do in the meantime. And let's be honest about the validation piece. If you're a merchant and your volume doesn't require a formal ROC, you still have to send your completed SAQ D to your acquiring bank or payment brand. They review it. Sometimes they accept it. Sometimes they reject it and ask for a QSA to perform a full assessment. There's no standard criteria for when that happens, and it varies by acquirer. I've seen the same SAQ D accepted by one bank and rejected by another for identical environments.
What I'd Do Differently Next Time
If I were starting a SAQ D process from scratch today, the first thing I'd do is build a proper cardholder data environment map before opening the questionnaire. Not a quick diagram, but a detailed one showing every system, every data flow, every interface point. This took my last client about two weeks because their environment was messy. But it cut the actual SAQ completion time from three weeks down to four days because we already knew where the gaps were. I'd also set up a continuous compliance process instead of an annual scramble. Tools like network scanning, configuration management, and automated evidence collection can keep your SAQ answers current throughout the year. It costs money, but it's cheaper than spending three weeks every December trying to remember whether you patched that server in Q2. One specific edge case that caught me off guard: my client had a third-party payment processor that claimed to be PCI compliant. Their compliance certificate was current. But the SAQ asked about the security of all systems that handled cardholder data, including those managed by third parties. The third party's compliance didn't automatically satisfy the requirement. We had to get their Attestation of Compliance and then map their covered systems against our own environment to identify where the responsibility boundaries fell. If you skip that step, you'll have unanswered questions in the SAQ about external dependencies.
The document itself is free to download from the PCI SSC website. You don't need to buy anything. What you need is time, honest documentation of your environment, and a willingness to find the gaps before your acquirer does.
