SOC 2 Exceptions and Qualified Opinions Explained

A SOC 2 exception is a documented finding from an auditor’s control testing. It does not automatically modify the opinion. A qualified opinion is an “except for” conclusion about a material matter whose effects, or possible effects when evidence is insufficient, are not pervasive. Qualifications can concern the system description, control design, operating effectiveness, or a scope limitation. Read the basis for the opinion and the detailed findings together to understand what customers can rely on.

Decoding Exceptions and Qualified Opinions in SOC 2

In a SOC 2 Type 2 audit, a deviation is a sampled instance where evidence does not meet the test of the described control. For example, a new hire completing security training on day 35 would deviate from a company policy requiring completion within 30 days. An exception documents the finding; it may describe one deviation or several. The auditor separately evaluates whether the findings affect the opinion, including whether other controls address the same risk.

Why This Distinction Matters for SOC 2 Compliance

An exception needs evaluation and, where appropriate, remediation. A qualified opinion identifies a material matter, but it does not always mean a control failed: a scope limitation may prevent the auditor from obtaining sufficient evidence. Whether a customer accepts the report depends on the matter’s relevance to the service they intend to use and their tolerance for the remaining risk.

Aim for controls that meet your service commitments and system requirements, and address failures promptly. Document any compensating controls so the auditor can evaluate the full control environment. A SOC 2 report example shows how the opinion and detailed findings fit together.

The Anatomy of a SOC 2 Report Finding

In a Type 2 report, look for exceptions in the section describing the auditor’s tests of controls and results, commonly Section IV. Section numbering varies by firm. Use the control statement, procedure, and result together to assess the finding and prepare a response.

Key Components of an Exception

The following components help explain a testing exception. Reports vary in layout and the detail they disclose, so request clarification where the report does not provide enough information. This is also a useful structure for documenting internal readiness findings.

Here are the main parts you’ll see:

• The Control: The specific control statement being tested, which is mapped directly to an AICPA Trust Services Criteria, such as CC6.2 and CC6.3 from the Security criteria.
• Auditor’s Test Procedure: A detailed description of the steps the auditor took to test the control’s effectiveness. For instance, “For a sample of terminated users, the auditor inspected system logs to verify that access was removed within the timeframe defined in the company’s access control policy.”
• Nature of the Exception: A factual statement describing the deviation or deviations found, precisely how the sampled items failed the test, and what that means for the control being tested.
• Population and Sample Size: The total number of items available for testing (the population) and the subset the auditor selected to test (the sample). Sample size and selection method are the auditor’s own judgment call, not a fixed rule; the worked example below uses a population of 50 and a sample of 25 purely to illustrate the format. See our SOC 2 sample size guide for how auditors actually decide that number.
• Number of Deviations: The exact count of sampled items that failed the test procedure. This is what “Nature of the Exception” reports on: a single deviation, or a pattern across several.

Read those parts together, rather than treating the exception heading as a verdict. The control, procedure, population, result, and management response should describe the same problem at the same level of specificity. The SOC 2 Quality Guild’s report-evidence rubric similarly treats internal consistency and concrete testing detail as useful signs of reliability. They do not, on their own, determine whether the vendor is acceptable for your use case.

Dissecting a Sample SOC 2 Exception

Let’s examine an illustrative example of how an access control exception is documented. This format provides the objective evidence needed for you, your auditor, and your customers to evaluate the finding’s impact.

Sample SOC 2 Exception Documentation

This illustrative format connects a control to its test and findings; it is not a mandatory report template.

This clear, quantifiable failure in meeting the control objective specified in CC6.2 and CC6.3 directly impacts the Security criterion. This matters for SOC 2 readiness because it demonstrates that policies alone are insufficient. You must have mechanisms to enforce those policies and generate auditable evidence. By using this same rigorous documentation format during your internal assessments, you force your team to confront control gaps with the same scrutiny an external auditor will apply, significantly reducing the risk of unexpected exceptions or a qualified opinion.

Common Causes of SOC 2 Exceptions

SOC 2 exceptions are rarely random; they are typically symptoms of underlying process weaknesses or systemic issues. For an organization pursuing a SOC 2 report, identifying and addressing these root causes proactively is the most effective strategy to prevent exceptions and avoid a qualified opinion. Understanding where auditors most commonly find failures allows you to focus your readiness efforts on high-risk areas, ensuring your controls are not just designed correctly but are also operating effectively and provably.

Access Control Failures

Access management is an important area to review because a missed removal or inappropriate privilege can expose customer data. Failures can arise from a disconnect between written policies and operational practices, especially when processes span HR and IT systems.

Offboarding controls commonly support CC6.2 and CC6.3, covering removal of credentials and access that is no longer authorized. The AICPA’s SOC 2 report-review checklist uses these criteria for its terminated-user example. Its 24-hour deadline is an illustrative company control, not a universal AICPA requirement. Review timing comes from the organization’s policy and risks.

Examples of Control Failures

Beyond general access control, several specific operational failures repeatedly lead to exceptions. These are critical areas to address during your SOC 2 readiness phase.

