PCI DSS v4.0.1 SAQ D for MerchantsSupported in OneClickComply

Complete SAQ D Merchant with evidence collected for you

SAQ D Merchant is the PCI DSS v4.0.1 Self-Assessment Questionnaire D for Merchants, the most comprehensive SAQ, used by merchants that do not meet the eligibility criteria for any other SAQ type. It asks the merchant to confirm compliance with every applicable PCI DSS requirement across all 12 principal requirements, marking any that do not apply with a justification. The completed questionnaire is signed off with an Attestation of Compliance (AOC) and submitted to the merchant's acquirer or the payment brands.

See the SAQ D Merchant requirements

SAQ D Merchant Aligned

Automated Evidence

OneClickFix Enabled

Continuous Monitoring

In-House Audit Team

Who needs SAQ D Merchant

Is SAQ D Merchant right for your organisation?

SAQ D for Merchants applies to merchants permitted to self-assess whose card environment is too broad for SAQ A, A-EP, B, B-IP, C, C-VT or P2PE, for example merchants that store account data electronically or run their own systems that process card data. Whether a merchant may self-assess at all, and which SAQ to use, is ultimately confirmed by its acquirer. Service providers use the separate SAQ D for Service Providers instead.

It is usually required by customers, partners or schemes rather than by law.

Issued by: PCI Security Standards Council (PCI SSC)
Latest version: SAQ D for Merchants for PCI DSS v4.0.1, published October 2024
Applies to: Self-assessing merchants not eligible for any other SAQ type
Scope: All applicable PCI DSS requirements across all 12 principal requirements
Validation output: Completed SAQ plus Attestation of Compliance (AOC), submitted to the acquirer or payment brands
Enforced by: Acquiring banks and payment card brands, through merchant agreements
Assessment frequency: Annually, with quarterly external ASV scans
Type: Standard (contractual)
Region: Global
In OneClickComply: Supported today

How we help

OneClickComply makes it simple

PCI DSS SAQ D for Merchants is mapped in OneClickComply's control library and available on request. OneClickComply links the SAQ D requirements to automated evidence from your cloud, identity and device tools, generates the policies requirement 12 expects from your real environment, and monitors controls continuously so drift is caught before your annual attestation. Our in-house audit team and Ask an Auditor help you scope the cardholder data environment and justify any requirements marked not applicable.

Requirements covered

All 12 PCI DSS v4.0.1 principal requirements and their merchant-applicable sub-requirements, plus Appendix A2 for card-present POI terminals still using SSL or early TLS, completed with an Attestation of Compliance.

Already working towards another framework?

ISO 2700125% of SAQ D Merchant overlaps
SOC 289% of SAQ D Merchant overlaps
NIST CSF73% of SAQ D Merchant overlaps
GDPR23% of SAQ D Merchant overlaps

Evidence you collect once counts towards every framework it applies to.

Manual SAQ D Merchant vs. OneClickComply

Manual SAQ D Merchant

Working through every PCI DSS requirement in a long questionnaire by hand
Chasing screenshots of firewall, access and logging settings each year
Writing and updating a full set of security policies from scratch
Losing track of quarterly scans, reviews and periodic tasks between attestations
Guessing which requirements can be justified as not applicable

With OneClickComply

Each SAQ D requirement linked to a control with its status in one place
Evidence collected automatically from connected tools and admin consoles
Audit-ready policies generated from your actual environment
Continuous monitoring and alerts when controls drift between attestations
Auditor guidance on scope so not-applicable answers are defensible

Capabilities

Everything you need for SAQ D Merchant

SAQ D Merchant requirements mapped to controls you already run

Automated evidence for access, MFA, logging and configuration requirements

OneClickFix for supported misconfigurations, logged as evidence

AutoComplete policies covering requirement 12 and per-requirement policies

Vendor risk tracking for third-party service providers under 12.8

Ask an Auditor support on scoping and not-applicable justifications

How it works

Three steps to SAQ D Merchant compliance

Connect & scan

Connect your cloud, identity and SaaS tools. OneClickComply checks them against SAQ D Merchant and shows you exactly where you stand.

Fix & generate

