Choosing the Right SAQ: A Plain-English Guide for Merchants

The right Self-Assessment Questionnaire (SAQ) depends on how you accept cards and whether your own systems ever store, process or transmit card data. In short, fully outsourced online or mail and telephone order payments point to SAQ A. An e-commerce site that controls how the payment page is delivered points to SAQ A-EP, and standalone terminals point to SAQ B or B-IP.

A validated P2PE solution means SAQ P2PE, a hosted virtual terminal on an isolated computer means SAQ C-VT, and an internet-connected payment application means SAQ C. Anything else needs SAQ D. Your acquirer has the final say.

What is a PCI SAQ, and who can use one?

An SAQ lets eligible merchants and service providers validate PCI DSS compliance themselves, instead of through a full Report on Compliance by a Qualified Security Assessor (QSA). Whether you're allowed to self-assess depends on your merchant level, which the card brands define and your acquirer applies. The largest merchants generally need a Report on Compliance, and most smaller merchants use an SAQ.

Each SAQ begins with eligibility criteria, and you must meet every one of them. If a single criterion doesn't hold, that SAQ isn't yours, however close the fit looks.

How many SAQ types are there in PCI DSS v4.0?

The PCI Security Standards Council (PCI SSC) published the v4.0 SAQs in April 2022, and there are nine:

• SAQ A
• SAQ A-EP
• SAQ B
• SAQ B-IP
• SAQ C
• SAQ C-VT
• SAQ P2PE
• SAQ D for Merchants
• SAQ D for Service Providers

The v3.2.1 versions remain usable until that standard retires on 31 March 2024. Whichever you choose, the SAQ and its attestation must match the version you're assessing against.

None of the nine is written specifically for accepting payments on a commercial phone or tablet. If that's how you take cards, ask your acquirer which questionnaire it expects.

Start with your payment channels

Before reading any eligibility list, map how you take payments. There are three broad channels: card-present (face to face), mail order or telephone order (MOTO), and e-commerce. For each one, note how card data enters your business, which systems it touches and which providers handle it.

Then answer three questions:

1. Does card data ever touch a system you own or manage, including a PC, a network, a spreadsheet or an email inbox?
2. Who controls the payment page or payment device: you or a provider?
3. Is any of your payment technology part of a validated, PCI-listed point-to-point encryption (P2PE) solution?

If you take payments through more than one channel, ask your acquirer whether it wants one questionnaire per channel or a single one that covers everything.

PCI SAQ types explained

SAQ A: fully outsourced card-not-present payments

SAQ A is for e-commerce and MOTO merchants that have outsourced all handling of account data to PCI DSS compliant service providers. You must not store, process or transmit card data electronically on your own systems or premises, and you must have reviewed your providers' Attestations of Compliance. For e-commerce, every element of the payment page delivered to the customer's browser must come only and directly from a compliant provider. In practice, that usually means a full redirect or an embedded frame.

The v4.0 version of SAQ A is longer than before. It now includes quarterly external vulnerability scans (requirement 11.3.2). It also adds two requirements for protecting payment pages from unauthorized scripts and changes, 6.4.3 and 11.6.1, which are best practices until 31 March 2025 and mandatory after that. They're there because the page on your site that leads to the provider's form can itself be tampered with.

SAQ A-EP: e-commerce with a merchant-controlled payment page

SAQ A-EP is for e-commerce-only merchants whose website doesn't receive card data but controls how customers or their data reach the payment processor. A payment form that posts directly to the processor, or JavaScript on your site that builds the form, typically puts you here. Everything except the payment page must be outsourced to compliant providers.

Because your website can affect the security of each transaction, A-EP is far larger than SAQ A and brings your web servers firmly into scope.

SAQ B: imprint machines and dial-out terminals

SAQ B covers merchants that use only imprint machines or standalone dial-out terminals. The terminals must not be connected to any other system in your environment or to the internet, and you can't store card data electronically. It applies to card-present and MOTO payments, not e-commerce.

SAQ B-IP: standalone IP-connected terminals

SAQ B-IP is for merchants using only standalone, PCI-approved PTS POI terminals that connect over IP to the payment processor. The terminals must not be connected to other systems in your environment, and they can't rely on another device, such as a computer, phone or tablet, to reach the processor. Secure card readers that plug into another device don't qualify. As with SAQ B, there's no electronic storage of card data.

