When a prospect asks for your SOC 2 report, they almost always mean Type II. Understanding why — and what the path to getting there looks like — saves you from building a compliance programme aimed at the wrong target.
The core difference
A Type I report says: your controls are designed correctly as of a specific date. An auditor reviewed your documentation and concluded that the controls you described are reasonable and appropriately designed.
A Type II report says: your controls operated effectively over a defined period — typically six to twelve months. An auditor reviewed evidence of the controls actually running, not just described.
Enterprise customers trust Type II because it covers actual operation. Type I is a design review. Type II is an operations review.
Do you need Type I first?
Not necessarily. Many organisations go straight to Type II. The argument for starting with Type I is that it forces you to get your documentation in order before the observation period begins — so you're not spending twelve months collecting evidence against poorly-designed controls.
The argument against: Type I adds three to five months and a separate audit fee. If your controls are already in place and operating, you can start the Type II observation window immediately and use the auditor's readiness assessment to fill gaps.
What the observation period looks like in practice
During the observation period, evidence must be collected for every control in scope. This means:
- Access reviews need to happen on your defined schedule and be documented
- Change management approvals need to exist in your ticketing system
- Vulnerability scans need to run and findings need to be tracked
- Security training needs completion records, not just completion
A GRC platform with continuous evidence collection makes this manageable. Without one, teams typically spend the last six weeks before the audit pulling evidence from a dozen different systems.
Common reasons Type II reports get qualified
An auditor issues a qualified opinion when they find evidence that a control failed to operate as described during the period. Common causes:
- Access reviews skipped for one or two quarters
- A terminated employee's access not removed within the defined SLA
- Patch management falling behind defined timelines
- Vendor assessments not completed on schedule
These aren't catastrophic failures. But they show up in the report, and customers notice.
The practical path
If your target is an enterprise customer requiring SOC 2 Type II:
- Map your in-scope systems and define which Trust Service Criteria apply
- Document your control set — what each control does and the evidence that proves it
- Set up continuous evidence collection before the observation window opens
- Run a readiness assessment (internally or with your auditor) at month three
- Address gaps before the end of the period
Six to twelve months of clean operation, properly evidenced, produces a clean report.