How to Read a SOC 2 Report: Exceptions and CUECs

A SOC 2 report is only as useful as the reading it gets, and most vendor reviews stop at the cover page and the word "unqualified". The value sits further in: which system was examined, which trust services categories were covered, which controls the vendor relies on you or its own suppliers to operate, and which tests found exceptions. This guide walks through a SOC 2 report section by section, explains complementary user entity controls (CUECs), subservice organisations and the carve-out and inclusive methods, shows how to judge exceptions and bridge letters, and lists the identity and access questions a report should answer. It is written for third-party risk analysts, security reviewers and procurement teams who read many reports a year. For what SOC 2 is and how an organisation achieves it, see the SOC 2 Guide; this page is about reading someone else's.

Key takeaways

Read the scope before the opinion. A clean opinion on a system that does not include the service you buy tells you nothing about that service.
Type 2 over a meaningful period is the default ask. A Type 1 report covers design at a point in time; a Type 2 also tests whether controls operated over a period.
CUECs are your controls. The vendor's assurance assumes you operate the listed user entity controls; if you do not, the criteria may not be met for you.
Carved-out subservice organisations need their own evidence. Under the carve-out method the auditor did not test the subservice organisation, so you must obtain assurance over it elsewhere.
Bridge letters are management statements, not assurance. They carry no auditor testing or opinion, and should cover only a short gap.

The report at a glance

SOC 2 examinations are attestation engagements performed by licensed CPA firms under AICPA standards. The current AICPA guide, SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy (October 2022 edition), applies the 2017 Trust Services Criteria with revised points of focus (2022) and the 2018 description criteria with revised implementation guidance (2022). Reports from different firms look different, but almost all contain the same parts.

Section	What it contains	What to look for
Independent service auditor's report	The CPA firm's opinion on the description, design and (Type 2) operating effectiveness	Opinion type, period, categories covered, any modification paragraph, firm name and signature date
Management's assertion	Management's statement that the description is fairly presented and controls were suitably designed and operated	Consistency with the opinion; any carve-outs or exclusions mentioned here first
System description	Services, principal service commitments and system requirements, infrastructure, software, people, data, processes, incidents, subservice organisations, CUECs	Whether your service, regions and data types are inside the boundary
Criteria, controls, tests and results	Each applicable criterion mapped to controls, the auditor's test and the result	Exceptions, sample sizes, tests that rely only on inquiry
Other information (if present)	Management's responses to exceptions, roadmaps, additional material	Usually not covered by the opinion; treat as management claims

Type 1 or Type 2

Question	Type 1	Type 2
What is examined	Fair presentation of the description and suitability of control design	The same, plus operating effectiveness of controls
Timeframe	As of a specific date	Over a period, commonly 6 or 12 months; shorter periods occur in first reports
Tests of operation	None	Inspection, observation, reperformance and inquiry over samples
When to accept it	A new vendor's first report, with a Type 2 committed for a date	Standard for ongoing reliance

SOC 2 reports are intended for specified users such as customers and their auditors, which is why vendors share them under NDA. A SOC 3 report covers the same criteria for general use but omits the detailed tests and results, so it is not a substitute in a security review.

Scope: system, categories and period

System boundary: confirm the named system matches the product, environment and regions you use. Vendors often scope one platform and sell several. A report on the "production SaaS platform" may exclude support tooling, mobile apps or a recently acquired product.
Trust services categories: Security (the common criteria) is always included. Availability, Confidentiality, Processing Integrity and Privacy are optional. If you depend on uptime, ask why Availability is absent; if the vendor holds your confidential data, Confidentiality matters.
Period: check the end date. A report whose period ended more than a year ago gives little comfort about today.
Principal service commitments and system requirements: the description states the commitments the controls are designed to meet. Compare them with your contract: if the contract promises encryption or data residency that the commitments do not mention, the report does not cover it.
Incidents: the description criteria ask for disclosure of significant security incidents. Read that part carefully; "none" over a period in which the vendor publicly disclosed an incident is a question to raise.

The common criteria and where identity sits

The Security category is evaluated against the common criteria, organised in nine series: CC1 Control Environment, CC2 Communication and Information, CC3 Risk Assessment, CC4 Monitoring Activities, CC5 Control Activities, CC6 Logical and Physical Access Controls, CC7 System Operations, CC8 Change Management and CC9 Risk Mitigation. For identity and non-human identity risk, the controls mapped to CC6 and CC7 deserve the closest reading.

