The PCI DSS self assessment is the compliance validation tool most used by Level 3 and 4 merchants. The self-assessment questionnaire (SAQ) exists in several variants, each designed for a specific type of payment acceptance architecture. Choosing the wrong SAQ or completing a more onerous one when unnecessary are common mistakes that increase compliance cost and complexity with no benefit. Understanding which SAQ applies to your situation is the first step to efficient compliance.
What the PCI DSS self assessment is and when it is used
The SAQ (Self-Assessment Questionnaire) is a self-evaluation document published by the PCI Security Standards Council that merchants can complete without the involvement of a certified QSA. It is available for Level 3 and 4 merchants and, in certain cases, for Level 2 merchants who request it from their scheme. The self-assessment process includes completing the questionnaire and, for some SAQ types, performing quarterly vulnerability scanning by a PCI SSC-approved ASV (Approved Scanning Vendor).
The self-assessment does not replace a formal audit in all contexts. Level 1 merchants, those with the highest transaction volumes, must always undergo an audit conducted by a QSA and produce a ROC (Report on Compliance). For Level 2 merchants, the requirement depends on the scheme: Visa Europe, for example, requires a ROC for all Level 2 merchants, while other schemes accept the SAQ. Before proceeding with the self-assessment, it is necessary to verify with the acquirer which validation method is accepted for your level.
Which SAQ you need to complete: the reference table
The SAQ to complete depends entirely on the payment acceptance architecture. SAQ A is the simplest, with fewer than 50 controls: it applies to e-commerce merchants that exclusively use payments hosted by third parties (hosted payment page or iframe) and merchants that accept cards only via certified terminals provided by third parties, without access to card data. SAQ A-EP, with approximately 190 controls, applies to e-commerce merchants using third-party JavaScript to collect card data directly in the customer's browser. SAQ B applies to merchants with POS terminals not connected to the internet or via telephone. SAQ B-IP is for standalone IP terminals connected to the internet but without card data storage.
SAQ C concerns merchants with internet-connected cash register systems. SAQ C-VT is for merchants who manually enter card data into a virtual terminal hosted by a provider. SAQ D is the most complex, with over 200 controls, and applies to all merchants not falling into previous categories, including those storing card data in their own systems or using APIs to transmit card data to gateways. SAQ P2PE applies to merchants using point-to-point encryption solutions validated by PCI SSC: it is very simple, with approximately 35 controls, because protection is managed entirely by the P2PE solution provider.
How to reduce the SAQ with tokenization
The most common and direct path from SAQ D to SAQ A is tokenization with a hosted payment page. A merchant today using their own checkout page with direct card data collection via API (SAQ D) can migrate to checkout hosted by the tokenization provider. In this scenario, the user enters card data on a page managed by the certified provider, the provider returns a token to the merchant, and the merchant never sees the PAN. The transition reduces the merchant's perimeter from a full CDE to no CDE, qualifying the merchant for SAQ A.
The operational savings of this migration are significant. An SAQ D merchant must perform quarterly vulnerability scanning of their servers, annual penetration testing, manage access control policies for the CDE, train staff on all applicable PCI DSS requirements and document dozens of controls. With SAQ A, most of these obligations disappear because the merchant's perimeter no longer includes systems that touch card data. The annual compliance cost for an SAQ A merchant is estimated at less than 20% of the equivalent cost for an SAQ D merchant with the same transaction volume.
Frequently asked questions
Does the self assessment replace a formal audit?
For Level 3 and 4 merchants, yes: the SAQ is the validation tool accepted by acquirers. For Level 1 merchants and many Level 2 merchants, a formal audit conducted by a QSA with production of a ROC is necessary. If you have doubts about your level or which validation method is accepted by your acquirer, verify directly with them before proceeding with the self-assessment.
Can I complete the SAQ on my own or do I need a QSA?
The SAQ can be completed independently by the merchant without QSA involvement. PCI SSC provides templates freely on its website, with detailed completion instructions. For complex architectures or doubts about correct SAQ classification, a consultant or payment service provider support can reduce the risk of errors. An incorrectly completed SAQ can be invalidated by the acquirer during review.
How many times per year do I need to complete the SAQ?
The SAQ must be completed once a year. Some acquirers require the updated SAQ to be submitted on acquiring contract renewal or on a fixed annual basis. For some SAQ types (such as SAQ A-EP and SAQ D), quarterly vulnerability scanning by an accredited ASV is also required. Check with your acquirer for the frequency and submission methods required for your contract.
From SAQ D to SAQ A with tokenization: the fastest path to simplify the annual PCI DSS self-assessment. Discover PCI Proxy EU.