The Startup Compliance Roadmap: What to Do at Seed, Series A, Series B, and Series C

The compliance roadmap at a glance

The single most useful artifact for a founder is a stage-by-stage matrix: what to pursue, what forces it, roughly what it costs, and how long it takes. The bands below are 2026 market estimates for a typical US-first SaaS company; regulatory triggers cite the governing standard. Treat the sequencing as an opinionated recommendation, not a rule — your data types and buyers can pull frameworks earlier.

Two axes drive everything in this table: which frameworks apply (a function of your customers and data, covered next) and how long each takes (the SOC 2 Type II observation window dominates — see the full SOC 2 audit timeline). Cost figures are market estimates aggregated from 2026 auditor and platform pricing surveys and are no substitute for a scoped quote.

How to know which framework you need

Before sequencing by stage, answer five questions about your customers and data. Each answer maps to a framework and, importantly, tells you whether the obligation is legal (you must comply regardless of sales) or market (buyers demand it to close deals). Legal triggers do not wait for your next round.

1. Do you sell to US enterprise? → SOC 2 (market).
2. Do you create, receive, store, or transmit health data? → HIPAA + a BAA (legal).
3. Do you offer services to, or monitor, people in the EU? → GDPR + a DPA (legal).
4. Do you store or transmit cardholder data? → PCI DSS (contractual/legal).
5. Do you sell to the US public sector? → FedRAMP / GovRAMP (market/contractual).

A note on report choice: SOC 1 covers controls relevant to a customer’s internal control over financial reporting (ICFR), while SOC 2 covers security and the other Trust Services Criteria. If a buyer’s auditors ask for assurance over financially significant processing, that is a SOC 1 request, not SOC 2 — do not conflate them.

Pre-seed & Seed: build compliant habits and get SOC 2 Type I

The cheapest compliance work happens before you have customers, because retrofitting controls onto a live production system is far more expensive than designing them in. At pre-seed, six architecture decisions pay off at every later stage: infrastructure-as-code (so configuration is reviewable and reproducible), centralized logging, a secrets manager (no credentials in code), role-based access control from day one, a written data classification scheme, and a lightweight vendor-review process before you adopt any subprocessor.

By Seed, the forcing function usually arrives as a vendor security questionnaire (sometimes called a DDQ) attached to your first enterprise deal. That is when SOC 2 stops being optional. The fastest credible response is a SOC 2 Type I, which attests that your controls are designed appropriately as of a point in time and can be completed in roughly two to three months once controls exist. Work through our SOC 2 readiness checklist before engaging an auditor to surface design gaps early.

What actually forces SOC 2 — and Type I vs Type II

SOC 2 is an attestation report issued by a licensed CPA firm under AICPA standards (SSAE 18, examined under AT-C section 205), evaluating controls mapped to the Trust Services Criteria — the Security category (the Common Criteria, CC1–CC9) is mandatory, with Availability, Processing Integrity, Confidentiality, and Privacy added by scope. It is not a law or a certification; it is market-required. A Type I tests control design at a single date; a Type II tests operating effectiveness over an observation window. The AICPA does not mandate a minimum period, but auditors typically accept a minimum of about three months as the fast path, with six months common for a first Type II and twelve months standard for renewals. Most Seed-stage teams do Type I first, then start the Type II clock immediately; a team with six-to-twelve months of runway and mature controls can go straight to Type II (see SOC 2 Type I vs Type II).

Series A: SOC 2 Type II in hand, plus HIPAA or GDPR by market

By Series A, enterprise buyers signing five- and six-figure contracts — and many investors during diligence — expect a SOC 2 Type II, because a Type I only proves controls existed on one day, not that they operated. This is also the stage where market-specific legal obligations attach based on your data. Both HIPAA and GDPR are laws: they bind you the moment their trigger is met, not when you decide to pursue them.

Healthtech path: when PHI triggers HIPAA and a BAA

