PCI DSS SAQ types explained: A, A-EP, B, C and D

Most smaller organisations validate their PCI DSS compliance by completing a Self-Assessment Questionnaire (SAQ). But there isn’t just one SAQ — there are several types, and picking the right one is the single most important step. This guide explains each type and when it applies.

Why there are different SAQs

The SAQ you complete is determined by how you accept card payments. Each type contains only the PCI DSS requirements relevant to that payment method, so choosing correctly means you assess the right controls — no more, no less. Complete the wrong SAQ and you may either miss controls you need or waste effort on controls that don’t apply.

If you take payments in more than one way, you may need to consider more than one SAQ, or a fuller one that covers all your channels.

The main SAQ types at a glance

SAQ	Best suited to	Card-present or not
A	Fully outsourced e-commerce / mail-order-telephone-order	Card-not-present
A-EP	E-commerce where your site affects the payment but doesn’t receive card data	Card-not-present
B	Standalone dial-out terminals or imprint machines, no electronic storage	Card-present
B-IP	Standalone IP-connected payment terminals, no electronic storage	Card-present
C	Payment application connected to the internet, no electronic storage	Card-present or e-commerce
C-VT	Web-based virtual terminal on an isolated computer	Card-not-present
D	Everyone else — merchants and service providers not covered above	Any
P2PE	Merchants using a validated point-to-point encryption solution	Card-present

SAQ A

SAQ A is the shortest and simplest. It applies to card-not-present merchants (e-commerce, mail order or telephone order) who have fully outsourced all cardholder data functions to a PCI DSS compliant third party. Your systems never store, process or transmit card data.

A typical example is an online shop that redirects customers to a payment provider’s hosted page, or embeds a payment form served entirely by that provider. Because card data never touches your systems, most of PCI DSS falls away.

SAQ A-EP

SAQ A-EP applies to e-commerce merchants who partially outsource payment processing but whose website can affect the security of the transaction — for example, a site that includes JavaScript from your own server on the payment page, or that manages the payment page itself while the card data goes directly to a processor.

A-EP is significantly longer than A because your web environment is in scope, even though you don’t store card data. If you run your own checkout code, this is often the one that applies.

SAQ B and B-IP

SAQ B is for card-present merchants using standalone, dial-out terminals (connecting over a phone line) or old-style imprint machines, with no electronic cardholder data storage.

SAQ B-IP is the modern equivalent for standalone terminals connected via IP (over the internet or a network) that are on the PCI-approved list, again with no electronic storage. Many small shops and care providers taking chip-and-PIN payments through a simple standalone terminal fall here.

SAQ C and C-VT

SAQ C applies to merchants with a payment application system connected to the internet — for example a till system linked to a payment terminal — provided there is no electronic storage of cardholder data.

SAQ C-VT applies to merchants who key payments into a web-based virtual terminal on a single, isolated computer with a dedicated internet connection, and who never store card data electronically. This is common where staff take occasional payments over the phone using a browser-based portal.

SAQ D

SAQ D is the comprehensive questionnaire and the catch-all. It applies to any merchant not eligible for the other SAQs — most notably those who store cardholder data electronically — and to most service providers. It covers the full set of applicable PCI DSS requirements, so it’s the longest and most demanding to complete.

P2PE

The P2PE SAQ is a short questionnaire for merchants using a validated point-to-point encryption solution, where card data is encrypted at the terminal and can only be decrypted by the solution provider. Because your environment never handles usable card data, the assessment is greatly simplified — provided the solution is on the PCI-listed P2PE list.

Choosing the right one

To identify your SAQ, work through these questions:

1. How do customers pay? In person, online, or over the phone?
2. Where does the card data go? Directly to a provider, or through your systems?
3. Do you store card data electronically? If yes, you’re heading towards SAQ D.
4. What equipment do you use? Standalone terminal, integrated till, virtual terminal, or a hosted web page?

The clearest way to simplify your obligations is to reduce your footprint so that a shorter SAQ applies — see reducing your PCI DSS scope. If a term here is unfamiliar, our glossary can help.

Why the shorter SAQs are worth aiming for

The difference between SAQ types isn’t just administrative — it reflects how much of your environment is exposed to card data. SAQ A contains only a handful of requirements, because card data never touches your systems. SAQ D, by contrast, covers the full standard and can run to hundreds of questions. Every step you take to keep card data out of your own systems moves you towards a shorter questionnaire and a lighter annual workload. This is why understanding SAQ types and scope reduction go hand in hand: the payment choices you make directly determine which questionnaire you’ll be completing each year.

A note on card-present versus card-not-present

A useful distinction running through the SAQs is whether the card is physically present. Card-present transactions (chip-and-PIN, contactless) generally map to SAQ B, B-IP, C or P2PE. Card-not-present transactions (online, phone, mail order) map to SAQ A, A-EP or C-VT. Many organisations take payments both ways — for example an in-person terminal plus an online shop — and each channel needs to be assessed against the right questionnaire. It’s perfectly normal to consider more than one, or to complete the more comprehensive SAQ D if your setup spans several channels.

Getting it wrong — and getting it right

The most common error is defaulting to SAQ A because it’s the shortest, when the way payments are actually taken calls for A-EP or C-VT. Another is assuming a payment provider’s compliance covers you entirely, when in fact you still have your own attestation to complete. The remedy is simple: map your payment flows honestly, from the moment a customer decides to pay to the point the transaction settles, and let that map — not convenience — dictate the SAQ.

How we can help

Selecting the wrong SAQ is one of the most common — and costly — PCI DSS mistakes. We offer a transparent, fixed-fee engagement that reviews exactly how you take payments, confirms the correct SAQ, and supports you through completing it accurately. To talk it through, see our PCI DSS service or get in touch for a no-obligation chat.