How to Critically Evaluate a Vendor's SOC 2 Report Instead of Treating It as a Checkbox

The opinion letter is the first section of the SOC 2 report and the only section most reviewers read. It contains two key elements:

The opinion type. An unqualified opinion means the auditor found the controls suitably designed and operating effectively. A qualified opinion means the auditor found specific exceptions -- areas where controls did not operate as described or were missing. A qualified opinion should trigger immediate follow-up, not automatic rejection: the relevant question is whether the exceptions affect the controls that protect your data or other controls.

The audit period. The audit period is the time range the opinion covers. A report with an audit period of January through December 2024 does not tell you anything about the vendor's security posture in 2025. For vendors where you have significant data or operational dependency, request evidence of the most recent report and flag vendors whose most recent report audit period ended more than 12 months ago.

What the opinion does not say. An unqualified opinion does not mean:

• The vendor's security posture is good in absolute terms (only that the described controls operated as stated)
• All of the vendor's infrastructure is covered (only the components in scope)
• The vendor has not had any security incidents during the audit period (incidents may or may not appear in the report depending on how the vendor's controls are described)
• The controls will operate the same way in the future (the opinion is historical)

The opinion is the starting point for reading the report, not the endpoint.

The exceptions section documents every instance where an auditor tested a control and found it did not operate as described. This is the most valuable section of a SOC 2 report for a security reviewer and the section most often skipped by teams that treat the report as a checkbox.

Exception entries typically include: the control that was tested, the number of samples tested, the number of exceptions found (e.g., "2 of 25 samples"), and a description of what the exception was. Common exception types include:

Access control exceptions. A control states that access is reviewed quarterly, but the auditor found 3 of 10 sampled reviews were not completed on time. This tells you the vendor has an access review process but it does not always execute on the defined cadence -- meaning some users may have access longer than intended.

Patch management exceptions. A control states that critical patches are applied within 14 days, but the auditor found 2 systems where patches were applied in 21 and 28 days respectively. Depending on which systems are involved, this may represent meaningful risk.

Vendor management exceptions. A control states that subprocessors undergo security review, but exceptions indicate some subprocessors were not reviewed within the required timeframe.

How to evaluate exceptions: ask the vendor (via a follow-up questionnaire) what remediation steps were taken for each exception, when remediation was completed, and whether the same exceptions appeared in the prior year's report. Repeated exceptions across multiple audit periods indicate a systemic control weakness, not a one-time operational miss.

CUECs are controls that the vendor specifies must be implemented by the customer (you) for the vendor's security assertions to hold. This is the most consequential section for your own security posture and the section most commonly skipped.

If the vendor's report states "User entities are responsible for implementing multi-factor authentication for all accounts accessing the service" as a CUEC, and you have users accessing the service without MFA, the vendor's security controls do not cover the gap your users create. The risk is yours, but it was disclosed in the vendor's SOC 2 report -- so a reviewer who claimed to have assessed the report and missed this has not completed a meaningful assessment.

Common CUECs to look for:

• Authentication requirements. The vendor may require MFA or specific password policies for accounts you provision in their system.
• Data classification and handling. The vendor may specify that you are responsible for classifying data before sending it to their service and that certain data categories should not be processed through their platform.
• User access management. The vendor may require you to implement your own access review and deprovisioning processes for accounts you create in their system.
• Incident notification. The vendor may specify that you are responsible for notifying the vendor of security incidents that may affect the vendor's environment (a compromised account used to access the vendor's service, for example).

For each CUEC: assess whether your organization has implemented the specified control. Document gaps. Assign remediation responsibility. A CUEC that specifies a control your organization does not have represents risk that is disclosed in the vendor's SOC 2 but unmitigated in your environment.

The system description defines what is in scope for the SOC 2 audit. What is out of scope is equally important. Three categories of scope gaps are most significant for the receiving organization:

