SOC 2 Common Exceptions and Deviations
Most SOC 2 reports contain exceptions, and they're not what you think they are.
A SOC 2 exception gets treated, far too often, as a scarlet letter: proof the audit was failed and the program is broken. SOC 2 does not produce a pass or fail result and does not issue a certificate; it produces an attestation report in which the auditor lands on one of four opinions, unqualified, qualified, adverse, or disclaimer of opinion. An exception is a specific, evidence-backed finding inside that report rather than a verdict on the whole control environment, and per Lazarus Alliance's benchmark, 71 percent of SOC 2 examinations contained at least one. That figure alone should reset expectations: an exception is closer to the norm than the exception to it.
Two terms get used as if they were interchangeable, and they are not. A deviation is a single sampled item where the evidence does not match the described control, the kind of thing an auditor finds when a new hire completes security training on day 35 against a stated 30-day policy. An exception is the auditor's formal written disclosure of one or more deviations against a specific Trust Services Criterion. A deviation is a data point; an exception is a conclusion drawn from one or more data points and written into the report with consequence. A related distinction separates an exception from an audit finding: an exception is narrow and evidence-backed, appears formally in the report, and can affect the opinion, while a finding is a broader observation that may surface in a management letter without automatically touching the opinion.
The framework being tested against has not shifted under anyone's feet. The AICPA continues to use the 2017 Trust Services Criteria with revised points of focus from 2022, codified in TSP section 100, and that criteria set was not changed or renumbered for 2026. An exception is measured against a stable, well-established yardstick, not a moving target. One more piece of the mental model matters before going further: almost all exceptions surface in SOC 2 Type II examinations, because Type II tests operating effectiveness across an entire observation period, rather than Type I's narrower question of whether a control existed on a single date. A Type II report asks whether the lock was used correctly every day for months, and that is a much harder standard to clear without a single slip.
The three structural types of SOC 2 exceptions
Treating them as interchangeable is where remediation plans go wrong before they start.
A design deficiency means a required control is missing, or was never built to achieve its stated objective. The gap here is structural rather than operational. The clearest example is an organization with no MFA policy implemented on production accounts: there is nothing to test for effectiveness, because the control that should exist simply does not. A design deficiency may produce an exception, and if significant, typically requires remediation before a clean report becomes possible.
A system description misstatement is an error or omission in how the organization describes its systems and services, specifically in Section III of the report. One documented case involved a report that described infrastructure as hosted on-premise, when the company had actually migrated to AWS six months into the observation period without ever updating Section III. The report describing it was wrong, and that is its own category of problem.
An operating effectiveness deficiency is different again: a correctly designed control that simply failed to work consistently across the observation period. Quarterly access reviews that were documented but only completed twice out of four times in the period fall into this category. This is the most common type found in Type II examinations, precisely because the auditor is testing consistency across the full window rather than existence at a single point in time.
The three types do not always stay in their lanes: mid-cycle process or infrastructure changes, made without corresponding updates to controls and to the system description, stand out as the single most dangerous root cause in the entire typology, because a change of that kind can produce all three exception types simultaneously. One change event, three separate findings. That is why mid-cycle change management deserves attention disproportionate to how routine it feels day to day.
Where exceptions form
Knowing the typology answers what kind of exception has occurred. It does not answer where exceptions tend to originate, and the honest answer is that they cluster hard around a small number of control areas, almost all of them sharing one of two root causes: a process that changed after the control was designed, or manual execution that breaks down the moment operational pressure rises.
Access control and user provisioning, the Trust Services Criterion labeled CC6, is the leading source of exceptions across examinations, appearing in a majority of reports that contain any exception at all. Within that criterion, one sub-control generates more findings than any other: CC6.2, timely removal of access for terminated users. The mechanism is almost always the same. A user is terminated inside the HR system, but access to AWS, Salesforce, or a production database keeps working, because HR and IT systems were never integrated to talk to each other. One documented scenario had a former employee retaining admin access to production systems for 18 days against a policy that required prompt revocation.
Change management, CC8.1, runs a close second, and it appears disproportionately in the reports of early-stage companies that have not yet formalized a software development lifecycle. The typical failures are mundane and familiar to anyone who has shipped code under deadline pressure: a developer approving their own release into production, changes going live without a complete approval trail, testing evidence that was never captured, emergency changes that never got documented after the fact.
Vulnerability management, CC7.1, deserves closer attention because it shows the mechanism by which a company's own stated policy becomes the auditor's standard of judgment. Running through CC6, CC8.1, and CC7.1 alike is the same manual-evidence root cause: teams relying on screenshots and spreadsheets tend to miss recurring control executions during busy quarters, and the gaps only surface later when the auditor samples the period and finds the hole. Across 75 SOC 2 examinations completed between January 2025 and June 2026, these areas, alongside risk assessment and vendor management, system description accuracy, security configuration, and incident response testing, made up the seven most common exception areas, with access control and change management sitting clearly at the top.
How auditors evaluate exceptions and qualify the opinion
A single exception landing in the report does not automatically tip the opinion into qualified territory. The auditor weighs nature, frequency, impact, and the presence of compensating controls, and that judgment call, not a mechanical scorecard, is what actually decides whether a finding reshapes the overall conclusion.
The opinion spectrum has four points on it. Unqualified, the clean opinion, means every tested control operated as described with no exceptions noted anywhere. Qualified means one or more specific controls failed testing, the matter is judged material but not pervasive, and the report carries an "except for" conclusion that lets the rest of the findings stand on their own; this is by far the most common modified opinion. Adverse means the deficiencies are pervasive enough that controls cannot be relied upon across most of the system, and this outcome is rare. A disclaimer of opinion means the auditor could not obtain sufficient evidence to form a conclusion at all, the result of missing logs, missing tickets, or no audit trail to sample against. Which part of that opinion gets modified depends on the category of exception: a qualification can concern the system description, control design, operating effectiveness, or a scope limitation, and each points the reader toward a different part of the report.
What tips a report from clean to qualified comes down to materiality, and auditors weigh whether a deviation is isolated or forms part of a pattern across a criterion, the nature of the control gap relative to the Trust Services Criteria it touches, and whether a compensating control addresses the same underlying risk. Multiple exceptions showing a pattern across the same criterion are what push a report toward qualification. That makes documenting compensating controls something other than a workaround; it is the auditor's explicit instruction, a chance to present the full control environment so the gap can be weighed against everything surrounding it.
It helps to understand how the sampling itself works, because it explains why a single deviation can matter so much. Type II tests operating effectiveness over the observation period, rather than just whether a control existed on one date, as Type I does. They pull a sample, commonly somewhere between 25 and 40 items for a large population of 250 occurrences or more, following AICPA sampling guidance tied to how frequently the control is supposed to run. When a control statement sets a firm cadence, weekly scans, quarterly reviews, a single deviation inside that sample is frequently enough to generate a written exception. The answer sits in what the organization itself promised: the auditor is not inventing a standard, it is holding the company to the cadence it wrote down.
Reading the report well means reading past the headline. Exceptions appear in the section describing tests of controls and results, commonly Section IV though numbering varies by firm, and the qualification language that appears earlier in Section II tells a reader almost nothing on its own. The control statement, the test procedure, the population size, the deviation count, and the management response all need to be read together, since this combination, not the four-word label the opinion carries, is what determines how serious a given exception really is.
What a qualified opinion costs
Understanding how an opinion gets modified is only useful once the stakes of that modification are clear. A qualified opinion signals a diagnosable deficiency to a specific set of readers, vendor-risk teams, financial auditors, and regulators, and those readers are increasingly trained to read the exception details themselves rather than stopping at the headline opinion.
The commercial impact is direct. A clean opinion sitting alongside a visible access-deprovisioning failure in the findings still requires a credible management response from the organization being reviewed.
Financial services and mortgage banking make the stakes concrete rather than abstract. SOC 1 and SOC 2 serve different readers and do not substitute for one another: a SOC 1 report under SSAE 18 exists so a customer's financial auditor can rely on controls that touch numbers flowing into financial reporting, while a SOC 2 exists so security and procurement teams can rely on controls over customer data. The Mortgage Office, a loan servicing platform, announced SOC 2 Type II compliance in October 2025, validated by an unqualified opinion confirming enterprise-level security for customer data. For platforms operating in that same environment, a qualified opinion raises direct questions with bank examiners reviewing third-party technology risk.
The regulated real estate and healthcare space adds another layer. FHA loans tied to skilled nursing facilities require the property owner to submit audited financial statements annually within 90 days of fiscal year-end, prepared under 24 CFR 5.801 and 200.36 guidelines. The SEC's 2024 amendments to Regulation S-P now require investment advisors to oversee service providers that have access to customer information, which adds a vendor-SOC-review obligation to advisors serving high-net-worth individuals and family offices. A single qualified opinion, in other words, rarely stays contained to the organization that received it.
Responding to an exception once it is in the report
Nothing about a qualified opinion or a visible exception is final the moment the report is issued. The management response attached to each exception is the organization's first and most visible chance to shape how a reader interprets the finding, and a specific response keeps that finding from staying contested, while a weak one lets it settle quietly into the record.
Every SOC 2 Type II report contains a section, typically titled "Description of Tests of Controls and Results," where each tested control sits next to the testing procedure applied, the result produced, and, wherever an exception was found, a management response. A weak response offers something like "the finding was addressed" and stops there, which gives a vendor-risk reviewer nothing to actually evaluate. A response that genuinely reduces reader concern covers four specific elements: the root cause behind the deviation, the specific corrective action taken, the date that action was implemented, and any compensating control that was already in place during the gap.
That four-part structure is not a formality for its own sake. It answers, in order, why this happened, what changed, when it changed, and what was protecting the data in the meantime. An exception written up without that context reads as an open question. An exception written up with it reads as a closed loop, evidence that the organization understood its own control environment well enough to diagnose the gap and close it. Given how routinely exceptions appear, appearing in 71 percent of examinations by one benchmark, the report itself was never going to stay spotless. What stays within the organization's control is how clearly it explains, in its own words, what the auditor found and what happened next.
