SOC 2 for Startups: A Practical Guide to Your First Audit

SOC 2 is not a certification. It is an attestation report: a licensed CPA firm examines your controls against the AICPA Trust Services Criteria and issues an opinion on them. Most startups scope only the Security category (the Common Criteria, CC1 to CC9) for their first report, use a Type 1 to unblock deals, then run a Type 2 observation window in which the auditor tests that the controls actually operated. The engineering work is evidence: MFA, access reviews, reviewed changes, logging, backups and incident response that you can prove from system records rather than screenshots taken the week before fieldwork.

Key takeaways

• There are two report types. Type 1 tests control design on a single date; Type 2 tests design and operating effectiveness over a period. Buyers who know the difference want Type 2.
• Security is the only required category. Add Availability, Confidentiality, Processing Integrity or Privacy only when your contracts make promises in those areas.
• The auditor tests populations and samples. Any production change, joiner or leaver in the window can be picked, so a control that lapses for a month shows up as an exception.
• Write policies that describe what you already do, then make your tooling enforce them. Aspirational policies are the most common source of exceptions.
• Compliance automation platforms collect evidence well. They do not decide your scope, run your risk assessment, or make a weak control strong.
• A clean report is a by-product of operating well. Teams that treat SOC 2 as a one-off project relearn it every year.

What a SOC 2 report actually is

SOC 2 is defined by the AICPA. You, the service organization, describe your system and its controls; an independent CPA firm examines them against the Trust Services Criteria and gives an opinion. The report is restricted use, shared with customers and prospects under NDA. If you want something to publish on your website, that is a SOC 3: a short general-use report built on the same examination. If your buyers are mostly outside North America, they may ask for ISO 27001 instead, and the control work largely carries over.

Enterprise security reviewers know exactly where to look in a SOC 2 report:

Two parts of the system description trip up first-time startups.

Subservice organizations. Your cloud provider, payment processor and other critical vendors are subservice organizations. Most startups use the carve-out method: those vendors' controls are excluded from your report, and you rely on their own SOC reports, which you are expected to review.

Complementary controls. Complementary subservice organization controls (CSOCs) are controls you assume your vendors operate. Complementary user entity controls (CUECs) are controls your customers must operate for yours to work, such as managing their own users' access to your product. List them honestly. Customers read them.

Type 1 vs Type 2

The common sequence: get ready, obtain a Type 1, start the Type 2 window on the same day, and use a shorter first window to reach a Type 2 sooner. After that, each annual report covers the twelve months following the previous one, so there is never a gap. Customers who ask between reports get a bridge letter from you covering the period since the last report ended.

The Trust Services Criteria

There are five categories. Security is mandatory and consists of the Common Criteria, which every report includes:

CC1 to CC5 follow the COSO internal control framework, which is why they read like corporate governance. CC6 to CC8 are where engineering lives.

The optional categories:

For a first report, Security alone or Security plus Availability is the usual choice for B2B SaaS. Privacy is substantial extra work that overlaps with GDPR obligations you may already handle elsewhere. Add it when a customer asks, not by default.

Step 1: Scope and gap assessment

Scope is the system that delivers the service your customers buy: production infrastructure, the code and pipelines that change it, the people who operate it, and the corporate systems that grant access to it (identity provider, laptops, source control). A staging environment can be out of scope if it holds no customer data and cannot deploy to production. If it can deploy, it is in.

Then compare what you do today against the criteria. The gap register becomes your project plan:

- id: GAP-07
  criteria: CC6 (logical access)
  finding: Production database access is granted ad hoc in the cloud console, with no record of approval.
  fix: Grant through an IdP group managed in Terraform; request via a ticket template; review quarterly.
  owner: platform-lead
  due: 2026-11-15
  evidence_after_fix: IdP group export, Terraform history, review ticket

Gaps startups usually find: no written risk assessment, access granted outside any process, leavers whose accounts linger in SaaS tools, no vendor inventory, an incident response plan never exercised, backups never restored, laptops without enforced disk encryption, and security training that never happened.

