PCI DSS SAQ Types: The Complete 2026 Guide to Choosing Yours

Choosing the wrong PCI DSS SAQ is the most common and most expensive mistake in card compliance, because nobody tells you it happened until an acquirer rejects your attestation or a forensic investigator points at it after a breach. There are nine questionnaires — ten if you count SAQ D’s separate merchant and service provider versions — and they range from a short eligibility-driven form to the full standard. Picking the shortest one you can defend is the whole game.

This guide walks through what each questionnaire covers, who is allowed to use it, and the five questions that settle your answer in about ten minutes.

What a PCI DSS SAQ actually is

A Self-Assessment Questionnaire is a validation tool, not a lighter version of the standard. Every PCI DSS SAQ contains a subset of the PCI DSS requirements that the Council considers applicable to a particular payment architecture. You still have to meet every requirement that applies to your environment; the questionnaire simply defines which ones you report on.

Three documents get confused constantly, so it is worth separating them:

• The SAQ — the questionnaire you complete, requirement by requirement, marking each as in place, in place with a compensating control, not applicable, or not in place.
• The AoC — the Attestation of Compliance, a signed declaration that accompanies every SAQ. This is the document your acquirer and your enterprise customers actually ask for.
• The RoC — the Report on Compliance, produced by a Qualified Security Assessor or an Internal Security Assessor. It replaces the SAQ entirely for organisations that cannot self-validate.

All of this now runs on PCI DSS v4.0.1, published in June 2024, with the v4.0.1 questionnaires released that October. The future-dated requirements that had been optional became mandatory on 31 March 2025, so there is no longer any version of the standard where they can be deferred.

Who decides which PCI DSS SAQ you use

Not the PCI Security Standards Council. Its own guidance is unusually blunt about this: the Council “does not define compliance requirements for any organization or set compliance validation responsibilities.” It publishes the tools. Your card brands, acquirer or payment facilitator — the compliance enforcing entities — decide whether you self-assess at all and which questionnaire they will accept.

That matters because merchant level comes first. Visa consolidated its Levels 3 and 4 into a single Level 3 effective 25 April 2024, leaving three levels; Mastercard still operates four. Broadly:

Visa merchant level	Annual Visa transactions	Typical validation route
Level 1	Over 6 million	Report on Compliance by a QSA, or an ISA-led assessment signed by a company officer
Level 2	1 million to 6 million	SAQ, sometimes with QSA involvement at the acquirer’s discretion
Level 3	20,000 to 1 million e-commerce	SAQ

Confirm your level and your permitted questionnaire in writing with your acquirer before you fill anything in. A compliance programme built on the wrong assumption costs a full re-scope.

The nine PCI DSS SAQ types compared

Eight of the nine are for merchants only. SAQ D for Service Providers is the sole option for any SAQ-eligible service provider, no matter how simple its environment looks.

Questionnaire	Who it is for	The deciding test	Relative burden
SAQ A	Card-not-present merchants — e-commerce or mail/telephone order	All account data functions fully outsourced to PCI DSS validated third parties; you keep only paper reports or receipts, and store, process or transmit no account data electronically	Lowest
SAQ A-EP	E-commerce merchants who outsource payment processing but whose own website affects the payment page	Your server delivers or can alter the page that takes the card — direct post, JavaScript-created iframe, or your own redirect logic	High (roughly 140 requirements)
SAQ B	Card-present merchants with imprint machines or standalone dial-out terminals	No internet connection to the terminal, no electronic account data storage	Low
SAQ B-IP	Card-present merchants with standalone IP-connected PTS-approved terminals	Terminal is internet-connected but validated to PTS, and you store no account data electronically	Low to medium
SAQ C	Merchants with a payment application connected to the internet	A POS or payment application system on a network, not isolated from other systems, with no electronic account data storage	Medium to high
SAQ C-VT	Merchants keying transactions into a web-based virtual terminal	One isolated computer, manual entry only, one transaction at a time, no account data storage	Low to medium
SAQ P2PE	Merchants using hardware terminals inside a PCI-validated point-to-point encryption solution	The solution appears on the Council’s list of validated P2PE solutions — vendor marketing claims do not count	Lowest for card-present
SAQ SPoC	Merchants taking PIN entry on off-the-shelf mobile devices	A secure card reader used with a validated Software-based PIN Entry on COTS solution	Low to medium
SAQ D (Merchant)	Any SAQ-eligible merchant who fits none of the above	You store account data electronically, or your environment spans several of the categories above	Highest — over 300 requirements
SAQ D (Service Provider)	Every SAQ-eligible service provider	There is no alternative	Highest

How to choose your PCI DSS SAQ in five questions

Work through these in order and stop at the first one that decides it.

