SOC 2 for a 15-person startup: a pragmatic path

At some point an enterprise prospect asks for your SOC 2 report, and the deal stalls until you have one. If you are a 15-person company, the advice you will find online is mostly written for 500-person companies, and following it will cost you a quarter of engineering morale. Here is the path we actually run with small teams.

Start from the deal, not the framework

SOC 2 has five trust services criteria. Almost every startup only needs one: Security. Availability sometimes gets added because a customer contract demands an SLA. Skip the rest unless a signed deal specifically requires them.

Scope matters more than anything else you will decide. One product, one cloud environment, the systems that touch customer data, and nothing more. Your office wifi and your marketing site do not need to be in scope, and a good auditor will agree.

The controls you already have

A modern startup on AWS or GCP with Google Workspace, GitHub, and single sign-on already operates most of the controls SOC 2 asks about. The gap is rarely practice. It is proof.

• Code review before merge: you do this. The evidence is your branch protection settings and PR history.
• Access control: SSO groups and your cloud IAM already express it. The evidence is exports, not essays.
• Change management: your CI/CD pipeline is the control. A deploy log is better evidence than a change advisory board ever was.
• Monitoring: alerts going to a channel someone actually reads counts. Screenshots and routing rules are the evidence.

What you genuinely might be missing: a tested backup restore, an offboarding checklist that someone owns, a short incident response plan, and vendor reviews for the handful of tools that touch customer data.

Policies people will actually read

You need a small set of policies, and every one of them should describe what your team really does. We write them at one to three pages each, in plain language.

If a policy describes a process your team does not follow, you have not reduced risk. You have manufactured audit findings.

Resist the template packs with 40 documents. Auditors read the policy, then ask for evidence that you follow it. Fewer, truer policies produce a calmer audit.

A realistic timeline

For a 15-person company that starts from a typical state, the calendar looks like this:

1. Weeks 1 to 2: gap assessment and scoping. Decide criteria, systems, and audit window.
2. Weeks 3 to 8: close the gaps. Offboarding checklist, restore test, incident plan, vendor list, policy set. Most of this is a few focused days of work spread across the team.
3. Weeks 9 to 12: evidence collection dry run, then pick the observation window for a Type II or go straight to a Type I if the deal cannot wait.

A Type I report says your controls were designed properly on a date. A Type II says they operated over a period, usually three to twelve months. Enterprises increasingly want the Type II, but a Type I has unblocked plenty of deals while the Type II window runs.

Where the money actually goes

Expect three costs: the auditor, a compliance automation tool if you choose to use one, and your own time. The tools help with evidence collection, but they are optional at this size, and they do not scope your audit, write truthful policies, or fix your gaps. That judgment work is where we spend our time with clients, and it is the part that determines whether the audit is calm or chaotic.

Done pragmatically, SOC 2 at 15 people is a quarter of steady, low-drama work. Done from templates and panic, it is a year of theater. The difference is scoping and honesty, not budget.