4.1: What a SOC 2 Actually Says

What a SOC 2 Actually Says

Lesson 1.6 left you with a rule: read the exceptions. This lesson is the rest of the manual.

First, the thing sales pages get wrong on purpose: “SOC 2 certified” is not a thing. A SOC 2 is an attestation — a CPA firm examined the vendor’s controls and issued an opinion. Nobody certifies anything, there is no pass/fail, and two clean SOC 2 reports can describe wildly different levels of actual security. The report is evidence, not a verdict. Your job is to read the evidence.

Type I vs. Type II — the first filter

A Type I says the controls were designed sensibly on one particular day. A Type II says the controls actually operated over a period — usually six to twelve months — and an auditor tested them. A vendor offering only a Type I is telling you their program is young. That’s not disqualifying for a startup tool holding low-stakes data; it is disqualifying for anyone touching production or customer PII. Ask when the Type II lands, and get it in the contract.

The four things worth reading

A SOC 2 report is long because most of it is boilerplate. Skip the auditor’s opinion letter formalities, skip the management assertion, skim the system description. Spend your time on:

1. Scope. SOC 2 covers up to five Trust Services Criteria — Security is mandatory; Availability, Confidentiality, Processing Integrity, and Privacy are opt-in. A vendor storing your customer data whose report covers Security only has scoped out the questions you care about. Also check which product was audited. Companies routinely attest the mature flagship and quietly exclude the two-year-old product you’re actually buying.

2. The exceptions. In the testing section, the auditor lists controls that failed testing and how management responded. This is the only place in the report where something went wrong and got written down. One or two exceptions with credible remediation is a normal, honest report. Zero exceptions across two hundred controls means either an exceptional program or a gentle auditor — and one of those is more common than the other.

3. Carve-outs. Most vendors run on AWS, GCP, or Azure and use the “carve-out method”: the cloud provider’s controls are excluded and assumed covered by the provider’s own reports. Fine. But watch for carve-outs of things that aren’t hyperscalers — a carved-out data processor or an offshore support subcontractor is a vendor of your vendor you’ve never heard of.

4. CUECs — the homework they assigned you. Every report lists Complementary User Entity Controls: things the vendor assumes you are doing, like enforcing MFA on your admin accounts, reviewing your own access lists, configuring retention. If a vendor incident traces back to a CUEC you ignored, that’s contractually your failure. Someone on your side should read this list once and confirm each item is actually true.

What a SOC 2 cannot tell you

It cannot tell you whether the vendor will be breached. Okta held current SOC 2 attestations in October 2023 when attackers compromised its support case system and stole session tokens from customer-uploaded HAR files. The attestation was not wrong — the controls in scope were operating. The breach came in anyway. A SOC 2 measures whether a program is run like a program. It does not measure the adversary.

So use it for what it’s for: a maturity filter and a source of specific questions. “Your report shows an exception on access reviews for Q3 — what changed?” is a question that gets you a real conversation. “Are you SOC 2 compliant?” gets you the deck.

The freshness check

Reports cover a period that ended before the report was issued. If the period ended nine months ago, ask for the bridge letter — a short statement that nothing material changed since. No bridge letter and a stale report is a real signal, and it costs you one email to find out.