A vendor sends its SOC 2 report. It runs to dozens of pages, most of them tables. Your procurement process needs an answer this week: is the vendor's security acceptable? The temptation is to check that the report exists, that the opinion looks clean, and move on.
That misses most of what the report can tell you. A clean opinion on a system that does not include the product you are buying is worth little. So is a report whose period ended long ago, or whose assurance depends on controls you were meant to operate and do not.
This article gives an order for reading a SOC 2 report in under an hour, what to look for in each section, and what to record so your own auditor can see the review happened.
Know the layout before you start
Most SOC 2 reports follow a similar structure, though the order and section names vary by firm:
The independent service auditor's report. The opinion, its scope, and any modifications.
Management's assertion. The vendor's statement about its description and controls.
The system description. Written by the vendor: services, boundaries, components, commitments, subservice organizations, and user entity controls.
Criteria, controls, tests, and results. In a Type II report, each control, what the auditor did to test it, and whether exceptions were found.
Other information. Optional material from the vendor, such as responses to exceptions. The auditor's opinion does not cover it.
Read them out of order. The sequence below puts the deciding questions first.
Step 1: check the opinion and its basics
Start with the auditor's report. You are looking for five facts:
Type. A Type I covers design at a point in time. A Type II covers operating effectiveness over a period. SOC 2 Type I vs Type II covers why the difference matters.
Period or date. For a Type II, when the period started and ended. Note how long ago it ended. If the gap is long, ask for a bridge letter or the date of the next report.
Categories. Security is always included. Check whether availability, confidentiality, processing integrity, or privacy are included, and whether that matches what you need from this vendor.
The issuing firm. SOC 2 examinations are performed by licensed CPA firms. If the report does not clearly come from one, ask.
Whether the opinion is modified. An unmodified opinion is the clean result. Look for words such as "except for", "adverse", or "do not express an opinion", and for a separate paragraph explaining the basis for the modification.
A modified opinion is not an automatic rejection, but it needs a conversation. Read the basis paragraph, identify which criteria are affected, and decide whether they matter for what this vendor does for you.
Step 2: confirm the report covers what you are buying
Open the system description and find the services covered. Then answer three questions:
Is the product you are buying in scope? Vendors with several products sometimes scope only one. Match the name on your order form to the name in the description.
Are the right locations and regions covered? If you need your data in a particular region, check that the infrastructure described includes it.
Does the description match what the vendor told you? If the questionnaire answers describe a control that the report does not mention, ask about it.
This step catches the most consequential problem in vendor reports: a clean opinion about the wrong system.
Step 3: find the subservice organizations
The description lists subservice organizations, and states whether each one is carved out or included. For a carve-out, the vendor's opinion relies on controls at that provider which its auditor did not test.
Decide whether that matters to you. For a large cloud provider, you may already hold its report, or be able to get it. For a smaller subservice organization that handles your data, you may want its report too, or more information about how the vendor monitors it. Carve-out vs inclusive explains both methods.
Step 4: map the user entity controls to your own
Find the list of complementary user entity controls. These are controls the vendor's design assumes you operate. The opinion's conclusions depend on them.
For each one, name the control on your side that meets it: your access reviews, your identity provider settings, your offboarding process. Where you have no matching control, decide whether to build one, accept the risk, or raise it with the vendor. Complementary user entity controls, explained covers this mapping in more detail.
This step is easy to skip, and it is the one with the most direct consequence for you. A gap here is a weakness you created, not one the vendor did.
Step 5: read the test results for the controls you care about
In a Type II report, the testing section lists each control, the tests performed, and the results. Most entries will say no exceptions were noted.
Do not read every row. Start from your concerns. If the vendor will hold sensitive data, read the access control and encryption entries. If it deploys code into your environment, read change management. Then search the section for every exception and read those in full, including any management response.
For each exception, ask:
Which control failed, and how often?
Does it relate to a risk you care about for this vendor?
Is there a management response, and does it describe a fix with a date?
Treat management responses as the vendor's account. They are usually outside the auditor's opinion. An exception is not necessarily a reason to reject a vendor. A pattern of exceptions in the same area, or one in a control central to your risk, is a reason to ask more.
What the report cannot tell you
A SOC 2 report is strong evidence about a defined system over a defined period. It is silent on several things a buyer often needs:
Anything outside scope. Products, regions, or entities not in the description are not covered, however similar they look.
Anything after the period. The report says nothing about the months since it ended.
Specific settings. The criteria do not name technologies or frequencies, so the report shows the vendor's own choices, not whether they meet a standard you hold.
Your contract. The report does not cover terms you negotiated, such as a deletion timeline or breach notice period. Check those against the vendor's commitments separately.
Fill those gaps with targeted questions, the vendor's data processing agreement, or a penetration test summary, rather than a full questionnaire.
Step 6: record your conclusion
Your own auditor may test your vendor management under CC9.2. The review needs to leave a record, not only a decision. A useful record includes:
- Not done:
Vendor, report type, period, categories, and issuing firm
- Not done:
Opinion: unmodified or modified, and the basis if modified
- Not done:
Whether the services you use are in scope
- Not done:
Subservice organizations relied on, and how you assessed them
- Not done:
User entity controls mapped to your controls, with any gaps
- Not done:
Exceptions relevant to you, and your assessment of each
- Not done:
Follow-up questions sent, and answers received
- Not done:
Your conclusion, the reviewer's name, the date, and the next review date
A vendor due diligence checklist puts the SOC 2 review in the context of the wider assessment. The SOC 2 framework page covers the surrounding terms.
How TrustLynce helps
TrustLynce's third-party risk module records each vendor review against the vendor, including the report, your conclusion, and the reassessment date, so the next review starts from the last one.