Subprocessors and fourth parties. Most SaaS vendors rely on other cloud services (AWS, GCP, Twilio, Stripe, SendGrid) to deliver their product. These subprocessors may handle or have access to your data. A SOC 2 report that covers the vendor's own systems but explicitly excludes subprocessors means the auditor only assessed controls the vendor directly manages. Ask: does the vendor have a subprocessor list available? Do the subprocessors that handle your data have their own SOC 2 reports (or equivalent)?

Infrastructure components explicitly excluded. Some vendors exclude specific infrastructure components from the audit scope -- for example, a production environment is in scope but a development environment that shares some infrastructure is excluded. If the excluded component could be a path to your data (a developer environment that uses production API keys, for example), the exclusion represents a meaningful gap.

TSC categories not included. A SOC 2 report can cover any combination of the five Trust Service Criteria: Security (CC criteria), Availability (A criteria), Processing Integrity (PI criteria), Confidentiality (C criteria), and Privacy (P criteria). A vendor whose report only includes the Security TSC has not been audited for availability, confidentiality, or privacy controls. For vendors processing regulated data or providing operationally critical services, confirm whether the relevant TSC categories are included in the report.

Acquisition or infrastructure changes during or after the audit period. If the vendor was acquired, underwent a major infrastructure migration, or made significant architecture changes during or after the audit period, the report may not reflect their current state. Ask the vendor directly about significant changes since the last audit period.

A SOC 2 report review that generates no follow-up questions is likely a checkbox review. A thorough review generates specific questions based on the exceptions, CUECs, and scope gaps identified. Template questions for common findings:

For exceptions in the report: "We noted [exception description] in your most recent SOC 2 report. Can you provide documentation of the remediation steps taken, the date remediation was completed, and whether this exception appeared in prior audit periods?"

For CUECs your organization may not have implemented: "Your SOC 2 report identifies [specific CUEC] as a customer responsibility. Can you confirm how our current configuration compares to this requirement and whether there are any technical controls on your side that enforce this requirement for your customers?"

For subprocessors: "Your SOC 2 report does not appear to cover [specific subprocessor] that processes our data. Do you have a current SOC 2 or equivalent attestation for this subprocessor? If not, how do you assess and monitor their security posture?"

For aging reports: "Your most recent SOC 2 report covers a period ending [date, more than 12 months ago]. Can you provide your current audit timeline and whether there are any significant infrastructure or control changes since the audit period that would affect our risk assessment?"

For qualified opinions or significant exceptions: "Your SOC 2 report includes [exception or qualification]. This is a control relevant to [the protection of our data / access to systems that process our data]. Can you provide a written management response describing the root cause, remediation status, and current state of this control?"

Applying the same review depth to every vendor's SOC 2 report is not the right approach -- a vendor who receives email marketing campaigns does not warrant the same scrutiny as a vendor who processes PHI or has administrative access to your production infrastructure.

A three-tier review framework calibrates depth to risk:

Tier 1 (high-risk vendors): Full review. Vendors with access to regulated data (PHI, PII, cardholder data), vendors with privileged access to your infrastructure, vendors whose failure would cause a significant operational outage. Full review: read all five sections (opinion, system description, complementary user entity controls, exceptions, and scope boundaries), map all CUECs against your implemented controls, send a written follow-up questionnaire for any exceptions or gaps, request prior year's report to compare exception patterns, and re-review annually.

Tier 2 (moderate-risk vendors): Targeted review. Vendors with access to non-regulated business data or operational services without privileged infrastructure access. Targeted review: read the opinion letter, exceptions section, and CUECs. Send follow-up only for critical exceptions. Re-review every 2 years.

Tier 3 (low-risk vendors): Opinion-only review. Vendors with no access to data beyond what is publicly available, no operational dependency, no privileged access. Confirm unqualified opinion, confirm audit period is current, file and review at contract renewal.

Document the tier assignment and review depth for each vendor in your third-party risk management system. An auditor or regulator asking about your TPRM process should be able to see not only that you collected SOC 2 reports but that you reviewed them at a depth proportional to the vendor's risk level.