# SOC 2 for Startups: The Complete Readiness Guide

Canonical: https://kaansystems.com/library/soc2-for-startups-complete-guide
Topic: Compliance · Published: 2026-09-16 · Updated: 2026-09-16
Summary: Most startups pursue SOC 2 because a deal requires it, then discover it's less a certificate than a standing operational commitment. This is the map: what SOC 2 is, Type I vs Type II, which Trust Services Criteria to scope, how long it takes, what it costs, and the engineering work your team actually has to build — with links to the deep dives for each step.

## Key takeaways

- SOC 2 is a CPA-issued attestation that your controls meet the AICPA Trust Services Criteria — for startups it's almost always driven by an enterprise customer's security review, not a legal requirement.
- Type I attests your controls are designed correctly at a point in time; Type II attests they operated effectively over a 3-12 month window. Buyers want Type II; Type I is a fast interim signal.
- Only the Security criterion is mandatory. Scope the other four (Availability, Confidentiality, Processing Integrity, Privacy) to what you actually commit to — over-scoping is the most common early mistake.
- Budget realistically: auditor fee, a compliance-automation platform, a penetration test, and — the biggest hidden cost — the engineering time to build and evidence the controls.
- A compliance platform automates the evidence, not the controls. You still have to consolidate identity, centralize logging, enforce change management, and manage vendor risk.
- Treat SOC 2 as an operating posture, not a document exercise: the report expires, the observation window is continuous, and manual evidence collection is what makes renewals painful.

**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](/library/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](/library/reading-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](/library/90-day-soc2-readiness-sprint) is the tactical, week-by-week version of this.

```mermaid
flowchart LR
  S["Scope<br/>criteria + systems"]
  G["Gap<br/>assessment"]
  R["Remediate<br/>build the controls"]
  T1["Type I<br/>point-in-time"]
  O["Observation<br/>window (3-12 mo)"]
  T2["Type II<br/>audit + report"]

  S --> G --> R --> T1 --> O --> T2

  classDef done fill:#1F4A3E,stroke:#3FA585,stroke-width:2px,color:#E8F5EE;
  classDef next fill:#0d1f1a,stroke:#3FA585,stroke-width:1.5px,color:#E8F5EE;
  class S,G,R done;
  class T1,O,T2 next;
```

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](/library/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](/library/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](/library/securing-phi-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](/library/minimum-viable-hipaa-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](/library/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](/library/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](/library/choosing-soc2-hitrust-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.

## Frequently asked questions

**Q: What is SOC 2 for a startup?**

SOC 2 is an audit report, issued by a licensed CPA firm, attesting that your company's security controls meet the AICPA's Trust Services Criteria. For a startup it is almost never a legal requirement — it's a sales unlock: enterprise and mid-market buyers require it in their vendor security reviews before they'll sign. You pursue it to remove a purchasing blocker, and the report becomes proof you can hand a prospect instead of answering a 300-line questionnaire from scratch.

**Q: What's the difference between SOC 2 Type I and Type II?**

Type I attests that your controls are designed appropriately at a single point in time; Type II attests that those controls actually operated effectively over a period, typically 3 to 12 months. Buyers almost always want Type II because design without operation proves little. Startups often get a Type I first as a fast interim signal, then run the observation window and follow with Type II.

**Q: How long does SOC 2 take for a startup?**

A focused startup can reach Type I readiness in roughly 6 to 10 weeks — scoping, a gap assessment, and remediation of the missing controls. Type II then requires an observation window (3 months is the common minimum, 6-12 for a mature report) during which the controls must run continuously, followed by the audit itself. So the realistic timeline from start to a Type II report is a quarter to two quarters, most of it the observation period.

**Q: How much does SOC 2 cost?**

For a startup, plan for four line items: the auditor's fee (often five figures), a compliance-automation platform (a few thousand to low five figures per year), a penetration test (often required, mid four to low five figures), and the engineering time to build and evidence the controls — the largest and most-underestimated cost. First-year totals for a small startup commonly land in the low-to-mid five figures plus significant internal effort.

**Q: Which Trust Services Criteria do I need for SOC 2?**

Only Security (the Common Criteria) is mandatory. The other four — Availability, Confidentiality, Processing Integrity, and Privacy — are optional and should be scoped to the commitments you actually make to customers. Most startups scope Security alone, sometimes adding Availability or Confidentiality if their contracts promise them. Over-scoping the criteria is the most common early mistake and adds cost and evidence burden for no sales benefit.

**Q: Do I need a compliance platform like Vanta or Drata for SOC 2?**

You don't strictly need one, but for most startups it pays for itself by automating evidence collection — pulling configuration from AWS, GitHub, your identity provider, and so on, mapping it to the criteria, and monitoring continuously. What it does not do is build the controls: you still have to consolidate identity, centralize logging, enforce change management, and manage vendor risk. Buy the platform to automate the evidence, not to substitute for the engineering.

Template: "SOC 2 readiness roadmap" — branded PDF at https://kaansystems.com/templates/soc2-for-startups-complete-guide.pdf

Source: https://kaansystems.com/library/soc2-for-startups-complete-guide · Work with Kaan Systems: https://kaansystems.com/contact