Which PCI SAQ applies to you, and why the wrong one gets picked

The self-assessment questionnaire you complete is determined by how you take payments, not by how big you are. Picking the wrong one produces an attestation that does not cover what you actually do.

There is no single PCI self-assessment questionnaire. There is a family of them, and which one you complete is decided by how card data reaches you and what happens to it afterwards. Merchant size determines whether you self-assess at all. It does not determine which SAQ you use.

This gets picked wrongly often enough to be worth stating plainly: a shorter SAQ is not a lighter version of a longer one. Each has its own eligibility criteria, printed in the front of the document, and completing one you do not qualify for produces an attestation that does not describe your environment.

What actually decides it

Three questions do most of the work:

1. 1How is the card number captured - through a payment page you do not control, a page you do control, a physical terminal, or your own systems?
2. 2Does the number pass through any system you operate, even briefly?
3. 3Do you store it after the transaction is authorised?

The first question separates e-commerce from card-present. The second separates full outsourcing from partial. The third is the one that moves you to the longest questionnaire regardless of the other two answers.

The eligibility criteria in each SAQ document are the authority here, not a summary on anyone's blog. Read the front section of the questionnaire before you start filling it in. The PCI SSC Document Library holds the current versions.

The questionnaires, and what each assumes

Each SAQ carries its eligibility criteria in its own front matter, and those criteria are the authority. The summary below is orientation for working out which document to open, not a substitute for reading it.

Two features of that table do most of the work in practice. Almost every shorter questionnaire says no electronic account data storage, so storage moves you to SAQ D regardless of how you take payments. And the split between SAQ A and SAQ A-EP turns on control of the payment page rather than on whether you receive the number.

The three mistakes worth naming

Claiming full outsourcing when the payment page is yours

The shortest e-commerce questionnaire assumes the entire payment page is delivered by a validated third party. If your own page hosts the form and posts the data onward, or if a script on your page can reach the payment fields, you are in different territory. The distinction is technical and it is checkable: look at what serves the page holding the card fields.

Answering for the payment flow and forgetting everything else

The questionnaire asks about your cardholder data environment. People answer it about their checkout. Those are the same thing only if the card number never appears anywhere else, and in most organisations it does: a customer emails one in, someone screenshots a payment confirmation, a refunds spreadsheet accumulates a column nobody meant to create.

None of that is in the payment flow, and all of it is in scope.

Treating the answer as fixed

Eligibility follows the environment, and the environment changes. Adding a phone-order channel, taking a deposit through a different provider, or letting support staff process a refund by hand can all move you to a different questionnaire. The answer is valid for the environment as it was when you gave it.

Treating the SAQ as the security work

The questionnaire is a validation instrument. It records that you have done something, and it is deliberately not an audit. Completing SAQ A honestly is a shorter exercise than completing SAQ D honestly, and that difference reflects a genuinely smaller environment rather than a lighter security standard.

Where this bites is the merchant who qualifies for a short questionnaire and concludes that PCI DSS is largely handled. The standard still applies to any account data you hold. The short form asks fewer questions because the assumption is that there is less to ask about, and that assumption is worth verifying rather than inheriting.

What counts as receiving account data

The SAQ A and SAQ A-EP boundary turns on a technical question that is often answered from an assumption about how the payment provider works rather than from looking at the page.

The PCI SSC glossary defines cardholder data as, at a minimum, the full primary account number, which may also appear with the cardholder name, expiration date or service code. The question for an e-commerce merchant is whether that data ever reaches infrastructure you control, and whether code you control can reach the fields it is typed into.

• A redirect to the provider's own domain, where the customer leaves your site to pay, keeps the data off your systems entirely.
• An iframe served from the provider's domain embeds their page in yours. The data goes to them, but your page controls what surrounds the frame and what scripts run alongside it.
• A form on your own page that posts to the provider means your infrastructure serves the fields the number is typed into.

Those three arrangements look similar to a customer and are treated differently. The way to settle it is to look at what serves the page holding the card fields, and what else can execute on it, rather than to rely on how the integration was described when it was sold.

This is also why script integrity has become a live concern for e-commerce merchants. Anything that can execute on a page adjacent to payment fields is in a position to affect the security of that payment, which is the reasoning behind the payment-page script requirements in PCI DSS v4.x.

The answer expires

Eligibility describes an environment, and environments change without anyone treating the change as a compliance event.

Requirement 12.5.2 of PCI DSS v4.0.1 asks for scope to be documented and confirmed at least once every 12 months and upon significant change to the in-scope environment. Service providers do the same at least once every six months under 12.5.2.1. A change of payment channel, provider, or working pattern is exactly the kind of significant change that provision contemplates.

Practical triggers worth building into whatever process already approves change:

1. 1Adding a channel, including a temporary one for an event, a campaign, or a single large customer.
2. 2Changing payment provider or integration method, even where the customer experience looks identical.
3. 3Letting staff take payments by phone, or process a refund by hand, where previously they did not.
4. 4Moving work off the office network, since that changes which machines handle the data.

Who decides what you actually submit

The Council publishes the questionnaires. It does not tell you which one to submit or when. The PCI SSC's own guidance for merchants is explicit that whether a small merchant is required to validate compliance is determined by the individual payment brands, and that merchants should contact their acquirer or the payment brand they do business with.

So the eligibility criteria in the questionnaire tell you which document fits your environment, and your acquirer tells you what you must submit and by when. Those are different questions with different authorities, and conflating them is why merchants sometimes complete a questionnaire nobody asked them for, or the wrong one for a deadline they did not know they had.

The attestation is a statement you sign

Each SAQ comes with an Attestation of Compliance, and the attestation is the part that goes to your acquirer. It is signed by an officer of the company, and it asserts that the environment described is the environment you have.

That framing is worth keeping in view when the eligibility question feels like paperwork. Selecting a questionnaire you do not qualify for produces a signed statement about an environment that is not yours, given to the organisation that provides your merchant account. The exposure is commercial and contractual rather than regulatory, but it is real, and it is the reason the eligibility criteria are printed at the front rather than buried.

If nobody in your organisation can say which SAQ you completed last year and why, that is the finding. The document is short; the reasoning behind choosing it is what tends to be missing.

The question underneath all of them

Whichever questionnaire you complete, one question recurs: do you store cardholder data, and if so, where and why. Every SAQ asks a version of it, and it is the question most often answered from memory rather than evidence.

Answering it accurately means knowing what is on the machines your staff use, not only what is in the systems you designed. Those are different sets, and the gap between them is where scope quietly grows.

Answering it well means separating three things that get conflated: the systems you designed to handle card data, the systems that touch it incidentally, and the places copies have accumulated. The first is documented, the second is usually discoverable by asking, and the third is neither.

The third category is where a merchant on a short questionnaire most often turns out to be on the wrong one. A refunds spreadsheet, an emailed invoice with a full number in it, or a saved payment confirmation all constitute electronic storage of account data, and every questionnaire short of SAQ D assumes none of that exists.

How EmberHound fits

EmberHound scans enrolled company devices for stored card data and reports what it finds by location. Matches return a masked preview and a salted fingerprint; the full number never leaves the endpoint. That turns the storage question from an assertion into a dated scan result you can put in front of an assessor.

It does not complete your SAQ or determine which one applies. Your acquirer sets your validation requirements, and the eligibility criteria sit in the questionnaire itself.

This article is general information, not legal or assessment advice. Confirm your validation requirements with your acquirer and your QSA.