Reviewing a vendor's SOC 2 report means checking that it covers the service you use, for a recent period, with an opinion you can rely on, and then taking on the work it hands back to you. Confirm the report type and that the review period ended recently. Read the auditor's opinion and note any qualification. Check that the system described is the service you buy and that the Trust Services Criteria in scope match your risk. Read every exception and management's response. Map the complementary user entity controls to owners in your organization. List the subservice organizations and decide which reports you need from them too. Record the review and any follow-up, and diary the next one.
A SOC 2 report is easy to file and hard to read. Vendor risk teams often check that one exists and move on, which leaves the parts of the report that matter most, the exceptions and the controls it hands back to you, unread.
Step 1: Check the basics
- Report type: a Type 2 tests operation over a period; a Type 1 only tests design at a date.
- Review period: when it ended, and whether you need a bridge letter for the time since.
- Issue date and the audit firm that signed the report.
- The auditor's opinion: unqualified, qualified, adverse or a disclaimer, and what any qualification is about.
The guide to bridge letters covers what to check when the period ended a while ago.
Step 2: Check the scope
Read the system description and confirm it covers the product, environment and regions you use. A vendor with several products may have a report on one of them. Then look at which Trust Services Criteria categories are in scope. Security is always included; if you rely on the vendor's uptime, Availability matters, and if you send confidential data, Confidentiality does.
Step 3: Read the exceptions
In the tests and results section, find every control where exceptions were noted. For each one, ask how severe it is, whether it touches the part of the service you rely on, whether several exceptions point to the same weakness, and whether management's response explains the cause and the fix. The guide to SOC 2 exceptions and opinions covers how to read them.
Step 4: Take on the complementary user entity controls
The report lists controls the vendor assumes you operate, such as managing your users' access or protecting the API keys it issues you. The auditor did not test them, and the vendor's controls only meet the criteria if you run them. Assign each one an owner and confirm it runs. The guide to CUECs and subservice organizations covers them in detail.
Step 5: Look through to subservice organizations
Most reports carve out the vendor's own critical providers, such as its cloud host. Their controls were not tested in this report. Decide which ones matter for your data, and ask the vendor how it monitors them, or ask for their reports directly where it matters.
Step 6: Record the review and follow up
| Record | Why |
|---|---|
| Report details: type, period, auditor, opinion | Shows which report you relied on and when |
| Scope fit and any gaps | Shows whether the report covers what you use |
| Exceptions and your assessment of each | Shows you read them and decided they were acceptable, or not |
| CUEC owners | Shows the controls handed back to you are being operated |
| Follow-up questions and answers | Closes the gaps the report left open |
| Next review date | Usually when the next report is due |
These records are also evidence for your own audits: vendor monitoring is part of the SOC 2 common criteria, and under DORA and NIS2 it is part of managing third-party and supply-chain risk. The third-party risk management solution shows how Noru keeps vendor reports and reviews in one place.