Criterion area	Questions the controls and tests should answer	Weak signal
CC6.1 logical access security	Is access to production authenticated with MFA? Are service accounts, API keys and machine credentials inventoried and stored in a vault?	Controls mention only "users" and passwords
CC6.2 and CC6.3 provisioning, changes and removal	Are access requests approved, reviewed periodically and removed promptly at termination, including for contractors and non-human accounts?	Access review tested on one quarter only, or excludes privileged roles
CC6.6 and CC6.7 external access and data transmission	How are customer-facing and admin interfaces protected, and how is data encrypted in transit?	No mention of admin console restrictions
CC7.2 monitoring	Are logs collected from production and identity systems, and are anomalies investigated?	Monitoring tested by inquiry alone
CC8.1 change management	Are code and infrastructure changes reviewed and approved, and who can deploy to production (people and pipelines)?	Pipeline service accounts with unrestricted deploy rights not addressed
CC9.2 vendor and business partner risk	How does the vendor assess its own suppliers, including the subservice organisations it carves out?	One generic policy control, no monitoring of supplier reports

If the report is silent on machine credentials, ask directly. See the Security Questionnaires Guide for follow-up questions and the Third-Party Access Guide for the access the vendor will hold in your environment.

Complementary user entity controls (CUECs)

CUECs are controls the service organisation assumes its customers (user entities) operate, and without which some criteria may not be achieved. They usually appear as a list near the end of the system description, sometimes mapped to criteria. They are not tested by the auditor, because they are your controls.

Typical CUECs: customers manage their own user accounts and roles in the application; customers review and remove access for their leavers; customers protect API keys and credentials issued to them; customers configure SSO and MFA where offered; customers report suspected security incidents promptly; customers ensure data sent to the service is authorised and accurate.
Turn them into owned tasks: map each CUEC to a control owner in your organisation and to your own control framework. If nobody owns "customers rotate API keys", the vendor's assurance has a gap at your end.
Watch for unreasonable CUECs: a CUEC that shifts a core vendor duty to you (for example "user entities are responsible for monitoring for unauthorised access to the platform") deserves a contract conversation.
Identity CUECs are NHI tasks: API keys, OAuth client secrets and integration tokens the vendor issues are non-human identities you must inventory, store and rotate. See the API Key Management Guide.

Subservice organisations: carve-out and inclusive

Most SaaS vendors run on cloud platforms and use other providers for payments, email, support tooling or monitoring. Where those providers perform controls relevant to the criteria, the report must say how they are treated.

Aspect	Carve-out method	Inclusive method
Subservice organisation in scope of the examination	No; its services are described but excluded	Yes; its relevant controls are part of the description
Auditor testing	Subservice controls not tested	Controls at both organisations tested
Opinion covers	Only the service organisation's own controls	Both organisations' relevant controls
Disclosure	Complementary subservice organisation controls (CSOCs) the service organisation expects the subservice organisation to operate	Subservice controls presented, usually distinguished from the vendor's own
What you must do	Obtain assurance over the carved-out controls elsewhere, typically the subservice organisation's own SOC report, and check the vendor monitors it	Review the subservice controls and test results like the vendor's own
Frequency in practice	The common default, especially for hyperscale cloud providers	Rare, because it needs the subservice organisation's cooperation

Build the chain: list each carved-out subservice organisation, the CSOCs, and whether you hold or can obtain its current report. The Third-Party Risk Management Guide covers fourth-party tracking.
Check vendor monitoring: the vendor should have a control (usually under CC9.2) to obtain and review subservice organisations' reports and act on their exceptions and CUECs.
Look for missing names: if the vendor's sub-processor list names providers that hold your data but the report names none, ask why.

Reading exceptions and the opinion

In a Type 2 report, each test lists a result: either "no exceptions noted" or a description of the deviation. An unmodified opinion can coexist with exceptions if the auditor concluded the criteria were still met; a modified opinion means they were not, for at least one criterion.

Finding	Meaning	Reviewer action
Unmodified opinion, no exceptions	Description fair, controls suitably designed and (Type 2) operating effectively for the period	Confirm scope fit, CUECs and carve-outs, then rely
Unmodified opinion with exceptions	Deviations found, but the auditor concluded the criteria were met	Read each exception, management's response and whether compensating controls were tested
Qualified opinion	One or more criteria not met, or description not fairly presented, in specific respects	Identify the affected criteria; decide whether they touch your risk; require a remediation date
Adverse opinion	Misstatements or deficiencies are pervasive	Do not rely; escalate
Disclaimer of opinion	The auditor could not obtain sufficient evidence	Do not rely; ask why

