Building something awesome.
A vendor SOC 2 report review is the process of reading a service provider's independent audit report to confirm that its controls cover the services you actually buy, operated effectively during the audit period, and leave no unmanaged gaps on your side. Most third-party risk teams collect SOC 2 reports by the hundred, yet many file them after checking only the opinion letter. This guide explains what to read, what to challenge, and how to turn a static attestation into assurance you can defend to auditors and regulators.
A SOC 2 report is an independent auditor's attestation, issued under the AICPA's SSAE 18 standard, on how a service organisation's controls meet the Trust Services Criteria for security, availability, processing integrity, confidentiality and privacy. Security is the only mandatory category; the vendor chooses which others to include, and that choice is the first thing a reviewer should notice.
For TPRM teams, the report is often the strongest piece of third-party evidence available. It replaces dozens of self-reported questionnaire answers with tested facts, and supervisors such as the OCC, EU authorities under DORA and the RBI expect firms to make use of independent assurance for critical service providers. But reliance is only defensible when someone has read the report against the actual engagement. A SOC 2 that covers a vendor's US payroll platform says nothing about the offshore support centre that handles your data.
A SOC 2 Type II report is the version most enterprises should require for critical vendors, because it tests whether controls operated effectively over a period, typically six to twelve months. A Type I report only confirms that controls were suitably designed at a single point in time.
Type I reports still have a place. They are common for young SaaS companies completing their first audit, and accepting one with a written commitment to deliver a Type II within a year is a reasonable decision for a low or moderate tier vendor. For vendors that host sensitive data, support critical business services or hold privileged access, a Type I should be treated as a gap that needs compensating evidence such as recent penetration test results, a targeted security assessment or contractual audit rights.
Check the review period dates as well. A Type II covering January to June that arrives in November already leaves five months of unassured operation.
An effective vendor SOC 2 report review follows a consistent sequence: confirm scope, read the opinion, examine exceptions, map customer responsibilities and then document a risk decision. Standardising this sequence lets analysts review a report in under an hour and makes conclusions comparable across the whole vendor portfolio.
The most common failure is reading out of order. Analysts who start with the control testing matrix lose time on tests that may not even cover the system they use. Start with the system description and confirm the services, locations, data centres and subservice organisations in scope before anything else.
Complementary user entity controls (CUECs) are the controls a vendor's auditor assumes the customer will operate for the vendor's control environment to work as described. Typical examples include reviewing user access to the vendor's platform, enforcing multi-factor authentication for your own staff and promptly removing leavers.
CUECs are where many audit findings originate. If your organisation never maps them to internal owners, the vendor's clean opinion rests on controls nobody performs. Internal auditors increasingly test this link directly: they sample CUECs from critical vendor reports and ask for evidence that the customer side was executed. Build a simple register that lists each CUEC, its internal control owner and the evidence of operation, and review it at least annually alongside the new report.
SOC 2 exceptions, bridge letters and carve-outs each signal residual risk that must be assessed rather than accepted by default. An exception means a tested control did not operate as described for at least some samples; it does not invalidate the report, but it does require a documented risk judgement.
Assess each exception for relevance to your use case, severity and the credibility of management's remediation. A failed access review on a system holding your customer data matters far more than a late policy acknowledgement. Track material exceptions as remediation items with owners and due dates, exactly as you would a questionnaire finding.
A bridge letter, sometimes called a gap letter, is the vendor's own statement that no material changes occurred between the end of the report period and today. It is a management assertion, not audit evidence, so limit how long you accept one. Carve-outs deserve equal scrutiny: when a vendor excludes its cloud host, request that subservice organisation's SOC 2 as well, because much of your fourth-party risk sits there.
A SOC 2 report is a historical snapshot, so it cannot tell you whether a vendor's control environment has changed since the auditor left. Breaches, leadership turnover, financial distress, new subprocessors and regulatory actions can all occur while a report is still considered current.
Leading TPRM programmes therefore treat the SOC 2 as one input among several. They combine report reviews with continuous vendor monitoring of external signals such as security ratings, adverse media, sanctions lists and financial health indicators, and they trigger reassessment when those signals move. The report answers whether controls were designed and operating; continuous monitoring answers whether anything is different now. Together they give risk leaders a defensible, current view of vendor assurance.
A disciplined vendor SOC 2 report review turns a document most teams merely collect into evidence they can genuinely rely on. Confirm scope first, insist on Type II reports for critical vendors, own your CUECs, treat exceptions as remediation items and close the gap between audit periods with continuous signals.
Crest helps risk, procurement and internal audit teams put this approach into practice, with AI-assisted review of assurance documents and continuous monitoring of every vendor between reports. Explore the Crest platform or schedule a demo to see evidence-backed vendor assurance in action.
Crest Perspective
Cyber risk in vendor relationships is not uniformly distributed. The vendors that represent the highest exposure are rarely those with the longest questionnaire responses — they are the ones with privileged access to production systems, those processing unstructured data at scale, and those operating in jurisdictions with limited breach notification requirements. Risk tiering that reflects actual access and data flows is more predictive than vendor size or certification status alone.
Start with the system description and scope section. Confirm the report covers the specific products, locations and data centres you use, and note any subservice organisations that are carved out. If the scope does not match your engagement, the rest of the report provides limited assurance.
A SOC 2 Type I report is usually acceptable for low or moderate risk vendors, especially young companies completing their first audit. For critical vendors it should be treated as a gap, because it only assesses control design at a single point in time. Ask for compensating evidence and a committed date for a Type II report.
A SOC 2 bridge letter is a statement from the vendor management team that no material changes to its control environment occurred between the end of the SOC 2 review period and the date of the letter. It is not audited evidence. Most organisations accept bridge letters covering roughly three to six months beyond the report period.
Complementary user entity controls, or CUECs, are controls the customer must operate for the vendor controls to be effective. Common examples are managing user access to the vendor platform and enforcing strong authentication for your own staff. Each CUEC should be mapped to an internal owner with evidence that it operates.
SOC 2 reports for critical and high-risk vendors should be reviewed every year when the new report is issued. Between reports, continuous monitoring of security, financial and adverse media signals helps detect changes the audit cannot capture. Material events such as a breach should trigger an immediate reassessment.
AI-powered TPRM, compliance automation and GRC intelligence for enterprise teams.
Request a Demo →Ready to get started?
Bring structure, automation, and continuous intelligence to your GRC Process — without adding headcount.
★ Schedule a Demo