Which PCI SAQ Do You Need? A Decision Guide

Your PCI self-assessment questionnaire is determined by how cardholder data touches your systems, not by your revenue or headcount. The PCI Security Standards Council describes SAQs as "validation tools for use by SAQ-eligible merchants and service providers to perform and report the results of their PCI DSS self-assessments," and notes that "There are several different SAQs, developed for specific types of environments as defined in each SAQ's eligibility criteria." Read that literally. You do not pick the questionnaire that suits you. You establish which eligibility criteria your environment actually meets, and the questionnaire follows. And whether you must validate at all is not the Council's call either: "Whether a small merchant is required to validate compliance is determined by the individual payment brands."

The uncomfortable consequence is that the single highest-leverage PCI decision at most companies is made by an engineer choosing a checkout integration, usually years before anyone in finance says the word PCI. This article is the decision logic, the boundary that actually costs money, and what to ask your acquirer.

Key takeaways

• Your SAQ is determined by how cardholder data touches your systems, not by revenue or headcount. You establish which eligibility criteria your environment meets, and the questionnaire follows.
• Connectivity counts as much as storage. A system that never sees a card number but has unrestricted connectivity to one that does is inside the cardholder data environment.
• Outsourcing the payment page is the most effective scope reduction available, and it never reduces your obligation to none.
• The SAQ A versus SAQ A-EP boundary is where the money is, and it turns on whether your own site can affect the security of the payment page. Read the current eligibility section and the Council's FAQ 1588 in the original.
• Neither the Council nor your consultant decides your validation type. Confirm it with your acquirer or payment brand, and keep the email.

First, the question behind the question

Three facts about card data settle almost every SAQ argument.

Storing, processing, or transmitting cardholder data puts you in the deep end. If a primary account number lands in your application, your database, your logs, or your support tooling, you are in the environment the Council calls the cardholder data environment, defined in its glossary as "the system components, people, and processes that store, process, or transmit cardholder data and/or sensitive authentication data, and system components that may not store, process, or transmit CHD/SAD but have unrestricted connectivity to system components that store, process, or transmit CHD/SAD."

Connectivity counts as much as storage. Read that last clause again. A system that never sees a card number but has unrestricted connectivity to one that does is in the environment. This is the sentence that turns a small assessment into a large one.

Outsourcing shrinks your obligation, it does not delete it. Handing the payment page to a validated provider is the most effective scope reduction available. It moves you toward the lightest questionnaire. It never moves you to none.

The questionnaires, in plain terms

The Council publishes several SAQs, each with an eligibility section at the front of the document. The families, roughly from lightest to heaviest:

We are deliberately not printing question counts for each one. They move between revisions of the questionnaires, and a count you read on a blog is the fastest way to plan against the wrong document. Open the actual SAQ in the Council's document library, check the version, and count the section you are eligible for.

The boundary that costs real money: SAQ A versus SAQ A-EP

For e-commerce, this is the whole game, and it turns on one question: can your site affect the security of the payment page?

A full redirect, where the customer leaves your site for the provider's hosted page, keeps the payment form entirely out of your hands. An embedded iframe served by the provider is the other common arrangement, and it is where the argument happens, because the surrounding page is still yours, and a script on your page can reach the customer's browser session even when it cannot reach inside the frame.

That is not a theoretical concern. Payment-page skimming works by injecting or compromising a script on the merchant's own page, which is why PCI DSS v4.x added Requirement 6.4.3 for managing scripts on payment pages and Requirement 11.6.1 for detecting unauthorized changes to payment page content. Both became mandatory on March 31, 2025, and 11.6.1 is one of the requirements walked through in our guide to the v4 future-dated requirements.

The Council maintains an FAQ on exactly this point, numbered 1588 and titled "How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?", in its FAQ library. If your checkout embeds a provider's iframe, that FAQ and the eligibility section of the current SAQ A are the two documents that decide your answer. Read them in the original. A great deal of secondary commentary on this change is written for assessors rather than for the merchant who quietly stopped qualifying.

What we would tell an engineering team: if you are choosing an integration today and you have any preference, choose the one that keeps scripts off the payment page. The difference in build effort is a day. The difference in annual compliance effort is a different questionnaire.