SAQ C-VT: virtual terminals on an isolated computer

SAQ C-VT fits merchants whose only payment processing is a virtual terminal: a web-based payment interface provided and hosted by a PCI DSS compliant service provider, used through an internet-connected browser. The computer used to access it must be isolated in a single location and not connected to other locations or systems. It can't have software that stores card data, such as batch processing tools, and it can't have card readers attached.

SAQ C: payment applications connected to the internet

SAQ C is for merchants with a payment application system and an internet connection on the same device or local network. The payment system must not be connected to other systems in your environment, and the location must not be connected to other premises, so any network serves a single store. No electronic storage of card data is allowed. A small shop or restaurant with a single point-of-sale system that isn't linked to anything else in the business is the typical case.

SAQ P2PE: validated point-to-point encryption

SAQ P2PE applies when all payment processing goes through terminals from a validated, PCI-listed P2PE solution. Those terminals must be the only systems in your environment that handle card data, and you must follow every control in the solution's P2PE Instruction Manual. It isn't available for e-commerce. An encrypting terminal on its own doesn't count unless it's part of a listed solution.

SAQ D for Merchants

SAQ D for Merchants is for merchants eligible to self-assess who don't meet the criteria of any other SAQ. It covers every applicable PCI DSS requirement. Common reasons to land here include storing card numbers electronically and running payment systems on a network shared with other business systems.

SAQ D for Service Providers

This is the only SAQ available to service providers. The v4.0 version asks for more than its predecessor, including a description of the assessed environment and of the testing behind each response.

SAQ comparison table

Apart from SAQ D, every merchant SAQ also rules out storing card data electronically. Any card data you keep must be on paper and must not have arrived electronically.

Common SAQ selection mistakes

• Assuming a payment provider means SAQ A. If your site hosts a form or script that collects card data and sends it to the provider, you're likely in A-EP. If card data ever reaches your server, you're in SAQ D.
• Connecting an IP terminal to a till PC. Once the terminal depends on or connects to another system, B-IP no longer applies.
• Using a shared office PC for a virtual terminal. C-VT requires an isolated computer. If the same machine handles email and file shares, the SAQ doesn't fit.
• Treating any encrypting terminal as P2PE. SAQ P2PE only applies to validated, PCI-listed solutions, with the instruction manual followed.
• Forgetting side channels. Card numbers in email, chat, spreadsheets or call recordings mean you're handling card data electronically, which rules out most of the shorter SAQs.
• Checking eligibility once and never again. A new checkout plugin or a terminal swap can change your SAQ overnight.

Who decides which SAQ you use?

Your acquirer. The PCI SSC defines the SAQs and their eligibility criteria, but the card brands and acquirers decide how their merchants validate. Some also ask for more than an SAQ, such as QSA involvement for larger merchants.

Write down your reasoning for each eligibility criterion and share it with your acquirer when you're unsure. That record also helps next year, when someone has to confirm nothing has changed.

Frequently asked questions

Can we complete more than one SAQ?

Sometimes. A merchant with an online shop and in-store terminals might validate each channel with a separate SAQ, but acquirers differ on this. Ask how yours wants multiple channels handled before you start.

Can a service provider use SAQ A or another short SAQ?

No. Service providers that are eligible to self-assess use SAQ D for Service Providers, however limited their involvement with card data.

Do we need ASV scans if we complete an SAQ?

If your SAQ includes requirement 11.3.2, yes. You'll need quarterly external scans by an Approved Scanning Vendor. Check the questionnaire itself, and remember that under v4.0 this now includes SAQ A.

Should we switch to the v4.0 SAQs now?

You can use either version until 31 March 2024. Moving early gives you time to work through the new requirements while the future-dated ones are still best practices.

Next steps

1. List every payment channel and every system and provider involved in each one.
2. Rule out the SAQs whose criteria you don't meet, starting with the shortest.
3. Confirm your choice with your acquirer, in writing if you can.
4. Download the SAQ from the PCI SSC document library and read its eligibility section in full.
5. Recheck eligibility whenever you change a payment page, terminal, provider or process.