If your product creates, receives, maintains, or transmits electronic Protected Health Information (ePHI) on behalf of a healthcare customer, you are a Business Associate under HIPAA. The HIPAA Security Rule requires administrative, physical, and technical safeguards (45 CFR 164.308, 164.310, 164.312), and a signed Business Associate Agreement (45 CFR 164.314(a)) is legally required with each such customer before PHI changes hands. Note that HHS issued a proposed update to the Security Rule (an NPRM) that, as of mid-2026, remains proposed rather than final — plan against the current rule and monitor the rulemaking rather than treating draft provisions as binding. For healthtech buyers, HITRUST CSF is increasingly requested alongside HIPAA as a certifiable way to demonstrate those safeguards.

EU expansion path: GDPR Article 3(2), DPAs, and EU representatives

A US startup with no EU entity still falls under the GDPR if it offers goods or services to, or monitors the behaviour of, people in the EU — the “targeting” criterion in Article 3(2). Payment is not required for an offering to count. When you process personal data for business customers you are typically a processor, so Article 28 requires a Data Processing Agreement. Depending on your processing, Article 27 may require you to appoint an EU representative — but Article 27(2) exempts processing that is occasional and low-risk, so this is conditional, not automatic. The EU-US Data Privacy Framework offers one transfer mechanism, but it remains legally contested, so keep Standard Contractual Clauses (SCCs) as your fallback for EU-to-US transfers. For assurance that international buyers recognize, an ISAE 3000 engagement is the cross-border analog to SOC 2.

Layering in the annual penetration test

An annual third-party penetration test becomes a de-facto expectation around Series A. It is embedded in enterprise vendor questionnaires, commonly requested as SOC 2 evidence (by convention, not as an explicit TSC line item), and it is an explicit PCI DSS requirement (Req. 11.4). Sequencing it onto the roadmap at Series A — rather than treating it as a separate track — means one test satisfies several diligence requests at once.

Series B: ISO 27001 for global enterprise, PCI DSS if you touch cards, FedRAMP for government

Series B is when the buyer base goes global and the frameworks broaden. European and multinational enterprises ask for ISO/IEC 27001 the way US buyers ask for SOC 2; card data pulls in PCI DSS; and a public-sector motion pulls in FedRAMP.

SOC 2 to ISO 27001: reusing your controls

ISO/IEC 27001:2022 certifies an information security management system (ISMS) against Annex A, which contains 93 controls across four themes (Organizational 37, People 8, Physical 14, Technological 34), and requires a Statement of Applicability (SoA) documenting which controls apply and why. Because SOC 2 and ISO 27001 address the same security domains, a large share of the controls overlap — the AICPA’s own TSC-to-ISO 27001 mapping is commonly summarized as roughly 80%, though other published crosswalks report less depending on whether you compare at the control or evidence level. The practical takeaway (an opinion, not a rule): doing SOC 2 first makes an ISO 27001 add-on materially cheaper, because most of your evidence already exists.

PCI DSS v4.0.1 merchant levels and SAQ vs ROC

If you store, process, or transmit cardholder data, you are subject to PCI DSS v4.0.1 (the current standard; v3.2.1 retired in 2024 and v4.0’s future-dated requirements became mandatory in March 2025). Merchant levels are set by annual card transaction volume — and, importantly, those thresholds are defined by the card brands (Visa, Mastercard), not by the PCI Security Standards Council. Lower-volume merchants can self-attest with a Self-Assessment Questionnaire (SAQ) matched to how they handle card data (for example, SAQ A for fully outsourced e-commerce, SAQ A-EP for partially outsourced, SAQ D for the broadest scope), while Level 1 merchants require a QSA-signed Report on Compliance (ROC).

On the public-sector path, note that FedRAMP is mid-transition to a new “20x” model with a single “FedRAMP Certified” label; its Low-baseline reciprocity is designed to accept a SOC 2 Type II, ISO 27001, or HITRUST as an on-ramp. StateRAMP has also rebranded as GovRAMP. Confirm the current terminology at the time you pursue it, because the program is actively changing in 2026.

