The PCI DSS SAQ A is the simplest self-assessment questionnaire provided by PCI DSS: fewer than 30 questions versus over 300 in SAQ D. Understanding who can complete it and how to get there is strategic for any merchant wanting to reduce the compliance burden without sacrificing security. The distinction between different SAQ types depends on how and where card data is handled.
PCI DSS SAQ types: from A to D, what changes
The PCI Security Standards Council has defined several types of SAQ (Self-Assessment Questionnaire) to adapt compliance requirements to the merchant's actual risk profile. Not all merchants have the same level of exposure: an e-commerce using a hosted payment page is very different from a company processing card numbers by phone and storing them in an internal database.
The main types are: SAQ A for card-not-present merchants that completely delegate card data handling to certified third parties; SAQ A-EP for e-commerce with partially delegated payment page; SAQ B for physical terminals not connected to the internet; SAQ C for connected POS systems; SAQ D for all other merchants, including those storing PANs or directly managing checkout. SAQ D is the most complete and onerous.
SAQ A vs SAQ D: the difference worth hours of work
The difference between SAQ A and SAQ D is not just in the number of questions. SAQ D requires documenting security policies, access controls, logging procedures, vulnerability management, incident response plans and much more. An average merchant takes weeks to gather evidence and complete it correctly, often with the support of an external consultant.
SAQ A, by contrast, focuses on a minimal perimeter: it verifies that the merchant does not store, process or transmit card data on their own systems and that the payment provider used is PCI DSS certified. With SAQ A, a merchant can independently manage their own self-assessment in a few hours, without specialised consulting and without having to document the entire IT infrastructure.
How to move from SAQ D to SAQ A with tokenization
The prerequisite for SAQ A is that no card data transits or is stored on the merchant's systems. Tokenization solves this problem at the root: checkout sends card data directly to PCI Proxy EU's certified vault via a hosted payment page or client-side SDK. The merchant receives only an opaque token, which has no value outside the vault.
This architectural change has a direct impact on the applicable SAQ type. A merchant today completing SAQ D because their CRM or management system receives PANs can migrate to SAQ A simply by adopting a certified tokenization solution. The perimeter shrinks, documentation simplifies and the total compliance cost drops significantly.
Frequently asked questions
How many questions does SAQ A have?
The SAQ A in PCI DSS v4.0 version contains approximately 22 verifiable requirements, many of which simply require confirmation that data handling is delegated to a certified provider. SAQ D, in the same version, exceeds 300 questions with requests for documentary evidence for each.
Does SAQ A apply to all e-commerce merchants?
No. SAQ A is valid only for card-not-present merchants who never touch card data on their own servers. If checkout is hosted entirely by the certified payment provider and the merchant never sees a PAN, SAQ A is applicable. If instead the merchant manages even just part of the payment form, they fall under SAQ A-EP or SAQ D.
With PCI Proxy EU which SAQ do I need to complete?
In the standard configuration, where checkout uses PCI Proxy EU's hosted page or client-side SDK without card data transiting through your servers, you can complete SAQ A. Your acquirer or PSP can confirm this during the onboarding phase.
Want to move from SAQ D to SAQ A, drastically reducing your compliance burden? Discover PCI Proxy EU.