OneClickFix remediates technical gaps in one click, and AutoComplete generates SAQ D Merchant-aligned policies from your real environment.

Monitor & evidence

Continuous monitoring keeps you compliant, and our in-house audit team is on hand when you need expert guidance.

Requirements

PCI DSS v4.0.1 SAQ D for Merchants requirements

The 12 PCI DSS v4.0.1 principal requirements with their merchant-applicable sub-requirement groups and Appendix A2; service-provider-only groups 12.4 and 12.9 and Appendix A1 are excluded from SAQ D for Merchants.

Reference	Requirement
1	Install and maintain network security controls
1.1	Processes and mechanisms for network security controls are defined and understood
1.2	Network security controls are configured and maintained
1.3	Network access to and from the cardholder data environment is restricted
1.4	Network connections between trusted and untrusted networks are controlled
1.5	Risks to the CDE from devices connecting to both untrusted networks and the CDE are mitigated
2	Apply secure configurations to all system components
2.1	Processes and mechanisms for applying secure configurations are defined and understood
2.2	System components are configured and managed securely
2.3	Wireless environments are configured and managed securely
3	Protect stored account data
3.1	Processes and mechanisms for protecting stored account data are defined and understood
3.2	Storage of account data is kept to a minimum
3.3	Sensitive authentication data is not stored after authorisation
3.4	Access to displays of full PAN and ability to copy PAN is restricted
3.5	Primary account number (PAN) is secured wherever it is stored
3.6	Cryptographic keys used to protect stored account data are secured
3.7	Key management processes cover all aspects of the key lifecycle
4	Protect cardholder data with strong cryptography during transmission over open, public networks
4.1	Processes and mechanisms for protecting cardholder data in transmission are defined and understood
4.2	PAN is protected with strong cryptography during transmission
5	Protect all systems and networks from malicious software
5.1	Processes and mechanisms for protecting against malware are defined and understood
5.2	Malware is prevented, or detected and addressed
5.3	Anti-malware mechanisms and processes are active, maintained and monitored
5.4	Anti-phishing mechanisms protect users against phishing attacks
6	Develop and maintain secure systems and software
6.1	Processes and mechanisms for developing and maintaining secure systems and software are defined and understood
6.2	Bespoke and custom software are developed securely
6.3	Security vulnerabilities are identified and addressed
6.4	Public-facing web applications are protected against attacks
6.5	Changes to all system components are managed securely
7	Restrict access to system components and cardholder data by business need to know
7.1	Processes and mechanisms for restricting access are defined and understood
7.2	Access to system components and data is appropriately defined and assigned
7.3	Access to system components and data is managed via an access control system
8	Identify users and authenticate access to system components
8.1	Processes and mechanisms for identifying users and authenticating access are defined and understood
8.2	User identification and related accounts are strictly managed throughout the account lifecycle
8.3	Strong authentication for users and administrators is established and managed
8.4	Multi-factor authentication is implemented to secure access into the CDE
8.5	Multi-factor authentication systems are configured to prevent misuse
8.6	Use of application and system accounts and their authentication factors is strictly managed
9	Restrict physical access to cardholder data
9.1	Processes and mechanisms for restricting physical access are defined and understood
9.2	Physical access controls manage entry into facilities and systems containing cardholder data
9.3	Physical access for personnel and visitors is authorised and managed
9.4	Media with cardholder data is securely stored, accessed, distributed and destroyed
9.5	Point of interaction (POI) devices are protected from tampering and unauthorised substitution
10	Log and monitor all access to system components and cardholder data
10.1	Processes and mechanisms for logging and monitoring are defined and understood
10.2	Audit logs are implemented to support detection of anomalies and forensic analysis
10.3	Audit logs are protected from destruction and unauthorised modification
10.4	Audit logs are reviewed to identify anomalies or suspicious activity
10.5	Audit log history is retained and available for analysis
10.6	Time-synchronisation mechanisms support consistent time settings across all systems
10.7	Failures of critical security control systems are detected, reported and responded to promptly
11	Test security of systems and networks regularly
11.1	Processes and mechanisms for regularly testing security are defined and understood
11.2	Wireless access points are identified and monitored, and unauthorised ones are addressed
11.3	External and internal vulnerabilities are regularly identified, prioritised and addressed
11.4	External and internal penetration testing is regularly performed and findings corrected
11.5	Network intrusions and unexpected file changes are detected and responded to
11.6	Unauthorised changes on payment pages are detected and responded to
12	Support information security with organisational policies and programmes
12.1	A comprehensive information security policy is known and current
12.2	Acceptable use policies for end-user technologies are defined and implemented
12.3	Risks to the cardholder data environment are formally identified, evaluated and managed
12.5	PCI DSS scope is documented and validated
12.6	Security awareness education is an ongoing activity
12.7	Personnel are screened to reduce risks from insider threats
12.8	Risk from third-party service provider relationships is managed
12.10	Suspected and confirmed security incidents that could impact the CDE are responded to immediately
A2.1	POI terminals using SSL or early TLS are confirmed as not susceptible to known exploits

