SOC 2 Type I vs Type II: What's the Difference?

What a SOC 2 report actually is

A SOC 2 is an independent auditor's report on how well a service organization's controls meet the AICPA Trust Services Criteria — security, and optionally availability, processing integrity, confidentiality, and privacy. It is the single most-requested artifact in a vendor security review, because it is third-party evidence rather than the vendor's own say-so.

One framing correction worth making up front: SOC 2 is a report, not a certificate. There is no pass/fail badge — there is an auditor's opinion, a defined scope, a time element, and a list of any exceptions. The whole skill of using a SOC 2 in a vendor review is reading those four things, and the first fork is whether you are holding a Type I or a Type II.

Type I — controls at a point in time

A SOC 2 Type I attests that a vendor's controls are suitably designed as of a single date. The auditor looks at the control environment on that day and gives an opinion on whether the controls, as described, are designed to meet the criteria.

What it proves: the vendor has thought through the right controls and they exist on paper. What it does NOT prove: that those controls actually operate, or that they held up over any length of time. A Type I is a snapshot — useful, but it is a photo of the controls, not a recording of them working.

Type II — controls over a period

A SOC 2 Type II attests to both the design AND the operating effectiveness of the controls over a period — typically 3 to 12 months. The auditor doesn't just confirm the controls exist; they test samples of evidence across the window to confirm the controls actually ran as intended throughout it.

This is the report that carries real assurance. A Type II says the vendor's access reviews actually happened each quarter, backups were actually tested, alerts were actually triaged — not just that a policy exists saying they should be. The longer the covered period, the stronger the signal.

The difference in one line

Type I: "these controls are designed correctly as of this date." Type II: "these controls actually operated effectively over this period." Design versus design-plus-operation; a point versus a span of time.

For a risk reviewer, the practical translation is simple — a Type II is evidence the controls work; a Type I is evidence the vendor knows what the controls should be. They are not interchangeable, and a Type I is not a smaller Type II.

Which to require from a vendor

Match the report to the risk tier and the vendor's maturity:

• Critical / high-impact vendors — require a current Type II. Operating effectiveness over time is the assurance that justifies trusting them with sensitive data or a critical process.
• A newer vendor with only a Type I — acceptable as an interim step IF they commit to a Type II on a stated timeline (their first observation window has to elapse before a Type II can exist). Record the expected date and follow up.
• Lower-impact vendors — a Type I, or even a completed questionnaire, may be proportionate. Don't demand a Type II where the risk doesn't warrant it.
• Never accept a Type I as a permanent substitute for a Type II on a vendor that matters. "They have a SOC 2" is not an answer until you know which kind, for what scope, covering what period.

How to read either report

Once you know the type, five things determine whether the report is actually reassuring:

• Period covered — for a Type II, how long is the window and how recent is it? A Type II that ended a year ago tells you little about today.
• Scope — which Trust Services Criteria, and which systems/products? Security is always in scope; a report that excludes the specific product you use, or omits availability/confidentiality where you need them, has a gap.
• The auditor's opinion — unqualified (clean) versus qualified (the auditor found something material). A qualified opinion is a flag to read closely, not necessarily a deal-breaker.
• Exceptions / deviations — the test results section lists controls that failed during the period and the vendor's response. This is the most informative part; a report with zero exceptions across a year is rare and worth a second look.
• The bridge (gap) letter — covers the time between the report's end date and now, where the vendor self-attests nothing material changed. Ask for it when the report period doesn't reach the present.

Common mistakes

Reviews tend to mishandle SOC 2 in a few repeatable ways:

• Treating "has a SOC 2" as binary — accepting the existence of a report without checking type, scope, period, or exceptions.
• Accepting a Type I and never following up for the Type II once the vendor's first observation window closes.
• Ignoring the report period — filing a Type II that expired months ago as if it were current evidence.
• Missing a scope gap — a SOC 2 that covers the vendor's corporate environment but not the product instance you actually use.
• Skimming past the exceptions section, which is exactly where the auditor tells you what didn't work.

Where SOC 2 fits in your program

A SOC 2 is not a one-time checkbox; it is dated evidence that expires. Record which report type you received, the period it covers, its scope, and any exceptions on the vendor's record — and track when the next report is due, because a Type II is only as good as its most recent window.

That expiry tracking is where SOC 2 review most often breaks down in a spreadsheet: a report quietly ages out and no one notices until an auditor asks. v3ndor's interface lets you record each vendor's evidence — report type, coverage period, and renewal date — on the vendor record and surfaces expiring attestations before they lapse, so "is their SOC 2 current?" is answerable at a glance. Request access at /request-access to see it on your own vendors.