There is a moment in almost every enterprise sales cycle where a security questionnaire lands in someone's inbox and one line stops everything cold: "Please provide your SOC 2 Type II report." Not Type I. Type II. Suddenly the difference between those two words, which can feel like a technicality, becomes a deal.
Both reports look similar on the surface. Same auditor. Same AICPA framework. Same official letterhead. But what they are actually certifying is quite different, and understanding that gap changes how a compliance programme gets built, communicated, and ultimately trusted.
What SOC 2 Is Actually Measuring
SOC 2 is not a product security test. It is not a penetration test. It is an audit of how a service organisation manages customer data, the processes, policies, and controls that govern who has access to what, how incidents get handled, how changes get approved, and whether the whole thing holds together under real operating conditions.
The framework uses five Trust Services Criteria: Security (mandatory for everyone), Availability, Processing Integrity, Confidentiality, and Privacy. An organisation picks the criteria relevant to its business, a licensed CPA firm audits against them, and the resulting report becomes the document that buyers, legal teams, and procurement committees read.
Type I: The Starting Line
A SOC 2 Type I is a snapshot. On a specific date, an auditor reviews the controls that have been put in place, the policies, the configurations, the documented procedures, and gives an opinion on one thing: are these controls designed well enough to achieve their stated purpose?
Getting controls designed correctly takes real work. Writing an incident response plan that actually maps to how the team operates, setting up access controls that reflect least privilege, configuring logging that captures what it needs to, none of this happens automatically. A Type I audit forces that design discipline.
"A Type I shows the right systems are in place. A Type II shows they have been running, without anyone watching."
But the auditor is not checking whether any of it worked in practice. There is no observation window. No sampling of whether access reviews actually happened last quarter. The report is honest about this, it says "as of [date]" right in the title. For early-stage companies, this is still a real milestone. Some buyers will accept a Type I as a good-faith starting point, especially paired with a clear roadmap toward Type II.
Type II: Proof Over Time
A SOC 2 Type II covers a period, usually six to twelve months. The auditor is not just asking whether controls are designed correctly. They are asking whether those controls actually ran, as designed, across the entire observation window.
This means pulling evidence. The auditor samples logs to verify that access reviews happened on schedule. They pull incident tickets to confirm the response process was followed. They check that multi-factor authentication was enforced during the periods the policy says it should have been. The report reflects what the security function did, not just what it was supposed to do.
Controls fail in practice all the time, not because they were badly designed, but because they were never consistently run. A quarterly access review that gets skipped twice. An alerting rule that nobody ever triaged. Type II audits exist precisely to surface this gap. That is why enterprise buyers ask for them specifically.
At a Glance: How They Compare
| What's Being Compared | Type I | Type II |
|---|---|---|
| What the auditor evaluates | Whether controls are well designed | Whether controls actually worked over time |
| Audit window | A single point in time | 6–12 month observation period |
| Evidence reviewed | Policies, configs, walkthroughs | Logs, samples, tickets, access records |
| Time to achieve | Weeks to a few months | 6+ months before audit can begin |
| Buyer trust signal | Readiness and structure | Proven, sustained execution |
| Typical use case | Early-stage milestone; initial deals | Enterprise sales; procurement requirements |
The Journey from One to the Other
Define the scope
Decide which systems, processes, and Trust Services Criteria the audit will cover. Scope shapes everything, a tighter scope moves faster; a broader one carries more weight with specific buyers.
Build and document controls
Design the policies and procedures, access management, encryption standards, incident response, vendor oversight. This is the work that produces a Type I report.
Run the controls, consistently
The observation period begins. Controls need to operate as designed, and evidence needs to accumulate. This phase is where programmes either build a strong foundation or quietly drift.
Go through fieldwork
A licensed CPA firm samples the evidence, interviews the team, and validates that controls ran throughout the observation window, not just in the weeks before the audit.
Issue the report, then maintain it
The Type II report is shared with customers under NDA. Annual re-audits keep the certification current and show that the programme is ongoing, not a one-time effort.
One Thing Worth Getting Right Early
Scope decisions matter more than most people expect. A SOC 2 Type II report covering Security alone is a very different document from one covering Security, Availability, and Confidentiality, and buyers in certain industries will notice. Healthcare, fintech, and government-adjacent buyers often have strong opinions about which criteria they expect to see covered. Getting scope right from the beginning means fewer surprises later.
"Compliance built around real risk ages well. Compliance built around checkbox anxiety tends to show its cracks at exactly the wrong moment."
Frequently Asked Questions
Type I is a snapshot, it evaluates whether controls are well designed as of a specific date. Type II covers a 6–12 month observation window and evaluates whether those controls actually operated as designed throughout that period. Type II is what enterprise buyers require.
At minimum 6 months from when the observation period begins, plus time for fieldwork and reporting. Most companies take 9–14 months end-to-end from starting control implementation to receiving the final Type II report.
Yes, and it is the recommended path. Type I forces the design discipline needed to build controls correctly. It creates exactly the foundation required to start an observation period for Type II. Many early-stage buyers will accept Type I as a starting point, especially paired with a clear roadmap to Type II.
Security (mandatory for all), Availability, Processing Integrity, Confidentiality, and Privacy. Organisations choose which criteria are relevant to their business. Security is always required. Healthcare SaaS platforms often add Availability and Confidentiality; payment processors typically add Processing Integrity.
Type II demonstrates a track record, documented evidence that controls ran week after week, not just on the day an auditor arrived. Enterprise procurement teams treat it as proof of sustained operational security, not just a design exercise. It reduces the need to take security posture on faith.