Most startups approach SOC 2 wrong. They treat it as a one-time checklist to complete right before an audit instead of a system to maintain year-round. The result: a frantic scramble, expensive last-minute work, and often a failed audit in the first attempt.
This checklist isn't about memorizing the 100+ SOC 2 controls. It's about understanding exactly what you need to build, document, and maintain to pass a SOC 2 Type II audit with a clean opinion.
The 5 Trust Service Criteria (TSC)
SOC 2 is built around five Trust Service Criteria. Your auditor will test against the ones you include in your scope.
Most startups start with Security only. Adding Availability makes sense if you offer an SLA. Privacy requires a formal privacy notice and is the most complex criterion. Start narrow and expand if customers require it.
Security Criteria Checklist
These controls are required for every SOC 2 audit. Build them before your audit window starts.
Availability Criteria Checklist
If you're adding Availability to your scope (common for SaaS platforms), here's what you need:
What to Do First
Start with your technology stack. Map out every system that touches customer data or critical operations. For each system, answer: Who has access? How is access granted and revoked? What logs exist?
Then map your policies to your actual practices. Auditors aren't just reading your documents — they're testing whether what you wrote matches what you actually do. The most common audit failure isn't missing controls — it's controls that exist on paper but aren't enforced in practice.
Common Mistakes Startups Make
1. Copying policies word-for-word from templates
Auditors can tell. Generic policies that don't match your actual infrastructure get flagged immediately. Write policies that describe how your team actually operates.
2. Trying to do everything right before the audit
SOC 2 Type II requires evidence that controls operated consistently over 6-12 months. You can't manufacture that history in a sprint. Compliance is a continuous practice.
3. Ignoring vendor risk
Your vendors are in scope. If you're using AWS, Okta, GitHub, Datadog — your auditor will expect vendor risk assessments and evidence of monitoring. Don't treat this as an afterthought.
4. Forgetting the people side
Background checks, security awareness training, acceptable use policies — these are controls too. Your engineering team isn't exempt from compliance requirements.
Timeline: How Long Does This Actually Take?
If you're starting from scratch with a small team (under 20 people):
- 3-4 months: Build and implement controls. Document policies. Set up monitoring.
- 6-12 months: Operate controls continuously (this is the Type II observation period).
- 2-3 months: Audit readiness assessment, auditor selection, audit execution.
Total: 12-18 months from start to clean opinion. For companies that already have strong security practices, the readiness phase can be shorter — but don't underestimate the observation period. You can't skip it.