SOC 226 April 2026 6 min read

SOC 2 Exceptions in Audit Reports: What They Mean

SOC 2 exceptions indicate control failures during the audit period. Learn how to read exceptions, how to assess their severity, and what they mean for your vendor relationships.

Key Takeaways

An exception in Section 5 means the auditor found at least one instance where a control did not operate as described — a control failure.
Exceptions are not automatically disqualifying — isolated exceptions in lower-risk controls are common and do not typically result in qualified opinions.
Assess exceptions on three dimensions: criticality (how sensitive is the affected control?), frequency (one instance vs. a pattern?), and remediation (was the root cause fixed?).
Management responses to exceptions in the report provide crucial context — a detailed, specific response demonstrates a mature control environment.
When reviewing a vendor's report with exceptions, the right response is a conversation, not an automatic disqualification.

In this guide

What Is a SOC 2 Exception
How Exceptions Appear in the Report
Assessing Exception Severity
Reading Management Responses
Common Exception Types
Vendor Review Process for Exceptions

What Is a SOC 2 Exception

A SOC 2 exception is a control test result where the auditor found that a control did not operate as described in the service organization's system description. Specifically, the auditor tested a sample of transactions, records, or configurations related to a control and found at least one instance in the sample that did not comply with the control as written. Each such instance is documented as an exception in Section 5 of the report.

Exceptions are distinct from findings or recommendations — they are documented deviations in the test results, not advisory observations. An exception means the control failed at least once during the observation period, not that the control is poorly designed or that the service organization has a systemic problem. Context determines significance.

Auditors test most controls by sampling rather than 100% examination. For a control with 200 applicable instances per month (e.g., production deployments requiring code review), the auditor might sample 25–40 instances across the 12-month period. An exception in this sample means at least one of the sampled instances did not comply — the actual failure rate in the full population could be much higher or just limited to that instance.

How Exceptions Appear in the Report

In Section 5 (Tests of Controls), each control listing includes a "Results of Tests" column or paragraph. For controls that operated effectively, this states "No exceptions noted." For controls where exceptions were found, the auditor describes: the nature of the test performed, the sample size, the testing period, the number of exceptions identified, and a description of each exception.

A typical exception entry: "Control: Terminated employees' access to in-scope systems is revoked on or before their last day of employment. Test: Inspected the employee termination record and corresponding system access revocation records for 15 terminated employees during the period. Result: Three exceptions noted. For three of 15 terminated employees, access was not revoked until 3, 7, and 12 days after the last day of employment, respectively."

Following the exception description, the management response section provides the service organization's explanation and corrective action. This is written by management before the report is finalized and represents their formal response to the exception. Reading both the exception and the management response together gives a complete picture.

Assessing Exception Severity

Assess exceptions on three dimensions: (1) Control criticality — how important is the control that failed? An exception in access revocation (a high-risk control directly protecting customer data) is more concerning than an exception in security training completion (also important, but with more layers of compensating controls). Map the control to the Trust Service Criteria it addresses and the data it protects.

(2) Frequency and pattern — one exception in a sample of 25 represents approximately 4% of sampled instances. Three exceptions in a sample of 25 represents 12%. Is this a one-time anomaly or a pattern suggesting systemic breakdown? The exception description should note whether all exceptions share a common root cause (suggesting a systemic issue) or appear unrelated (suggesting isolated incidents).