Weigh exceptions by control, not count: one terminated administrator whose access survived for months matters more than five late security awareness completions.
Check sample sizes: "selected a sample of 2 terminations" over a year in a large company is weak evidence even with no exceptions.
Check the test method: inquiry alone does not show a control operated. Prefer inspection and reperformance.
Treat management responses as claims: remediation described in the other information section is not covered by the opinion.

Bridge letters and gaps between periods

Reports cover a past period. When a customer needs comfort for the months between the period end and the next report, vendors issue a bridge letter (also called a gap letter). It is signed by the service organisation's management, not the auditor, and states that, to management's knowledge, there have been no material changes to the control environment since the period ended.

Assurance level: no independent testing and no opinion. Treat it as a written management representation.
Length: there is no formal standard, but practitioners commonly treat about three months as the longest gap a bridge letter can reasonably cover.
Contents to expect: reference to the prior report and period, statement of no significant changes or a list of changes, disclosure of any incidents, the expected date of the next report, and a signatory with authority.
Red flag: a bridge letter covering most of a year, or successive letters with no new report.

Judging the report itself

The AICPA's Journal of Accountancy reported in February 2026 on concerns that "fast and easy" SOC offerings threaten report quality, and noted that "compliance" is not a term used in SOC 2 examinations. Its suggestions for report users translate into review checks.

Templated content: descriptions and control lists that read as boilerplate, nearly identical across vendors using the same platform, may show weak tailoring to the actual system.
Firm qualifications: confirm the signing firm is a licensed CPA firm and consider its size, experience and peer review results.
Independence: be cautious of very short timelines and arrangements where the tooling vendor refers the audit firm.
Testing depth: look for tests beyond inquiry and for sampling appropriate to the period.

Detection and measurement for a SOC review programme

Track expiry: record each vendor's period end and expected next report; alert when a report is more than 12 months past period end with no bridge letter.
Track CUEC ownership: every CUEC from critical vendors mapped to an internal owner and control.
Metric: coverage, share of critical vendors with a current Type 2 report covering the services used.
Metric: carve-out completeness, share of carved-out subservice organisations for which you hold or have assessed a current report.
Metric: exception follow-up, exceptions affecting your risk with an agreed remediation date and closure evidence.
Metric: review time to decision, days from receipt of report to documented reliance decision.

Where SOC report review sits in your own frameworks

Activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ISO/IEC 27001:2022 Annex A
Review a report before contract	GV.SC-06	SR-06 Supplier Assessments and Reviews	A.5.19, A.5.20
Annual re-review, exceptions and bridge letters	GV.SC-07	SR-06, SA-09 External System Services	A.5.22
Tiering vendors to decide who needs a Type 2	GV.SC-04	SR-06	A.5.19
Operating CUECs and cloud service controls	GV.SC-07	SA-09	A.5.23

Common failure patterns

Opinion-only review: filing the report after reading the first page, without checking system scope or exceptions.
Ignoring CUECs: accepting the vendor's assurance while not operating the user controls it depends on, such as reviewing your own users and protecting issued API keys.
Losing the fourth parties: not following carved-out subservice organisations, so the cloud, support or AI providers that hold your data are never assessed.
Accepting stale reports: relying on a report whose period ended more than a year ago, or on chained bridge letters.
Assuming SOC 2 equals secure: the report describes controls over a past period against criteria the vendor chose; it does not certify the vendor and does not predict breaches.

Lessons from incidents

The Okta Support System Breach 2023 is a reminder that shared responsibility runs both ways. An attacker used a stolen support service account credential to access support case files, including browser HAR files that customers had uploaded for troubleshooting, some of which contained session tokens. Whatever a vendor's report says about its own controls, the customer side, what you send to a vendor's support system and whether you sanitise tokens first, is exactly the kind of user entity responsibility a CUEC list describes. Read CUECs as a list of your own controls, and treat vendor support channels as part of your data flow.

Practitioner checklist

Confirm the report type, period end date and that the system boundary includes the services, regions and data you use.
Check which trust services categories are covered against what you depend on (Availability, Confidentiality, Privacy).
Read the opinion for any modification and the management assertion for exclusions.
Review every exception, its affected criterion, sample size and management response, and record your assessment.
Map each CUEC to an internal owner and control, including protection and rotation of vendor-issued credentials.
List carved-out subservice organisations and CSOCs, and obtain or assess their current reports.
Check CC6, CC7, CC8 and CC9.2 controls for coverage of privileged access, machine credentials, monitoring and supplier oversight.
Accept bridge letters only for short gaps and diarise the next report.
Record a reliance decision with conditions and a review date.

How to Read a SOC 2 Report Guide: Exceptions, CUECs, Carve-Outs and Bridge Letters Explained