How to Evaluate a Vendor's SOC 2 Report: The TPRM Practitioner's Guide to Reading What Actually Matters

TL;DR:

• Collecting a SOC 2 report isn’t the same as reviewing it. Most TPRM programs have a collection problem dressed up as a review program.
• Three sections that get skipped: subservice organization carve-outs (excludes key infrastructure from scope), CUECs (controls the vendor assumes you have), and exception descriptions (where the actual risk lives).
• Exceptions aren’t automatically disqualifying — read them in context of management’s response and your risk profile.
• OCC Bulletin 2023-17 and FFIEC examination procedures expect a documented review memo, not just a PDF in your vendor file.

Most TPRM programs have a collection problem, not a review problem.

The checklist says “obtain SOC 2 report.” The analyst emails the vendor, gets a PDF, attaches it to the vendor file, marks the checkbox complete. The SOC 2 has been collected. It has not been reviewed. Those are different things, and examiners know the difference.

A SOC 2 report contains five sections. The cover page and the auditor’s opinion — the part that says “except for the matter described below, the controls operated effectively” — are Section I and II. Most people read those and call it done. The sections where actual due diligence happens are III, IV, and V. Here is how to read them.

What’s Actually in a SOC 2 Report

Before walking through the review methodology, a quick orientation to the document structure:

A Type 1 report confirms controls were designed appropriately as of a specific date. A Type 2 report covers an audit period — typically 6 to 12 months — and tests whether controls operated effectively throughout that period. For ongoing vendor oversight purposes, request the Type 2. Point-in-time design adequacy doesn’t tell you whether controls held up under operational conditions.

Step 1: Check Currency, Type, and Scope Before Reading Anything Else

Three threshold questions before you open Section III:

Currency: When does the audit period end? A SOC 2 with a period ending more than 6 months ago is stale. If you’re onboarding a vendor in June 2026 with a SOC 2 covering the period ending September 2025, you have 9 months of unaudited operations. Request a bridge letter. If the vendor can’t provide one, document why and escalate for risk acceptance.

Type: Is this Type 1 or Type 2? If it’s Type 1, ask when the next Type 2 is expected. A new vendor with only a Type 1 isn’t automatically unacceptable, but it limits the assurance value and should be noted in your review memo.

Trust Services Criteria (TSC): SOC 2 reports are scoped to one or more TSC categories: Security (always included), Availability, Processing Integrity, Confidentiality, Privacy. A vendor processing your customers’ financial data with a SOC 2 scoped only to Security and Availability — excluding Confidentiality and Privacy — has a scope gap that matters for your risk assessment. Confirm the TSC categories align with your primary risk exposure before reading further.

Step 2: Find the Subservice Organizations (The Carve-Out Problem)

Section III describes the vendor’s system, and most enterprise vendors rely on subservice organizations — AWS, Azure, GCP, Salesforce, payment processors, identity providers — for parts of their service delivery.

The key question is how those subservice organizations are handled in the audit:

Inclusive method: The audit includes the subservice organization within scope. The auditor tested controls at both the service organization and the subservice organization. This is the stronger option — coverage extends through the full service delivery chain.

Carve-out method: The subservice organization is explicitly excluded from the audit scope. The vendor’s clean opinion applies only to the components within their direct control. The excluded subservice organization’s systems, access controls, and data handling are not covered.

When a vendor uses the carve-out method — and most do, because auditing AWS’s entire infrastructure isn’t practical — you need either the subservice organization’s own SOC 2 or a documented risk acceptance that you’re comfortable relying on the vendor’s contractual controls over its subcontractors.

For critical cloud-hosted SaaS vendors, ask directly: which cloud provider hosts this environment, and can you provide their SOC 2? AWS, Azure, and GCP all publish their SOC 2 reports and make them available under NDA through their compliance portals. A complete review of your SaaS vendor’s SOC 2 should include the hosting infrastructure SOC 2 alongside the application-layer audit.

The Panorays analysis of SOC 2 in TPRM programs identifies this as one of the most common gaps in vendor due diligence: reviewing the application-level SOC 2 while treating the cloud provider as a black box.

Step 3: Read the Exceptions in Section IV

Section IV is where reviewers either do their job or skip past the most important information in the document.

An exception is a control that didn’t operate effectively during the audit period. The auditor identified it, tested it, characterized it, and reported it. The presence of an exception does not automatically mean the vendor is unacceptable — it means you need to understand what failed and what happened in response.

For each exception, assess:

Control domain: Does the failed control fall in your primary risk area? An exception in physical data center access controls matters less for a cloud-native SaaS vendor than an exception in logical access review or encryption key management.

Frequency and pattern: A single exception in one control instance is different from exceptions noted in the same control across multiple test periods. If you’re reviewing the current SOC 2 alongside last year’s, note whether any exceptions repeat. Recurring exceptions in the same control area indicate a process problem, not an isolated incident.

Auditor’s characterization: The auditor’s language matters. “The control did not operate as designed during two of fifteen instances tested” is a different finding than “the control was not performed during the audit period.” Read the test procedure description and the exception description together.

Management’s response in Section V: Does management acknowledge the exception, describe what happened, and commit to remediation? A management response that disputes the auditor’s finding or provides no remediation plan is a red flag. A management response that describes a root cause, interim compensating controls, and a remediation timeline is a meaningful data point.

