PCI DSS SAQ Selection Guide: Choosing the Right Questionnaire

Priya Nathan had already signed the attestation when the email from the acquirer landed. She was VP of Payments Risk at Larkspur Home & Garden, a mid-market omnichannel retailer doing about $140M a year across a Shopify Plus storefront, forty retail locations, a call center that took phone orders during the holiday rush, and a growing subscription box business. For three straight years, Larkspur had self-certified as SAQ A, the shortest questionnaire in the PCI DSS stack — twenty-some questions, an afternoon's work, done. Then Larkspur's marketing team added a JavaScript personalization widget to the checkout page to A/B test button colors and upsell copy. Nobody looped in payments risk. Nobody re-ran the eligibility check.

The acquirer's risk team found the script during a routine review of merchant websites, cross-referenced it against Larkspur's attestation, and sent the email: your checkout page now includes merchant-controlled scripting capable of affecting the payment transaction. You are not SAQ A eligible. You need to complete SAQ A-EP, which carries roughly eight times the control set, including a formal script inventory and integrity-monitoring program under Requirements 6.4.3 and 11.6.1. Their letter gave Larkspur ninety days to re-attest correctly or face a compliance hold on new card-not-present volume — a hold that would have cut off close to $9M a quarter in online revenue at the start of Larkspur's busiest season.

Nobody at Larkspur had done anything malicious. They had simply never been taught that the SAQ isn't a form you pick once and forget — it's a live conclusion about your architecture that breaks the moment your architecture changes. That gap is exactly what this guide exists to close.

Who This Is For, and What You'll Walk Away With

This is for the person who actually has to answer "which SAQ do we file" — a compliance manager, a payments engineer, a controller who inherited PCI DSS along with the finance stack, or a founder filling out their first attestation. You'll get a rigorous, repeatable selection methodology: the four variables that actually determine your SAQ, a decision tree you can run in an afternoon, a channel-by-channel selector for every common acceptance method, and a pitfalls table built from the mistakes I've watched merchants make across two decades of assessments. This piece is deliberately the decision tool — for the full definition, question count, and control detail of each SAQ type, see our companion reference, PCI DSS Self-Assessment Questionnaire (SAQ): Types and Selection. We won't re-explain what SAQ C-VT covers here; we'll tell you how to know, definitively, whether it's the one you need.

Why SAQ Selection Isn't a Formality

Here's the thing most merchants get backwards: they treat SAQ selection as an administrative step that happens after the "real" compliance work, when in fact it's the single decision that determines how much real work there is. SAQ A and SAQ D can represent a twenty-fold difference in control count, evidence burden, and assessment hours. Pick wrong in the direction of "too easy," and you've filed a legally binding attestation that doesn't match your actual environment — a fact that surfaces exactly when you least want it to: after a breach, during a forensic investigation, or when an acquirer's periodic review catches the mismatch, as it did for Larkspur.

Pick wrong in the direction of "too conservative," and you've committed your team to months of unnecessary control implementation and evidence-gathering for requirements that don't apply to your actual card-acceptance footprint. Both errors are expensive. Only one methodology avoids them: work the selection from your actual technical architecture, not from what questionnaire feels familiar or what a vendor's marketing page told you to file.

"The SAQ isn't a self-reported opinion — it's a technical conclusion. I ask every new client the same question: if I put your payment flow on a whiteboard, does it match the box you checked? Nine times out of ten, the mismatch is where the incident starts." — Derek Amato, Principal QSA, Ashgrove Payment Assurance

The Four Variables That Actually Decide Your SAQ

Every SAQ eligibility question the PCI Security Standards Council publishes reduces, in practice, to combinations of four underlying variables. Get these four answers right for your environment and the correct SAQ falls out almost mechanically.

Every section that follows is really just a deeper look at one or more of these four variables, mapped onto real-world acceptance methods.

All Nine SAQ Types at a Glance