1. Are you a service provider? If you store, process or transmit account data on behalf of other organisations, or your service can affect the security of their card data, it is SAQ D for Service Providers. Done.
2. Do you store account data electronically? Any electronic storage of the primary account number, anywhere, puts a merchant into SAQ D. Search your databases, log files, CRM notes, support tickets and email archives before you answer this. Cardholder data in a ticketing system is the classic hidden disqualifier.
3. Is every transaction card-not-present? If so you are in the SAQ A or SAQ A-EP branch, and the split is entirely about your website’s relationship to the payment page. Fully hosted payment page or a true iframe you do not generate means SAQ A. Anything where your server delivers, builds or can modify the page that captures the card means SAQ A-EP.
4. Card-present — how is the terminal deployed? A validated P2PE solution gives you SAQ P2PE. A standalone dial-out terminal gives you SAQ B. A standalone PTS-approved IP terminal gives you SAQ B-IP. A mobile device with a validated SPoC solution gives you SAQ SPoC. A payment application on your general network gives you SAQ C.
5. Mixed channels? If you take cards through genuinely separate channels you may complete more than one questionnaire, but many acquirers prefer a single SAQ D. Ask before you split.

Each of these answers depends on knowing exactly where card data goes, which is why scoping comes before questionnaire selection, not after. Our guide to PCI DSS scope covers how to draw that boundary and defend it.

What changed for SAQ A, and why it still bites

In January 2025 the Council removed Requirements 6.4.3 and 11.6.1 — payment page script authorisation and inventory, and tamper detection on payment pages — from SAQ A, along with the Requirement 12.3.1 targeted risk analysis that supported 11.6.1. The October 2024 version of SAQ A was retired on 31 March 2025 and the January 2025 version took effect the same day.

Read the replacement carefully, because it is not a reprieve. In place of those line items, SAQ A now carries an eligibility criterion: merchants must confirm their site “is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” The Council was explicit that this does not remove or diminish the underlying requirements. The obligation moved from a question you answer to a condition you must satisfy in order to use the questionnaire at all — and failing an eligibility criterion does not give you a low score, it makes you ineligible for the PCI DSS SAQ you were planning to file.

Practically, that means e-commerce merchants on SAQ A still need to know what scripts run on their checkout page, and either verify the position themselves or hold written confirmation from their compliant provider. Digital skimming is the reason the requirement exists; it has not gone anywhere.

Five PCI DSS SAQ mistakes worth avoiding

• Choosing SAQ A because it is short. If your own server touches the payment page, SAQ A is not available to you, and an AoC signed against the wrong questionnaire is worse than no AoC — it is a false attestation.
• Assuming a hosted checkout means SAQ A. The test is whether your site can alter the page capturing the card, not whether the processor’s name is on the URL. Custom JavaScript that builds the iframe usually pushes you to SAQ A-EP.
• Trusting a vendor’s “P2PE” claim. SAQ P2PE requires a solution listed as validated by the Council. Point-to-point encryption as a marketing term is not the same thing.
• Forgetting the service provider test. Software companies that handle payments for their customers are service providers even when they feel like merchants. That is SAQ D and the annual expectations that come with it.
• Filing the questionnaire and stopping. Requirements like quarterly ASV scanning, annual penetration testing and evidence retention run all year. A questionnaire completed in one sitting from memory will not survive a breach investigation. Our PCI DSS documentation checklist sets out what to keep.

PCI DSS SAQ frequently asked questions

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

Nine questionnaires: A, A-EP, B, B-IP, C, C-VT, P2PE, SPoC and D — with D published in separate merchant and service provider versions, which is why some sources count ten. The list did not change between v3.2.1 and v4.0.1; the content of each questionnaire did.

Can I complete more than one questionnaire?

Yes, where you operate genuinely distinct payment channels — a retail estate on SAQ B-IP and a separate e-commerce site on SAQ A, for instance. Your acquirer has to accept the split, and each channel needs its own scope boundary and its own attestation. Many acquirers would rather see one SAQ D.

Does a PCI DSS SAQ need a QSA?

Not by definition — the point of self-assessment is that you sign it yourself. Some acquirers require QSA involvement for Level 2 merchants, and many organisations engage one for a first submission or after a scope change. Check your acquirer’s programme rules rather than assuming.

How often do I have to complete it?

Annually, plus whenever your payment architecture changes materially. Moving from a hosted checkout to a custom one, adding a new terminal type, or bringing card data in-house can all change which questionnaire applies mid-cycle.

What happens if I used the wrong PCI DSS SAQ last year?

Fix it at the next submission and tell your acquirer. The realistic risk is not a fine for the paperwork; it is that an under-scoped attestation offers no protection at all if you are breached, and card brand penalties in that situation are assessed against your acquirer and passed to you.

Getting the evidence together

Whichever questionnaire you land on, the answers have to be backed by documented policies, procedures and records — access control, key management, logging, change management, incident response, vendor management, and the annual risk and testing artefacts. That is the part that takes months if you start from a blank page. Our PCI-DSS Toolkit provides 180+ editable Word and Excel templates covering the full v4.0 document set for $99, so you can spend your time confirming controls rather than drafting policies.

Start with scope, confirm your level and permitted questionnaire with your acquirer, then pick the shortest PCI DSS SAQ your architecture honestly supports. For the wider picture of what v4.0 asks of you, see our guide to PCI DSS v4.0 compliance, and for what happens after you sign, our breakdown of PCI DSS validation.