PCI-DSS is the compliance framework that startups most often architect around incorrectly. Founders read about PCI-DSS, assume it applies broadly, and either over-build (treating their entire stack as if it stores card data) or under-build (assuming Stripe makes everything compliant automatically). Both are wrong, and both are expensive.
This post is for fintech and payments-adjacent founders trying to figure out what PCI-DSS actually requires for their architecture and where a fractional CTO accelerates the work.
What PCI-DSS Is and What It Isn't
PCI-DSS (Payment Card Industry Data Security Standard) is a contractually-enforced standard from the major card networks (Visa, Mastercard, Amex, Discover, JCB), not a government regulation. The standard defines requirements for any organization that "stores, processes, or transmits cardholder data."
Critical concept: the work changes massively based on whether your architecture stores, processes, or transmits cardholder data — or whether it simply redirects customers to a service provider that does. The latter (using Stripe Checkout, Stripe Elements, or equivalent) keeps you in a much lighter compliance scope (SAQ A or SAQ A-EP) than building card handling yourself (SAQ D).
For most startups, the right answer is: don't store, process, or transmit card data. Use a vault. Stay in SAQ A or SAQ A-EP. Save yourself a year of compliance work.
SAQ Levels — What Actually Applies
The Self-Assessment Questionnaire (SAQ) levels map to different architecture patterns. The right level for your company depends on how card data flows:
SAQ A (lightest): Customer is redirected to a fully-hosted payment page operated by a PCI-DSS Level 1 service provider (e.g., Stripe Checkout). Your servers never see card data, your DOM never includes card form fields. ~22 controls, mostly around vendor management and policy. Self-attested annually.
SAQ A-EP: Card form fields are rendered on your site via iframe or similar mechanism (e.g., Stripe Elements), but card data goes directly from the customer's browser to the service provider — never through your servers. Your DOM includes the iframe but not the card data. ~190 controls. Still self-attestable, much lighter than SAQ D.
SAQ D-Merchant or D-Service Provider: You actually handle, store, or transmit cardholder data. Could be because you built tokenization yourself, run your own card vault, or process payments through a less-PCI-shielded path. ~330 controls covering everything. Typically requires QSA-led Report on Compliance (RoC) for higher transaction volumes; lower volumes can self-attest but with full SAQ D scope.
The architectural implication: if you can stay in SAQ A or SAQ A-EP scope, your engineering team can ship features instead of running a full-scale PCI compliance program. We have repeatedly migrated companies from SAQ D back to SAQ A-EP after a previous architectural decision pulled them into wider scope.
Common Patterns We See and Recommend
After multiple PCI-relevant fintech engagements, the patterns that work:
Tokenization via vault, never cardholder data on your servers. Stripe Issuing, Stripe Connect (if you're operating as a marketplace), Adyen, Spreedly, Basis Theory — pick a vault and use it. The vault returns tokens; you store tokens; you never store PANs. This is by far the highest-leverage architectural decision.
Network-isolated cardholder data environments (CDE) when you can't avoid handling card data. If your business model genuinely requires you to process card data (rare — usually requires being a payments service provider, not a SaaS company), the cardholder data environment must be network-isolated, with strict access controls, separate identity management, and dedicated logging and monitoring. Most engineers have never built this; senior pattern matching matters.
Tokenized, scoped, time-limited audit logs. PCI requires audit logging of all access to cardholder data, retention for at least one year, and protection of logs from tampering. The logging architecture interacts with your other compliance frameworks (HIPAA if healthcare-fintech, SOC 2 broadly).
Quarterly external vulnerability scans and annual pentests. PCI requires both. ASV (Approved Scanning Vendor) scans on the external-facing infrastructure quarterly; annual pentest covering the cardholder data environment. Build this into the operational rhythm rather than scrambling for it before audits.
Network segmentation when CDE exists. PCI scope is reduced when the cardholder data environment is isolated from the rest of the network. Most companies that didn't architect for this initially end up rebuilding the network during PCI scope reduction work. Doing it correctly upfront saves months of remediation.
Where Most Startups Go Wrong
Building card tokenization to "save money on transaction fees." This is almost always a mistake. The cost of staying in SAQ D scope (additional engineering time, audit fees, operational controls, breach liability) is much larger than the savings on processor fees for any startup below ~$50M in transaction volume.
Storing card data "just in case we need it later." The PCI standard prohibits storing CVV2 entirely. Storing PAN requires specific encryption, retention policies, and logging — and pulls you into SAQ D scope. If you don't have a current need to store card data, don't.
Assuming Stripe + Stripe = automatic compliance. Stripe handles card data on its end; your obligation is to make sure card data never reaches your servers. If your custom checkout collects card numbers and POSTs them to Stripe's API, you're in SAQ A-EP scope at minimum (and likely SAQ D depending on architecture).
Treating PCI as a one-time audit instead of an operational program. PCI compliance requires ongoing controls — quarterly scans, annual reviews, change management discipline, vendor management. Companies that achieve attestation and then drift fail the next year's review.
What a Fractional CTO Owns
For fintech startups handling PCI-relevant architecture, fractional CTO work covers:
- Architectural decisions to stay in SAQ A or SAQ A-EP scope — vault selection, integration patterns, browser-side card data handling
- Network and infrastructure design for any CDE that genuinely needs to exist
- PCI documentation aligned to startup-stage scope — many founders write PCI documentation that's either far too heavy or far too light; getting the scoping right saves months
- Vendor management and BAAs/DPAs — every payment-adjacent vendor needs evaluation
- Audit prep and QSA coordination when SAQ D becomes unavoidable
- Hiring the dedicated security engineer when the company outgrows the fractional model
How We Engage for Fintech / PCI Work
Our fractional CTO services include a fintech-specific track for PCI-DSS, SOC 2, and the broader regulatory architecture. For founders specifically in the payments and fintech space, our fintech industry page and fractional CTO for fintech post cover the broader engagement model.
Need help thinking this through?
PCI-DSS architecture decisions made pre-Series-A determine whether you spend the next year shipping features or shipping compliance work. Book a 30-min call — no pitch. Book a Free 30-Min Strategy Call →