SOC 2 Type I vs Type II: which report do you actually need?

Every SOC 2 report is one of two types, and the difference isn't cosmetic. It changes how long the audit takes, how much assurance it gives your customers, and, often, whether a deal clears procurement. If you're new to SOC 2, start with what a SOC 2 actually is; if you already know that, here's how to choose between Type I and Type II.

The one-line difference

• A Type I report answers: are the controls suitably designed as of a specific date? It's a snapshot.
• A Type II report answers: were the controls suitably designed and operating effectively throughout a period? It's a film.

A Type I looks at your controls on the day the auditor examines them. A Type II watches them run over months and tests whether they actually did what they're supposed to, every time, across the whole window.

Why the period matters

The value of a Type II is the observation period. Anyone can have a clean-looking control on the day of an audit. What a customer really wants to know is whether your access reviews happened every quarter, whether every production change went through review, whether alerts were actually triggered and actioned, month after month. A Type II tests a sample of evidence across the period and reports what the auditor found, including any exceptions.

That observation window is typically 3, 6, 9 or 12 months. A first Type II is often run over three to six months to get a report out sooner; mature vendors then settle into an annual, twelve-month cycle, so they always hold a current report covering an unbroken period.

Which one do buyers want?

In practice, enterprise and regulated buyers expect a Type II. A Type I tells them your controls are well designed; it says nothing about whether you operate them. For anything beyond an early-stage vendor review, that gap is usually a dealbreaker, and a security team will ask when your Type II is coming.

A Type I still has its uses:

• It's faster, because there's no observation period to wait out, so it can unblock a specific deal quickly.
• It's a reasonable first step for a company that has just stood up its controls and wants third-party validation of the design while a Type II period runs in the background.

The pattern most teams follow is either to run a Type I and immediately begin a Type II observation period, or, increasingly, to skip straight to a short-window Type II. What you should avoid is treating a Type I as the destination. It rarely satisfies the buyers who are asking for SOC 2 in the first place.

Keeping a report "current": the bridge letter

A SOC 2 Type II covers a fixed period that ends on a specific date. Between that end date and your next report, there's a gap, and a prospect doing diligence in that window will notice. A bridge letter (sometimes called a gap letter) covers it: a short statement that no material changes to your controls have occurred since the report period ended.

Two things to know about bridge letters:

• They are signed by you, the vendor, not the auditor, so they carry less weight than the report itself.
• They should cover no more than about three months. A bridge letter stretching to cover half a year is a sign the audit cycle has slipped, and sharp buyers read it that way.

The clean answer to the gap problem isn't a longer bridge letter; it's an annual audit cadence so a fresh report is always close behind the last one.

The real work is between audits

Whichever type you choose, the report only reflects what your controls actually did. A Type II especially rewards organisations that run their controls consistently all year, because the auditor is sampling the whole period, not the week you spent preparing. That's the difference between a scramble before each audit and a system that's always audit-ready.

ResiliencePilot keeps your controls and evidence current continuously, so a Type II observation period is a byproduct of how you operate rather than a project. See the SOC 2 solution, the wider SOC 2 hub, or book a demo.