Category: PCI DSS Compliance

SAQ D

Also known as: SAQ D, Self-Assessment Questionnaire D, SAQ D for Merchants, SAQ D for Service Providers

Simply put

SAQ D is a type of PCI DSS Self-Assessment Questionnaire that businesses use to check and report their own compliance with payment card security requirements. It is the longest and most comprehensive questionnaire, and it serves as the catch-all option for organizations that store, process, or transmit card data and do not qualify for one of the shorter, more narrowly scoped questionnaires. There are separate versions for merchants and for service providers.

Formal definition

SAQ D is a Self-Assessment Questionnaire published by the PCI Security Standards Council for use by SAQ-eligible entities in self-validating adherence to PCI DSS. It exists in two forms: SAQ D for Merchants, which applies to SAQ-eligible merchants that do not meet the eligibility criteria for any other SAQ type, and SAQ D for Service Providers, which applies to all service providers defined by a payment brand as SAQ-eligible. Because it functions as the catch-all questionnaire, SAQ D covers the broadest set of applicable PCI DSS requirements relative to other SAQ types, reflecting environments that electronically store, process, or transmit cardholder data. The specific requirement content, wording, and numbering vary by PCI DSS version (for example between v3.x and v4.0), so practitioners should validate against the current SAQ D document and PCI DSS version published by the PCI SSC and confirm SAQ eligibility with the applicable payment brand or acquirer.

Why it matters

SAQ D matters because it is the fallback validation path for organizations whose payment environments are too broad or complex to fit any of the shorter, narrowly scoped questionnaires. Merchants and service providers that electronically store, process, or transmit cardholder data, and that do not meet the eligibility criteria for another SAQ type, use SAQ D to self-assess and report their adherence to PCI DSS. Because it functions as the catch-all, it covers the broadest set of applicable PCI DSS requirements, which means it typically demands the most extensive documentation and control validation of any SAQ.

Getting the questionnaire selection right is consequential. Choosing a shorter SAQ when SAQ D actually applies can leave applicable requirements unassessed, creating a gap between reported compliance and the actual control environment. Conversely, treating an environment as fully in scope when it could be reduced through segmentation, tokenization, or other validated methods can impose unnecessary assessment burden. The evidence indicates that SAQ eligibility is determined by the applicable payment brand or acquirer, so practitioners should confirm which SAQ type applies rather than assuming.

Because the specific requirement content, wording, and numbering differ across PCI DSS versions, an organization completing SAQ D should validate against the current SAQ D document and PCI DSS version published by the PCI SSC. Relying on outdated questionnaire content can misstate which controls are in effect and how they are evidenced.

Who it's relevant to

Merchants with complex card data environments

SAQ-eligible merchants that store, process, or transmit cardholder data and do not qualify for a shorter, more narrowly scoped SAQ use SAQ D for Merchants. Because it is the catch-all merchant questionnaire, these organizations should confirm with their acquirer or payment brand that no other SAQ type applies before proceeding.

Service providers

SAQ D for Service Providers applies to all service providers that a payment brand defines as SAQ-eligible. Service providers should confirm their SAQ eligibility with the applicable payment brand, since eligibility to self-assess is determined by the brand rather than assumed.

Compliance and validation teams

Compliance officers and internal validation staff responsible for PCI DSS self-assessment need to determine whether SAQ D is the correct questionnaire and then work through its comprehensive requirement set. They should validate against the current SAQ D document and PCI DSS version, since requirement content, wording, and numbering vary between versions such as v3.x and v4.0.

Acquirers and payment brands

Acquirers and payment brands set and confirm SAQ eligibility for the merchants and service providers they work with. They are relevant to SAQ D because determining whether an entity may use a self-assessment questionnaire, and which type, falls to the applicable payment brand or acquirer.

Inside SAQ D

Most comprehensive SAQ

SAQ D is the Self-Assessment Questionnaire covering the broadest set of PCI DSS requirements, intended for merchants and service providers whose environments do not meet the narrower eligibility criteria of the other SAQ types. It reflects the widest applicability of controls among the SAQs.

Two variants

SAQ D exists in a version for merchants and a version for service providers. The service provider variant addresses additional requirements relevant to entities that store, process, or transmit cardholder data on behalf of others, so practitioners should select the variant matching their role.

Cardholder data storage in scope

SAQ D is commonly applicable to entities that store cardholder data (such as PAN and, under defined controls, other cardholder data elements). It addresses controls for protecting stored cardholder data; sensitive authentication data must not be retained after authorization, even when encrypted.

Requirement coverage across the standard

SAQ D spans requirements addressing areas such as securing stored data, encryption of transmission, access control, logging and monitoring, and security policies. The exact requirement numbering and wording differ between PCI DSS versions, so confirm against the current published standard and the current SAQ D document.

Attestation of Compliance (AOC)

