PCI SAQ A vs SAQ D: a 10x audit cost decision
The same e-commerce business can fall into two different PCI scopes depending on a single architectural choice. The cost difference is roughly 10x. Most teams don't realize it until the QSA quotes them.
Built on tools you trust
← swipe · 12 tools →
If you take card payments and you process more than a handful of transactions a year, you're in scope for PCI DSS. The question is which scope.
There are nine different PCI Self-Assessment Questionnaires (SAQs). The two that matter for most e-commerce businesses are SAQ A and SAQ D. The compliance work, the engineering work, and the audit cost are all roughly an order of magnitude apart.
SAQ A — the easy version
You qualify for SAQ A if card data never touches your servers. Concretely:
- Tokenized payment fields are served via Stripe Elements / Braintree Hosted Fields / Adyen Drop-in / Shop Pay.
- Your form posts the tokenized result to your backend, never the raw PAN, CVV, or expiry.
- Your customer is redirected entirely off your domain to the processor's hosted page (also qualifies, sometimes called "redirect e-commerce").
SAQ A asks ~22 questions. It's mostly about your relationship with the tokenization vendor (do they have their own AOC, do you list them as your service provider, do you have a written agreement). You can typically self-attest without a QSA on-site engagement.
SAQ D — the full version
You fall into SAQ D if any card data touches your infrastructure. Concretely:
- You have a custom checkout form that takes the raw PAN before posting to the processor.
- You log request bodies and the request body sometimes contains card data (even accidentally — happens).
- You have a customer-service tool where reps can take card numbers over the phone and key them into a form that hits your servers.
- Your fraud-review tool stores the last-four + first-six (BIN) of card numbers for cross-customer correlation.
SAQ D asks ~329 questions. You need an on-site QSA assessment for any serious processor. Network segmentation, encryption-at-rest, key management, quarterly external pentests, hardened build standards, intrusion detection — the full stack. Audit costs typically start around $30K–$50K and scale with cardholder data environment (CDE) size.
The 10x
A SAQ A engagement can be done for a few thousand dollars in engineering time and a few hundred dollars of self-attestation paperwork. SAQ D engagements typically run $30K–$100K+ all-in, plus ongoing quarterly costs.
That delta is almost entirely an architectural decision, not a business decision.
When teams accidentally land in SAQ D
The single most common cause we see: a custom checkout form that "feels nicer" than the hosted Stripe page. The dev team builds a React form that calls Stripe.js for tokenization. Looks like SAQ A.
But somewhere in the request flow, the raw PAN gets:
- Logged into Datadog APM (request body capture enabled).
- Sent to Sentry as part of an exception trace.
- Cached in a Redis "session" alongside other form data for resume.
- Passed through a backend "validate before tokenize" check that inadvertently saves it.
Now you're in SAQ D. The Datadog audit, the Sentry audit, the network segmentation — all in scope.
How we architect for SAQ A
When we ship an e-commerce checkout, we use Stripe Elements (or equivalent) and aggressively scrub anything that could reach the PAN:
- Datadog / Sentry middleware filters card-shape strings before sampling.
- Redis sessions never accept fields named
card_number,pan,cc, or matching the BIN+last4 pattern. - The "validate before tokenize" check happens client-side via Stripe's API, not by sending the PAN to our server.
- Logging frameworks have a written redact-list including all card-data field names.
The result: tokenized data flows through your servers, raw data doesn't. SAQ A territory.
What this is worth
For a Series A e-commerce company doing $1M-$5M ARR, the SAQ A vs SAQ D decision is roughly $30K-$80K of compliance cost in year one, plus ongoing operational overhead. Done right at architecture time, it's free. Done wrong, it's an annual tax.
If you're scoping a new payment surface or unsure where you currently sit, our cybersecurity-for-ecommerce SKU includes a scope-reduction architecture review. The math on a scope-reduction engagement typically pays for itself at the next QSA quote.
The Hayaiti team
Hayaiti
Hayaiti is a productized engineering studio. We ship web, software, iOS, and cybersecurity work on fixed prices and calendar-day timelines. The team takes turns on the shipping log.
More from the shipping log
Multi-tenant isolation: the SaaS pentest gap nobody scopes for
Every B2B SaaS pentest scope says 'web app + API'. Almost none of them say 'cross-tenant data access via IDOR, RLS bypass, JWT scope leaks, shared S3 paths, leaky webhook payloads'. That's the gap.
Subdomain takeover: still everywhere in 2026
We checked the top 10K domains for dangling DNS records pointing to deprovisioned cloud resources. The numbers are bad.
Three OAuth state-bypass patterns we keep finding in the wild
Three OAuth state-handling bugs we reported on bug-bounty programs last quarter. All three were exploitable. Here's the pattern, the fix, and why CSRF tokens alone aren't enough.
Want help shipping this?
We turn posts like this into production code. Fixed price. Calendar-day timelines. Source code in your repo on day one.