Series C and beyond: mature, renew, and go multi-region

At Series C, compliance shifts from acquiring frameworks to operating a program. The work is renewal on annual cadences, expanding scope across regions, and adding frameworks tied to new business lines. If your platform becomes financially significant to customers — for example, you process transactions that feed their financial statements — their auditors will request a SOC 1 report on your controls over financial reporting, with ISAE 3402 as the international equivalent. Multi-region growth also brings regional privacy laws (CCPA/CPRA in California, UK GDPR and the Data Protection Act 2018 in the UK, and sector or state-specific regimes), and you will map Complementary User Entity Controls (CUECs) so customers understand their part of the shared control environment. NIST CSF 2.0 and NIST 800-53 often become the internal backbone that all of these frameworks map back to.

Framework comparison: SOC 2 vs ISO 27001 vs HIPAA vs GDPR vs PCI DSS

The frameworks differ not just in scope but in kind — an attestation is not a certification, and neither is a law. Getting this right matters in buyer conversations, because saying you are “SOC 2 certified” (you cannot be) or “HIPAA certified” (there is no such certification) signals inexperience.

SOC 1 is examined under AT-C section 320; SOC 2 under AT-C section 205 — a distinction worth getting right. HIPAA and GDPR carry statutory penalties and apply the instant their triggers are met, which is why they cannot be “deferred to the next round” the way a market framework can.

How the frameworks overlap

The reason sequencing works is control reuse: implement a control domain once and it satisfies obligations across several frameworks. The crosswalk below maps common domains to their reference in each standard. It is illustrative — the exact clause depends on your control design — and it is why the second and third frameworks cost far less than the first. Our multi-framework control mapping guide works through the crosswalk in detail.

Implemented once and evidenced consistently, each of these domains satisfies its row across SOC 2, ISO 27001, and HIPAA at the same time — the practical basis for running one evidence rhythm rather than three separate audits.

Realistic costs and timelines by stage

Cost is driven more by delivery model and scope than by which report you buy. There are two broad paths: a platform-assisted path (a compliance automation platform such as Vanta, Drata, or Secureframe plus an audit) and a traditional CPA audit path. The figures below are 2026 market estimates aggregated from auditor and platform pricing surveys, not quotes, and they exclude internal engineering time.

The build-vs-buy question is real: platforms automate evidence collection and lower the audit-prep burden, which is why the platform-assisted band is lower. What they cannot do is issue the report — only a licensed CPA firm can. The most cost-effective programs use a platform for evidence and a CPA firm for the attestation, then reuse that evidence base as they layer ISO 27001, HIPAA, or GDPR, since the incremental framework is far cheaper than the first.

Common mistakes founders make sequencing compliance

The first mistake is over-buying frameworks before any buyer requires them — pursuing ISO 27001 or PCI DSS at Seed when no deal needs them, burning cash and engineering time on assurance nobody asked for. Start with the framework your actual pipeline demands.

The second is buying a Type I when the deal needs a Type II. A Type I proves design on one day; a large enterprise contract that explicitly requires “Type II” will not close on a Type I. Read the security addendum before you scope the audit.

The third is ignoring GDPR after landing an EU pilot. The moment you onboard EU users, Article 3(2) applies and you likely need a DPA — treating it as a “later” problem creates legal exposure that predates your next round.

The fourth is touching PHI without a BAA. Handling ePHI for a healthcare customer without a signed Business Associate Agreement is a HIPAA violation from the first record, regardless of how good your controls are. The BAA comes first, then the data.

The fifth is rebuilding evidence for every framework from scratch. Because the frameworks overlap heavily, teams that keep a single governed evidence base and one control register add each new framework far more cheaply than teams that run parallel, disconnected audits.