SOC 2 gets referred to casually as a "certification" almost universally, which sets the wrong expectation for what the process actually produces and requires. This article covers what a SOC 2 report actually is, the five Trust Services Criteria it can evaluate, the Type I vs. Type II distinction that determines what the report actually demonstrates, and why SOC 2 has become close to mandatory for B2B vendor relationships even without any regulatory requirement behind it.
SOC 2 is an attestation report, not a certification
There is no governing body that "certifies" an organization as SOC 2 compliant. A SOC 2 report is an attestation report produced by an independent, licensed CPA firm, evaluating an organization's controls against the American Institute of CPAs' (AICPA) Trust Services Criteria. The output is a detailed report — including the auditor's opinion, a description of the system, and the tested controls — not a certificate or badge, though many organizations produce a summary or badge for marketing purposes once they have a report in hand.
A SOC 2 report describes an organization's own controls, not a generic checklist
Unlike a standard with a single fixed set of controls, SOC 2 evaluates the specific controls an organization designed to meet the Trust Services Criteria relevant to its own business — two organizations' SOC 2 reports can look meaningfully different in their specific control implementations while both satisfying the same criteria.
The five Trust Services Criteria
| Criterion | What it covers | Included by default? |
|---|---|---|
| Security | Protection against unauthorized access, both physical and logical — the baseline criterion for every SOC 2 report | Yes — mandatory in every SOC 2 report |
| Availability | Whether systems are available for operation and use as committed or agreed | Selected based on relevance — common for infrastructure/SaaS providers |
| Processing Integrity | Whether system processing is complete, valid, accurate, timely, and authorized | Selected based on relevance — common where data transformation or transaction processing is core to the service |
| Confidentiality | Whether information designated as confidential is protected as committed or agreed | Selected based on relevance — common where sensitive business data is handled |
| Privacy | How personal information is collected, used, retained, disclosed, and disposed of | Selected based on relevance — typically scoped narrowly to specific personal data handling |
Security is the only mandatory criterion; every SOC 2 report includes it. The other four are selected based on which are actually relevant to the service being evaluated — a company should scope its report around what its customers actually need assurance about, not add criteria simply because they sound more comprehensive.
Type I vs. Type II
Type I evaluates whether an organization's controls are designed appropriately as of a specific point in time. It answers "are the right controls in place, on paper and in configuration, as of this date?" It does not evaluate whether those controls actually operated correctly over any period.
Type II evaluates whether those same controls operated effectively over an observation period, typically ranging from three to twelve months. It answers a materially stronger question: not just "are the controls designed correctly," but "did they actually work, consistently, over time?"
Type II is what most enterprise customers actually require
Type I is often used as an initial milestone or a way to demonstrate progress quickly, but most enterprise vendor security reviews specifically require a Type II report — a Type I report demonstrates intent and design, not operational proof, and increasingly sophisticated procurement teams know the difference and ask for it directly.
Why SOC 2 has become a de facto requirement
No regulation mandates SOC 2. Yet for B2B SaaS vendors and many other technology-enabled service providers, it has become close to a prerequisite for closing enterprise deals — procurement and security review teams at larger customers routinely request a current SOC 2 Type II report before signing, treating its absence as a red flag regardless of the vendor's actual security posture. This has effectively made SOC 2 a market-driven compliance requirement: not legally mandatory, but commercially unavoidable for vendors selling into any reasonably mature enterprise buyer base. Organizations that treat it as optional often find it becomes the deciding factor in a competitive sales cycle against a competitor that already has a report in hand.
Common mistakes
- Starting the Type II observation period before controls are actually operating consistently. If a control isn't yet embedded in day-to-day operations, starting the clock early just produces exceptions and findings in the final report rather than a clean result.
- Underestimating the evidence-collection burden. Type II requires continuous evidence — access review logs, change management tickets, onboarding/offboarding records — collected consistently across the entire observation period, not assembled retroactively at the end.
- Treating the audit as a one-time project rather than an ongoing operating model. SOC 2 reports have a defined period and require renewal; the underlying controls need to keep operating (and generating evidence) continuously, not just during the run-up to an audit.
- Selecting Trust Services Criteria that don't match customer expectations. Adding Availability or Processing Integrity because it seems more thorough, without customer demand driving it, adds audit cost and scope without a corresponding sales benefit.
FAQ
How long does a SOC 2 audit take? The audit itself (the auditor's fieldwork and reporting) typically takes a few weeks to a couple of months, but that's separate from the Type II observation period it evaluates, which runs three to twelve months before the audit can even begin. Total time from a standing start to a first Type II report is commonly six months to over a year depending on control maturity going in.
Do we need a Type I before Type II? Not strictly — an organization can go straight to a Type II observation period if its controls are already operating. A Type I is useful mainly as an earlier proof point (useful for a sales cycle that can't wait for a full observation period) or to catch design gaps before committing to a longer Type II window.
Does SOC 2 apply only to software companies? No — any service organization that manages customer data or systems on a customer's behalf can pursue SOC 2, including managed service providers, data processors, and other technology-enabled service businesses, not just SaaS products specifically.