Building for SOC 2 Compliance from Day One

Most early-stage SaaS companies treat SOC 2 as something they will deal with later — when a customer demands it. By then, they are paying a consulting firm $40,000 to retrofit compliance onto a system that was never designed for it. The same compliance posture, built in from the start, costs a fraction of that.

SOC 2 is an attestation framework, not a prescriptive standard. The American Institute of CPAs (AICPA) Trust Services Criteria define what you need to achieve, not how. This flexibility is a feature — you can satisfy the criteria in ways that fit your architecture — but it also means there is no cookbook. This guide is the cookbook.

The Five Trust Services Criteria

SOC 2 audits can cover up to five criteria: Security (required), Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory for any SOC 2 report. Most SaaS companies pursuing their first SOC 2 add Availability and Confidentiality. Processing Integrity is relevant for data processing services. Privacy (based on AICPA GAPP) is complex and usually deferred to a second audit cycle.

Infrastructure Controls That Need Day-One Architecture

Some SOC 2 controls are easy to retrofit. Documenting a policy takes an afternoon. Others require architectural decisions that are expensive to change after the fact. Know which is which before you start building.

Processes That Need to Be Running Before the Audit Period

Evidence collection for SOC 2 Type II requires showing consistent execution of controls over time, typically 6-12 months. Processes that need to be running before your audit period starts include vulnerability management (regular scanning and documented remediation), security incident response (a documented process with evidence of execution), access reviews (quarterly review and certification of who has access to what), change management (evidence that code changes were reviewed and approved), and vendor risk management (documented assessment of your critical vendors).

The auditor will ask for evidence from across the audit period, not just from the date of the audit. A vulnerability scan run the week before the audit covers nothing. A vulnerability scan run monthly for twelve months with documented remediation of findings is the evidence the auditor needs.

Type I vs Type II: The Practical Difference

SOC 2 Type I attests that controls are suitably designed at a point in time. Type II attests that controls operated effectively over a period (typically 6-12 months). Most enterprise customers require Type II. Type I is a stepping stone — useful to show progress to prospects while you accumulate Type II evidence. Do not let vendors or consultants sell you on Type I as a destination.

SOC 2 Type I vs Type II: What the Difference Actually Means

SOC 2 Type I is a point-in-time assessment: an auditor evaluates whether your controls are designed appropriately as of a single date. Type II covers a period of time — typically 6 to 12 months — and tests whether those controls actually operated effectively throughout the period. Type I can be completed faster (often 2-3 months from readiness), but most enterprise procurement teams want Type II before signing material contracts. A Type I report is a useful milestone and sales asset, but plan for Type II from the start.

The practical implication: to get a Type II report, you need to run your controls consistently for the entire observation period. That means your access review process, your encryption key rotation, your incident response runbooks — all of it must actually operate, be documented, and leave evidence. Auditors do not accept "we planned to do this"; they need logs, tickets, and screenshots proving the control ran on schedule.

Implementation Checklist: The Five Trust Service Criteria

SOC 2 is built around five Trust Service Criteria (TSC): Security (CC), Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P). Security is mandatory. The others are optional but commonly added — Availability and Confidentiality are standard additions for SaaS companies. Each criterion maps to a set of controls your organisation must implement and evidence.

Vendor management deserves particular attention. Auditors will ask for evidence that you have reviewed the security posture of services that handle customer data. At minimum, collect SOC 2 reports or security questionnaire responses from your top 10-15 vendors annually. For AI services that may process customer data, this includes LLM API providers — a concern covered in depth in our HIPAA AI engineering guide.

Automation Platforms: Vanta vs Drata vs Secureframe

Compliance automation platforms have become the standard approach for startup SOC 2 programs. They connect to your infrastructure (AWS, GCP, GitHub, Okta, etc.), continuously test controls, and generate the evidence collection that auditors need. The three dominant players differ in integration depth, audit firm relationships, and pricing model.

All three platforms reduce the manual evidence-collection burden by 60-80%. The real time sink is not the platform — it is the policy writing, the control implementation (actually setting up MFA, access reviews, encryption), and the personnel security work (background checks, security training, signed acceptable use policies). Plan for 2-3 months of engineering and operations effort before an auditor steps in regardless of which platform you use.

Realistic Timeline to Certification

Cost Breakdown for Startups

The numbers are real. A seed-stage startup with 10 engineers, AWS infrastructure, and a 6-month observation period should budget $40K-60K all-in for a first Type II report. The cost drops significantly for subsequent annual audits — the platform is already set up, controls are running, and auditors spend less time on design evaluation. For teams managing multiple compliance frameworks simultaneously, the AI governance and NIST RMF guide covers how SOC 2 intersects with emerging AI-specific frameworks.

Continuous Compliance in Practice

SOC 2 compliance is not a one-time event — it is an ongoing operational practice. After achieving Type II certification, you must maintain compliance continuously for your next audit period. This means: access reviews every quarter (verify that terminated employees have been deprovisioned, that access levels match job roles), vulnerability scans on a regular cadence (monthly at minimum), evidence collection for every control (automated through Vanta/Drata or manual through a shared drive), and incident response drills annually.

The most common audit finding in renewal audits: access reviews that did not happen on schedule. An employee left 3 months ago and their AWS access was never revoked. A contractor's VPN access was never terminated. These findings are easy to prevent with automated access review tools (Cerby, Opal, custom scripts that compare HR records against identity provider groups) but surprisingly common in teams that treat compliance as a project rather than a process. For teams also building for HIPAA compliance, the access control requirements overlap significantly — a single access management process can satisfy both frameworks.

Common Mistakes That Delay Certification

The three most common mistakes that delay SOC 2 certification: starting evidence collection too late (you need 3-6 months of continuous compliance evidence for Type II — starting evidence collection 2 months before the audit is too late), over-scoping (including every system in scope when only customer-facing systems need to be covered — more scope means more controls, more evidence, more audit cost), and treating compliance as a project instead of a process (building controls for the audit and then letting them decay until the next audit cycle).

The over-scoping mistake deserves emphasis. Your SOC 2 scope should include only the systems that store, process, or transmit customer data. Internal tools, development environments, and employee-facing systems typically do not need to be in scope. A smaller scope means fewer controls, less evidence, faster audits, and lower cost. Work with your auditor to define the boundary precisely before starting implementation. For teams that also need to handle health data, the HIPAA compliance requirements have similar scoping decisions around what constitutes a covered system.