Step 2: Controls that produce their own evidence

The best SOC 2 controls are the ones where tooling enforces the rule and logs prove it. These are the controls auditors sample most heavily, and how to make each one self-evidencing:

Manage these controls as code wherever you can. Branch protection, for example, should not be a setting an admin toggles in a UI:

resource "github_branch_protection" "main" {
  for_each      = toset(var.production_repos)
  repository_id = each.value
  pattern       = "main"
 
  enforce_admins          = true
  required_linear_history = true
 
  required_pull_request_reviews {
    required_approving_review_count = 1
    dismiss_stale_reviews           = true
    require_code_owner_reviews      = true
  }
 
  required_status_checks {
    strict   = true
    contexts = ["ci/test", "ci/security-scan"]
  }
}

With protection defined in infrastructure as code, the history of this file is your CC8 evidence that nobody quietly switched it off.

For access reviews, export memberships and give each owner something reviewable rather than a console screenshot. This script snapshots who can reach production at the start of each quarter's review: GitHub organization admins, the production deploy team, and everyone assigned the production admin permission set in AWS IAM Identity Center.

#!/usr/bin/env bash
set -euo pipefail
Q="$(date +%Y)-Q$(( ($(date +%-m) - 1) / 3 + 1 ))"
mkdir -p "evidence/$Q"
 
gh api "orgs/acme/members?role=admin" --paginate --jq '.[].login' \
  > "evidence/$Q/github-org-admins.txt"
gh api "orgs/acme/teams/prod-deployers/members" --paginate --jq '.[].login' \
  > "evidence/$Q/github-prod-deployers.txt"
 
aws sso-admin list-account-assignments \
  --instance-arn "$SSO_INSTANCE_ARN" \
  --account-id "$PROD_ACCOUNT_ID" \
  --permission-set-arn "$PROD_ADMIN_PS_ARN" \
  --output json > "evidence/$Q/aws-prod-admin-assignments.json"
 
echo "Snapshot written to evidence/$Q. Open a review ticket per file and assign it to the system owner."

The review itself is a human decision. The owner marks each person keep or remove, the removals happen, and the ticket records both. An access review in which nothing ever changes is a pattern auditors notice.

Step 3: Policies that match reality

You need policies covering the criteria in scope: information security, access control, change management, incident response, risk assessment, vendor management, data classification and retention, business continuity and disaster recovery, acceptable use, and encryption. Templates are a fine starting point. Shipping them unedited is not.

Auditors test what the policy says. If your change management policy requires approval from a change advisory board and you are an eight-person team merging pull requests, every sampled change is an exception. Write "every production change is made through a pull request approved by an engineer other than the author and deployed by CI", then make the tooling enforce exactly that.

Two habits keep policies honest: store them in Git as Markdown so changes are reviewed and versioned, and review each one at least yearly with a named owner.

Step 4: Tools and the auditor

Compliance automation platforms such as Vanta, Drata, Secureframe and Sprinto connect to your cloud accounts, identity provider, HR system and source control, run continuous checks, collect evidence, and host policies and training. For a startup they save real time, and many auditors work inside them directly. Their limits: they check configuration, not whether a control is meaningful; they cannot tell whether an access review was a real review; and a green dashboard says nothing about whether your scope and system description are right.

The auditor must be a licensed CPA firm. Choose one that audits companies of your size and stack, and ask:

• How do they sample, and which populations will they request?
• Do they work inside your compliance platform, or run their own evidence requests?
• Who will do the fieldwork, and have they audited cloud-native companies?
• Can they deliver a Type 1 now and start the Type 2 window straight after?

Independence matters. The firm that issues your report cannot also design and run your controls. A readiness assessment from the auditor is normally fine; building your control environment for you is not.

Step 5: The observation window

Once the Type 2 window opens, the job is boring consistency. Every control must operate every time it should, for the whole window, and leave a record:

• Every joiner has an approved access request. Every leaver is deprovisioned within the time your policy states.
• Every production change has a reviewed pull request. Emergency changes follow the emergency procedure, including the review after the fact.
• Every quarterly access review happens in its quarter, not in a batch at the end.
• Critical and high vulnerabilities are fixed within your stated timelines or carry a documented exception.
• The incident response tabletop, the restore test and the vendor reviews happen when the calendar says.

At the end of the window the auditor requests populations ("all production deployments between 1 March and 31 August"), selects samples and asks for evidence for each. If evidence comes from systems of record, that is an export. If it lives in people's heads, it is a month of archaeology.

What goes wrong in production

The exceptions in real SOC 2 reports are rarely exotic. They come from the gap between how a team says it works and how it works at 2am.

• Emergency changes with no follow-up. Someone hotfixes production during an incident, bypassing review. That is fine if your policy has an emergency path, and an exception if nobody reviews the change afterwards. Put the review of emergency changes into the incident template.
• Leavers who linger. The identity provider account is disabled, but the person still has a personal access token in GitHub, an API key in a monitoring tool, or a local account in a SaaS app outside SSO. Deprovisioning must cover tokens and non-SSO apps.
• Shared and break-glass accounts. A shared admin login to a vendor console makes access attributable to nobody. Use individual accounts, and keep break-glass credentials sealed, logged and rotated after every use.
• Scope drift. A new service launches mid-window on infrastructure nobody added to scope, or real customer data is copied into staging to debug something. Both silently change your system.
• Aspirational policies. A policy that promises weekly log reviews when nobody reviews logs weekly. Promise only what you will do every week of the window.
• Pen test findings left open. Most auditors and buyers expect an annual penetration test, and a report full of unremediated highs does more harm than good. Our penetration testing guide covers scoping a test that finds real issues.
• Vendor reviews that never happen. The inventory lists your cloud provider, but nobody read its SOC 2 report or checked the complementary controls it assigns to you.

Frequently Asked Questions

How long does SOC 2 take for a startup?

It depends mostly on how many gaps you have and on the length of your observation window. A Type 1 can follow as soon as controls are designed and in place. A Type 2 adds an observation window, commonly three to twelve months, and startups often choose a shorter first window to get a report sooner. Plan for the readiness work, plus the window, plus a few weeks for the auditor to issue the report.

What is the difference between SOC 2 Type 1 and Type 2?

A Type 1 report assesses whether controls are suitably designed and in place on a single date. A Type 2 report assesses whether those controls operated effectively throughout a period, by testing samples across the window. Enterprise buyers generally want a Type 2, and a Type 1 mainly bridges the gap while the first window runs.

Which SOC 2 Trust Services Criteria are required?

Only Security, made up of the Common Criteria CC1 to CC9, is required in every SOC 2 report. Availability, Confidentiality, Processing Integrity and Privacy are optional. Include an optional category when your contracts or product commitments make promises in that area, such as uptime SLAs for Availability.

Is SOC 2 a certification?

No. SOC 2 is an attestation: a licensed CPA firm examines your controls and issues a report containing its opinion. There is no SOC 2 certificate, and the report is restricted use, so it is shared with customers under NDA. ISO 27001, by contrast, is a certification.

Do you need a penetration test for SOC 2?

The Trust Services Criteria do not explicitly require a penetration test, but they do require you to identify and evaluate vulnerabilities, and most auditors and enterprise customers expect an annual external test. Treat it as expected. Evidence that you remediated what the test found matters as much as the test itself.

Need help getting SOC 2 ready?

We build and run production systems, so we come at SOC 2 from the engineering side: controls enforced by your tooling, evidence pulled from systems of record, and a scope that matches how your platform really works. If we built it, we are on the pager for it, which is why our controls hold up through the observation window.

• Cybersecurity and compliance
• Startup tech consulting
• Talk to an engineer