What a SOC 2 report does not tell you
A SOC 2 on file is not the same as a third party assessed. Six things buried in the report that decide whether it actually covers your risk, and why most of them never get read.
Collecting a SOC 2 report feels like completing a step. The document arrives, it goes in the file, the checklist item closes, and the relationship is treated as diligenced for another year.
The problem is that a SOC 2 is not a pass/fail certificate. It is a long, carefully scoped auditor’s report about a defined set of systems over a defined window of time, and almost everything that determines whether it covers your risk is buried in sections most people never reach. A report can be entirely clean and still tell you nothing useful about the service you actually bought.
Here is what is in there, and why it matters.
1. The scope, which is narrower than the logo on the cover
The first thing to find is what the report actually covers. A third party with twelve products may have a SOC 2 covering three of them. The report describes a specific system boundary, and services outside that boundary were never examined.
If the report covers the flagship platform and you bought the adjacent module, you are holding an audit of something you do not use. This is not rare, and it is not usually disclosed anywhere except the system description.
2. Complementary user entity controls, which are your obligations
Buried in most reports is a section listing complementary user entity controls, or CUECs. These are controls the auditor assumed you are performing. The third party’s control environment is only effective if those assumptions hold.
A CUEC might read: the user entity is responsible for provisioning and deprovisioning its own users, or for configuring encryption on data it transmits. In other words, part of the control set was handed back to you, and if nobody on your side is doing it, the assurance the report offers is partly hollow.
This section is where a surprising amount of unmanaged risk lives, because it is written in the passive voice, sits near the back, and creates work for the reader.
3. Subservice organizations, which are your fourth parties
Almost every service provider depends on other providers. The report discloses these as subservice organizations, and it handles them one of two ways.
Under the carve-out method, the subservice organization’s controls are excluded from the audit entirely. The report tells you they exist and then explicitly does not examine them. Under the inclusive method, they are covered, which is less common.
Either way, this section is the single best source of fourth-party visibility you will get without asking. It is a list of the companies your third party depends on to deliver the service you depend on. Most programs never extract it.
4. The period covered, which has already ended
A Type II report covers a historical window, often twelve months, and that window closed before the report was issued. By the time it reaches you, it may describe controls as they operated a year ago.
This is what bridge letters are for. A bridge letter, or gap letter, is the third party asserting that nothing material changed between the end of the audit period and a more recent date. It is unaudited, it is short, and it is the third party’s own statement rather than an auditor’s opinion.
The thing to check is whether the bridge letter actually closes the gap to today, or whether it stops three months short and leaves a window nobody has covered.
5. The exceptions, and what the auditor said about them
Exceptions are the findings: instances where a control did not operate as described. Their presence is not automatically alarming, and their absence is not automatically reassuring.
What matters is which control failed, how many times, whether the third party remediated it, and whether that control has anything to do with the risk you care about. A handful of exceptions in physical access controls at a facility you never touch is very different from an exception in access revocation for the system holding your customer data.
Reading the exception and then reading the management response is the work. Counting exceptions is not.
6. What changed since last year
The most useful review of a SOC 2 is almost never the report on its own. It is the comparison against the prior year: a control that was in scope and no longer is, a new subservice organization, an exception that has now appeared twice, a change of auditor, a shortened period.
Year-over-year drift is where a deteriorating third party shows up first. It is also the analysis that almost never happens, because it requires having last year’s report at hand, and having read it.
Why this does not get done
None of this is a secret, and none of it is beyond a competent risk analyst. The obstacle is arithmetic.
A single SOC 2 runs 60 to 100 pages. A program with 200 third parties, a meaningful share of them producing an annual report, is looking at thousands of pages a year, on top of insurance certificates, financial statements, continuity plans, and the questionnaires. The analyst who reads every page of every report carefully is the analyst who does nothing else.
So the report gets skimmed for the opinion letter, filed, and treated as evidence of diligence rather than as a source of it. The exceptions are noted if they are on the first page. The CUECs are not extracted. The subservice organizations are not recorded. Next year’s report is never compared to this one.
That is the gap worth closing, and it is a reading problem before it is a risk problem. The evidence is already sitting in the file. It has just never been read.
ThirdPartyIQ reads third-party documentation in full and returns it as cited, structured findings, including the exceptions, the controls pushed back onto you, the scope gaps, the subservice organizations, and what changed since the last version. If that sounds useful for your program, get in touch.