Open resource, CC BY 4.0
PCI DSS SAQ eligibility table
Which self assessment questionnaire you qualify for, laid out by payment channel, with the disqualifiers called out.
The table itself
This is the artifact, not a preview of it. Search across every column, filter it down, print what you filtered. Nothing is sent anywhere and there is no email step.
Showing 10 of 10 rows
| SAQ | Who it is for | Card data handling | Disqualifiers | Requirements |
|---|---|---|---|---|
| A | Card not present merchants, e-commerce or mail order | Fully outsourced. You never store, process or transmit card data | Any page you serve that takes card data directly. A redirect or an iframe from the provider is required | Around 30, plus the v4 payment page script requirements |
| A-EP | E-commerce merchants whose site affects the payment page but does not receive card data | Provider handles card data, your site influences how the payment form loads | Receiving card data on your own servers at any point | Around 150 |
| B | Merchants using imprint machines or standalone dial-out terminals | No electronic storage of cardholder data | Any internet connected payment device | Around 40 |
| B-IP | Merchants using standalone IP connected terminals | No electronic storage, terminals validated to PTS | Storing card data electronically, or non-validated terminals | Around 80 |
| C-VT | Merchants keying transactions into a virtual terminal on an isolated machine | Manual entry, one transaction at a time, no storage | Any batch processing, or the machine used for anything else | Around 80 |
| C | Merchants with payment applications connected to the internet, no electronic storage | Application processes card data, nothing stored | Storing card data electronically | Around 160 |
| P2PE | Merchants using a validated point to point encryption solution | Card data encrypted at the device, you never see it | The solution not being on the PCI validated P2PE list | Around 35 |
| D Merchant | Any merchant not eligible for another SAQ | You store, process or transmit card data | Not applicable, this is the fallback | All applicable requirements, over 300 |
| D Service Provider | Service providers eligible to self assess | Handling card data on behalf of others | Volume thresholds that require a Report on Compliance | All applicable requirements plus service provider specific ones |
| Report on Compliance | Level 1 merchants and larger service providers | Any handling of card data at scale | Not applicable, this is required rather than chosen | Full assessment signed by a QSA |
Eligibility is confirmed by your acquirer or QSA, not by this table. Where you sit near a boundary, get it in writing before you complete the form.
Where the facts come from
Nothing here is our opinion dressed up as a rule. Every line traces back to a published source, cited so you can check it.
- PCI Security Standards Council SAQ instructions and guidelines, v4.0.1
- PCI DSS v4.0.1 requirements
What people use it for
Checking, before you fill one in, that you are filling in the right one.
Licence
Published under Creative Commons Attribution 4.0. Copy it, cut it about, put it in your own audit pack, sell the work you do with it. Credit Threatsys and you are within the licence. There is no email gate and there never will be.
More open resources
- India compliance registryEvery cyber security obligation an Indian organisation can be held to, in one table, with the regulator and the trigger against each.Open it
- CERT-In directions readiness checklistThe April 2022 directions turned into checks you can actually run, including the log retention and clock sync duties people miss.Open it
- DPDP compliance timelineWhat the DPDP Act asks for, in the order you have to do it, with the dependencies that decide what you can start today.Open it
Why picking the wrong SAQ is expensive
The self assessment questionnaires differ enormously in length and in what they require, and eligibility is determined by how you handle account data rather than by your size or volume.
Choosing the wrong one wastes effort in both directions. Preparing for a longer questionnaire than you need costs months. Preparing for a shorter one than you are eligible for costs more, because it surfaces at validation and you start again.
The distinction most often got wrong is between a hosted payment page where the payment fields are genuinely isolated from your page, and an implementation where your page can read or influence those fields. Those land in different questionnaires and the technical difference can look cosmetic.
What actually determines eligibility
Whether account data touches your systems at all. If a properly integrated hosted page or tokenisation means it never does, entire requirements leave your scope rather than being satisfied.
The channel. Card present, e-commerce, mail and telephone order, and unattended terminals each route differently.
Whether you store account data, which changes the picture substantially wherever it is true and is worth eliminating if you can.
Whether third parties are involved in the payment path, and what their own validation position is. Their compliance does not transfer to you, but it does affect what you are responsible for demonstrating.
How to use this table honestly
Answer against what your systems actually do, not against what the architecture diagram says. The commonest source of an incorrect eligibility answer is a diagram that predates a change.
Where you are between two categories, take the more demanding one for planning and confirm with your acquirer or QSA. Planning for more and needing less is recoverable; the reverse is not.
Then confirm the outcome in writing before you begin evidence collection. Your acquirer sets your validation requirements, and an assumption about which questionnaire applies is not a substitute for their confirmation.
What to do once you know your route
Start the evidence with a time dimension immediately: quarterly scans with rescans showing remediation, and log review records. These cannot be produced retrospectively, and they are what determines your earliest possible validation date.
Then reduce scope further if you can. Even after eligibility is settled, removing systems from the environment reduces the work each year, permanently.
Then work the technical gaps, which is where organisations instinctively start because it feels like progress and which is the least effective place to begin.
Not sure where to start?
Book a 30-minute call with a senior engineer. We will walk through your current posture, the frameworks that bind you, and what a realistic programme looks like.