• Employee Offboarding Delays: A user is terminated in the HR system but retains access to critical systems. This can indicate a failure of the company’s offboarding control supporting CC6.2 and CC6.3.
• Inconsistent Access Reviews: Periodic access reviews can support role-based authorization under CC6.3. The organization defines a review frequency appropriate to its risks; quarterly reviews are a common policy choice, not a fixed frequency in the criterion. Retain evidence of the review and follow-up.
• Poor Change Management Evidence: Controls supporting CC8.1 should retain authorization, testing, and approval evidence linked to the change. A retained chat approval may help if it identifies the change, approver, and timing; undocumented verbal approval is harder to substantiate.

Missing evidence can prevent an auditor from establishing that a control operated. The auditor evaluates whether other appropriate evidence is available and how any remaining limitation affects the examination.

Complex migrations, such as moving regulated data between collaboration platforms, create more opportunities to miss a control or lose evidence. Automation can help, but SOC 2 does not require every workflow to be automated. Manual controls also need clear owners, repeatable procedures, and retained evidence.

How Auditors Judge Exceptions

When an auditor uncovers a SOC 2 exception, they begin a critical evaluation process to determine its significance. The decision to issue a qualified opinion is not based on the sheer number of exceptions but on their materiality. A material exception is a control failure so significant that it could mislead a user of the report or impact their decision-making. For a company undergoing a SOC 2 audit, understanding this judgment process is vital. It helps you prioritize which control gaps to fix and how to discuss any potential findings with your auditor.

The Pervasiveness and Severity Test

Auditors assess materiality by examining the severity and pervasiveness of each exception. This framework helps them distinguish between an isolated mistake and a systemic breakdown of the control environment.

• Severity: This measures the potential impact of the control failure. For example, a single new hire completing security training one day late is a low-severity exception. In contrast, the failure to apply a patch for a critical remote code execution vulnerability for 90 days is a high-severity failure that directly threatens the Security criterion.

• Pervasiveness: This concerns the extent of the effects on the subject matter, including whether they are confined to particular areas or affect the control environment more broadly. A sample failure percentage alone does not establish pervasiveness.

Materiality and pervasiveness affect the opinion differently. Under AICPA AT-C 205, paragraphs .72–.78, a material matter that is not pervasive can lead to a qualified opinion. Material and pervasive misstatements lead to an adverse opinion. Inability to obtain sufficient evidence can lead to a qualification or, if the possible effects are material and pervasive, a disclaimer. The auditor evaluates the nature and extent of the matter; a count of offboarding failures alone does not predict the outcome.

Check the exception pattern against the opinion

Start with the opinion and any Basis for Qualified Opinion, then trace the cited criteria into the detailed testing section. The narrative should make sense across those sections: a qualified opinion should identify the matter that drove it, and the testing detail should let you understand its scope. If several exceptions concern the same risk but the opinion gives you no way to reconcile them, ask the vendor or auditor for an explanation. That mismatch is a review question, not a conclusion about the audit.

An unqualified opinion does not make every exception irrelevant. For a buyer, the practical question is whether a finding affects the systems, data, or commitments you will rely on. That is a different decision from the auditor’s report opinion.

The Role of Compensating Controls

Before finalizing their opinion, auditors will also consider the presence of compensating controls. These are alternative controls that mitigate the risk associated with the failure of a primary control.

For example, imagine a firewall rule intended to block traffic from known malicious IP addresses was misconfigured during the audit period. A separate host-based firewall that blocked those connections throughout the same period could address the same risk. The auditor would need evidence of its configuration and operation before treating it as a compensating control.

While the primary control failed, the compensating control effectively reduced the risk to an acceptable level. The exception will still be noted, but the auditor may conclude it’s not material enough to qualify the opinion.

This demonstrates that auditors evaluate the control environment holistically. A strong, layered security posture can prevent a single point of failure from becoming a material weakness. As you can discover more about how to handle SOC 2 test exceptions on strikegraph.com, understanding and documenting your compensating controls is a critical part of audit readiness and can be the key to maintaining an unqualified opinion even when minor exceptions are found.

Evaluating a Vendor with a Qualified SOC 2 Report

Receiving a vendor’s SOC 2 report with a qualified opinion is not an automatic disqualification; it is a trigger for heightened due diligence. Read the basis for the qualification to establish whether it concerns the system description, control design, operating effectiveness, or a limitation on the evidence available. Then assess its relevance to your organization. For anyone in a compliance or security role, knowing how to properly dissect a qualified report is a critical skill for managing third-party risk effectively.

The Initial Triage

Locate the independent service auditor’s report, commonly Section I, and read the Basis for Qualified Opinion. Establish whether the matter concerns the description, design, operating effectiveness, or available evidence, and which systems or criteria it affects. Do not assume the qualification is limited to a single Trust Services Category.

Scale vendor follow-up to the risk the exception creates for your intended use.

