Why Most Merchants Are Filing the Wrong PCI Questionnaire

Most merchants find out which SAQ they need after their acquirer tells them, not before. By then the card data flow is already built, and moving it is a bigger project than it should have been.

The self-assessment questionnaire you file isn't a formality. SAQ D runs to roughly 200 requirements across all twelve PCI DSS control areas. SAQ A covers about 22. That difference isn't about paperwork. It reflects how much of your infrastructure is actually exposed to raw card data, and how much work it takes to keep that infrastructure secure.

What decides your SAQ isn't your business type

Merchants tend to assume their SAQ is determined by industry, size, or transaction volume. It isn't. PCI DSS scoping comes down to one question: does cardholder data ever touch a system you control?

If a raw PAN ever lands on your servers, gets logged by your application, passes through your database, or sits in memory on a box you're responsible for patching, you're in SAQ D territory regardless of how briefly it's there. It doesn't matter if you're a five-person subscription startup or a hotel chain running a legacy PMS. The moment card data enters your environment, your environment becomes the Cardholder Data Environment, and every system in scope has to meet the full requirement set.

SAQ A works the other way. It applies to merchants whose payment page and payment processing are fully handled by a PCI DSS compliant third party, with no cardholder data ever touching the merchant's own systems, electronically or otherwise. Under PCI DSS v4.0.1, that includes a specific requirement that every element of the payment page loaded in the customer's browser comes directly from that compliant provider.

SAQ D: what you're actually signing up for

SAQ D isn't one extra form. It's the full PCI DSS requirement set: network segmentation, quarterly vulnerability scans by an Approved Scanning Vendor, annual penetration testing, file integrity monitoring, intrusion detection, encryption key management, access control reviews, and formal incident response. Each of those needs to be documented, evidenced, and maintained continuously, not assembled once a year before an audit.

This is the tier built for merchants and service providers who genuinely need to process card data directly: acquirers, payment gateways, PSPs, and merchants running their own card-on-file infrastructure for legitimate reasons. If that's your business, SAQ D isn't a mistake. It's the correct scope for what you do.

Where it becomes a problem is when a merchant ends up there by accident. A checkout form that posts to the merchant's own backend before forwarding to a processor. A support team that pastes card numbers into a CRM field because there was no other way to log a refund request. A PMS at the front desk that stores guest card numbers in a local database "just in case." None of these are payment processing decisions. They're scope decisions, made without anyone realizing it, and they turn a small e-commerce or hospitality business into an SAQ D merchant with SAQ D obligations.

SAQ A: what changed under PCI DSS v4.0.1

SAQ A used to include two requirements around payment page scripts, 6.4.3 and 11.6.1, that pushed some merchants toward SAQ A-EP even when their card data never touched their servers. In early 2025, the PCI Security Standards Council removed those two requirements from SAQ A and replaced them with an eligibility criterion instead: confirm that your payment page elements load only and directly from a compliant third-party provider, and that your site isn't exposed to script-based attacks on the checkout flow.

That distinction matters more than it sounds. A merchant using an iframe or redirect from a compliant processor, where nothing on the payment page originates from the merchant's own domain, can now qualify for SAQ A even under v4.0.1. A merchant who builds their own payment form and only sends the data to a processor on submit does not qualify, because the page itself is merchant-controlled, and that pushes them to SAQ A-EP, which runs to roughly 140 requirements. Getting this distinction wrong is one of the most common self-assessment errors merchants make, and it's usually invisible until an acquirer or QSA checks the actual page source.

Tokenization is the mechanism, not the buzzword

Here's the part that actually matters operationally: SAQ eligibility isn't something you request. It's something your architecture earns.

A merchant moving from SAQ D to SAQ A isn't filling out a different form. They're removing raw card data from their own systems entirely. That's what a token vault does. Card data is captured directly by the vault, never by the merchant's servers, and the merchant's systems only ever see a token, a non-sensitive reference that's useless outside the vault that issued it. The merchant can still run recurring billing, refunds, and reporting against that token. What they can't do is leak, mishandle, or expose a PAN they never had.

This is also why "we use a hosted checkout" isn't automatically the same as SAQ A eligibility. If a single script on that checkout page, an analytics tag, a chat widget, a retargeting pixel, loads from the merchant's own domain rather than the compliant provider, the merchant is back in scope for the page itself. Confirming this isn't optional. It's the actual eligibility test, not a formality on top of it.

Where merchants get caught out

Hospitality is a good example of scope creep nobody planned for. Most hotel PMS integrations still pass card data through the front desk system for incidentals, deposits, or no-show charges. Each of those flows, if it touches the property's own systems, expands the CDE and the SAQ that comes with it. The fix isn't a new PMS. It's making sure card capture at every touchpoint, front desk included, routes through the same tokenized flow as the booking engine.

Subscription businesses run into a related version of the same problem: storing a raw PAN on file "temporarily" while migrating providers, or during a manual retry process for failed payments. Temporary is doing a lot of work in that sentence. The moment that PAN sits on a server you manage, the scope question has already been answered, regardless of how long it stays there.

Checking where you actually stand

Confirming your SAQ isn't a guess. Trace an actual card number through your architecture, end to end. If it ever reaches a system your company owns or operates, in a log, a database, a support ticket, a spreadsheet, you're scoped for SAQ D until that stops happening. If it never does, and your payment page is fully delivered by a compliant provider, SAQ A is available to you.

Reducing scope from SAQ D to SAQ A doesn't happen by filing a different questionnaire. It happens by removing the reasons your systems were ever in scope to begin with. That's an architecture decision, not a compliance one, and it's usually cheaper to make before your next audit than after.