Before the decision tree, you need the full roster in front of you. This table is a quick-reference index, not the definitive control breakdown — for the complete eligibility language, control counts, and testing procedures behind each type, see PCI DSS Self-Assessment Questionnaire (SAQ): Types and Selection.

Nine boxes, but only four real decision points. The rest of this guide is about running your environment through those four variables until one box is left standing.

The SAQ Selection Decision Tree

I build this tree with clients on a whiteboard before we ever open a questionnaire PDF, because the SAQ document itself buries the branching logic inside dense eligibility paragraphs. Draw it out first, and the paperwork becomes a formality.

The tree asks, in strict order: (1) Do you store cardholder data electronically anywhere in your environment, even briefly? If yes, you're done — SAQ D. (2) If no, how does the cardholder present the card — online/MOTO, or in person? (3) For card-not-present: is the payment function fully outsourced with zero website involvement in the transaction, or does your site touch the payment flow? (4) For card-present: what captures the card — imprint/dial-out terminal, IP-connected standalone PTS device, virtual terminal, or a connected payment application? (5) Regardless of channel: are you using a fully validated P2PE solution end to end? If yes, that usually routes you to SAQ P2PE instead of the channel default.

Walking the Tree Step by Step

Turn each decision node into a question you can literally ask your payments and engineering teams. Answer honestly — the goal is an accurate self-assessment, not the shortest form.

Channel 1: Pure E-Commerce, Fully Outsourced — SAQ A

This is the narrowest and most misunderstood box in the entire SAQ catalog, which is exactly why Larkspur fell out of it. SAQ A is reserved for merchants whose website plays no functional role in the payment transaction beyond sending the shopper to (or embedding, via iframe, a properly isolated payment page from) a PCI DSS-validated third-party service provider. The merchant's own servers never receive, process, transmit, or store account data in any form — not even for a millisecond in memory during a pass-through.

Under PCI DSS v4.0, the eligibility bar for SAQ A got measurably stricter. The Council added explicit conditions confirming that the merchant's website cannot include content or functionality capable of impacting the security of the payment page — because that's precisely the mechanism Magecart-style card-skimming attacks exploit. Practically, that means even a fully hosted-payment-page merchant must now inventory the scripts loaded on or near the payment page and confirm none of them could alter it, tying SAQ A eligibility to the same script-governance discipline that Requirements 6.4.3 and 11.6.1 formalize for e-commerce generally. For the full mechanics of e-commerce scope reduction, our PCI DSS for E-commerce piece goes deeper on payment-page architecture.

v4.0 Tightened SAQ A Eligibility: What Changed

Channel 2: E-Commerce With a Website That Touches the Payment — SAQ A-EP

SAQ A-EP exists for the vast middle ground between "fully hosted, zero touch" and "we run our own payment gateway." If your website uses direct-post (form fields on your page submit directly to the processor via a background call your JavaScript orchestrates), or if your JavaScript constructs, loads, or governs the iframe that displays the third party's payment fields, your site has enough influence over the transaction that a compromise of your web application could redirect, log, or exfiltrate card data before it ever reaches the processor. That influence is what pulls you out of SAQ A and into SAQ A-EP, which applies the majority of the full PCI DSS control set — network security, secure configuration, vulnerability management, access control, logging, and the script-governance requirements — to your web-facing systems, even though you still never store CHD.

"A-EP catches people off guard because nothing about the checkout looks different to the customer. The card fields still visually appear on a Stripe- or Braintree-hosted page. But if your JavaScript is the thing deciding what loads into that page, you own the security of that decision — and that's an A-EP-sized responsibility." — Maren Solis, Director of Payment Security, Solis Cyber Partners

SAQ A vs SAQ A-EP: The Line That Trips Up Merchants

Channel 3: Mail Order/Telephone Order and Virtual Terminals — SAQ C-VT

