PCI DSS for Startups: Scope, SAQs, and Infrastructure

Most startups never need the heavy version of PCI DSS. If your customers’ card data goes straight from their browser to Stripe, Adyen, or Braintree through a hosted iframe or redirect — and never touches your servers or your own payment form — you typically qualify for SAQ A, the shortest self-assessment questionnaire. Per Stripe’s own compliance guide, Checkout and Elements host card inputs in an iframe served from Stripe’s domain precisely so card data never reaches your infrastructure. The moment your code builds the payment form or your backend touches a PAN, scope expands toward SAQ A-EP or the full-fat SAQ D, and PCI stops being a checkbox and starts being an infrastructure program.

One line up front: this is engineering guidance from a practitioner, not legal or QSA advice — validate your specific situation with your acquirer or a Qualified Security Assessor.

What is PCI DSS, and does my startup actually have to comply?

PCI DSS is the card brands’ security standard, and it applies to every merchant that stores, processes, or transmits cardholder data — there is no revenue floor. What varies is how you validate. The current version is PCI DSS 4.0.1, published June 2024; v4.0 was retired at the end of 2024, and the future-dated requirements introduced in 4.0 became mandatory on March 31, 2025. So “PCI 4.x” is not on the horizon — it is the standard you are being measured against today.

Validation burden scales with card volume. Merchant levels run from Level 4 (under 20,000 e-commerce transactions a year) up to Level 1 (over 6 million), where a formal assessor-led Report on Compliance replaces self-assessment. A seed-to-Series-B startup is almost always Level 3 or 4: a Self-Assessment Questionnaire (SAQ) plus whatever scans that SAQ requires. Which SAQ you file is the whole game.

SAQ A vs A-EP vs D: which one applies to you?

The short answer: SAQ A if a third party hosts the payment fields, SAQ A-EP if your page constructs the payment form, SAQ D if card data touches your systems. The difference in effort between these is enormous — SAQ A is a short questionnaire; SAQ D is essentially the entire standard.

SAQ	When it applies	Typical integration	Burden
A	All payment functions fully outsourced; card data collected in the provider’s hosted iframe or redirect page	Stripe Checkout, Stripe Elements, hosted payment pages	Smallest questionnaire; lightest controls
A-EP	Your website doesn’t receive card data, but your code controls how the payment page or form is built	Direct-post / JS integrations where your page assembles the form	Most of PCI DSS; ASV scans, pen testing, hardening of web infra
D	Card data is stored, processed, or transmitted by your systems	Passing PANs through your API or database	The full 12 requirement families

Stripe’s guide is blunt about the far end of this table: pass card data directly to their API and you validate with SAQ D, “the most demanding of the SAQs.” Their fix is the same as ours — move to hosted fields.

Two cautions on SAQ A. First, “we use Stripe” is not automatically SAQ A: it depends on which integration your frontend team shipped — swapping a hosted field for a custom form silently changes your compliance posture. Second, the Council has revised SAQ A’s eligibility criteria during the 4.x cycle, particularly around how e-commerce script security (requirements 6.4.3 and 11.6.1 in the standard) applies to fully outsourced pages — read the current SAQ A document from the PCI SSC library, not a 2022-era blog post, and expect your payment provider to offer payment-page script-integrity tooling either way.

When does PCI scope explode?

Scope explodes the moment cardholder data enters an environment you operate. PCI scope isn’t one server — it’s the cardholder data environment (CDE) plus every system that can reach it. In a flat VPC where payments, staging, and analytics share a network, the whole VPC is arguably in scope.

Common scope-exploders in startup environments:

• Logging full request bodies at the API gateway, capturing PANs into your log pipeline
• Call-center or “manual entry” flows where staff type card numbers into internal tools
• Building a custom card form for conversion reasons, dropping you from A to A-EP
• Storing PANs “temporarily” in a queue or database during a migration

Each of these turns adjacent infrastructure — logging stack, office network, message broker — into audit surface.

What infrastructure does real PCI scope require?

If you land in SAQ A-EP or D territory, budget for a genuine engineering program, not a form. The recurring pillars in the standard’s 12 requirements are segmentation, hardening, logging, and testing:

• Segmentation: isolate the CDE in its own network segment (separate VPC or tightly firewalled subnets) so the rest of your infrastructure falls out of scope. This is the single highest-leverage move, and it works the same on AWS, GCP, or Azure.
• Scanning and testing: quarterly external vulnerability scans by an Approved Scanning Vendor (ASV), plus periodic penetration testing that validates your segmentation actually holds.
• Logging and monitoring: centralized audit logs covering access to cardholder systems, retained and reviewed — with card data itself scrubbed from those logs.
• Access control: MFA into the CDE, need-to-know access, and secure configuration baselines (the CIS Benchmarks are a sane starting point).

The good news: this overlaps heavily with what SOC 2 already asks of your infrastructure, so sequencing matters — see our startup compliance roadmap for which certification to tackle at which stage.

How do you keep PCI scope small by design?

Tokenize at the edge and treat “no PANs on our systems” as an architectural invariant. Use your processor’s hosted fields, block card-number patterns in your log scrubbers, and put a CI check or code-review rule on any change to payment pages so a well-meaning refactor can’t silently move you from SAQ A to A-EP. Review the actual integration annually — not the intention, the deployed code.

If you’re not certain which SAQ you qualify for, or whether your VPC layout would survive a segmentation test, that’s exactly what our infrastructure audit answers — see the depth in a sample audit report. A focused week of scoping is far cheaper than learning at contract time that a customer expects SAQ D evidence you don’t have.