SOC 2 has become the table-stakes compliance certification for B2B SaaS. Enterprise procurement teams ask for it before signing contracts of any meaningful size, security questionnaires reference it as the baseline, and the absence of a clean SOC 2 report stalls deals during legal review. This guide explains the framework's structure, the practical steps to a clean Type II report, and the tooling decisions that separate a six-month sprint from an eighteen-month grind.
Unlike HIPAA or PCI DSS, SOC 2 is not a regulatory requirement — it is a market requirement, driven by buyers who need to demonstrate to their own auditors that their vendors meet a defined security bar. The framework is governed by the AICPA and audited by licensed CPA firms.
A SOC 2 report is not a pass/fail certification; it is an opinion document describing the control environment and any exceptions noted during testing. The "AICPA Trust Services Criteria" publication is explicit on this point: "the auditor's opinion expresses whether management's description fairly presents the system and whether the controls were designed and operated effectively." Buyers read the report — not just the cover letter — which means the design and operation of controls matter as much as the auditor's signature.
SOC 2 is structured around five Trust Services Criteria (TSC), defined in TSP Section 100. Security is the only mandatory criterion (sometimes called the Common Criteria) and forms the baseline for every SOC 2 engagement.
The Security TSC contains nine series of criteria (CC1 through CC9) covering control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. Every SOC 2 report must address all nine series.
The most-tested area at growth-stage SaaS audits. SSO with MFA, role-based access control, formal access reviews, terminated-employee de-provisioning workflows. Most exceptions found in SOC 2 audits trace back to access management gaps.
Monitoring, anomaly detection, incident response. The criterion that most often pulls observability tooling into the audit scope; Datadog dashboards, PagerDuty rotations, and runbooks become evidence.
Production change controls, code review, segregation of duties between development and deployment. The CI/CD pipeline becomes audit-relevant the day the criterion is in scope.
Most B2B SaaS scopes Security plus Availability for the Type II. Adding Confidentiality is common; the others are situational.
The two report types differ in observation period.
Documents control design as of a single date. Useful for early-stage companies that need an attestation for a specific procurement deal but cannot yet show a track record. Typical timeline: 3-4 months from kickoff to report.
Documents control operation across a 3-12 month observation period. The format enterprise buyers actually want. Most first-time audits run a 6-month observation; mature programs run 12-month observations aligned to the fiscal calendar.
Companies often run a Type I in year one to demonstrate the program exists, then transition to Type II in year two with a longer observation window. The Type I work directly accelerates the Type II by establishing the control environment and remediation history.
The path from "we do not have a SOC 2" to a clean Type II report follows a recognizable arc.
Gap analysis against the Common Criteria. Identify missing controls, document exceptions, and produce a remediation roadmap. The output is a ranked backlog with effort estimates.
The work happens here. Common implementations:
Controls run continuously. Evidence accumulates automatically (CloudTrail logs, Datadog dashboards, ticket history). The observation window is where automation pays off; manual evidence collection across a 6-month period consumes weeks of engineering time.
The auditor samples evidence, tests controls, requests interviews, and writes the report. Typical fieldwork runs 4-6 weeks for a mid-sized SaaS.
SOC 2 is one program; the cloud infrastructure, identity stack, and engineering practice that the controls run on top of are another. Our team brings both — compliance practitioners who run the audit program, and SREs who build the infrastructure the controls depend on. We map your existing controls to the Common Criteria, design the gaps, run the implementation, and produce the audit-ready evidence package. We pair well with GRC platforms (continuous controls verification, automated evidence collection) when you want the tooling, and we run with our team alone when the platform overhead does not justify itself.
A practical guide to SOC 2 for B2B SaaS companies. Covers the five Trust Services Criteria, Type I vs Type II decision-making, control implementation patterns, and what auditors actually look for during fieldwork.