One exception in a well-managed control environment with documented management response is not the same as three exceptions with no management response. Meditology’s guidance on reading SOC 2 from a vendor management perspective makes this same point: exception severity depends heavily on the control’s role in your risk profile, not just on its presence.

Step 4: Map the CUECs Against Your Actual Controls

Complementary User Entity Controls (CUECs) are listed in Section III. They are controls the vendor assumes you — the customer — have in place for the vendor’s controls to function completely.

A SOC 2 with a clean opinion that lists CUECs is saying: “Our controls work as designed, assuming you’re doing your part.” If you’re not doing your part, the vendor’s clean opinion doesn’t cover the resulting gap.

Common CUECs in financial services vendor SOC 2 reports:

• Customer maintains its own access controls for user provisioning and deprovisioning
• Customer encrypts sensitive data before transmission
• Customer monitors its own user activity logs
• Customer implements its own change management for configurations
• Customer reviews vendor-provided audit logs periodically

The practical review step: print or export the CUEC list and go through each one with your information security or IT team. For each CUEC, document whether your institution has a control that addresses it, where that control is documented, and who owns it. If a CUEC identifies a control you don’t have, that’s a gap — either in your own control environment or in your understanding of the vendor relationship.

Wolf & Company’s analysis of CUECs notes that CUECs are often the section service organization clients spend the least time reviewing — and the section with the most significant implications for the client’s own control environment. For your most critical vendors, CUEC mapping belongs in the review memo, not as a checkbox exercise.

Step 5: Map the Audit Scope to Your Risk Profile

After working through Sections III, IV, and V, step back and assess what the SOC 2 does and doesn’t cover relative to your institution’s specific use case.

A vendor SOC 2 is written to describe the vendor’s service in general. Your use of that service may have a different risk profile than the general case. A few mapping questions:

Data types: Does your use of this vendor involve data types that create heightened risk — PII, account numbers, financial transactions, health information for employee benefits? Are the controls around those data types reflected in the tested control set?

Integration points: Does your implementation involve direct database access, API integrations, or data transfers that may not be covered by the standard SOC 2 scope? Some enterprise implementations involve custom configurations that fall outside the audited environment.

Criticality tier: For your highest-criticality vendors — those whose failure would directly impair core banking, payments, or customer-facing operations — the SOC 2 review should be more intensive, including a documented mapping of their controls to your critical risk scenarios.

For detailed guidance on what questions to surface from vendor documentation at different risk tiers, our vendor due diligence techniques guide covers the documentation review and verification process from questionnaire through site visit.

Bridge Letters: When to Request One and What It Means

A bridge letter is a representation from vendor management — sometimes accompanied by the auditor — that controls have continued to operate effectively from the end of the audit period through a more recent date.

Request one when:

• The SOC 2 audit period ends more than 3-6 months before your review date
• You’re onboarding a high-criticality vendor mid-year with a stale report
• A vendor has had a disclosed security incident since the SOC 2 audit period ended

Bridge letters carry lower assurance than a full audit — they’re management representations, not tested attestations. But they document that the vendor has no known material deterioration in its control environment since the last audit. For file purposes, a bridge letter plus a stale SOC 2 is better than a stale SOC 2 alone.

Red Flags vs. Yellow Flags

After your review, categorize findings before writing up the memo:

What Regulators Expect in Your Documentation

OCC Bulletin 2023-17 and the FFIEC’s examination procedures for third-party risk management both expect evidence that your institution reviewed the SOC 2 — not just collected it.

A compliant review memo documents:

• Reviewer name, title, and date
• Vendor name and service description
• SOC 2 report period and auditor
• Trust Services Criteria covered
• Whether subservice organizations were carve-outs or inclusive, and how carve-outs were addressed
• Exceptions identified in Section IV and your assessment of each
• CUEC mapping results — which CUECs are met, which have gaps
• Overall risk determination and any required follow-up actions

This memo is what goes in the vendor file alongside the SOC 2 PDF. A SOC 2 without a review memo isn’t evidence of third-party due diligence — it’s evidence of document collection. Examiners and auditors know the difference, and your vendor due diligence questionnaire process is only as strong as the documentation that confirms the answers were verified.

The Third-Party Risk Management Kit includes a vendor SOC 2 review checklist with fields for each of these sections — carve-out analysis, CUEC mapping, exception tracking, and risk determination — designed to produce the documented review memo your examiners want to see. For the broader control testing approach your institution applies to its own controls as well as vendor assessments, the control testing and evidence guide covers the sampling and documentation methods that hold up under examination.

So What?

A SOC 2 is only worth the review behind it. Collecting a report without reviewing it — really reviewing it, Sections III through V — doesn’t give you assurance. It gives you a PDF.

The three sections most commonly skipped are also the three most likely to surface meaningful risk. Subservice organization carve-outs can exclude your vendor’s entire hosting infrastructure from audit scope. CUECs describe gaps in your own control environment you’ve been relying on the vendor to cover. Exception descriptions tell you what actually broke during the audit period and whether the vendor has a remediation plan worth believing.

The review doesn’t take long once you know what to look for. An experienced analyst can work through Sections III, IV, and V in under an hour for a typical SaaS vendor. What it requires is a structured approach and documentation that shows the work.

That’s what separates a TPRM program that creates assurance from one that creates files.