PCI SAQ D: why you landed on the full questionnaire, and the way off

How a merchant lands on SAQ D

Nobody chooses SAQ D. You end up there when no shorter questionnaire describes how you take cards. The Council's summary puts it in one line: SAQ D for Merchants is for “All merchants not included in descriptions for the above SAQ types.” The SAQ type finder walks the Council's flowchart in the same order, and SAQ D sits at the end of several of its branches:

1. 01Are you a service provider eligible to self-assess? SAQ D for Service Providers
2. 02Is account data stored electronically, old files included? SAQ D for Merchants
3. 03For each channel: does it meet every criterion of a shorter SAQ? If not, SAQ D for Merchants
4. 04More than one channel, on different SAQs? Ask your acquirer

6. None of thesea shorter SAQ

Source: SAQ Instructions v4.0.1 r1, flowchart pp. 24–25, read on 2026-10-22

Storage comes before channels on purpose. Storing card data electronically, legacy data included, sends a merchant to SAQ D for Merchants in the Council's flowchart, whatever the channel. A tidy counter terminal does not help if last year's phone orders still sit in a spreadsheet. Here is how that looks in a small business:

One line explains many of the surprises. Every shorter SAQ, from A to SPoC, carries the same line in its eligibility criteria: “Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically.” A card number a customer emailed you is account data received electronically, and it stays in the inbox until someone deletes it. Our guide on storing credit card information covers where those copies hide.

What SAQ D asks: the whole standard

The shorter SAQs are cut-down versions of PCI DSS, each trimmed to the requirements its setup can touch. SAQ D is not trimmed. The Council's own table of e-commerce methods shows the jump:

Source: SAQ Instructions v4.0.1 r1, p. 10 (PCI DSS v4.x requirements per e-commerce method), read on 2026-10-22

“All” means every one of the 12 requirements below, sub-requirements included. Stripe, which sends its direct-API users to SAQ D, puts the size of that in its own words: a business that handles card data “might be required to meet each of the 300+ security controls in PCI DSS.” That is Stripe's figure, not a Council count.

1. 01Install and maintain network security controls.
2. 02Apply secure configurations to all system components.
3. 03Protect stored account data.
4. 04Protect cardholder data with strong cryptography during transmission over open, public networks.
5. 05Protect all systems and networks from malicious software.
6. 06Develop and maintain secure systems and software.
7. 07Restrict access to system components and cardholder data by business need to know.
8. 08Identify users and authenticate access to system components.
9. 09Restrict physical access to cardholder data.
10. 10Log and monitor all access to system components and cardholder data.
11. 11Test security of systems and networks regularly.
12. 12Support information security with organizational policies and programs.

Source: PCI DSS v4.x Quick Reference Guide, p. 8, read on 2026-10-22

The form also reads like the standard itself. When the Council rewrote the SAQs for v4.x, it added explanations to help merchants judge the more complicated requirements in the context of their SAQ, a change it footnotes as applying to every SAQ “Except for SAQ D for Merchants and SAQ D for Service Providers.” And every requirement needs an answer. Where one cannot apply to you (a requirement written for service providers only, say), each SAQ carries “Guidance for Not Applicable Requirements” and an appendix where you describe why. A requirement you simply skip is not the same as one you mark Not Applicable with a reason.

The SAQ D year: what comes back, and when

Filling in the form is a once-a-year job. Most of what makes SAQ D heavy keeps coming back through the year. These are the requirements whose own text sets a schedule; the rest are things you keep in place all the time.

If you sell online, one more line runs all year without a date of its own. Under 6.4.3, every script on the payment page that runs in the shopper's browser is authorized, its integrity is assured, and an inventory lists every script with a written reason it is needed; 11.6.1 in the table then watches those scripts for changes. The SAQ A guide explains both, and how the January 2025 change took them off SAQ A.

The penetration test

External (11.4.3) and internal (11.4.2) penetration tests run “At least once every 12 months” and after any significant infrastructure or application change, by a qualified, independent tester (not required to be a QSA or ASV). If you use segmentation, it is tested at least once every 12 months too (11.4.5). You also write down how you test. Requirement 11.4.1 asks for a methodology that includes, among other things:

• “Coverage for the entire CDE perimeter and critical systems.”
• “Testing from both inside and outside the network.”
• “Testing to validate any segmentation and scope-reduction controls.”
• “Application-layer penetration testing”

Source: PCI DSS v4.0.1, 11.4.1 to 11.4.5 (Prioritized Approach Tool), read on 2026-10-22

“Independent” is the word small businesses trip on. For internal scans the Council gives its own example, “a network administrator should not be responsible for scanning the network,” and the testers in 11.4.2 and 11.4.3 need the same organizational independence. Our guide to what a PCI penetration test costs covers what drives the price and what to ask a tester before you sign.

Internal and external scans, every quarter

SAQ D carries both scan requirements. Internal vulnerability scans run “At least once every three months,” by qualified, independent staff; a QSA or ASV is not required for internal scans. External vulnerability scans run “At least once every three months” and “By a PCI SSC Approved Scanning Vendor (ASV),” with rescans until the ASV Program Guide's passing-scan rules are met. In the first year, you do not need four passing scans if the most recent scan passed, a written policy requires scans at least every three months, and fixes were confirmed by rescan. After the first year, the Council expects passing scans at least every three months.

Only a company on the Council's Approved Scanning Vendors list can run the external scan. What an ASV scan is explains a passing report, and the ASV scanning vendors compared sets the listed scanners side by side.

Training, on hire and every year

Requirement 12.6 asks for a formal security awareness program; staff are trained “Upon hire and at least once every 12 months,” acknowledge the security policy at least once every 12 months, and training covers phishing and social engineering (12.6.3.1). For a shop with a handful of staff this can be short, but it has to happen, be repeated and leave a record. The PCI security awareness training guide covers what the program needs.

How to get off SAQ D

SAQ D follows how card data moves through your business, not what you sell. Change the thing that sent you there and the finder can walk you to a shorter form. Processors know this: Stripe's own PCI guide calls SAQ D “the most demanding of the SAQs” and lists the integrations that avoid it. The common exits: a hosted or iframe checkout instead of your own card form, tokens instead of stored card numbers, and a P2PE terminal instead of a setup that fails its criteria. Pick your reason:

Before you start the shorter SAQ, confirm with the organization you submit it to (usually your acquirer, the merchant bank) that you are eligible for it. Each exit changes what you tell them, so put it in writing: what you changed, on which date, and what you deleted. The SAQ A guide covers the online side in depth, and tokenization vs encryption explains why tokens shrink scope and encrypted copies may not.

If you stay on SAQ D: keep the scope small

Some setups keep SAQ D for a reason, such as software you run that has to handle card numbers itself. Then the job is to keep the part of the business that touches card data as small as you can, because every requirement applies to everything inside it. PCI DSS scope is documented and confirmed “at least once every 12 months and upon significant change,” and that review starts with “Identifying all data flows for the various payment stages” and all locations where account data is stored, processed and transmitted.

1. 01Map every place a card number goes: each payment stage, each channel, each system that stores, processes or transmits it. Req. 12.5.2
2. 02Wall those systems off from the rest of the network, so the office PCs and guest Wi-Fi sit outside the cardholder data environment. Req. 1.3.1
3. 03Penetration-test that wall every 12 months and after any change to it, or it does not count as out of scope. Req. 11.4.5
4. 04Remove card data from everything that does not need it: old exports, test copies, staff laptops, shared drives. Req. 3.2.1
5. 05Write it down: the scope, the security policy and an incident response plan that is ready to be activated. Req. 12.1.1, 12.10.1

Source: PCI DSS v4.0.1, 1.3.1, 3.2.1, 11.4.5, 12.1.1, 12.5.2, 12.10.1 (Prioritized Approach Tool), read on 2026-10-22

Compliance software can hold the evidence and remind you of the dates; the PCI compliance software compared page shows which platforms name which SAQs. If the scope itself is the hard part, a consultant or a QSA can draw it with you; see PCI compliance consultants compared.

SAQ D on one receipt