Planning guide · Updated 2026-08-28 · 14 min

How to start SOC 2: a practical path from customer request to audit

A decision-first guide for founders and security teams: define the commercial goal, choose scope, assign owners, close control gaps, collect evidence, and enter the audit without manufacturing certainty.

01

Start with the business trigger, not a tool

Write down who is asking for SOC 2, what they need to buy, and whether they require a Type I or Type II report. A procurement request, a strategic enterprise deal, and a board-led security program create different deadlines. Record the target contract date and work backward; do not let a software demo define the program.

02

Choose a defensible scope

Map the services, infrastructure, people, data flows, and locations that support the product customers rely on. The system description and control environment need coherent boundaries. Scope that is artificially narrow may not answer a customer’s diligence question; scope that is unnecessarily broad creates evidence and remediation work.

  • Name the in-scope product and customer promise.
  • List cloud accounts, identity systems, repositories, ticketing, HR, endpoints, vendors, and production data stores.
  • Identify subprocessors and complementary user-entity controls.
  • Document exclusions and why they do not affect the service commitment.
03

Pick criteria from actual commitments

Security is part of every SOC 2 examination. Availability, confidentiality, processing integrity, and privacy should be added when contracts, product behavior, or customer expectations make them relevant—not because more criteria look impressive. Each added category expands what must be described, operated, and evidenced.

04

Assign control owners before writing policies

A policy without an operator is not a control. For every expected control, identify the accountable owner, operating cadence, evidence artifact, and escalation path. Engineering commonly owns change management and vulnerability remediation; People owns onboarding and offboarding inputs; Security or Compliance coordinates the evidence system and exceptions.

05

Run readiness as a gap-closing project

Test whether controls are both designed and operating. Sample access reviews, terminated-user removals, production changes, incidents, backups, vendor reviews, risk treatment, and security training. Record each gap with an owner and due date. Avoid backdating approvals or creating evidence after the fact.

06

Select the auditor independently

The CPA firm is the independent examiner. Compare licensing, relevant industry experience, engagement-team continuity, audit approach, platform compatibility, proposed timing, change-order terms, and how exceptions are handled. A compliance platform can facilitate evidence, but it cannot issue the SOC 2 report unless the relevant audit work is performed by an independent qualified firm.

07

Enter the examination with a stable evidence rhythm

Before the audit window, confirm control language, sample expectations, owner availability, evidence-retention conventions, and the request process. Keep an exception log. For Type II, controls need to operate throughout the observation period; a clean screenshot at the end does not prove consistent operation.

SOC 1SOC 2SOC 3Type IType IIAudit readinessTrust centersVendor riskSecurity evidenceProcurement