Which SAQ applies to you: PCI DSS self-assessment eligibility explained

What an SAQ is, and why there are so many

An SAQ is a self-assessment tool from the PCI Security Standards Council for merchants and service providers allowed to validate without a full Report on Compliance. It lists the requirements that apply to one payment environment, asks whether each is in place, and ends with an attestation your organisation signs.

There are several versions because scope differs. A merchant whose website hands the whole payment to a compliant provider touches far less of the standard than one running its own payment application on an internet-connected network, so the Council publishes shorter questionnaires for narrower environments. The shorter the questionnaire, the stricter its eligibility conditions.

Whether you need to validate at all is covered in Do you need PCI DSS? Merchant levels, service providers and who decides; how the SAQ, ROC and AOC fit together in PCI DSS validation step by step: ROC, SAQ and AOC.

The SAQ family for PCI DSS v4.0.1

The table maps the questionnaires in use with v4.0.1 to the condition that most often decides eligibility. Each SAQ carries its own full list of criteria, and you must meet every item.

Once account data is kept on your systems after authorisation, even in a spreadsheet, a call recording or an e-mail archive, the short questionnaires stop applying and SAQ D becomes the route.

E-commerce: SAQ A or SAQ A-EP, and the script question

Both SAQ A and SAQ A-EP assume you use a payment provider. The difference is who controls the page or form where the customer types the card number. A redirect to the provider's page, or payment fields in an embedded frame served entirely by the provider, may fit SAQ A. If your own site builds or serves the payment form, through direct post or scripts you host or load, it can change where the data goes, and SAQ A-EP is the questionnaire written for it.

What changed for SAQ A

PCI DSS v4.0 introduced requirements to manage payment page scripts and detect unauthorised changes to them, mandatory since 31 March 2025. In January 2025 the Council removed those requirements, and the targeted risk analysis behind one of them, from SAQ A and replaced them with an eligibility criterion: the merchant must confirm its site is not susceptible to attacks from scripts that could affect its e-commerce systems. You must be able to show how you reached it. A parent page that loads analytics, chat or tag-manager scripts alongside the frame deserves a close look before SAQ A is chosen.

Card-present and phone payments

For shops, hotels and contact centres the question is how card data travels from the terminal or keyboard to the processor, and what it passes on the way.

• Standalone terminals. A dial-out terminal, or one connected over IP straight to the processor and not linked to your till or other systems, points to SAQ B or B-IP. Connecting it to the till network can end that eligibility.
• Validated encryption. Where every terminal belongs to a listed P2PE solution, SAQ P2PE usually gives the smallest card-present scope.
• Virtual terminals. Phone orders keyed one at a time into a provider's web terminal on a standalone computer fit SAQ C-VT. Card numbers on notepads, in the CRM or in call recordings take you outside it.
• Integrated point-of-sale. A payment application on an internet-connected, segmented system with no storage points to SAQ C; otherwise SAQ D.

Scope reduction is what usually moves a merchant to a shorter questionnaire; see PCI DSS scoping and segmentation: shrinking the CDE.

Why service providers use SAQ D or a ROC

A service provider handles account data for other businesses or can affect its security: hosting companies, gateways, BPOs and contact centres taking payments for clients. The shorter questionnaires describe merchant environments, so none apply. The only SAQ open to a service provider is SAQ D for Service Providers, and only where the card brands allow it to self-assess.

The brands set separate service-provider levels, and the largest providers must validate with a ROC from a QSA. Your customers matter as much: merchants that rely on you must monitor your compliance, and many ask for an AOC resulting from a ROC plus a responsibility matrix. A self-assessed AOC can meet the brand minimum and still fall short of a bank's or a large retailer's contract.

Who decides, and who signs

You propose a questionnaire; the acquirer accepts it or not. Applying the card brands' programmes, it confirms your level, whether self-assessment is allowed, which SAQ it expects and when the AOC is due, and it can set a higher bar than the brand minimum. Confirm the choice with it before you start; that is the Council's own advice.

The acquirer may also require a QSA, or an Internal Security Assessor (ISA) trained and qualified by the Council, to complete or review the SAQ. Otherwise an executive officer of your organisation signs, stating that every answer is true.

The AOC that goes with every SAQ

Each SAQ has a matching Attestation of Compliance summarising the environment, the channels covered, the providers relied on and the result. It is the document the acquirer files and customers ask for; an SAQ without its signed AOC does not complete validation.

The mistakes that invalidate an SAQ

• SAQ A with a script-loaded payment page. A site that builds the payment form, or loads unmanaged scripts beside the provider's frame, cannot simply tick the script criterion; address and evidence the exposure, or use SAQ A-EP.
• Mixed channels. A website, a shop and a phone line are three environments. Some acquirers accept one SAQ per channel; others want one questionnaire covering all, usually SAQ D. Ask first.
• Hidden storage. Card numbers in e-mail, chat logs, call recordings or scanned forms break the no-storage condition.
• No provider AOC. Several SAQs depend on your provider being compliant; without its current AOC you cannot confirm the criterion.
• Yes without evidence. An SAQ is an attestation, not a survey; after a breach, the evidence behind each answer is what gets examined.

For the wider picture see PCI DSS common mistakes: the ten that fail assessments and PCI DSS checklist: the 12 requirements in the order you will meet them.

Which SAQ applies to you: questions buyers ask