What is SOC 2 for a startup, and how do you actually get it? SOC 2 is an audit report — issued by a licensed CPA firm — attesting that your security controls meet the AICPA’s Trust Services Criteria. For a startup it’s almost always a sales requirement, not a legal one: an enterprise buyer’s security review demands it before they’ll sign. Getting it means scoping the right criteria, building real controls (access, logging, change management, vendor risk), running them for an observation window, and collecting the evidence an auditor will believe. This guide is the whole path, with links to the deep dives for each step.
This is the hub for our compliance library. Each section here is the map; the linked articles are the terrain. If you’re still deciding whether you even need the machinery, start with do you need a compliance platform.
Do you actually need SOC 2 yet?
Usually you pursue SOC 2 the quarter a real deal stalls on it — not before. It’s expensive and it’s a standing commitment, so doing it speculatively burns money and attention you need elsewhere. The honest trigger is simple: a customer you want has put “provide a SOC 2 report” in their procurement path, or you’re losing deals in security review. When that happens, SOC 2 stops being overhead and becomes revenue you’re leaving on the table.
The report also pays a secondary dividend: it collapses the security-questionnaire tax. Instead of hand-answering a 300-line spreadsheet per prospect, you hand over the report and a few artifacts — see reading a security questionnaire for how to shortcut that process even before the report lands.
What’s actually in scope: the five Trust Services Criteria
SOC 2 is built on five Trust Services Criteria (TSC). Only the first is mandatory; the rest are scoped to what you commit to.
| Criterion | Mandatory? | What it covers | Scope it when… |
|---|---|---|---|
| Security (Common Criteria) | Yes | Access control, change management, risk management, monitoring — the baseline | Always |
| Availability | No | Uptime, DR, capacity, monitoring | You make uptime commitments (SLAs) |
| Confidentiality | No | Protecting data designated confidential | Contracts promise confidentiality beyond the norm |
| Processing Integrity | No | Processing is complete, valid, accurate, timely | You process transactions/data on customers’ behalf |
| Privacy | No | Handling of personal information per your notice | You collect consumer PII and make privacy commitments |
Most startups scope Security only for the first report, occasionally adding Availability or Confidentiality when a contract explicitly requires them. Adding criteria multiplies the controls you must build and evidence — so scope to the commitments you’ve actually made, not to look thorough.
Type I vs. Type II: which do you start with?
Type I proves the controls are designed right on one day; Type II proves they ran over a period. The difference is the whole value.
| Type I | Type II | |
|---|---|---|
| What it attests | Controls suitably designed at a point in time | Controls operated effectively over a period |
| Observation window | None (a snapshot) | Typically 3-12 months |
| What buyers accept | A weak interim signal | The real thing |
| Time to obtain | Fastest (weeks) | The window + the audit |
| Best used as | An interim proof while you run the window | The report you actually hand customers |
The common startup path: reach Type I readiness fast to unblock a deal with an interim report, start the observation window the same day, and convert to Type II once the window closes. Some teams skip Type I entirely and go straight to a short (3-month) Type II window.
The readiness timeline
The path is the same regardless of tooling: scope, find the gaps, fix them, then run and evidence the controls. The 90-day SOC 2 readiness sprint is the tactical, week-by-week version of this.
The load-bearing phase is remediation — actually building the controls — and it’s where engineering, not compliance, does the work.
What it costs
Four line items, and the fourth is the one teams underestimate:
- Auditor fee. The CPA firm that issues the report. For a startup this is typically five figures and scales with scope and report type.
- Compliance-automation platform. Vanta, Drata, Secureframe, and peers automate evidence collection — a few thousand to low five figures per year. Worth it for most startups; see do you need a compliance platform for the honest build-vs-buy.
- Penetration test. Frequently expected by auditors and buyers; mid four to low five figures.
- Engineering time. The largest and least-visible cost — building and then continuously evidencing the controls. Budget it explicitly or it comes out of your roadmap by surprise.
The engineering work (what your team actually builds)
This is the part a platform can’t do for you. The controls that satisfy the Security criterion are, overwhelmingly, ordinary good platform engineering:
- Access & identity. SSO everywhere, MFA on every account, least-privilege roles, and one-action offboarding. The single highest-leverage move is killing long-lived credentials in favor of federated, short-lived access — auditors and attackers care about the same thing here.
- Change management. Every production change flows through a reviewed pull request and a gated pipeline, with a traceable history. That history is your change-management evidence.
- Logging & monitoring. Centralized, tamper-resistant logs with alerting. The same discipline behind securing PHI in observability applies to SOC 2 — protect the logs, and make them prove what happened.
- Encryption. At rest and in transit, with sane key management. If you’re also on the healthcare path, the minimum-viable HIPAA on AWS controls overlap heavily with SOC 2’s.
- Vendor / subprocessor risk. A maintained subprocessor list with signed DPAs and a review cadence — vendor risk scoring is the lightweight method.
- Evidence collection. The ongoing burden: proving, continuously, that the above operate. Automate it or drown in screenshots. Evidence pipelines 101 is the pattern that turns evidence from a quarterly fire drill into a byproduct of running the system.
SOC 2 vs. HIPAA vs. HITRUST
SOC 2 isn’t the only framework, and picking the wrong one wastes a year. In short: SOC 2 is a flexible, sales-driven attestation; HIPAA is a US legal requirement for handling PHI (not a certification you “pass”); HITRUST is a prescriptive, certifiable framework often demanded in healthcare. Which one you need depends on who you sell to and what data you touch — the full decision is in choosing between SOC 2, HITRUST, and HIPAA.
Common pitfalls
- Over-scoping the criteria. Adding Availability/Privacy “to be safe” multiplies work for no sales benefit.
- Treating it as a document exercise. A binder of policies with no operating controls fails a Type II and, worse, doesn’t make you secure.
- Manual evidence. If evidence collection is a person taking screenshots, every audit and renewal is a fire drill.
- Buying the platform before consolidating identity. The platform evidences controls that don’t exist yet. Fix identity first.
- No owner. SOC 2 without a named owner drifts; the observation window quietly breaks and nobody notices until the audit.
The Template
A SOC 2 readiness roadmap. Work top to bottom; each phase makes the next meaningful. Score each item Not started / In progress / Done.
Phase 1 — Scope
- Confirmed the business trigger (a real deal / lost deals in security review)
- Chosen Type I-then-II vs. straight-to-Type-II
- Scoped criteria (Security + only the others you commit to)
- Defined the systems/boundaries in scope
Phase 2 — Gap assessment
- Mapped current controls to the Common Criteria
- Identified the gaps (access, change mgmt, logging, encryption, vendor risk, evidence)
- Named an owner for the program
Phase 3 — Remediate (the engineering work)
- SSO + universal MFA; least-privilege roles; one-action offboarding
- Long-lived credentials eliminated in favor of federated, short-lived access
- Change management: reviewed PRs + gated pipeline with traceable history
- Centralized, tamper-resistant logging + alerting
- Encryption at rest + in transit with managed keys
- Subprocessor list + signed DPAs + review cadence
- Backup/DR + a tested restore
- Incident-response plan documented and exercised
Phase 4 — Evidence + observe
- Compliance platform integrated (or an evidence pipeline stood up)
- Evidence collection automated, not manual
- Observation window started; controls running continuously
Phase 5 — Audit
- Auditor engaged; penetration test complete
- Type I issued (if used as interim)
- Type II window closed; report issued and shareable with prospects
Most startups find Phase 3 is 80% of the effort and Phase 4 is where discipline pays off or falls apart. Both are engineering problems more than compliance ones.