PCI DSS v4.0 SAQ-D: Everything Merchants and Service Providers Need to Know
PCI DSS v4.0 became mandatory on March 31, 2024 when the PCI Security Standards Council retired v3.2.1. SAQ-D is the most comprehensive Self-Assessment Questionnaire, covering all 12 PCI DSS Requirements in full. If your organisation stores, processes, or transmits cardholder data and doesn't qualify for a simpler SAQ (A, A-EP, B, B-IP, C, P2PE), SAQ-D applies. Use the PCI DSS v4.0 SAQ-D Compliance Checklist to assess your organisation across 42 key controls and generate a tailored remediation report.
What Is PCI DSS and Who Must Comply?
The Payment Card Industry Data Security Standard (PCI DSS) was created by the PCI Security Standards Council — founded by Visa, Mastercard, American Express, Discover, and JCB — to protect cardholder data across all entities involved in payment card processing. Compliance is required by card brand rules and typically enforced through contractual obligations with acquiring banks.
Who must comply: Any merchant or service provider that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). This includes e-commerce platforms, SaaS companies handling payment data, payment facilitators, acquirers, and any third-party service provider with access to the cardholder data environment (CDE).
Merchant levels: Level 1 (>6M transactions/year, or any breached merchant) requires annual onsite assessment by a Qualified Security Assessor (QSA) producing a Report on Compliance (ROC). Levels 2–4 may self-assess using an SAQ. Service providers have separate Level 1/2 thresholds.
Key Changes in PCI DSS v4.0
1. Customised Approach (New in v4.0)
Organisations can now implement alternative controls that meet the stated objective of each PCI DSS requirement, rather than the specific prescribed control. Each Customised Approach control must be formally documented with a Controls Matrix explaining how the objective is met, reviewed and validated by a QSA, and supported by ongoing evidence. This is valuable for organisations with mature security programmes that exceed the prescriptive minimum but implement controls differently (e.g. using a different MFA technology).
2. Targeted Risk Analysis (TRA)
Many v4.0 requirements allow the frequency of control execution to be determined by a documented Targeted Risk Analysis rather than fixed intervals. A TRA must: identify the asset/activity being protected, identify realistic threats, assess likelihood and impact, determine how the control mitigates the threat, and conclude on the appropriate frequency. This shifts PCI DSS from a compliance checkbox exercise to genuine risk management — but also means organisations must maintain TRA documentation for QSA review.
3. Password Policy Strengthened (Req 8.3.6)
v4.0 raises the minimum password length from 7 characters (v3.2.1) to 12 characters for systems that support this. Systems that technically cannot support 12-character passwords may use 8 characters with additional complexity (uppercase + lowercase + number + special character). Password reuse: last 4 passwords cannot be reused. Maximum age: 90 days. For low-risk accounts with MFA on every login, some password rotation requirements may be adjusted via TRA.
4. MFA Expanded to All CDE Access (Req 8.4–8.5)
v3.2.1 required MFA only for remote access into the CDE (e.g. VPN). v4.0 requires MFA for all non-console access to CDE system components — including administrative access from within the internal network. This means a system administrator logging into a production database server from their workstation inside the office network now requires MFA if that server is in scope. MFA must not be bypassed for any user including administrators.
5. Authenticated Internal Vulnerability Scanning (Req 11.3.1.1)
v4.0 introduces a new requirement: internal vulnerability scans must use authenticated scanning credentials. Unauthenticated scans miss many vulnerabilities visible only after login — missing patches, misconfigurations, and weak service accounts. Authenticated scanning requires scanner credentials with read access to system configuration; results are significantly more comprehensive and may reveal vulnerabilities that previously went undetected in quarterly scans.
6. SDLC Security (Req 6.2, 6.3)
v4.0 formalises software development lifecycle security requirements: all custom code must be reviewed before production deployment (using manual code review, automated SAST tools, or DAST for web apps); developers must complete secure coding training at least annually; and separation of duties must prevent developers from promoting their own code to production. This applies to all in-scope custom code including payment page JavaScript, backend APIs, and mobile apps.
7. File Integrity Monitoring Enhanced (Req 11.5.2)
v4.0 explicitly extends FIM requirements to cover content files — not just system/configuration files. This is a direct response to the Magecart/web skimming attack pattern: attackers inject malicious JavaScript into payment page files to exfiltrate card data in real time. FIM must alert on unauthorised modification of payment page scripts, CDN-hosted assets, and any content files served to browsers during the checkout process.
SAQ Types: Which Applies to You?
- SAQ A: Card-not-present merchants that have fully outsourced all payment functions; no CHD on premises; redirect or iFrame payment page hosted by PCI-compliant provider
- SAQ A-EP: E-commerce merchants using a partially outsourced payment page where the merchant's website directly affects security (e.g. JavaScript loaded from merchant server)
- SAQ B: Merchants using only imprint machines or standalone terminal dial-up; no electronic cardholder data
- SAQ B-IP: Merchants using standalone IP-connected payment terminals; no other electronic CHD
- SAQ C: Merchants with internet-connected payment application systems; no stored CHD
- SAQ P2PE: Merchants using PCI SSC-validated Point-to-Point Encryption solution; significantly reduced scope
- SAQ D — Merchants: Merchants not qualifying for any other SAQ type; all 12 Requirements apply
- SAQ D — Service Providers: Service providers eligible to self-assess; all 12 Requirements apply
Scope Reduction Strategies
Reducing PCI DSS scope — the number of systems, people, and processes subject to assessment — is the single most effective compliance strategy. Fewer in-scope components means lower cost, simpler compliance, and reduced breach risk.
Tokenisation: Replace the PAN with a non-sensitive token after the first transaction. The token has no value to attackers. Systems using only tokens are typically out of scope. The tokenisation system itself remains in scope and must be PCI-compliant or performed by a validated third-party token service provider.
Point-to-Point Encryption (P2PE): A PCI SSC-validated P2PE solution encrypts card data at the point of interaction (card swipe/dip/tap) before it enters any merchant system. The merchant never handles cleartext PAN. With a validated P2PE solution, merchants may qualify for SAQ P2PE rather than SAQ D — dramatically reduced scope.
Hosted payment page (redirect/iFrame): Redirect the cardholder to a PCI-compliant payment provider's hosted page at checkout. If implemented correctly (no merchant-side JavaScript influencing the payment page, no CHD touching merchant servers), merchants may qualify for SAQ A — the simplest assessment type.
Outsourced card storage: Use the payment provider's card-on-file / recurring billing token vault rather than storing PANs internally. Eliminates Requirement 3 storage obligations.
Penalties for Non-Compliance
- Card brand fines: $5,000–$100,000 per month for non-compliance, escalating with time and severity
- Breach-related costs: Forensic investigation, card replacement costs ($3–$10 per card), fraudulent transaction liability, legal fees
- Card processing disqualification: Visa/Mastercard can prohibit merchants from accepting their cards — business-ending for e-commerce
- Reputational damage: Breach disclosure requirements, customer notification, news coverage
Use the PCI DSS v4.0 SAQ-D Compliance Checklist
The PCI DSS v4.0 SAQ-D Compliance Checklist covers 42 key controls across six requirement groups: network security (Req 1–2), account data protection (Req 3–4), vulnerability management (Req 5–6), access control (Req 7–9), monitoring and testing (Req 10–11), and information security policy (Req 12). Generate a tailored AI compliance report highlighting gaps against v4.0 new requirements, QSA evidence considerations, and a prioritised 90-day remediation roadmap — ideal preparation before engaging a Qualified Security Assessor.