There are nine PCI DSS SAQ types, and the one that applies to you is determined by how card data moves through your payment channel — not by your size, your revenue, or your preference. A Self-Assessment Questionnaire is a validation instrument for merchants and service providers who are not required to produce a Report on Compliance. Each SAQ is a subset of the twelve PCI DSS requirements, matched to a specific channel, and each is submitted with an Attestation of Compliance.
Most teams get this wrong in one of two directions. E-commerce merchants claim SAQ A when their checkout page makes them SAQ A-EP. Or a single unexamined system — a call recording, a legacy database, a terminal plugged into the office network — drops them all the way to SAQ D, which is substantially the full standard.
The questionnaires are published on the PCI Security Standards Council site. Getting the selection right before you start answering is worth more than any amount of care in the answers themselves.
Which SAQ Do I Need, in One Pass
Which SAQ you need comes down to one question asked in sequence: what touches cardholder data, and what can influence the thing that touches it. Walk it in this order.
- Do you take cards only by phone, mail or web, with every account data function outsourced and nothing stored, processed or transmitted on your systems? If the answer is genuinely yes, SAQ A.
- Are you e-commerce, outsourcing the processing, but your own website can affect the security of the payment transaction? SAQ A-EP.
- Do you use only imprint machines or standalone dial-out terminals, with no electronic storage? SAQ B.
- Do you use only standalone IP-connected payment terminals? SAQ B-IP.
- Do you use only a validated point-to-point encryption solution with hardware terminals? SAQ P2PE.
- Do you enter transactions only into a web-based virtual terminal on an isolated device? SAQ C-VT.
- Do you run a payment application system that is connected to the internet? SAQ C.
- Anything else, or more than one of the above in a way no single SAQ covers? SAQ D for Merchants.
Service providers eligible to use a questionnaire at all use SAQ D for Service Providers, which is scoped to the service provider role rather than a merchant channel.
The PCI DSS SAQ Types at a Glance
The nine PCI DSS SAQ types map to payment channels, so read the table below as a description of your own architecture rather than as a menu. Each row is a subset of the same twelve requirements.
| SAQ | Who it is for |
|---|---|
| A | Card-not-present merchants who have fully outsourced all account data functions, with no electronic storage, processing or transmission on their own systems |
| A-EP | E-commerce merchants who outsource payment processing but whose website can affect the security of the payment transaction |
| B | Merchants using only imprint machines or standalone dial-out terminals, with no electronic cardholder data storage |
| B-IP | Merchants using only standalone, IP-connected payment terminals |
| C-VT | Merchants using only a web-based virtual payment terminal on an isolated device |
| C | Merchants with payment application systems connected to the internet |
| P2PE | Merchants using only a validated point-to-point encryption solution with hardware terminals |
| D for Merchants | All other merchants |
| D for Service Providers | Service providers that are eligible to use an SAQ |
Two things are worth noticing. The short questionnaires are short because the channel removes you from most of the requirements, not because a lighter standard applies. And the eligibility conditions are absolute — "only", "no electronic storage", "fully outsourced" mean what they say, and one exception moves you off the form.
Who Decides Which SAQ You Use
Your acquirer or the card brand decides which SAQ is acceptable and which one you use. It is not your decision, and it is not the PCI Security Standards Council's decision either — the Council publishes the documents, the acquirer accepts the submission.
This is the single most useful fact in SAQ selection, because it reframes the work. You are not choosing a form; you are building a case for a form, which your acquirer may accept, reject or override. Teams who treat it as a choice discover the override late, usually after the questionnaire is finished.
So write down your payment channel, your PCI DSS scope and your proposed SAQ against v4.0.1, and send that to your acquirer before you answer a single question. If they disagree, you have lost an email. If you skip the step and they disagree, you have lost a quarter. Your merchant level and transaction volume also determine whether an SAQ is available to you at all.
Not sure whether you are SAQ A or SAQ A-EP?
Share your work email and we will map your checkout flow against the eligibility criteria for both and tell you which one your acquirer is likely to accept.
SAQ A-EP vs SAQ A for E-Commerce
SAQ A-EP vs SAQ A is the comparison that costs e-commerce merchants the most money, because the two forms sit on opposite sides of a line that is easy to cross without noticing. SAQ A assumes your systems have nothing to do with the payment. SAQ A-EP assumes your website can affect the security of the payment transaction, even though a third party does the processing.
The distinction is not about where the card number goes — in both cases it goes to the provider. It is about whether your site can influence what happens to it on the way.
What Counts as Affecting the Payment Page
What counts as affecting the payment page is broader than most teams assume, and v4 narrowed the SAQ A eligibility criteria specifically here. Scripts running on a payment page that can affect the integrity of the checkout bring that page into scope — and that is enough to move a merchant from SAQ A to SAQ A-EP.
That matters because almost nobody ships a bare checkout page. Analytics tags, session replay, chat widgets, consent managers, A/B testing snippets and tag managers that can inject further scripts all execute in the same page context as the payment fields. If your page loads them, your page can affect the transaction.
Script integrity management on payment pages is a genuine theme of v4 rather than an edge case, and it is one of the changes that pushed previously comfortable SAQ A merchants onto a longer form. The v4 changes worth planning around are largely of this shape: not new requirements for new technology, but tighter definitions that reclassify existing setups.
Choosing Between the Two Honestly
Choosing between the two honestly means looking at the rendered page, not the architecture diagram. Open your checkout in a browser, list every one of the scripts that loads, and ask who controls each and whether it could alter the payment fields or the page around them. On a typical commerce stack that list runs to a dozen entries.
A fully redirected or hosted-page flow where the customer leaves your domain entirely, and where your page has no scripts capable of touching the payment form, is the clean SAQ A case. An iframe or hosted-fields integration embedded in a page you control and instrument is where the argument gets hard, and where your acquirer will have an opinion.
If you want SAQ A, the route is reducing scope deliberately — stripping the payment page back to the point where the eligibility criteria are plainly met — rather than arguing that a page full of third-party tags qualifies. The engineering work is smaller than the compliance work it avoids.
When a Merchant Falls to SAQ D
A merchant falls to SAQ D when no channel-specific questionnaire fits, and the fall is expensive because SAQ D is substantially the full set of requirements rather than a subset. Everything the shorter forms exclude comes back: network segmentation, encryption of stored data, logging, vulnerability management, the full weight of the twelve PCI DSS requirements.
The common triggers are mundane.
- Mixed channels. You take e-commerce and phone orders, or e-commerce and card-present, and no single SAQ describes both. One channel qualifying for a short form does not rescue the other.
- Storage you forgot about. Call recordings containing read-aloud card numbers, chargeback evidence folders, emailed order forms, a reporting database that retained a PAN column. Electronic storage disqualifies several SAQs outright.
- Terminals on the corporate network. A terminal that is not standalone — because it shares a network with workstations, or routes through your own infrastructure — breaks the B-IP and P2PE eligibility conditions.
- A payment application you operate. Once you run the application that handles the transaction, you are at SAQ C at best, and at SAQ D if that application is not isolated the way SAQ C expects.
- An unvalidated P2PE solution. Encryption at the terminal only buys SAQ P2PE if the solution is a validated one. Vendor marketing that says "end-to-end encrypted" is not the same claim.
Before accepting SAQ D, it is worth spending a week on scope. Removing a single storage location or isolating a single device frequently moves a merchant back onto a channel-specific form, and the effort difference between the two outcomes is large enough that the week always pays for itself. It also changes your overall cost of getting compliant more than any other decision you will make in the programme.
SAQ A Eligibility Mistakes That Cost the Most
The SAQ A eligibility mistakes that cost the most are the ones discovered after submission, when an acquirer or a forensic investigator reads the attestation and disagrees with it. Four recur.
Treating "outsourced" as a commercial fact rather than a technical one. You can have a contract that puts all payment handling with a provider and still have a page that participates in the transaction. The criteria look at your systems, not your invoices.
Forgetting the non-e-commerce channel. A merchant who is genuinely SAQ A for the website but also takes the occasional card over the phone has a second channel that SAQ A does not cover.
Assuming the integration has not changed. Checkout pages accumulate tags. An attestation signed eighteen months ago may describe a page that no longer exists, and nothing notifies you when marketing adds a script.
Skipping the scanning question. Merchants on SAQ A-EP, SAQ B-IP, SAQ C and SAQ D generally have external-facing infrastructure in scope, which brings ASV scanning obligations with it. Discovering that after choosing the form is a scheduling problem as well as a technical one.
Self-Assessment Questionnaire PCI Questions Teams Ask
These are the self-assessment questionnaire PCI questions teams ask most often once they realise the form is assigned rather than chosen.
No. Your acquirer or the card brand decides whether an SAQ is acceptable for you and which one applies. The PCI Security Standards Council publishes the questionnaires but does not make that determination, and neither do you. What you can do is document your payment channel and scope, propose the SAQ you believe fits, and get written agreement before you begin. That sequence is faster than answering a questionnaire and having it rejected.
Not automatically. SAQ A requires that all account data functions are fully outsourced and that nothing is stored, processed or transmitted on your systems. Under v4 the eligibility criteria narrowed: scripts on a payment page that can affect the integrity of the checkout bring the page into scope, which can move you to SAQ A-EP even with an iframe or hosted fields. The deciding factor is what your page can influence, not which embedding technique you used.
SAQ D is substantially the full set of PCI DSS requirements, where the channel-specific questionnaires are subsets matched to a narrower payment flow. Moving from a short form to SAQ D does not add a few questions; it adds whole requirement areas — segmentation, stored data protection, logging and monitoring, vulnerability management — that the shorter forms exclude because the channel made them irrelevant.
The current version is v4.0.1, and the requirements that were future-dated in v4.0 became mandatory on 31 March 2025. If you are working from an older copy of a questionnaire, or from guidance written before that date, you are measuring yourself against criteria that no longer apply. Download the current SAQ from the PCI Security Standards Council rather than reusing last cycle's file.
Some do. SAQ D for Service Providers exists for service providers that are eligible to use a questionnaire rather than being required to produce a Report on Compliance. Eligibility is again a determination made by the card brands and acquirers, and a service provider that is not eligible produces a Report on Compliance instead. If you are a service provider whose customers ask for your compliance status, confirm which instrument you are expected to produce before you build the evidence for it.
Keep your SAQ scope accurate between assessments
Book a demo and we will show how Konfirmity tracks your payment channel scope, your in-scope systems and the evidence behind each requirement so next year's questionnaire starts from facts.
Book a demo
Confirm the SAQ Before You Start Filling It In
The expensive mistakes in this process are all selection mistakes, and all of them are cheap to avoid. Write down how card data moves through each of your channels, name the SAQ you think applies to each, and send that to your acquirer for confirmation. Treat their answer as the starting point for the work rather than a formality at the end of it.
Then re-check the assumption annually, and specifically re-check the checkout page. Scripts arrive on payment pages without anyone filing a change request, and under v4 that is enough to change which questionnaire you are eligible for. An attestation that was accurate when signed is not self-maintaining.
If the answer comes back as SAQ D and you were expecting a short form, do not start answering immediately. Spend the time on pulling systems out of scope first — it is the one piece of work in a PCI programme that reliably reduces everything downstream of it.
