SOC 2 vendor review
Collecting a vendor's SOC 2 report is easy. Establishing whether that report supports the decision you are about to make is the actual work. Governli records what the report covers — period, scope, criteria, exceptions — and maps it to the requirements you set, so unresolved points surface before signature instead of after.
Sample assessment
Sample Vendor AB · SOC 2 Type II
- ReportEvidence found
SOC 2 Type II, 12-month audit period ending 31 March
- System description
Core platform and supporting infrastructure
The boundary in Section III determines what the opinion actually applies to.
- Relevant controls
Security and Availability criteria in scope
Confidentiality, Processing Integrity and Privacy are not covered.
- ExceptionsManual review
Two exceptions noted in access review testing
Management response describes remediation completed during the period.
- Requirement coverage
21 of 26 in-scope requirements evidenced by the report
Finding
Partial evidenceAnalytics module outside the described system
The report is current and the opinion is unqualified, but the system description covers the core platform only. The analytics module being purchased is not part of the described system.
Decision implication: Request coverage confirmation or compensating evidence
Having a SOC 2 report is not the same as being covered by one
In most procurement processes the SOC 2 question is binary: does the vendor have a report, yes or no. The answer is recorded, the PDF is filed, and the assessment moves on. That approach is defensible for a low-impact tool. It becomes a problem when the supplier holds customer data, supports a regulated process, or sits in the availability path of your own service.
A SOC 2 report is an attestation about a specific system, against selected criteria, over a defined period, produced by a CPA firm. Each of those three qualifiers can move the report away from the thing you are buying. The review question is therefore not "is there a report" but "does this report say anything about the requirements I care about — and where it does, how strong is what it says".
Seven things worth establishing from every report
These are the structural attributes that change how the rest of the document should be interpreted. Governli captures them as evidence attributes on the report and cites the relevant section, so a later reviewer does not have to reopen the PDF to check.
- 1Report type and period
Type I describes design at a point in time; Type II covers operating effectiveness over a period. Check that the period is recent and that there is no unexplained gap since the previous report — a lapsed or discontinuous period is a legitimate question, not a formality.
- 2System description and scope
The system description defines what was examined: which products, environments, regions and supporting functions. If the service you are procuring is not clearly named there, the opinion does not extend to it.
- 3Trust services criteria selected
Security is always included. Availability, Confidentiality, Processing Integrity and Privacy are optional. If your requirements concern uptime commitments or personal data handling and those criteria were not in scope, the report cannot evidence them.
- 4Opinion and any qualification
An unqualified opinion is the common case. A qualified or adverse opinion, or a disclaimer, changes how the rest of the report should be read and usually warrants specialist review.
- 5Exceptions and management responses
Type II testing frequently identifies exceptions. What matters is which control failed, how often, whether it touches something you depend on, and whether the management response describes a remediation you find credible.
- 6Sub-service organisations
Carve-out reports exclude the controls of sub-service organisations entirely; inclusive reports cover them. A carve-out means part of the delivery chain is unexamined and may need its own evidence.
- 7Complementary user entity controls
Obligations the report assumes you perform. These become requirements on your own organisation and should be assigned before the service goes live.
From control description to decision implication
A SOC 2 report is organised around the service organisation's own control set. Your assessment is organised around your requirements. Reviewing the report means moving between the two: for each requirement, which described control speaks to it, was that control tested, and did the test find anything.
Common in Type I reports and for controls added late in a Type II period. The design is described; the operation is not evidenced. That distinction belongs in the finding.
The report may evidence multi-factor authentication for internal administrators while your requirement concerns end-user SSO enforcement in the tenant you will operate.
An exception in access review or backup restoration is material if your requirement depends on it, and marginal if it does not. Relevance is judged against your requirement set, not in the abstract.
Data residency guarantees, sub-processor change notice periods and deletion timelines are contractual. They are evidenced in the DPA and the agreement, not in an attestation report.
Worked example: a valid Type II report that stops short of the service
Illustrative only — not a real customer case. A vendor supplies a SOC 2 Type II report with an unqualified opinion covering a twelve-month period ending four months ago. The system description names the vendor's original hosted platform. The product you are buying is a newer analytics module the vendor launched during that period, delivered from a separate environment.
The service processing our data must be covered by an independent attestation of security controls, with the reporting period ending no more than twelve months before assessment.
SOC 2 Type II report uploaded. Type, period, criteria in scope, opinion and two access-review exceptions recorded. System description captured, with the named in-scope services cited.
Report is current and unqualified, but scope relevance to the analytics module is not established from the system description. Recommended follow-up: ask whether the module is inside the examination boundary, and if not, when it will be included and what interim evidence exists for that environment.
The report is retained as strong evidence for the platform requirements it does cover. The specific requirement stays open, so the approver sees an explicit unresolved item rather than a satisfied checkbox — and can accept the residual risk deliberately if the module is low impact.
What the review produces
- Report attributes recorded as structured evidence
- Requirement-level mapping with citations to report sections
- Evidence strength: Found, Partial, Missing, Manual review
- Exceptions and CUECs surfaced as reviewable items
- Recommended follow-up questions for the vendor
- Decision Snapshot and exportable Decision Package
Analysis supports the reviewer; it does not replace them. Findings are reviewed by a person, and the terminal decision passes through a separate reviewer and approver.
Where SOC 2 fits next to other evidence
SOC 2 evidences how named controls performed over a period. ISO 27001 certification evidences that a governed management system was independently assessed — different questions, frequently both worth asking, as SOC 2 vs ISO 27001 sets out. Contractual and data protection obligations are evidenced through the DPA, and where your concern is a specific control area, a vendor security assessment is the narrower instrument. All of it can sit inside one vendor due diligence assessment against a single requirement catalogue — see Requirements-to-Evidence Mapping or browse all solutions.
Governli does not perform SOC 2 examinations, does not issue or validate a CPA firm's opinion, and does not verify controls beyond the evidence supplied to it. Where a report carries a qualified opinion or an exception you cannot interpret, specialist review is the right next step.
SOC 2 review FAQ
Is a SOC 2 report enough to approve a vendor?+
It depends entirely on what you need the vendor to satisfy. A SOC 2 report is strong evidence about a defined system, over a defined period, against the criteria the vendor selected. It says nothing about contractual terms, data transfer mechanisms, retention or exit provisions, and it may not cover the exact service you are buying. Treat it as one substantial evidence source inside a wider requirement set rather than as an approval in itself.
What is the practical difference between Type I and Type II for a buyer?+
A Type I report describes controls and the auditor's opinion on their design at a single point in time. A Type II report additionally covers operating effectiveness across a period, usually six to twelve months, and reports exceptions found during testing. For a supplier that will hold your data on an ongoing basis, a Type II with a recent, continuous period is normally the more useful evidence — and the exceptions section is often the most informative part of it.
What are complementary user entity controls and why do they matter?+
CUECs are the controls the report assumes you operate on your side for the vendor's controls to be effective — for example provisioning and de-provisioning your own users, configuring SSO correctly or managing your encryption keys. They are frequently skipped during review, which quietly transfers assumed responsibility to your organisation. Recording them as requirements against your own team makes that responsibility visible before signature.
Does Governli audit vendors or issue SOC 2 reports?+
No. SOC 2 examinations are performed by licensed CPA firms. Governli reviews the report the vendor supplies, records its structural attributes and maps its content to the requirements you have configured, so a reviewer can see what the report supports and what it leaves open.