(3) Remediation quality — was the root cause identified and credibly fixed? An exception with a management response that identifies the specific root cause (a specific process gap, a misconfigured system, an individual's error), describes the corrective action taken with dates, and explains how recurrence was prevented is more reassuring than an exception with a vague management response or no response.

Reading Management Responses

Management responses to exceptions are one of the most important signals in a SOC 2 report — they reveal how seriously the organization takes control failures and how capable they are of identifying and fixing root causes. A strong management response reads like an internal post-mortem: it names the specific cause, describes the actions taken (with dates), and explains the preventive measure.

Weak management responses raise more concern than the exceptions themselves. Responses like "We will improve our processes going forward" with no specifics, or responses that minimize the exception ("This was an isolated incident with no material impact") without substantive detail, suggest a culture that treats compliance as a checkbox rather than a genuine control environment.

Check the dates in management responses. A management response describing a corrective action "implemented on March 15, 2026" for an exception that occurred in June 2025 suggests a 9-month delay in addressing a known control failure. That pattern is more concerning than the original exception.

Common Exception Types

Access management exceptions: the most frequently occurring exception category across SOC 2 reports. Common variants: terminated employees with access not revoked on time; users with access that exceeds their role requirements (over-provisioned access identified in a review but not revoked within the required timeframe); quarterly access reviews not completed for one or more systems during the period; and access provisioned without an approved access request.

Change management exceptions: production deployments merged without required code review approvals; changes deployed to production before CI tests passed; emergency changes not retroactively documented within the required timeframe; and IaC changes committed directly without going through the PR review process.

Security training exceptions: employees who accessed in-scope systems during the period without having completed the required annual training; new hires who were given production access before completing onboarding security training; or training completion records that cannot be verified because the training platform did not retain completion data.

Vendor Review Process for Exceptions

When reviewing a vendor's SOC 2 report with exceptions as part of vendor due diligence, follow a structured review process. Step 1: Count and categorize exceptions by control area (access management, change management, monitoring, etc.). Step 2: Assess each exception against the three dimensions (criticality, frequency, remediation). Step 3: Identify whether any exceptions affect controls that directly protect your data or services.

For material exceptions — those that affect high-criticality controls or show patterns of failure — request a call with the vendor's security team. Ask them to walk through the exception, explain the root cause, and describe what has changed. Ask to see specific evidence of the corrective action (a screenshot of the branch protection rule that was fixed, a copy of the updated offboarding checklist, the Q1 access review record that was completed after the exception). Vendors who cannot or will not provide this evidence warrant heightened scrutiny.

Document your review decision. If you decide to continue using a vendor despite notable exceptions, record your assessment and rationale: "Vendor has two access revocation exceptions — reviewed management response showing corrective actions implemented on [date], confirmed with vendor security team that updated offboarding process has been operational for 6 months. Accepted risk with annual re-review." This documentation protects you in your own SOC 2 audit (CC9.2 testing) and in any future incident investigation.

Frequently Asked Questions

How many exceptions can a SOC 2 report have before we should be concerned?

There is no specific number. Assess the nature and area of exceptions, not just the count. One exception in access revocation may be more concerning than five exceptions in a lower-risk control. Focus on: Does the exception affect controls that directly protect your data? Is there a pattern suggesting systemic failure? Is the management response specific and credible? These questions provide more useful guidance than an exception count threshold.

Are exceptions the same as "deviations" in an audit report?

Yes. "Exceptions," "deviations," and "deviations noted" are used interchangeably in SOC 2 reports to describe instances where a tested control did not operate as described. Some auditors use slightly different terminology (e.g., "one instance noted where...") but the meaning is the same. All represent a control failure in the auditor's sample.

Can we ask the auditor to remove an exception from the report?

No. Auditors are professional and legally accountable for their work — they cannot remove a documented finding from a published report. What management can do is provide a strong management response that contextualizes the exception and describes remediation. Attempting to have findings removed would be professional misconduct on the auditor's part and could constitute fraud. If you believe an exception was documented incorrectly (the evidence supports the control operating correctly), raise this with your auditor before the report is finalized — there is a proper dispute process.

We found exceptions in our own vendor's SOC 2 report. Do we need to report this to our auditor?

Yes. When you review a subservice organization's SOC 2 report as part of CC9.2, your review should include documenting any material exceptions and assessing whether they affect controls you rely on. Your CC9.2 evidence should note: the vendor's report had [n] exceptions, you reviewed each one, your assessment of materiality, and any compensating controls you have implemented. Your auditor will ask whether you reviewed your vendors' reports and what you found.

Our internal SOC 2 audit is showing exceptions. What should we do now?

If exceptions are identified during fieldwork, work with your auditor immediately on two tracks: (1) Document and execute corrective actions as quickly as possible — revoke the overdue accesses, enforce the missing code reviews, complete the outstanding training. (2) Prepare a detailed management response documenting the root cause and corrective actions. Auditors have discretion in how they characterize exceptions — a single well-remediated exception with a strong management response is treated differently than a pattern of unaddressed failures.