Skip to main content
Back to the shipping log
Security4 min read

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.

HTThe Hayaiti team
#pci#ecommerce#compliance#security

Built on tools you trust

Vercel
Stripe
Cloudflare
GitHub
Linear
Slack
Resend
Sentry
Postgres
PostHog
Loom
Notion

← 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.

HT

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

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.