MOTO transactions — a customer reading a card number over the phone, or mailing an order form — sit awkwardly between card-present and card-not-present categories, and the SAQ that fits depends entirely on how the agent enters the number. If your call-center staff key the card into a browser-based virtual terminal running on a single, locked-down computer that has no other network connections, no local card storage, and no integration into other business systems, SAQ C-VT applies. The isolation requirement is not decorative — the moment that machine also runs email, a CRM, or general office software, the isolation argument collapses and you're pushed toward SAQ C or SAQ D. MOTO order intake is one of the most common places SAD ends up on a sticky note or in a shared spreadsheet, which is worth flagging to any call-center manager who thinks the SAQ conversation doesn't apply to them.

Channel 4: Card-Present With Imprint or Standalone Dial-Out — SAQ B

SAQ B is the oldest and narrowest card-present box: physical imprint ("knuckle-buster") machines, or standalone terminals that dial out over a analog phone line with no IP connectivity and no local storage of transaction data. It's increasingly rare in modern retail but still shows up in low-volume, low-infrastructure settings — pop-up markets, food trucks without reliable connectivity, or backup payment paths for outage scenarios.

Channel 5: Card-Present With Standalone IP-Connected Terminals — SAQ B-IP

SAQ B-IP is SAQ B's modern successor: a standalone, PTS-approved terminal that connects to the processor over IP rather than a phone line, but remains isolated from every other system on the merchant's network — no shared switch traffic into the corporate LAN, no integration with inventory or loyalty systems, and no electronic storage. The terminal itself must appear on the PCI SSC's list of approved PTS devices; a consumer-grade card reader plugged into a general-purpose computer does not qualify, no matter how isolated the machine seems.

Channel 6: Payment Application Connected to the Internet — SAQ C

SAQ C is the box for merchants running an internet-connected payment application — often integrated POS software — that is not merely a standalone terminal and is not eligible for the tighter isolation claims of B, B-IP, or C-VT. Think of a restaurant's POS terminal that also manages table assignments, tips, and inventory, with the payment module talking to a processor over the internet. Because the system is connected and integrated rather than isolated, SAQ C's control set is meaningfully larger than B/B-IP/C-VT, though still narrower than SAQ D, provided the merchant genuinely never stores CHD electronically.

Channel 7: Validated P2PE Solution — SAQ P2PE

Point-to-point encryption changes the calculus for any channel by encrypting card data at the point of capture using validated hardware, so that decryption only happens at the solution provider's secure environment — never inside the merchant's own systems. If every device and process touching card data is part of a PCI SSC-listed P2PE solution, with no manual key-entry fallback and no unencrypted card data anywhere in the merchant environment, SAQ P2PE becomes available regardless of whether the underlying channel is card-present or MOTO. It's frequently the single highest-leverage scope-reduction move a card-present merchant can make; our Point-to-Point Encryption (P2PE) article covers solution validation and deployment mechanics in depth, and the broader tactics sit inside PCI DSS Scope Reduction Strategies.

"P2PE is the closest thing to a 'skip the line' card in PCI DSS. But it only works if it's the whole path — one manually keyed fallback terminal that isn't part of the validated solution, and you're back to whatever SAQ your other channels require." — Julian Cho, Payments Architecture Lead, Northfell Retail Group

Channel 8: Everything Else, and Anyone Who Stores CHD — SAQ D

SAQ D (Merchant) is the default landing spot for any merchant who doesn't cleanly satisfy another SAQ's eligibility criteria — including anyone who electronically stores cardholder data for any business reason (loyalty programs, recurring billing built in-house, custom order-management systems), anyone running a partially outsourced but heavily integrated payment stack, and anyone whose acquirer simply designates SAQ D regardless of architecture. It applies nearly the full PCI DSS requirement set and is the longest, most evidence-intensive questionnaire a merchant can complete without triggering a full Report on Compliance (ROC).

SAQ D for Service Providers: A Different Animal

