12 PCI DSS Requirements, One Real Question: Which SAQ Actually Applies to You?

A founder once forwarded me a PCI DSS checklist his payment processor had sent over — all 12 requirements, dozens of sub-controls, quarterly scans, annual penetration tests, the works. He was convinced his three-person e-commerce shop was about to spend six figures on compliance. It took one conversation to sort out that almost none of that list actually applied to him. He needed SAQ A, not the full standard — a fraction of the work he'd braced for.

This mix-up happens constantly, and it's the single biggest source of confusion in PCI compliance audits. Everyone finds the 12 requirements. Almost nobody finds the document that tells them which of those requirements they're actually on the hook for: the SAQ.

What the 12 Requirements Actually Cover, Briefly

PCI DSS organises its requirements around six broad goals — building secure networks, protecting cardholder data, running a vulnerability management program, enforcing strong access control, monitoring and testing networks regularly, and maintaining an information security policy. Under those six goals sit the 12 individual requirements: things like installing network security controls, encrypting stored account data, restricting access on a need-to-know basis, logging and monitoring system activity, and running regular vulnerability scans and penetration tests.

Read as a flat list, this looks like a single, uniform standard every business has to fully implement. That's the misconception. PCI DSS was never designed to apply the same weight to every merchant — a five-person Shopify store and a payment processor handling millions of transactions a year face very different risk profiles, and the standard accounts for that through the SAQ system.

What an SAQ Actually Is

A Self-Assessment Questionnaire (SAQ) is a validation tool published by the PCI Security Standards Council that maps a specific business scenario to a specific subset of the 12 requirements. Instead of every merchant working through the full requirement set, most businesses complete the SAQ that matches how they actually handle cardholder data — and that SAQ tells them exactly which controls apply to their situation and which ones don't.’

This is the step most companies skip. They see "PCI DSS" mentioned in a merchant agreement, pull up the full 12-requirement list, and start building a compliance program around all of it — when a correctly scoped SAQ might have cut that scope by 70% or more.

The SAQ Types That Actually Matter

There are several SAQ types, but most businesses fall into one of a handful of common categories.

• SAQ A applies to merchants who've fully outsourced payment processing to a validated third party — think a business using a hosted checkout page from Stripe or Razorpay, where cardholder data never actually touches the merchant's own systems. This is the lightest SAQ by far, with a small handful of requirements, mostly around policy and vendor management.

• SAQ A-EP applies to a similar setup, but where the merchant's website still influences the payment process — for example, a page that redirects to a hosted payment form but isn't fully separated from it. This pulls in meaningfully more requirements than SAQ A, because the merchant's own web environment is now part of the security picture.

• SAQ B applies to merchants using standalone, dial-out payment terminals with no internet connection to other systems — common in smaller retail or offline setups.

• SAQ C applies to businesses using a payment application connected to the internet, where the merchant's own systems are more directly involved in processing.

• SAQ D is the full set — and it applies to merchants who store, process, or transmit cardholder data directly on their own systems, without the protective separation the other SAQs assume. This is the SAQ most people picture when they think of "PCI compliance," but it's actually the exception, not the default, for most modern businesses using third-party payment processors.

SAQ D for Service Providers is a separate, heavier version for companies that process, store, or transmit cardholder data on behalf of other businesses — payment gateways, hosting providers, and similar service providers fall here, and this is typically the point where a formal PCI DSS audit conducted by a Qualified Security Assessor becomes necessary rather than a self-assessment.

Why Getting This Wrong Costs Real Money

Picking the wrong SAQ — or worse, not picking one at all and defaulting to the full requirement list — has a direct cost. Every extra requirement in scope means more documentation, more technical controls to implement, and in some cases, genuinely unnecessary infrastructure changes for a business that was never at meaningful risk in the first place.

The reverse mistake is just as damaging, though less common: assuming a lighter SAQ applies when the business's actual payment flow doesn't qualify for it. This shows up later, usually during a payment processor's own review, or worse, after an incident — and it can mean the business was never actually compliant despite believing it was.

How Your Actual Payment Flow Determines the Right SAQ

The deciding factor isn't your industry or your revenue — it's exactly how cardholder data moves through your systems, end to end.

Does your checkout redirect entirely to a third-party hosted page, with your own servers never seeing a card number? That points toward SAQ A. Does your own website embed or control any part of the payment form, even if the actual transaction is handled elsewhere? That likely bumps you to SAQ A-EP. Does cardholder data get stored, even temporarily, in your own database, logs, or backups? That's SAQ D territory, and it's worth checking carefully, because logging and backup systems are a common place where cardholder data ends up without anyone intending it to.

This is also where a lot of businesses discover gaps they didn't know existed — a support team that pastes card numbers into a ticketing system, a marketing tool that accidentally captures form data, a legacy integration nobody's touched in years. None of these show up by reading the 12 requirements in isolation. They show up by mapping your actual data flow against the SAQ definitions.

Why Some Businesses Skip Self-Assessment Entirely

Not every business gets to self-assess. Larger merchants — generally those processing above a transaction volume threshold set by the card networks, along with all Level 1 merchants and most service providers handling significant volumes — are required to undergo a full PCI DSS audit performed by a PCI QSA (Qualified Security Assessor) rather than completing an SAQ internally.

This distinction matters because a PCI QSA audit is a materially different process from filling out a questionnaire. A PCI certified assessor independently validates your controls against the full requirement set relevant to your environment, produces a formal Report on Compliance, and brings a level of scrutiny that a self-assessment simply doesn't. If your transaction volume or business model puts you in this category, the right first move isn't figuring out which SAQ to fill out — it's engaging PCI QSA services early, since a full audit takes meaningfully longer to prepare for than a self-assessment does.

A Practical Way to Approach This

Start by mapping your actual payment flow before opening any requirement checklist. Sketch out, literally, every point cardholder data touches — your website, your servers, your payment processor's hosted pages, your support tools, your backups. Once that map exists, matching it against the SAQ definitions becomes straightforward, and the requirement list that actually applies to you shrinks into something manageable.

If your business has grown or changed its payment setup recently — a new checkout integration, a new payment processor, an in-house feature that touches card data — it's worth re-checking your SAQ classification rather than assuming last year's answer still holds. SAQ eligibility isn't permanent; it follows your current architecture, not your business's history.

For businesses that fall into full QSA-audit territory, or that are genuinely unsure which SAQ their setup qualifies for, it's usually faster and cheaper to get that scoping question answered by someone who does PCI compliance audits regularly than to guess and rebuild later. Getting the classification right at the start is what keeps a PCI DSS audit proportional to the actual risk in your business, instead of turning into six figures of unnecessary work for a three-person team that never needed SAQ D in the first place.