Who actually decides your validation type

Not the Council, and not your consultant. The Council's own guidance is explicit: "For questions regarding compliance validation and reporting requirements, merchants should contact their acquirer (merchant bank) or payment brand they do business with, as applicable."

So the sequence is: work out which eligibility criteria you meet, then confirm with your acquirer that this is the validation type they expect, and get the answer in writing. Two reasons. First, the brands set validation requirements independently and they are not identical. Second, an acquirer can escalate a merchant's requirements after a breach or for its own risk reasons, and when that happens the email you have is worth more than the reasoning you did.

For what your acquirer's answer implies about hiring an assessor, see do you need a QSA.

The three mistakes we see most

Assuming the processor's compliance is yours. It is not, and the processors say so themselves. Our Stripe and Shopify article covers the residual obligation in detail.

Scoping to the payment page and forgetting the back office. Refunds by phone, a spreadsheet of card numbers a finance team keeps for chargebacks, a support agent who accepts a number over chat, a call recording that captures one. Every one of those puts cardholder data on systems that were never in the diagram. The environment is where the data actually goes, not where the architecture says it should.

Treating the SAQ as an annual paperwork exercise. The questionnaire is an attestation about controls that either run or do not. Filling one in accurately usually surfaces work; filling one in optimistically creates a signed record of a claim you cannot evidence.

Where Top Floor fits, and where we do not

Top Floor is not a Qualified Security Assessor. We cannot sign a Report on Compliance and we do not issue attestations. What we do under our PCI DSS practice is the readiness work: mapping where card data actually goes, arguing the scope down before anyone assesses it, closing the gaps, and preparing the evidence so the validation you do owe is short. Where PCI sits alongside SOC 2 or ISO 27001, Compliance as a Service is the multi-framework version of the same thing.

If you take a few hundred card-not-present transactions a year through a fully hosted checkout, you probably do not need us. You need the current SAQ A, an hour of honest reading, and your acquirer's email. Say so to any consultant who quotes you a project for it.

How to decide this week

Draw the card data flow on one page, including the paths nobody designed: phone refunds, support chats, finance spreadsheets, call recordings. That drawing is your scope.

Open the current SAQ documents in the Council's library and read only the eligibility sections. They are short, and they are the actual test.

Then email your acquirer with your integration type and ask which validation type they require and at what level. Keep the reply. That single email settles more arguments than any consultant's opinion.

Frequently asked questions

How do I know which PCI SAQ applies to my business?

Eligibility is defined by your environment, not your size. The Council publishes several SAQs and states that each is developed for specific types of environments as defined in that SAQ's eligibility criteria, so the correct method is to read the eligibility section at the front of each current questionnaire and identify which one your card data flow actually satisfies. Then confirm with your acquirer or payment brand, because the Council also states that whether a merchant is required to validate compliance is determined by the individual payment brands.

What is the difference between SAQ A and SAQ A-EP?

SAQ A is for card-not-present merchants who have fully outsourced all cardholder data functions to PCI DSS validated third parties and who do not electronically store, process or transmit cardholder data themselves. SAQ A-EP applies to e-commerce merchants who outsource payment processing but whose own website can affect the security of the payment transaction. The practical trigger is whether scripts on your page can influence the payment experience, which is why the Council maintains FAQ 1588 on how an e-commerce merchant meets the SAQ A eligibility criteria for scripts. A-EP is substantially heavier, including scanning obligations SAQ A merchants generally do not carry.

Does using a hosted payment page mean we have no PCI obligations?

No. Outsourcing the payment page is the most effective scope reduction available and it moves you toward the lightest questionnaire, but it never removes the obligation entirely. You still have a validation type, you still attest annually if your acquirer requires it, and you still own everything around the payment page: the scripts on your site, your back-office handling of card data, and the third-party management requirements that apply to the providers you rely on.

Who decides whether we file an SAQ or a Report on Compliance?

Your acquirer and the payment brands, not the PCI Security Standards Council and not your consultant. The Council directs merchants with questions about compliance validation and reporting requirements to contact their acquirer or the payment brand they do business with. Get that answer in writing, because an acquirer can also escalate a merchant's requirements after a breach or for its own risk reasons, and the written answer is what protects you when the expectation changes.