Category: PCI DSS Compliance

Self-Assessment Questionnaire (SAQ)

Also known as: SAQ, PCI SAQ, PCI DSS Self-Assessment Questionnaire

Simply put

A Self-Assessment Questionnaire (SAQ) is a tool that lets certain merchants and service providers check and report their own compliance with PCI DSS instead of undergoing a full on-site assessment. It applies to organizations that are eligible for self-validation based on how they accept and handle payment card data. Different SAQ types exist for different business situations, so an organization must use the version that matches how it processes transactions.

Formal definition

The SAQ is a set of PCI DSS validation tools published by the PCI Security Standards Council to help SAQ-eligible merchants and service providers perform and report the results of a self-assessment against applicable PCI DSS requirements. Multiple SAQ types exist, each scoped to a specific acceptance channel and processing environment; for example, SAQ A addresses merchants whose cardholder data functions are completely outsourced to validated third parties. Eligibility for a given SAQ, and the subset of requirements it covers, depends on the organization's payment acceptance model, and the SAQ is distinct from a full Report on Compliance (ROC) produced during an on-site assessment. SAQ content, eligibility criteria, and requirement mappings differ by PCI DSS version; SAQs for PCI DSS v4.0.1 were made available in October 2024, and practitioners should confirm the correct SAQ type and current version against the published standards rather than assuming fixed criteria.

Why it matters

The SAQ is the primary mechanism by which eligible merchants and service providers demonstrate PCI DSS compliance without the cost and effort of a full on-site assessment culminating in a Report on Compliance (ROC). For the large population of smaller merchants and organizations that outsource most or all of their cardholder data handling, the SAQ makes validation practical and proportionate to their risk profile. It gives acquirers and payment networks a documented statement that the organization has evaluated itself against the applicable PCI DSS requirements.

The stakes lie in selecting the correct SAQ type. Because each SAQ is scoped to a specific payment acceptance model and covers only a subset of PCI DSS requirements, using a version that does not match how an organization actually processes transactions can lead to an incomplete assessment that overlooks requirements genuinely in scope. An organization that believes its cardholder data functions are fully outsourced, for example, may nonetheless retain scope through redirect mechanisms, page integration, or supporting systems, and choosing an SAQ that assumes complete outsourcing could leave real exposure unaddressed.

SAQ content, eligibility criteria, and requirement mappings change between PCI DSS versions. The PCI Security Standards Council made SAQs for PCI DSS v4.0.1 available in October 2024, and the correct SAQ type and current version should be confirmed against the published standards rather than assumed from prior practice. Treating an SAQ as a fixed checklist across versions risks misalignment with the requirements that actually apply.

Who it's relevant to

Merchants

Merchants eligible for self-validation use the SAQ to assess and report their PCI DSS compliance based on how they accept and handle payment card data. Selecting the SAQ type that matches the actual acceptance model — rather than the one that appears simplest — is essential, since choosing an inappropriate version can leave in-scope requirements unassessed.

Service Providers

SAQ-eligible service providers may use the appropriate SAQ to perform and report a self-assessment against applicable PCI DSS requirements. They should confirm both their eligibility for self-validation and the correct SAQ type for their service model, as some service providers may instead be required to complete a full assessment.

Acquirers and Payment Networks

Acquirers and card networks receive SAQ results as a documented statement of a merchant's or service provider's PCI DSS compliance. They rely on the correct SAQ type being used and typically set validation expectations, so they benefit from verifying that the reported SAQ matches the organization's actual acceptance channel.

Compliance Officers and QSAs

Compliance officers and Qualified Security Assessors advising SAQ-eligible organizations help confirm eligibility, select the correct SAQ type, and interpret the applicable requirement subset. Because SAQ content and mappings differ by PCI DSS version, they should reference the current published standards — including the SAQs for PCI DSS v4.0.1 made available in October 2024 — rather than assuming fixed criteria.

Inside SAQ

SAQ Types

The PCI DSS SAQ is published in multiple variants (for example SAQ A, A-EP, B, B-IP, C, C-VT, P2PE, and D) intended to match different merchant and service provider processing environments. Each type includes a distinct subset of requirements based on how cardholder data is handled, so eligibility depends on the specific acceptance channel and technology in use. Confirm the applicable type and its criteria against the current published standard.

Attestation of Compliance (AOC)

A separate document typically completed alongside the SAQ, in which the merchant or service provider attests to the validation results. The AOC summarizes the assessment outcome and is often what acquirers or payment brands require as evidence, distinct from the questionnaire responses themselves.

Requirement Questions

A set of yes/no/not-applicable questions mapped to the applicable PCI DSS requirements for the chosen SAQ type. Requirement numbering and wording differ between PCI DSS versions, so the questions should be answered against the version and questionnaire currently in force rather than a remembered fixed set.

Eligibility Criteria

Each SAQ type states the conditions a merchant must meet to use it, such as constraints on whether cardholder data is stored electronically or how it is transmitted. Meeting the criteria is what determines the correct questionnaire; using an SAQ whose criteria are not met does not accurately reflect scope.

