A SOC 2 Type 2 is one of the most requested documents in B2B procurement and one of the least understood. Buyers ask for it because a checklist told them to; vendors produce it because deals stall without it. Both sides would make better decisions if the report stopped being a black box. So let's open it.
The acronym fog is the first obstacle, so we'll clear it once and move on. SOC stands for System and Organization Controls — a reporting framework from the American Institute of CPAs (AICPA). A SOC 2 report describes a service organization's controls relevant to security and, optionally, a few related qualities. The "Type 2" part tells you how the controls were examined. That's the whole shape of it; everything below is detail.
- SOC 2 is an attestation by a licensed CPA firm — not a certification and not a pass/fail badge. The auditor reports an opinion; there is no SOC 2 "certificate."
- Type 1 tests whether controls were designed properly at a single point in time. Type 2 tests whether they actually operated over a period — usually three to twelve months.
- Only the Security criterion is mandatory. The other four are included only if the organization chose them, so two reports are rarely comparable on scope.
- The value is in the detail, not the cover: read the opinion, the period, the exceptions, and the complementary user entity controls.
01 / DefinitionWhat SOC 2 is — and what it isn't
A SOC 2 is an attestation engagement performed by a licensed CPA firm under the AICPA's attestation standards (SSAE 18). The auditor examines a service organization's controls and issues a report containing a formal opinion on them. That framing matters because of what it rules out.
It is not a certification. Nobody "passes" SOC 2 and nobody is issued a certificate — that's an ISO 27001 concept, not a SOC 2 one. A vendor who says "we are SOC 2 certified" is using the wrong word, and the slip is worth noticing: it often signals the report has been treated as a logo rather than read.
It is not a fixed checklist either. Unlike a framework with a prescribed control list, SOC 2 lets the organization define its own controls to meet a set of broad criteria. The auditor then tests whether those self-defined controls are suitable and effective. Two organizations meeting the same criterion can do so with very different controls — which is exactly why you read the report rather than trust the acronym.
02 / ScopeThe five Trust Services Criteria
SOC 2 is built on the AICPA's Trust Services Criteria. There are five, and a report covers one or more of them. The single most useful fact about SOC 2 scope: only the first is required.
- Security (the "common criteria") — protection of systems and data against unauthorized access. Mandatory in every SOC 2. If a report exists, Security is in it.
- Availability — whether the system is available for operation and use as committed. Relevant when you depend on uptime.
- Processing Integrity — whether processing is complete, valid, accurate, and timely. Matters most for systems that compute or transact on your behalf.
- Confidentiality — protection of information designated as confidential (think contracts, IP, business data).
- Privacy — how personal information is collected, used, retained, and disposed of, against the organization's privacy commitments.
Because four of the five are optional, "they have a SOC 2" tells you almost nothing about scope on its own. A report covering only Security is common and entirely legitimate — but if you're relying on a vendor for uptime or handing them confidential data, you want to see those criteria explicitly in scope, not assume them.
Two vendors can both hold a clean SOC 2 Type 2 and have audited completely different things. The criteria they selected are where you find out.
03 / Type 1 vs Type 2Design versus operating effectiveness
This is the distinction the name turns on, and it's simpler than it sounds. Both types examine the same controls against the same criteria. They differ on the question they answer.
| SOC 2 Type 1 | SOC 2 Type 2 | |
|---|---|---|
| Question answered | Were the controls suitably designed? | Did the controls operate effectively? |
| Time frame | A single point in time ("as of" a date) | A period of time ("for the period" — typically 3–12 months) |
| Evidence | Control descriptions and design review | Samples and testing across the whole window |
| What it proves | The controls exist and are built right today | The controls were actually run, consistently, over time |
| Typical use | A first report, or a fast answer for a deal | The report buyers and regulators actually want |
A Type 1 is a photograph; a Type 2 is a time-lapse. A control can look immaculate on paper (clean Type 1) and still fail in practice — access reviews that never happen, alerts nobody reads. Type 2 is harder to earn precisely because it catches that gap, which is why it carries more weight. When someone asks for "a SOC 2," they almost always mean Type 2.
04 / The windowWhat the observation period means
A Type 2 report covers a defined observation period — the window over which the auditor tested operating effectiveness. You'll see it stated as something like "for the period October 1 to September 30." That date range is not decoration; it bounds the entire report.
Two practical consequences follow. First, anything that happened after the period close isn't in the report — a control change, an incident, or a newly shipped feature last month is simply outside what was observed. Second, the report ages. A Type 2 with a period that ended ten months ago is stale for a current decision, and most buyers expect a report covering the trailing twelve months. When there's a gap between the period end and today, that's what a bridge letter is for — covered below.
05 / AnatomyWhat's actually inside the report
A SOC 2 report has a consistent structure. Knowing the four sections turns a 60-page PDF into something you can navigate in minutes.
- Section I — Independent auditor's report (the opinion). The CPA firm's formal conclusion. This is the first thing to read, and the opinion type is what matters (see below).
- Section II — Management's assertion. The service organization's own written statement about its system and controls — what they are claiming, which the auditor then tests.
- Section III — System description. Management's account of the system in scope: the services, infrastructure, people, data, and crucially the boundaries. This is where you learn what was actually examined.
- Section IV — Controls, tests, and results. The detailed matrix: each control, the auditor's test of it, and the result — including any exceptions (instances where a control didn't operate as intended).
Two cross-cutting elements live inside these sections and deserve their own attention:
- Complementary user entity controls (CUECs) — controls the report assumes you, the customer, are performing. The vendor's assurance depends on them. They are the report's fine print and often where your real obligations hide.
- Subservice organizations — the third parties the vendor relies on (cloud hosts, sub-processors), and whether their controls are carved out (excluded) or included. Carve-out is the norm, which means those providers' controls are not in the report you're holding.
About that opinion: it isn't always a clean bill of health. An unqualified opinion is the clean one. A qualified opinion flags one or more meaningful problems while the rest holds. Adverse and disclaimer opinions are serious and rare. A report can be unqualified and still contain exceptions in Section IV — so the opinion and the exceptions are two separate reads, not one.
06 / Reading oneHow to review a report you've received
When a vendor sends you their SOC 2, you don't need to read all 60 pages. You need to hit six points in order and stop when something doesn't add up.
- The opinion. Section I — is it unqualified? If qualified, adverse, or disclaimed, find out why before anything else.
- Type and period. Is it Type 2, and does the observation window cover a recent, relevant stretch (ideally the trailing 12 months)?
- Scope. Which Trust Services Criteria are included, and does the system description cover the product and data you actually use?
- Exceptions. Section IV — were there control failures, and how did management respond? A few well-handled exceptions are normal; a pattern is a signal.
- CUECs. What is the report assuming you do on your side — and are you actually doing it?
- Subservice orgs. Who's carved out, and do you need their report too (especially the cloud host or any sub-processor touching regulated data)?
07 / Bridge lettersCovering the gap to today
Because a Type 2 period always ends in the past, there's usually a gap between the report's close date and the day you review it. A bridge letter (also called a gap letter) closes that interval. It's a short statement from the vendor's management affirming that no material changes to the control environment occurred between the report's end date and the bridge letter's date.
Two things to keep in mind. A bridge letter is written by the vendor, not the auditor — it carries no independent testing, only management's assurance. And it has a short shelf life: it's meant to span a few months, not to substitute for a fresh report indefinitely. If a vendor is bridging a year-old report, ask when the next examination period closes.
08 / Your own reportThe timeline and cost reality for the mid-market
If you're the one earning a SOC 2 rather than reviewing one, set expectations early — leadership and sales tend to assume it's faster than it is. The work runs in stages: define scope and criteria, run a readiness assessment to find gaps, remediate, then sit through the observation period before the auditor can test it.
The observation period is the part you can't compress. For a Type 2, the auditor needs months of evidence that controls operated — so even a well-run program is typically looking at six to twelve months from kickoff to a first Type 2 report, with cost scaling by scope, number of criteria, and how much remediation is needed. Many organizations take a sensible shortcut: earn a Type 1 first to satisfy deals quickly, then convert to Type 2 once a full observation window has elapsed.
09 / PitfallsThe mistakes that recur on both sides
The same handful of errors show up whether you're issuing or evaluating a report:
- Treating it as pass/fail. There's no passing grade — there's an opinion and a set of results to interpret. "They have one" is not a conclusion.
- Skipping the exceptions. An unqualified opinion can still sit on top of control failures in Section IV. Read them.
- Ignoring CUECs. If the report assumes you enforce access controls you haven't enforced, the vendor's assurance doesn't transfer to you.
- Assuming all five criteria. Most reports are narrower than buyers assume. Confirm the scope rather than inferring it.
- Mistaking scope for the whole company. The report covers a defined system, not every product the vendor sells — a gap that matters especially for newer features and AI capabilities.
The "scope is not the whole company" pitfall is exactly where AI features tend to fall out of a SOC 2 — shipped after the window, running on a carved-out model provider, or in a separate pipeline the system description never folds in. If a vendor's AI is part of your decision, treat it as its own diligence track. We walk through how in Your Vendor Has a SOC 2 — But Is Their AI Covered?
10 / Bottom lineA SOC 2 rewards reading, not collecting
A SOC 2 Type 2 is a genuinely useful artifact — independent, structured, and grounded in evidence rather than promises. Its value just doesn't live on the cover page. Know that it's an attestation and not a certificate, check which criteria are in scope, read the opinion and the exceptions, mind the CUECs and the carve-outs, and watch the period dates. Do that, and a stack of SOC 2 PDFs stops being a compliance formality and becomes what it was meant to be: real signal about who you're trusting with your systems and your data.