What the report shows	Decision question	Constructive next step
A bounded exception outside your planned use	Does it touch your data, integration, or the service commitment you depend on?	Document why it is out of scope for your risk assessment and monitor the next report or bridge period.
An exception affecting a control you rely on	Is the stated cause understood, and is the residual risk acceptable before remediation?	Ask for the remediation owner, target date, and evidence that the corrected control has operated.
A qualified opinion or recurring issue in a core area	Can the vendor meet your requirements with safeguards, a changed scope, or a later start date?	Escalate the decision, define any compensating safeguards, and set a condition for accepting evidence of remediation.

A Step-by-Step Vendor Evaluation Process

A structured evaluation ensures your analysis is thorough, repeatable, and defensible. The goal is to move beyond the “qualified” label and understand the specific context of the failure and its potential impact on your data and services.

Here’s a practical process to follow:

1. Trace the Basis for Qualified Opinion: For a Type 2 testing finding, inspect the relevant control tests and results, commonly Section IV, including any sample information. For a description, design, or scope matter, follow the auditor’s explanation instead of assuming a sample failure caused the qualification.
2. Read Management’s Response, If Provided: It may appear beside the finding or in a separate section. Treat the response as a commitment, not proof that the issue is fixed. Look for a stated cause, an owner, a target date, and a way to verify the corrected control has operated.
3. Determine the Real-World Impact: This is the crucial step. Does the failed control protect data or systems relevant to your engagement with the vendor? A failure in physical security controls at a data center you are not using may be irrelevant. However, a systemic failure to remove terminated employee access (CC6.2 and CC6.3) for a SaaS platform where your customer data will reside is a direct and material risk.
4. Request Remediation Evidence: Ask for dated records showing what changed and how the corrected control has operated. A management response or bridge letter can explain the claimed fix, but does not provide independent auditor assurance. If that assurance is needed, request an appropriately scoped subsequent examination or other auditor reporting.

This methodical approach turns a potentially contentious review into a collaborative, risk-based discussion focused on tangible evidence.

Vendor Qualified Opinion Evaluation Checklist

Use this checklist to ensure a consistent and documented vendor review process. This creates an audit trail demonstrating your organization’s due diligence.

Mastering this evaluation process does more than protect your organization from supply chain risk. It provides a blueprint for how your own customers will scrutinize your SOC 2 report. This perspective is invaluable for building a compliance program that not only passes an audit but instills genuine confidence in your clients.

Turning SOC 2 Readiness into a Continuous State

Operate controls throughout the reporting period and retain evidence as work happens. Waiting until fieldwork to collect records can leave gaps that are difficult to reconstruct. Continuous monitoring helps identify failures, but it does not guarantee effective controls or an unmodified opinion.

A mature SOC 2 program begins with a rigorous readiness assessment where you act as your own auditor, pressure-testing your controls against the AICPA Trust Services Criteria. The goal is to find and fix control gaps yourself, long before an external auditor has the chance. This internal diligence is the foundation of a clean report.

From Manual Checklists to Automated Proof

Automation can reduce missed tasks such as de-provisioning or scheduled access reviews. It is a control-design choice, not a universal SOC 2 requirement.

An HRIS-to-identity-provider workflow can remove access from connected applications when an employee is terminated. Test which accounts it actually covers, handle disconnected applications, and retain timestamped logs with appropriate access and retention controls. Automation does not make those logs immutable or sufficient audit evidence by itself.

Review the detailed findings and their relevance to your intended use even when the opinion is unmodified. A qualified opinion calls for additional investigation into the basis for the qualification.

An unmodified opinion does not automatically approve a vendor for your use case. Decide whether to accept the residual risk after reviewing scope, exceptions, customer responsibilities, and remediation.

Adopt Continuous Control Monitoring

The cornerstone of a modern SOC 2 readiness program is continuous control monitoring (CCM). Instead of manually gathering screenshots and logs just before the audit, CCM tools automatically collect evidence from your core systems throughout the year.

• Effortless Evidence: CCM platforms integrate with your cloud providers, code repositories, and HR systems to automatically log events like access changes, policy updates, and security training completions, storing them in an audit-ready format.
• Real-Time Alerts: This technology can instantly detect and alert you to control failures — such as a new public S3 bucket being created without proper tags — allowing for immediate remediation rather than discovering the gap months later during an audit.
• No More Audit Fatigue: When your audit fieldwork begins, a significant portion of the required evidence is already collected, organized, and mapped to specific SOC 2 controls. This drastically reduces the burden on your engineering and security teams.

Continuous monitoring can help retain evidence throughout the reporting period. A Type 2 examination still evaluates controls over that historical period; monitoring does not turn the report into real-time assurance.

Understanding how auditors evaluate SOC 2 exceptions and qualified opinions helps you prioritize fixes: address material gaps, document compensating controls, and consider automation where tasks fail repeatedly. Operate each control at its defined frequency throughout the reporting period and retain the evidence the auditor needs.

---

Compare audit firms’ scope, pricing, and timelines in the SOC 2 auditor directory. Ask how each firm evaluates exceptions and communicates the basis for a modified opinion.