Scope Definition

The environment covered by the questionnaire, including systems, people, and processes that store, process, or transmit cardholder data or can affect its security. Controls such as tokenization, truncation, or validated P2PE may reduce scope, but their effect depends on correct implementation and validation, not on the label alone.

Common questions

Answers to the questions practitioners most commonly ask about SAQ.

Does completing an SAQ mean I'm fully PCI DSS compliant and don't need any other validation?

No. An SAQ is a self-validation tool intended to help eligible merchants and service providers document their assessment against the applicable PCI DSS requirements. Completing it does not, by itself, guarantee compliance, and it is not equivalent to a Report on Compliance (ROC) produced through a full assessment by a Qualified Security Assessor. Eligibility to use an SAQ, and whether additional validation is required, depends on your acquirer's and the applicable card brand's program rules, which vary and change. Confirm your specific validation obligations with your acquirer rather than assuming an SAQ is sufficient.

Is there just one SAQ that every organization uses?

No. There are multiple SAQ types, each intended for a different set of eligibility criteria based on how an organization accepts and handles account data, for example fully outsourced e-commerce, card-present with certain terminal configurations, or other channel-specific scenarios. Each SAQ type contains a different subset of requirements. Using the wrong SAQ can misrepresent your actual scope, so the SAQ selected should match the eligibility conditions defined in the current SAQ documentation, confirmed with your acquirer.

How do I determine which SAQ type applies to my environment?

Selection is driven by eligibility criteria tied to your acceptance channels and how account data is handled or outsourced. Review the eligibility descriptions in the current SAQ documents and confirm your interpretation with your acquirer, since they administer your validation program. Because SAQ types and their eligibility wording can differ between PCI DSS versions, verify against the currently published SAQ set rather than relying on a previously used type.

What information should I gather before starting an SAQ?

Before beginning, it helps to have an accurate scope definition, including the systems, people, and processes that store, process, or transmit cardholder data or that can affect the security of the cardholder data environment. Documentation such as network diagrams, data-flow diagrams, an inventory of system components, details of any outsourced functions and responsible parties, and evidence supporting each applicable requirement supports accurate self-assessment. Confirm the exact applicable requirements against the specific SAQ type and PCI DSS version you are using.

Does using an SAQ reduce the requirements I must meet, or just how I validate them?

An SAQ reflects a subset of requirements considered applicable to a specific eligibility scenario; it is a validation vehicle, not a reduction of your underlying security obligations. Requirements outside a given SAQ are generally excluded because the eligibility criteria assume those functions are not present or are outsourced. If your environment does not match the SAQ's assumptions, additional requirements may apply. Confirm applicability against the current SAQ and PCI DSS version and with your acquirer.

Do outsourcing and third-party providers affect my SAQ obligations?

Yes. Outsourcing certain functions can influence which SAQ type you are eligible to use and can shift some responsibilities to third-party service providers, but it generally does not remove your accountability for confirming that those providers meet applicable PCI DSS requirements. You typically need to document which responsibilities are yours and which belong to each provider. The specifics depend on your arrangements, the current SAQ eligibility criteria, and your acquirer's program rules; confirm these directly rather than assuming outsourcing removes all obligations.

Common misconceptions

Completing an SAQ is the same as being certified compliant with PCI DSS for all purposes.

An SAQ is a self-assessment validation option intended for eligible entities; it documents self-reported compliance for a defined scope. It is not equivalent to an assessment performed by a Qualified Security Assessor, and acquirers or payment brands set which validation method applies to a given entity.

Any SAQ type can be chosen, and simpler SAQs like SAQ A always apply.

The correct SAQ is determined by how the environment handles cardholder data and by the stated eligibility criteria of each type. Using a shorter questionnaire that does not match the actual acceptance channel misrepresents scope; eligibility must be confirmed against the current published criteria.

The SAQ only concerns cardholder data, so storing authentication data is acceptable if the questions are answered.

PCI DSS prohibits storing sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks) after authorization, even when encrypted. No SAQ response overrides that prohibition; some cardholder data may be stored only under defined controls.

Best practices

Confirm the correct SAQ type by comparing your actual cardholder data flows and acceptance channels against the eligibility criteria in the current published questionnaire, rather than defaulting to the shortest form.

Accurately define and document scope first, including any tokenization, truncation, masking, or validated P2PE, and verify that scope-reducing controls are implemented and validated before relying on them to select a simpler SAQ.

Verify that no sensitive authentication data is retained after authorization, and that any stored cardholder data is protected under the applicable defined controls.

Answer requirement questions against the version and wording of the standard currently in force, since numbering and phrasing differ between PCI DSS versions.

Complete and retain the associated Attestation of Compliance, and confirm with your acquirer or payment brand which validation method and documents they require for your entity.

Reassess the applicable SAQ type whenever the payment environment, technology, or data flows change, and coordinate with your acquirer on regional and network-specific expectations.