How to Read a Vendor SOC 2 Report: What Actually Matters and What to Ignore
A SOC 2 Type II report is a third-party auditor's assessment of a vendor's security, availability, confidentiality, processing integrity, and privacy controls over a defined period -- typically 6 to 12 months. The document answers one question: did the vendor's controls operate effectively during that period? Most vendor risk reviews check that the report exists and is unqualified, then file it. That misses the three sections where actual risk lives: the scope definition, the exceptions table in Section 3, and the Complementary User Entity Controls that your organization is required to implement.
Understanding the Report Structure
A SOC 2 Type II report has four primary sections. Understanding which sections are auditor-produced and which are vendor-produced is essential for interpreting the document correctly.
Section 1: Management's Description of the System This section is written by the vendor, not the auditor. It describes the system in scope, the infrastructure, the data flows, the people and processes, and the controls the vendor claims to operate. Read it skeptically -- it is a marketing-quality description of the control environment as the vendor sees it. The auditor's job in Section 3 is to test whether this description is accurate.
Section 2: Auditor's Opinion This is the most-read section and the least informative for practitioners. The opinion is typically one to two paragraphs stating whether the system description was fairly presented and whether the controls operated effectively. Look for the word 'unqualified' -- that is the clean bill of health. Any qualification language requires investigation. Also note the audit period dates: these define the window the tests covered.
Section 3: Description of Tests of Controls and Results This is the section most reviewers skip and the one that contains all the risk signal. For each control tested, you see: the control description, the test procedure the auditor performed, the sample size, and the result. Exception rows are buried in this section. Allocate 80% of your review time here.
Section 4: Additional Information / Vendor Response Vendor responses to exceptions noted in Section 3, along with remediation commitments and timelines. Read this alongside Section 3: an exception with a documented, completed remediation is very different from one with a vague future commitment.
Carve-out vs. Inclusive subservice organization method: The report's introduction or the auditor's opinion will state which method applies. Carve-out means subservice organizations are excluded from the audit scope -- you need their SOC 2 reports separately. Inclusive means the auditor tested the relevant controls at the subservice organization as part of this engagement.
The Scope Section: What the Audit Actually Covered
Before reading anything else, verify that the audit scope covers the systems and data that matter for your use case.
What to check in scope:
-
Which products or services are in scope? Vendors often audit a subset of their product line. If you use a feature or product that is explicitly excluded from scope, the SOC 2 provides no assurance for your specific use case. The system description in Section 1 should name the in-scope services.
-
Which Trust Service Categories (TSCs) are included?
- Security (CC): Logical and physical access, change management, risk assessment, incident response. This is the baseline and should be in every vendor's SOC 2.
- Availability (A): System uptime and performance commitments. Required if SLA matters.
- Confidentiality (C): Protection of confidential information. Required for data you consider confidential.
- Processing Integrity (PI): Complete, accurate, timely processing. Required for financial or critical transaction processing.
- Privacy (P): Collection, use, retention, disclosure, and disposal of personal information. Required for any vendor processing personal data.
-
Red flag -- scope mismatch: A vendor that processes sensitive personal data (health records, financial records, PII) but only has the Security TSC in scope has not been audited on how they handle that data's privacy. The Security category addresses access controls, not data handling practices.
-
Which data center locations or cloud regions are in scope? If your data is processed in a region not covered by the audit, the controls for that region have not been tested.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Reading the Exceptions Table: Where Risk Actually Lives
Section 3 is typically the longest section of the report, organized by control. Each control has a row showing the auditor's test and result. Exceptions are disclosed inline, usually with language like 'exception noted,' 'the control did not operate,' or 'for X of Y items tested, the required documentation was not present.'
How to find exceptions efficiently: Search (Ctrl+F) the PDF for: 'exception,' 'deviation,' 'did not operate,' 'no evidence,' 'not performed,' 'not completed.'
What each exception row contains:
- The control being tested (e.g., CC6.1: Logical access is restricted to authorized users)
- The test the auditor performed (e.g., 'For a sample of 25 user accounts, inspected access provisioning records to determine whether access requests were approved by a manager before access was granted')
- The result (e.g., 'For 3 of 25 items tested, no manager approval was documented prior to access being provisioned')
Severity assessment framework:
| Factor | Lower Concern | Higher Concern |
|---|---|---|
| Exception rate | 1-2 of 25 samples | 5+ of 25 samples |
| Control category | PI, Availability | CC (Security), Privacy |
| Remediated by | Report issuance date | Future date / ongoing |
| Control type | Compensating control | Primary control |
| Recurrence | First time noted | Noted in prior year report |
Request prior year reports: If the vendor has a prior SOC 2, request it and compare the exceptions. A control that failed in two consecutive audit periods indicates a systemic process problem, not a one-time gap.
Sample exception language and interpretation: 'For 4 of 25 items tested, access reviews were not completed within the required 90-day period.' This means the vendor's access review process is not operating on schedule. Ask: what is the current review cadence? Who owns it? Was any unauthorized access found during the late review period?
Complementary User Entity Controls
CUECs are the section of the SOC 2 report most frequently missed by vendor risk teams and the one with direct compliance implications for your organization.
Where to find them: CUECs are typically listed in an appendix at the end of Section 1, labeled 'Complementary User Entity Controls' or 'User Entity Control Considerations.' Some reports embed them in individual control descriptions.
Common CUECs across vendor types:
| CUEC | What it requires from you |
|---|---|
| Access management | You must review and certify your users' access to the vendor platform at least quarterly |
| Authentication | You must enforce MFA for all user accounts accessing the vendor's system |
| Data transmission | You must use TLS 1.2 or higher for all API connections to the vendor |
| Incident notification | You must notify the vendor within 24 hours if a user account is compromised or an authorized user should be revoked |
| Data classification | You must not upload data classified above [level] to the vendor system unless explicitly approved |
| Offboarding | You must remove vendor access for terminated employees within [timeframe] |
How to operationalize CUECs:
- Extract every CUEC from the report into a spreadsheet
- Assign an internal control owner for each
- Map each CUEC to your existing controls or create a new control requirement
- Add CUEC compliance to your vendor review checklist
- Document CUEC status in your GRC system
Non-compliance with CUECs is not a vendor finding -- it is your finding. If you have not implemented the CUECs and an incident occurs, the vendor's SOC 2 attestation does not transfer the risk to them.
Subservice Organizations and the Carve-Out Problem
When a vendor uses the carve-out method for subservice organizations, those third parties are outside the audit scope. The report will typically state something like: 'The services provided by AWS are carved out from the scope of this examination. The description and the scope of this examination do not include the controls of AWS.'
Finding carve-outs in the report: Search for 'carved out,' 'carve-out,' 'subservice organization,' or 'user entity.' The auditor's opinion will reference which method applies.
Building your transitive third-party inventory:
For each carved-out subservice organization:
- Identify whether they handle your data (directly or indirectly)
- Request their SOC 2 Type II report or SOC 3 summary report
- If they are a major cloud provider (AWS, Azure, GCP): their SOC 2 reports are publicly available at their compliance portals
- If they are a smaller subservice organization: request directly through the vendor or ask for confirmation that the subservice organization has its own SOC 2
Inclusive method (preferred): If the vendor uses the inclusive method, their auditor extended testing to relevant controls at the subservice organization. This is a stronger assurance posture but still requires you to verify which subservice organizations are included and which are excluded.
Risk when a critical subservice organization is carved out: If your vendor processes all data on AWS and AWS is carved out, you have an unaudited gap in the infrastructure that hosts your data. The mitigation is obtaining AWS's SOC 2 report (publicly available at aws.amazon.com/compliance/soc-faqs/) and confirming the relevant services and regions are in scope.
Questions to Send the Vendor After Review
After completing your review, send a structured follow-up to document your assessment and get vendor responses on record.
Template:
Subject: SOC 2 Type II Review Follow-Up -- [Your Company] / [Vendor]
We completed our review of your SOC 2 Type II report covering [audit period]. We have the following questions:
Exception -- Control CC6.1 (Access Provisioning): Your report notes that for 3 of 25 samples, access provisioning records did not include manager approval prior to access being granted. Please describe the current approval process, the owner, and whether this control has been updated since the audit period end date.
Subservice Organization -- AWS (Carve-Out): Your report uses the carve-out method for AWS infrastructure. Can you provide AWS's most recent SOC 2 Type II report, or confirm the specific AWS services in use and point us to their publicly available SOC 2 documentation?
Complementary User Entity Control 3: This control requires us to review our users' access to your platform on at least a quarterly basis. Please confirm: (a) the format and method you use to deliver access reports to customers, (b) the frequency at which access reports are available, and (c) whether this is included in our current contract tier.
We are targeting completion of our vendor risk review by [date]. Please respond by [date].
Document vendor responses and store them alongside the SOC 2 report in your vendor risk file. Unresponsive vendors should be escalated through procurement or legal before contract renewal.
The bottom line
A SOC 2 report is an audit of a vendor's controls over a fixed period in the past. What actually matters: the scope (which services and TSCs are covered), the exceptions (what failed during the audit period), the CUECs (what you are required to control on your side), and the subservice organization disclosures (what is not covered). Everything else is background.
Frequently asked questions
What is the difference between SOC 2 Type I and Type II?
A SOC 2 Type I report is a point-in-time assessment: the auditor evaluated whether the vendor's security controls were designed appropriately as of a specific date. It does not test whether the controls actually worked over time. A SOC 2 Type II report covers a defined period -- typically 6 to 12 months -- and includes testing of whether controls operated effectively throughout that entire period. For vendor risk purposes, always request a Type II report. A Type I tells you the controls existed on one day; a Type II tells you they functioned over months. If a vendor only has a Type I, ask when their Type II audit window begins and whether they have a penetration test or other operational evidence to supplement it.
What does 'qualified opinion' mean in a SOC 2 report?
The auditor's opinion in Section 2 of the SOC 2 report is either unqualified (clean) or qualified. An unqualified opinion means the auditor concluded the system description was fairly presented and the controls operated effectively throughout the audit period with no material exceptions. A qualified opinion means the auditor found exceptions significant enough to qualify -- but not completely disclaim -- the overall assessment. Qualified opinions require deeper review: read the specific basis for qualification, understand which controls failed and for how long, and ask the vendor for their remediation plan and timeline. A qualified opinion is not automatically a deal-breaker, but it requires a documented risk acceptance decision.
What are exceptions in a SOC 2 report and how serious are they?
Exceptions are individual control failures found during the auditor's testing. They appear in Section 3 of the report as rows where the test result deviates from the expected outcome -- look for language like 'exception noted,' 'deviation noted,' or 'the control did not operate as described.' To assess severity: (1) Which Trust Service Category does the control belong to? An exception in CC6 (Logical and Physical Access Controls) is higher risk than one in PI (Processing Integrity) for most use cases. (2) What was the sample size and how many samples failed? One exception in 25 samples is different from 8 exceptions in 25. (3) Is the vendor's response in Section 4 reactive or proactive -- did they remediate before the audit ended or after? (4) Is the exception for a compensating control or a primary control?
What are Complementary User Entity Controls?
Complementary User Entity Controls (CUECs) are controls that your organization -- the user entity -- must implement for the vendor's security environment to function as described in the SOC 2 report. They are obligations, not recommendations. Common examples: you must enforce MFA for all users of the vendor's platform; you must review and certify your user access to the vendor system quarterly; you must use TLS 1.2 or higher when transmitting data to the vendor's API; you must notify the vendor within 24 hours if an authorized user's account should be revoked. If you are not implementing CUECs, the vendor's SOC 2 attestation does not cover the resulting risk -- that risk lives entirely on your side. CUECs should be extracted, assigned to internal control owners, and tracked in your GRC system.
What is a subservice organization and why does it matter?
A subservice organization is a third party the vendor relies on to provide services that are part of the audited system. Common examples: AWS or Azure for infrastructure, Twilio for SMS delivery, Stripe for payment processing. SOC 2 reports handle subservice organizations in one of two ways. The carve-out method excludes the subservice organization from scope -- the auditor does not test their controls, and you need to obtain the subservice organization's own SOC 2 report to understand that portion of the risk. The inclusive method tests the subservice organization's relevant controls as part of the vendor's audit. When reviewing a vendor's SOC 2, identify which method is used and which subservice organizations are carved out. For each carved-out organization that handles your data, obtain their SOC 2 report (or SOC 3 summary if the full report is unavailable).
What should I ask for if the vendor's SOC 2 report is more than 12 months old?
A SOC 2 Type II report covering a period that ended more than 12 months ago is stale. The audit period end date appears on the auditor's opinion page. If the report is stale, request one of: (1) A bridge letter from the vendor's auditor -- a letter stating that no material changes to the control environment occurred since the audit period ended and that the auditor is aware of no events that would change their opinion. This is the strongest form of gap coverage. (2) A management attestation letter from the vendor's leadership stating that controls remain in place and no significant incidents have occurred since the report period. (3) The in-progress audit schedule -- if the new audit is already underway, you can document the expected completion date and accept the gap with a time-bound risk acceptance.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.