SOC 2 Type I vs Type II: what's the difference?
Updated September 25, 2026
A SOC 2 report is an independent auditor’s opinion on a service organisation’s controls, under the AICPA’s Trust Services Criteria. It’s the report most SaaS vendors hand over during a security review, and it comes in two types. Both say the controls are designed properly; only a Type II says they actually worked, over a period of time.
Strictly speaking, SOC 2 is an attestation, not a certification: a licensed CPA firm examines the controls and issues a report with its opinion. Vendors still say “SOC 2 certified”, and trust pages list it next to certifications such as ISO 27001.
Type I: designed well, on one day
A Type I report covers the vendor’s description of its system and whether its controls are suitably designed as of a specific date. The auditor checks that the right controls exist and would meet the criteria if they operate as described. It doesn’t test whether they did.
Vendors often start with a Type I because it can be done quickly, and move to a Type II once they have run their controls long enough to be tested.
Type II: working, over a period
A Type II report covers the same ground and tests whether the controls operated effectively throughout a review period, typically between three and twelve months. The auditor samples evidence across the period (access reviews, change approvals, incident tickets) and lists any exceptions it found.
That is why buyers ask for a Type II: it’s evidence of how the vendor behaved, not just what it planned.
Side by side
| Type I | Type II | |
|---|---|---|
| What it covers | The design of the controls | Their design and how they operated |
| When | One date | A period, usually 3 to 12 months |
| Evidence of operation | None | Tested by sampling across the period |
| How buyers treat it | A starting point | The report most security reviews expect |
What to read in a vendor’s report
SOC 2 reports are restricted-use: vendors share them under an NDA, often through their trust page. When you get one, check:
- The period. When did it end? A report describes the past, so a gap of months since the period ended should be covered by a bridge letter, a statement from the vendor’s management that nothing material has changed since.
- The scope. Which products, systems and locations it covers. A report on one product says nothing about another.
- The criteria. Security is always included; availability, processing integrity, confidentiality and privacy are optional. Check the ones you rely on are in.
- The opinion and the exceptions. A qualified opinion, or exceptions in the tests, deserve a question to the vendor.
- The carve-outs. Vendors usually leave their own providers (the cloud host, for one) out of scope and list the controls they expect those providers to run. Those providers are the vendor’s subprocessors, and their own reports matter too.
- Your side. The report lists complementary user entity controls: the things you are expected to do, such as managing your own users’ access.
A SOC 3 report covers the same criteria in a short, public form, without the detail of the tests.
How long a report stays current
Vendors renew SOC 2 Type II reports every year, with each period starting where the last one ended. A report whose period ended more than a year ago is out of date, and it’s worth asking for the new one or a bridge letter.
ClauseTrail reads vendors’ trust pages and records the certifications they list, with the report dates when the page gives them. A report dated more than 15 months ago counts as lapsed, and a certification that disappears from the page alerts the teams tracking that vendor the same day.