Always check the official SAQ D Merchant text for the exact wording.

SAQ D Merchant FAQs

What is SAQ D for Merchants?

SAQ D for Merchants is the PCI DSS Self-Assessment Questionnaire for merchants that do not qualify for any of the simpler SAQ types. Published by the PCI Security Standards Council, the v4.0.1 version covers every applicable PCI DSS requirement across all 12 principal requirements. The merchant answers each requirement, justifies any marked not applicable, and signs an Attestation of Compliance that goes to its acquirer or the payment brands.

Who needs to complete SAQ D for Merchants?

Merchants that are allowed to self-assess but do not meet the eligibility criteria for SAQ A, A-EP, B, B-IP, C, C-VT or P2PE must complete SAQ D for Merchants. Typical examples are merchants that store cardholder data electronically or whose own systems store, process or transmit card data. Your acquirer confirms whether you can self-assess and which SAQ applies, so check with them before you start.

What is the difference between SAQ D for Merchants and SAQ D for Service Providers?

SAQ D for Merchants is for businesses that accept card payments for their own goods or services, while SAQ D for Service Providers is for organisations that store, process or transmit account data on behalf of other businesses. The service provider version includes additional requirements that apply only to service providers, such as those in 12.4 and 12.9 on compliance responsibility and supporting customers. Merchants should not use the service provider version.

How many requirements are in SAQ D for Merchants?

SAQ D for Merchants covers all 12 PCI DSS principal requirements and every merchant-applicable sub-requirement, making it the longest merchant SAQ. It also includes Appendix A2 for merchants with card-present POI terminals that still use SSL or early TLS. Requirements that do not apply to your environment can be marked not applicable, but each one needs a documented justification.

What happens if a merchant does not complete its SAQ D?

PCI DSS is enforced contractually through acquirers and payment card brands rather than by law. A merchant that fails to validate compliance can face consequences set out in its merchant agreement, which may include fees or penalties passed on by the acquirer, increased transaction costs, or in serious cases loss of the ability to accept card payments. A breach while non-compliant can also bring higher remediation costs.

How does SAQ D relate to ISO 27001?

SAQ D and ISO 27001 overlap heavily in areas such as access control, logging, vulnerability management, incident response and security policies, but they are not interchangeable. ISO 27001 certification does not replace PCI DSS validation, and SAQ D adds card-specific requirements such as protecting stored PAN and quarterly ASV scans. Mapping controls once lets evidence count towards both.

How often must SAQ D for Merchants be completed?

SAQ D for Merchants is normally completed annually, with a new Attestation of Compliance each year. Several requirements also involve recurring activity during the year, including quarterly external vulnerability scans by a PCI SSC Approved Scanning Vendor, quarterly internal scans, and periodic reviews of access, logs and third-party service providers. Your acquirer may set additional reporting expectations.

Does OneClickComply support SAQ D for Merchants?

SAQ D for Merchants is mapped in OneClickComply's control library and available on request. OneClickComply links its requirements to automated evidence collection, policy generation and continuous monitoring, and our in-house audit team can help with scoping. OneClickComply does not sign your Attestation of Compliance; the merchant remains responsible for its answers and for submitting the SAQ to its acquirer.

Related standards

All standards

Get SAQ D Merchant ready, not stressed

Automate controls, gather evidence continuously and stay audit-ready, all on one platform.