How to Actually Read a Vendor's SOC 2 Report

A vendor sends you their SOC 2 report. It is ninety pages, you skim the first few, see an unqualified opinion, and mark the vendor approved.

You have skipped the parts that matter. The report's value is almost entirely in four sections that most reviewers never reach, and one of them lists things you are required to do for the vendor's controls to work at all.

This post is how to read one in about thirty minutes and come away knowing something. For whoever handles vendor review, which is often whoever is free.

Type I or Type II, and the period

First page. Type I says the controls existed on a single date. Type II says they operated over a period, and only Type II tells you anything about whether the controls actually work.

Then find the observation period. A Type II covering three months is much weaker than one covering twelve, and vendors issuing their first report often start with three. That is normal and worth noting.

Then check when the period ended. A report whose period ended eleven months ago tells you about last year. Ask for a bridge letter, which is a short statement from the vendor covering the gap between the report's end date and today, asserting no material changes. It is not audited, and its absence when asked is informative.

The scope section, which is where the exclusions live

This is the section to read closely, and it is usually skipped because it reads like boilerplate.

Which systems are in scope. Vendors frequently scope the report to their main product and exclude the specific service you are buying, or exclude a region, or exclude a recently acquired platform. A report is only evidence about what it covers.

Which Trust Services Criteria. Security is mandatory. Availability, Confidentiality, Processing Integrity and Privacy are optional, and vendors select them. If you care about uptime commitments and the report does not include Availability, the report says nothing about uptime. If you are handing them personal data and Privacy is not included, the same applies.

Check both against what you are actually buying. The mismatch between scope and use is the most common real finding in vendor review, and it takes two minutes.

The auditor's opinion, and what a qualification means

Usually a page or two, near the front.

Unqualified means the auditor found the controls suitably designed and operating effectively. This is the normal, good result.

Qualified means they found something. This is not automatically disqualifying, and it is the single most informative word in the document. Read what the qualification is about, and judge it on relevance: a qualification about a control in a product you will not use matters less than one about access management.

A qualified opinion honestly disclosed, with remediation described, is often a better signal than a clean report from a vendor who scoped their way around the problem.

Section 4, the testing table, where the exceptions are

This is the long section everyone skips, and it is the substance.

For each control the auditor lists what they tested, how, and the result. Scan the results column for exceptions, deviations, or any language other than "no exceptions noted". Most reports have some. They are footnotes to the reader who only looked at the opinion, and they are the actual findings.

What to look for specifically:

• Exceptions in access management: onboarding, offboarding, access reviews. These are the controls whose failure most often precedes an incident.
• Exceptions in change management or deployment.
• Any exception the vendor describes as remediated, and when. "Remediated in month eleven of a twelve-month period" means it was broken for most of the period being attested.
• Controls tested by inquiry alone. "Inquired of management" means the auditor asked and was told. It is much weaker than inspection or observation, and a report heavy with inquiry-only testing is a weaker report regardless of its opinion.

Complementary user entity controls, the part nobody reads

Somewhere near the back is a list of controls the vendor assumes you will perform. Configure SSO. Manage your own user accounts. Set appropriate permissions. Enable MFA on your side. Review your own audit logs.

The vendor's controls are only effective if these are in place, and the report explicitly says so. This list is the vendor telling you, on the record, where their responsibility ends.

Almost nobody reads it, which means almost nobody does the things on it. Extract it, turn it into tasks, and assign them. This is the highest-value ten minutes in the whole review, and it is the section that converts a compliance artifact into actual work that reduces risk.

There is usually an adjacent list of subservice organisations, the vendors your vendor depends on, and whether the report carves them out or includes them. A carve-out means those controls are not covered here at all, and you may want their reports too.

A thirty-minute procedure

1. Type I or II, period covered, period end date. Ask for a bridge letter if stale.
2. Scope: systems and criteria. Compare against what you are buying.
3. Opinion. If qualified, read why.
4. Section 4: scan the results column for exceptions. Read every one.
5. Extract the complementary user entity controls into a task list.
6. Note the subservice organisations and whether they are carved out.
7. Write half a page: what it covers, what it does not, what you must do, what you are accepting.

That last artifact is what you keep. In two years somebody will ask why this vendor was approved, and a half-page memo answers it.

The concession

A SOC 2 report is a point-in-time attestation by an auditor the vendor selected and paid, against controls the vendor largely defined. It does not mean the vendor is secure, and several breached companies held clean reports at the time.

Read as a security guarantee it is nearly worthless. Read as what it is, evidence that a process exists, was examined by a third party, and has documented boundaries, it is useful, and the exceptions and the user entity controls are where the useful part lives.

So do not treat it as a gate that a clean report passes. Treat it as a document that tells you which questions to ask next.

The implication

The reviewer who reads only the opinion learns one bit of information. The reviewer who reads the scope, the exceptions and the user entity controls learns what the vendor actually covers, where their controls failed during the period, and what work has just been assigned to your team.

That is thirty minutes, and it is the difference between a compliance checkbox and a vendor review.