SAQ D (Service Provider) looks similar on paper but serves a structurally different population: entities that store, process, or transmit account data on behalf of other organizations, or that could affect the security of another entity's cardholder data environment, and whose card brand or acquirer permits self-assessment rather than mandating a QSA-led ROC. Payment gateways, hosting providers with payment-adjacent infrastructure, and smaller processors often land here. Merchants should never confuse the two — filing a merchant-flavored SAQ D when you are contractually a service provider (or vice versa) is its own compliance failure, independent of the underlying control work.

Table: Channel-by-Channel SAQ Selector

Use this as the fast-path reference once you understand the logic behind it.

The Storage Question: Why It Overrides Everything Else

Of the four variables, electronic storage of cardholder data is the one that trumps all the others. It doesn't matter how well-outsourced your checkout is, how isolated your terminal is, or how validated your P2PE solution appears — if any system anywhere in your environment retains the PAN, expiration date, or cardholder name electronically after the authorization completes (a database column, a log file that wasn't scrubbed, a support ticketing tool where an agent pasted a card number, a backup that captured a database snapshot before masking ran), you are no longer eligible for a short-form SAQ. Storage of SAD — the full track, CVV, or PIN — after authorization is prohibited entirely under PCI DSS regardless of SAQ type; finding it disqualifies you from every SAQ and typically triggers incident-response obligations on top of the compliance gap. This is why every SAQ selection exercise should begin with a cardholder-data discovery pass across logs, databases, file shares, and ticketing systems, not with a channel inventory.

The Terminal Question: Standalone, Connected, or Virtual

For card-present and MOTO acceptance, the terminal or capture mechanism is the second-order decision that separates B, B-IP, C-VT, and C. The dividing line is connectivity and integration, not brand or age of hardware: a terminal that only talks to the processor, with nothing else on its network segment, stays in the standalone family (B or B-IP depending on IP vs dial-out). A terminal or software application woven into broader business systems — POS, inventory, CRM, loyalty — moves you into SAQ C, because a compromise anywhere in that connected stack can reach the payment function. A virtual terminal is its own category because the "terminal" is software running on a general-purpose computer; SAQ C-VT's isolation requirement (single dedicated machine, no other network connections) is stricter than it looks, and it's the requirement most call centers quietly violate by letting agents also use that machine for email.

The Outsourcing Question: How Much of the CDE Is Actually Yours

Outsourcing degree is really a question about where the boundary of your responsibility sits relative to your cardholder data environment (CDE). Full outsourcing — a TPSP handles capture, transmission, and any storage, and your systems never touch account data — is what makes SAQ A and SAQ P2PE possible. Partial outsourcing, where a TPSP processes the transaction but your systems influence, orchestrate, or sit adjacent to that flow, is what defines SAQ A-EP and SAQ C. A written PCI DSS responsibility matrix with each TPSP, specifying exactly which requirements they own versus which remain yours, is the single best artifact for proving your outsourcing claim during an eligibility review — and it's worth building even for a straightforward SAQ A merchant, because "we assumed our processor handled that" is not a defense an acquirer will accept.

Table: Storage, Terminal, and Outsourcing Factor Matrix

When You Accept Cards Three Different Ways: Multi-Channel Merchants

This is where Larkspur's story generalizes to almost every mid-market merchant I work with: a business rarely accepts cards through exactly one channel. Larkspur had e-commerce, retail POS, and phone orders running simultaneously, each of which independently maps to a different SAQ. PCI DSS doesn't give you a menu to pick the easiest one — a merchant with multiple distinct acceptance channels generally must satisfy the requirements applicable to each channel it operates, which in practice usually means either completing multiple SAQs (one per qualifying channel) or, more commonly for merchants whose channels can't each cleanly meet a short-form SAQ's isolation criteria, defaulting to SAQ D across the board. Acquirers vary in how they administer this: some accept multiple SAQs filed together, others require a single SAQ D once a merchant's footprint crosses a certain complexity threshold. Either way, the mistake to avoid is filing the shortest SAQ because it matches your simplest channel while ignoring the other two.

