At some point in the life of any SaaS company, a large customer sends over a security questionnaire. Buried in page 7 is a question: "Do you have a SOC 2 report?" If you have to Google what that means, you are in the right place. This guide explains SOC 2 without the accounting jargon, the CPA firm sales pitch, or the twenty-slide deck that does not actually answer anything.
SOC 2 is an audit report, produced by a CPA firm, that tells your customers: "A third party examined this company's security controls and here is what they found."
That is it. It is not a certification like ISO 27001. You do not "pass" SOC 2 and receive a badge. You receive a report, and that report either describes controls that look good, or it describes controls with exceptions (meaning gaps an auditor found). Customers read the report -- or more often, their security teams skim the executive summary -- to decide whether to trust you with their data.
Think of SOC 2 like a restaurant health inspection. The health inspector (CPA firm) comes in, looks at everything, and issues a report. The report does not say "this restaurant passed" -- it says "here is what we found." A clean report with no major issues is what you want. Customers are the people who read the inspection report before deciding to eat there.
SOC 2 comes from the American Institute of CPAs (AICPA), the same organization behind generally accepted accounting principles. In the mid-2000s, as SaaS companies started holding more and more sensitive customer data in the cloud, enterprise buyers needed a way to evaluate vendor security without sending their own security teams to audit every vendor they used. The AICPA created SOC 2 as a standardized framework for exactly that purpose.
The "SOC" in SOC 2 stands for System and Organization Controls. There is also a SOC 1 (focused on financial reporting controls) and a SOC 3 (a public summary version of SOC 2). Almost everyone who asks you about SOC 2 means the full SOC 2 report, not the SOC 3 summary.
The analogy people use: Type I is like a restaurant inspector showing up and checking that the kitchen has a thermometer. Type II is like the inspector reviewing six months of temperature logs to verify that someone actually used it every day. Which one would you trust more when choosing a restaurant?
Most serious enterprise buyers want Type II. Type I is sometimes accepted as an interim report while a company is building toward Type II, but if a big deal is on the line and procurement asks for your SOC 2, they almost certainly mean Type II.
SOC 2 is built around five Trust Services Criteria (TSC). Only one is required. The other four are in scope only if they apply to your services.
The system is protected against unauthorized access, both logical and physical. This is the backbone of every SOC 2 report. Covers access controls, encryption, monitoring, incident response, change management, vendor risk, and more. Organized into nine categories (CC1-CC9).
The system is available for operation as agreed. If your customers have uptime SLAs or your service is business-critical, this criterion is relevant. Covers monitoring, incident response, disaster recovery, and capacity planning.
System processing is complete, valid, accurate, timely, and authorized. Most relevant for companies that process financial transactions, healthcare data, or other data where correctness of processing is critical.
Information designated as confidential is protected as committed. Relevant if you handle trade secrets, business strategies, financial projections, or other information customers expect you to keep confidential.
Personal information is collected, used, retained, and disclosed in conformity with commitments. Relevant if you handle personal data -- particularly if GDPR, CCPA, or similar privacy regulations apply to your customers.
Most companies start with Security only and add criteria as customers demand them. "Security + Availability" is a common combination for SaaS companies with uptime commitments. Adding all five at once is unusual and probably overkill for an initial SOC 2.
SOC 2 is not required by law in most situations (unlike HIPAA or PCI-DSS, which are legally mandated for specific industries). It is a market expectation. The question is not "am I legally required to have SOC 2?" but "will I lose deals without it?"
SOC 2 is most relevant for:
If you are a B2B company and your customers are asking you to fill out security questionnaires, or if deals are stalling in "security review," SOC 2 is almost certainly the answer they are looking for.
The chicken-and-egg trap: Many founders wait until a customer requires SOC 2 before starting the process -- then discover it takes 9-18 months and lose the deal anyway. The right time to start SOC 2 is about 12 months before your customers will start asking for it. If you are starting to close deals over $50K ACV, start thinking about SOC 2 now.
| Phase | What Happens | Typical Duration |
|---|---|---|
| Readiness Assessment | Gap analysis against the TSC -- identify what controls you have vs. what you need | 4-8 weeks |
| Remediation | Implement missing controls, write missing policies, collect initial evidence | 2-4 months |
| Audit Preparation | Organize evidence, brief the auditor on your environment | 2-4 weeks |
| Type I Audit | Auditor reviews controls as of a specific date | 2-4 weeks |
| Observation Period (Type II) | Controls must operate continuously while the auditor observes | 6-12 months |
| Type II Fieldwork + Report | Auditor reviews evidence from the observation period and issues the report | 4-8 weeks |
Realistic total time from "we should probably do SOC 2" to receiving a Type II report: 9-18 months for a company starting with low security maturity. Companies with good security hygiene already in place can compress that to 6-9 months.
This varies widely, but rough market ranges (2026):
Smaller startups often use compliance automation platforms to reduce audit prep time and cost. The platforms do not replace the CPA firm audit, but they automate evidence collection, policy management, and control monitoring -- which reduces the billable hours the auditor spends doing fieldwork.
One thing people consistently underestimate: The cost of the audit itself is often not the biggest expense. The biggest cost is internal employee time -- your engineering team implementing controls, your security team writing policies, and your operations team managing evidence collection. Budget for that before you budget for the auditor.
A few common misconceptions worth clearing up before they waste your time:
The smartest first move is a readiness assessment: evaluating your current controls against the SOC 2 Trust Services Criteria to see how big the gap is. That gap analysis tells you what to build, in what order, before the auditor shows up.
The Security criterion alone (CC1-CC9) covers 33 individual control activities across nine categories. Working through each one systematically -- and collecting the evidence that proves they are operating -- is the real work of SOC 2 preparation.
A structured Word document covering all 33 Common Criteria controls (CC1-CC9) with evidence requirements, policy library checklist, and a gap remediation tracker. Start your readiness review without building the spreadsheet from scratch.
Get the Checklist → $29All 110 NIST SP 800-171 practices organized by domain. Free PDF, instant access.