TL;DR: SAQ D self-assessment scope for e-commerce merchants
- Every merchant wants to be on SAQ A. Most of them belong on SAQ D and do not know it. If your site loads any script that could touch a payment field, you are not on the short form, no matter what the sales deck says.
- SAQ D covers all 12 PCI DSS requirements and runs 90+ pages to complete. Since PCI DSS 4.0.1 became mandatory in March 2025, 6.4.3 and 11.6.1 are in scope for every SAQ D merchant, and the January 2025 SAQ A exemptions do not apply.
- If you accept card data on systems you control, mix payment methods, or store cardholder data, complete SAQ D and build the 6.4.3 script inventory plus 11.6.1 header monitoring now. If a fully hosted iframe is your only integration and no first-party script can touch it, confirm with your acquirer whether SAQ A fits instead.
SAQ D is the Self-Assessment Questionnaire that covers everything the shorter SAQs do not. It applies to merchants and service providers whose payment environment is too broad to fit the narrower questionnaires. If your business accepts card data directly on any system you control, SAQ D is likely the form you complete each year.
Who has to complete SAQ D
The PCI Security Standards Council publishes several SAQ variants, each for a specific merchant profile:
| SAQ | Applies to |
|---|---|
| A | Fully outsourced e-commerce; card data never touches merchant systems; hosted iframe or redirect only |
| A-EP | E-commerce merchant whose website affects security of payment page (loads scripts, iframes with same-origin script access) |
| B | Imprint machines or standalone dial-out terminals, no electronic storage |
| B-IP | Standalone IP-connected terminals, no electronic storage |
| C | Payment application connected to internet, no electronic storage |
| C-VT | Virtual terminals accessed via browser, no electronic storage |
| P2PE | PCI-listed P2PE hardware payment terminals only |
| D | Everyone else who does not qualify for the above |
That last row is where most e-commerce ends up. Any merchant that accepts card data on their own systems, uses a mix of payment methods, or stores cardholder data completes SAQ D. Service providers below Level 1 also use SAQ D.
What SAQ D covers
SAQ D includes all 12 PCI DSS requirements in full:
- Install and maintain network security controls
- Apply secure configurations to all system components
- Protect stored account data
- Protect cardholder data with strong cryptography during transmission
- Protect all systems and networks from malicious software
- Develop and maintain secure systems and software
- Restrict access to system components and cardholder data by business need to know
- Identify users and authenticate access to system components
- Restrict physical access to cardholder data
- Log and monitor all access to system components and cardholder data
- Test security of systems and networks regularly
- Support information security with organizational policies and programs
Every requirement has multiple sub-requirements and evidence expectations. The current SAQ D template runs 90+ pages just to complete.
Where SAQ D gets hard: client-side controls
Requirements 6.4.3 and 11.6.1 became mandatory with PCI DSS 4.0.1 in March 2025. Both apply squarely to SAQ D merchants and cover client-side script control on payment pages:
- 6.4.3: maintain an inventory of every script loaded on payment pages, document business justification for each, verify integrity, detect unauthorized change
- 11.6.1: monitor HTTP headers on payment pages, detect and alert on unauthorized change
Most merchants completing SAQ D for the first time under 4.0.1 have no artifacts for either requirement. Our practical guide to complying with PCI 6.4.3 and 11.6.1 walks through what the evidence needs to look like.
The January 2025 update to SAQ A introduced very limited exemptions from 6.4.3 and 11.6.1, but those exemptions do not apply to SAQ D. If you are on SAQ D, both requirements are in scope.
How SAQ D differs from SAQ A
SAQ A is short (under 30 pages) because it assumes card data never touches your systems. SAQ D is long because it does not make that assumption. If you are unsure which SAQ you should be on, our how to be a PCI DSS SAQ A company guide walks through the criteria for the narrower form. If you cannot meet all of them, SAQ D is the answer.
A checklist before you start SAQ D
- Confirm SAQ D is actually the right form for your environment (talk to your acquirer if unsure)
- Complete your scope diagram covering every system that stores, processes, or transmits cardholder data
- Build the script inventory for every payment page (6.4.3)
- Set up HTTP header monitoring for payment pages (11.6.1)
- Pull evidence for each of the 12 requirements: configuration exports, screenshots, log samples, policies
- Book time for internal review before final attestation
Where cside fits
cside handles the 6.4.3 and 11.6.1 evidence directly. Continuous script inventory, business-justification tagging, integrity monitoring, header change detection, and alert history come from the platform, so those two requirements move from "we intend to comply" to "here is the evidence."
For the deeper walk-through of what the compliance dashboard produces and how it maps to SAQ D questions, see the PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 compliance guide.