"I tell multi-channel clients: your SAQ isn't a vote, it's a union. Every channel has to clear its own bar, and the moment one channel can't, the whole attestation typically has to reflect that." — Renata Osei, Compliance Director, Vantage Merchant Solutions

Table: Multi-Channel Handling

Your Acquirer Has the Final Word

Everything in this guide describes how the eligibility criteria are meant to work — but PCI DSS SAQ selection is not purely self-determined. Your acquiring bank, and by extension the card brands whose rules the acquirer enforces, has the contractual authority to require a specific SAQ type, mandate a QSA-led assessment instead of self-assessment, or reject a self-selected SAQ they believe doesn't match your environment. This isn't a rubber-stamp formality: acquirers increasingly cross-reference merchant websites, terminal registrations, and processor data against submitted attestations, which is exactly the mechanism that caught Larkspur. Before you finalize a selection — especially a borderline call between SAQ A and A-EP, or between a short-form card-present SAQ and SAQ D — confirm it directly with your acquirer or merchant services provider in writing. That confirmation email is worth keeping; it's evidence of good-faith diligence if your architecture is later found to have drifted.

The Self-Check: Can You Actually Prove Eligibility

Selecting the right box on paper is only half the job — you also need documented evidence that supports the claim, because an SAQ without evidence is just an assertion. Build this evidence trail before, not during, an acquirer inquiry.

Table: Eligibility Evidence by SAQ Type

Table: SAQ Relative Length and Effort (Illustrative)

Exact question counts shift slightly between PCI SSC releases, so treat this as a planning-level indicator, not a citation — always confirm against the current SAQ document published by the PCI Security Standards Council for the version you're filing.

Common Pitfalls: Picking an SAQ That's Too Small

The failure mode I see most often isn't malicious misreporting — it's a well-meaning team locking in the shortest plausible SAQ during initial onboarding and never revisiting it as the business evolves. A few patterns recur constantly.

Table: Pitfalls and Their Consequences

Note that last row deliberately: over-scoping isn't "safe," it's just a different kind of wrong. The goal is accuracy, not caution in one direction.

Case Study: The Direct-Post Checkout That Should Have Been SAQ A-EP

Larkspur's remediation, once the acquirer's letter landed, moved fast because the underlying architecture problem was well understood — the checkout personalization script had been added by a marketing agency contractor who had no visibility into PCI scope at all. Priya's team ran a full script inventory across the checkout flow, found four third-party tags loading on the payment page (a heatmap tool, two ad-retargeting pixels, and the personalization widget), and determined that the personalization widget was the only one capable of interacting with the payment iframe's container — which was enough to trigger the A-EP conclusion regardless of the other three. The fix wasn't to abandon personalization; it was to move the widget off the payment step entirely, restore a clean redirect-only checkout, implement a Content Security Policy limiting what could load on that page, and stand up quarterly script-inventory reviews as a standing control. Larkspur re-attested SAQ A within six weeks, avoided the compliance hold, and — as a side effect — cut their checkout page load time by 400 milliseconds once the extraneous scripts were gone. Total incremental cost of the remediation: roughly $38,000 in contractor and engineering time, against a $9M-per-quarter revenue exposure if the hold had gone into effect.

Case Study: The Restaurant Group With Three Acceptance Channels

A twelve-location restaurant group I advised — I'll call them Birchwood Hospitality Group — had grown through acquisition and inherited three different payment setups: legacy locations with standalone dial-out terminals, newer locations with an integrated POS system connected to a corporate reporting network, and a catering division that took phone orders through a shared office computer running a virtual terminal alongside email and a reservations app. For two years, the corporate office had filed a single SAQ B, matching only the legacy locations, because that's the form the original franchise agreement referenced. When Birchwood's new CFO ordered a compliance audit ahead of a refinancing round, the gap became obvious: the integrated POS locations needed SAQ C, the shared-computer virtual terminal wasn't isolated enough for SAQ C-VT, and neither of those facts had ever been assessed. Rather than chase three separate SAQs across an inconsistent estate, Birchwood standardized on validated P2PE terminals at every location, retired the shared-computer virtual terminal in favor of a dedicated device, and consolidated onto SAQ P2PE across all twelve locations within four months — cutting their annual assessment effort from an estimated 240 hours (had they gone the multi-SAQ route matching the mixed environment) to about 60 hours, and closing the refinancing round on schedule.