Completion of SAQ D includes an associated Attestation of Compliance in which the assessed entity affirms its validation results. The AOC accompanies the completed questionnaire when reporting to acquirers or applicable parties.

Eligibility by exclusion

SAQ D generally applies to entities that do not qualify for a more specific SAQ (such as those tied to particular acceptance channels or outsourcing arrangements). Eligibility should be confirmed against the criteria defined in the current SAQ documentation.

Common questions

Answers to the questions practitioners most commonly ask about SAQ D.

Is SAQ D only for merchants that store cardholder data?

No. SAQ D is not limited to merchants that store cardholder data. It is the most comprehensive self-assessment questionnaire and applies to merchants that do not meet the eligibility criteria for any of the simpler, more narrowly scoped SAQs. A merchant may qualify for SAQ D based on how it accepts, processes, or transmits account data, not solely on whether it stores that data. Confirm eligibility against the current SAQ instructions and criteria published by the PCI Security Standards Council rather than assuming storage is the determining factor.

Does completing SAQ D mean I have satisfied every PCI DSS requirement in full?

Completing SAQ D means you are attesting to the applicable PCI DSS requirements as reflected in that questionnaire, but it is a self-assessment, not an assessment performed by a QSA, and it is scoped to the version of PCI DSS in effect. Some requirements may be marked as not applicable when properly justified. The specific requirements, their numbering, and their wording differ between PCI DSS versions, so you should validate your responses against the current published standard and the corresponding SAQ D document rather than assuming a fixed set of requirements.

How do I decide whether I should use SAQ D or a shorter SAQ?

Eligibility is determined by your acceptance channels and how account data flows through your environment, not by preference. Review the eligibility criteria stated in each SAQ and its instructions. If your environment does not fully match the narrower criteria of a channel-specific SAQ, SAQ D is typically the applicable option. Because criteria and questionnaire types can change between versions, confirm your selection against the current documents published by the PCI Security Standards Council, and consult your acquirer or the relevant card brand where their reporting requirements apply.

There are separate SAQ D versions for merchants and service providers. Which one applies to me?

One version of SAQ D is intended for eligible merchants and a separate version is intended for eligible service providers. Which applies depends on your role in the payment flow and how the card brands and your acquirer classify your entity. If you both accept payments as a merchant and provide services that could affect the security of other entities' account data, clarify your classification with your acquirer or the applicable card brand before selecting a version, and confirm against the current published documents.

How does my scope for SAQ D affect the effort involved in completing it?

Scope drives the effort. The systems, people, and processes that store, process, or transmit account data, and any systems that can affect the security of that environment, fall within scope. Reducing scope through validated approaches may lower the number of applicable requirements, but the effect on scope depends on the implementation and how it is validated, not on a label. Because scope directly determines which SAQ D questions apply and how they must be evidenced, defining and documenting scope accurately is a prerequisite before completing the questionnaire.

Can requirements in SAQ D be marked not applicable, and what supports that?

Some requirements may be recorded as not applicable when the underlying condition genuinely does not exist in your environment, and this must be justified rather than simply asserted. The current SAQ D document specifies how not-applicable responses are to be documented and what supporting rationale is expected. Because the handling of applicability, compensating controls, and reporting can differ between PCI DSS versions, follow the guidance in the version of SAQ D you are completing and retain documentation that supports each such determination.

Common misconceptions

Encrypting stored data means SAQ D lets you keep any card data you want.

Encryption may protect stored cardholder data under defined controls, but sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks) must not be stored after authorization even when encrypted. Encryption does not change that prohibition.

SAQ D is a single document that applies the same way to everyone.

SAQ D has separate merchant and service provider variants, and its applicability depends on the entity's role and environment. The correct variant and full applicability must be determined from the current SAQ criteria, not assumed.

SAQ D and PA-DSS or the PCI Software Security Framework are interchangeable ways to validate software.

SAQ D is a PCI DSS self-assessment mechanism for an entity's environment. Payment application and software security are governed by separate standards such as PA-DSS and the PCI Software Security Framework, which have their own scope and validation.

Best practices

Confirm which SAQ applies to your environment before defaulting to SAQ D, and select the correct merchant or service provider variant based on your role and acceptance channels.

Validate the current requirement wording and numbering against the published PCI DSS version and the current SAQ D document rather than relying on memory of prior versions.

Reduce SAQ D scope where feasible by minimizing where cardholder data is stored, processed, or transmitted, using techniques such as tokenization, truncation, or masking, and validate their effect on scope through implementation review rather than the label alone.

Verify that no sensitive authentication data is retained after authorization anywhere in the environment, including logs, backups, and encrypted stores.

Maintain documented evidence for each answered requirement, including access control, logging and monitoring, and encryption of transmitted cardholder data, so responses are supportable.

Complete and retain the associated Attestation of Compliance accurately, and coordinate with your acquirer or applicable reporting party on submission expectations.