A customer's security team emails procurement. They need "your SOC report" before the deal can close. You forward it to your engineering lead. Three days later, you're on a call with an auditor who asks which type you want — and nobody in the room knows the answer.
This happens constantly. SOC 1, SOC 2, and SOC 3 sound like levels of the same certification. They're not. They measure different things, serve different audiences, and require different scopes of work. Choosing wrong doesn't just cost you audit fees — it can delay a deal by six months or produce a report your customer won't accept.
Here is what each one actually means.
What SOC Reports Are (and What They're Not)
SOC stands for System and Organization Controls. The framework is maintained by the AICPA (American Institute of Certified Public Accountants). Unlike self-certifications or questionnaire-based assessments, SOC reports require a licensed CPA firm to audit your environment and attest to the findings.
All three report types share that audit requirement. What differs is what gets audited, who reads the report, and why.
SOC 1: Financial Controls, Not Security
SOC 1 reports are scoped to controls that affect a client's financial reporting. The governing standard is SSAE 18 (formerly SAS 70). If your product processes payroll, handles transactions that feed into a client's general ledger, or manages benefits data that shows up on financial statements, your clients' auditors may need a SOC 1 from you.
Most SaaS companies don't need a SOC 1. If your product manages project tasks, stores documents, handles customer support tickets, or runs marketing analytics — it's not sitting in anyone's financial reporting chain. When a customer asks for "your SOC report" and your product has nothing to do with finance, they almost certainly mean SOC 2.
Two subtypes: Type I attests to whether your controls are designed appropriately at a point in time. Type II tests whether those controls operated effectively over a defined period — typically six to twelve months. Type II carries substantially more weight in procurement.
SOC 2: The Default for SaaS and Cloud Companies
SOC 2 is what most technology companies need. It assesses controls across five Trust Services Criteria: Security (required), Availability, Confidentiality, Processing Integrity, and Privacy. Security is always in scope. The other four are optional — you elect which ones to include based on what your customers care about and what your product actually does.
Type I vs Type II applies here too, and the same rule holds: enterprise procurement teams want Type II. A Type I report shows your controls exist. A Type II report shows they worked. The difference matters more than most companies realize, particularly in regulated industries.
SOC 2 reports are restricted-use documents. You share them under NDA with specific customers or prospects — not publicly. The report includes the auditor's opinion, a description of your systems and controls, and the testing results. Enterprise security teams read it carefully.
One practical note: the SOC 2 audit covers a period, not just a snapshot. If you start your audit engagement in January, the auditor needs to see six to twelve months of control operation before they can issue a Type II opinion. Companies that engage an auditor before their controls are actually running consistently end up paying for two audits — or waiting out the observation period with a gap in their deal pipeline.
SOC 3: The Public Marketing Version
SOC 3 is a SOC 2 audit with the detailed report replaced by a short public summary. Same audit scope, same CPA attestation, different output. You're allowed to post it on your website and call yourself SOC 3 certified.
The limitation: it contains no control-level detail. A security team reviewing your SOC 3 learns almost nothing useful. They'll ask for the SOC 2 anyway. SOC 3 serves as a trust signal for prospects who haven't yet asked for the full report — it's marketing, not procurement.
If you've already completed a SOC 2 audit, asking your auditor for the corresponding SOC 3 summary is typically a small additional cost and worth doing. If you haven't done a SOC 2 yet, there's no reason to think about SOC 3.
Which One Your Company Actually Needs
The decision is usually straightforward:
If your product sits in a client's financial transaction or reporting chain — SOC 1, and probably SOC 2 as well.
If you're a SaaS company selling to enterprise or mid-market customers — SOC 2 Type II. This is the right answer for the overwhelming majority of technology companies.
If a customer asked for "a SOC report" without specifying — ask them. The answer is almost always SOC 2. Occasionally it's SOC 1. It is rarely SOC 3.
If you want a public trust page for your website — SOC 3, but only after you've completed SOC 2.
If you're a startup that hasn't yet sold to enterprise customers — neither, yet. Wait until a customer asks and budget for the 12-month runway from controls implementation to Type II opinion. Doing it speculatively before you need it is expensive.
Before You Call an Auditor
The audit itself is the smallest part of the work. The real time investment is getting your controls in place, documented, and operating consistently before the observation period begins. Companies that skip this step don't fail their audit — they never finish it, because the observation period restarts every time a significant gap is discovered.
Common prep mistakes: implementing controls after the audit starts, not scoping the systems in advance, and treating the SOC 2 as an IT project rather than a company-wide program. Controls in HR, vendor management, and change management are all in scope. Engineering doesn't own this alone.
The Right Starting Point
Before you engage an auditor, know your scope: which Trust Services Criteria, which systems, which observation period. If you're unsure, that scoping work is exactly where a fractional vCISO adds the most value — before you've committed to an audit engagement that may be too broad, too narrow, or simply premature.