Case Study: The P2PE Migration That Cut Their Questionnaire by 80%

A regional fuel and convenience chain — Coastview Fuel & Mart, forty sites — had been filing SAQ D every year because their pump payment terminals were integrated with a back-office inventory and loyalty system that also retained transaction-level detail, including masked-but-not-fully-tokenized PAN fragments in an older loyalty database. The SAQ D cycle consumed roughly six weeks of combined IT, finance, and store-operations time annually. Coastview's new IT director led a project to deploy a validated P2PE solution at every pump and register, replaced the legacy loyalty database with a tokenized architecture using network tokens instead of PAN fragments, and formally decommissioned the old storage. Once card data was encrypted at the point of capture with no clear-text exposure anywhere in Coastview's environment, they moved to SAQ P2PE the following cycle — cutting the assessment from roughly 330 applicable requirement items down to a substantially shorter, hardware-and-process-focused questionnaire, and reducing annual assessment labor from six weeks to about eight days. The P2PE hardware refresh cost approximately $410,000 across all sites; Coastview's team calculated payback within two years purely from reduced internal assessment labor and eliminated compensating-control documentation, before counting the reduced breach exposure.

Table: Case Study Outcomes at a Glance

Working the Annual Cycle: SAQ Selection Isn't a One-Time Decision

Every one of the case studies above shares a root cause: an SAQ selection made once, correctly, at a point in time, that silently stopped being correct as the business changed. PCI DSS attestation is an annual cycle for most merchant levels (with quarterly ASV scanning layered on top where applicable — see PCI DSS Merchant Levels for how validation frequency maps to transaction volume), and the discipline that prevents drift is treating SAQ eligibility as something you re-derive each cycle from current architecture, not something you carry forward from last year's PDF. Build the re-derivation into whatever change-management process already governs your checkout, POS, and integration work, so that a new script, a new terminal model, or a new system integration triggers an eligibility re-check automatically rather than waiting for the annual attestation deadline — or, worse, an acquirer's audit — to surface it.

Table: Annual SAQ Confirmation Checklist

Table: Merchant vs. Service Provider SAQ Responsibility

SAQ Discipline as a Business Advantage

It's tempting to treat SAQ selection purely as a compliance chore, but the merchants who get it right consistently turn it into a genuine architectural advantage. Every one of the case studies above ends the same way: the organization that invested in getting its SAQ classification precisely right also ended up with a smaller, cleaner, better-understood cardholder data environment — because the exercise of proving eligibility forces exactly the kind of scope discipline that reduces both compliance cost and breach exposure simultaneously. A business that can say, with evidence, "our checkout never touches card data, our terminals are fully isolated, and our storage footprint is zero" isn't just filling out a shorter form — it has a materially smaller attack surface than a competitor who filed SAQ D because nobody ever mapped the environment closely enough to prove otherwise. Selling that story to a board, an acquirer, or a prospective enterprise customer during due diligence is worth more than the hours saved on paperwork. If your team is still deciding which SAQ fits, or suspects — the way Larkspur did — that the box you checked no longer matches the architecture you run, PentesterWorld's assessors can walk your environment through this exact decision tree and confirm the classification before your acquirer does it for you.

Try our SAQ Selector tool to run your environment through this decision logic interactively, download the PCI DSS Scoping & CDE Worksheet to document your cardholder data environment before your next attestation cycle, or take the Are You PCI DSS Ready? quiz to get a fast read on where your program stands. For merchants who confirm they're in SAQ D territory and want to reduce it, our Merchant Level / SAQ Reference maps validation obligations to your actual transaction volume so you can plan scope reduction with a clear target in mind.