SOC 2 Common Exceptions and Deviations

SOC 2 reports use a small set of precise terms, and mixing them up is the fastest way to misread one. An exception, a deviation, and a finding are not interchangeable words for "something went wrong"; each one describes a different kind of failure, sits in a different part of the report, and calls for a different fix. This piece walks through that vocabulary, where each term shows up in a report, and what actually happens once an auditor decides something qualifies as a problem worth naming.

Start with the basics. An exception is a specific, evidence-backed instance where a control did not meet the Trust Services Criteria, whether that failure came from bad design, inconsistent execution, or missing documentation. A deviation is a particular flavor of exception: a control that existed and was documented, but did not operate the way the documentation said it would. The security awareness training example is the one everybody in this field has seen at least once. Policy says training is due by a certain date, but a handful of employees finish a week late, and that gap between "what the policy says" and "what actually happened" is a deviation. A finding is the broader auditor observation that wraps around one or more exceptions, the narrative context that explains what was tested, what broke, and how often.

Where does a reader actually find these things? Section 4 of the report, titled "Results of Auditor's Tests," is where descriptive misstatements, design deficiencies, deviations, and noncompliance all get recorded. Anyone reviewing a vendor's SOC 2, or prepping their own organization for one, should treat Section 4 as the section to read first, not last. The opinion letter up front tells a reader what conclusion the auditor reached, while Section 4 tells a reader why.

The three types of exception and what each one is actually saying

The AICPA framework recognizes three distinct exception types, and each one points to a different failure mode.

A system description misstatement means the written description of the organization's services and systems does not match reality. Sometimes that's intentional, an omission meant to steer the auditor away from a weak spot. More often it's just neglect: a system changed, and nobody went back to update the description that accompanies the report. Either way, the signal to a reader is the same: the map does not match the territory, and that mismatch undermines confidence in every other claim the document makes.

A design deficiency means a necessary control is missing entirely, or an existing control was never built to actually achieve what it claims to achieve. Picture an access review process that runs like clockwork every quarter, reviewed by the right people, documented properly, except the query used to pull the list of active users quietly excludes a subset of accounts. The process runs, yet the control still fails, because it was never structured to catch everything it needed to catch. No amount of diligent execution fixes that; the fix has to happen at the policy or architecture level, before the next test even starts.

An operating effectiveness deficiency is different in kind, since here the control is designed correctly but just didn't run consistently across the period the auditor tested. This is the dominant exception type in SOC 2 Type II reports, and there's a structural reason for that: Type II tests whether a control worked throughout an entire observation window, often six or twelve months, not whether it existed on one single day. A well-designed access termination process that gets skipped twice during a busy quarter produces exactly this kind of finding. The root cause is almost always process, staffing, or tooling; it's rarely a policy problem.

That distinction matters more than it might seem at first glance. A design deficiency is a structural problem, and structural problems require structural fixes. An operating effectiveness deficiency is an execution problem, and execution problems get fixed by rebuilding a habit and proving it holds over time. Confuse the two, and remediation effort goes to the wrong place.

Where exceptions land in the auditor's opinion and what the opinion language actually means

Auditors issue opinions rather than pass/fail grades, and that distinction changes how a report should be read.

An unqualified opinion, often called "clean," means the controls tested were designed and operated effectively, and any exceptions noted were not pervasive enough to present material risk to the system as a whole. Note the wording there: clean doesn't mean zero exceptions, but rather that the exceptions which exist didn't rise to the level of undermining the whole picture.

A qualified opinion means misstatements or control failures were material, but limited in scope, not pervasive across the environment. Readers will spot this in a "Basis for Qualified Opinion" paragraph followed by "except for" language, carving out the specific area where reliance can't be placed. Qualified opinions show up often in an organization's first year of examination, when controls are new and evidence habits haven't matured yet. A qualified report is still a valid report, and the qualification is disclosed, bounded, and explained, not hidden.

An adverse opinion is the more serious outcome: deviations in design or operating effectiveness were both material and pervasive, and report users generally cannot rely on the system as described. A disclaimer is different again, and rarer, meaning the auditor could not form an opinion at all, typically because access was restricted or evidence simply wasn't available to test.

Here's the nuance that trips people up. An exception recorded in Section 4 does not automatically drag the opinion down a category. Auditors weigh materiality and pervasiveness before making that call, which raises an obvious follow-up question: what actually determines whether an exception stays contained, or spreads into the opinion itself?

How auditors decide whether an exception stays a footnote or changes the opinion

Two variables do most of the work here, pervasiveness and materiality, rather than the mere existence of an exception.

Frequency is the first signal, and it reads very differently depending on the ratio. "In 1 of 25 instances tested" is a rounding error in an otherwise functioning control, while "In 12 of 25 instances tested" describes a control that isn't really operating at all; it just happens to work sometimes. A couple of late access removals out of 25 sampled cases usually won't move the opinion, because the broader pattern still demonstrates the control is doing its job most of the time. High-frequency failure is a different animal, one that's systemic rather than incidental.

Which control failed carries just as much weight as how often. An exception buried in a peripheral administrative control, something like a rarely-used vendor form, just doesn't carry the same risk as an exception inside CC6.1, logical access management, or inside incident response. Auditors know this, and they weigh accordingly.

Pervasiveness asks a wider question: does this failure sit in one bounded corner of the environment, or does it bleed across multiple criteria and undermine confidence in the system generally? Pervasive failures are what push a report toward adverse territory. For an organization heading into an audit, the practical takeaway is straightforward: not every control carries equal consequence, so remediation effort belongs first wherever the opinion-level risk actually lives.

The eight control areas where exceptions appear most often

Eight areas account for the large majority, roughly 70%, of material findings across SOC 2 audits, and they recur because every organization, regardless of size or sector, has to implement them.

Logical access controls under CC6.1 top the list, and it isn't close. CC6.1 is the longest criterion in the framework, spanning identity and access management configuration, multi-factor authentication, hardening standards, physical access, and periodic access reviews. A gap anywhere along that chain produces an exception. Hardening standards documentation and quarterly access review records are the two pieces most often missing. In practice, that shows up as terminated employees who keep system access for days or weeks after their last day, or as shared credentials and generic admin logins that nobody can trace back to a single person.

Vulnerability and configuration management, CC7.1, produces its own recurring pattern: policy calls for quarterly vulnerability scans, and one or more quarters simply pass without a scan being run. This usually isn't a knowledge gap, since teams know the requirement exists; the failure happens when a busy quarter crowds it out.

Change management, CC8.1, is especially exception-prone at earlier-stage organizations that haven't formalized a software development lifecycle yet. Common findings include a developer approving their own release into production, emergency changes that never get documented after the fact, or gaps in the change log that nobody can explain.

Business continuity and disaster recovery, CC9.1, tends to slip between audit cycles. BCP and DR testing evidence is one of the most commonly missed continuous controls, because auditors expect completed tests at a defined frequency, at minimum annually, and semi-annually for many organizations, and testing is easy to defer when nothing has gone wrong recently.

Vendor and third-party risk management, CC9.2, introduces a different wrinkle: a vendor's own control failure becomes the service organization's exception. Gaps in documentation generate findings even when the underlying vendor risk was actually managed well; the paperwork just didn't keep up. Auditors check for a current vendor inventory, documented risk decisions, contracts carrying security clauses, and follow-up records for the vendors considered critical.

Security awareness training has to be documented, tracked, and completed annually, and that includes contractors, not just full-time staff. Even a small number of late completions counts as a deviation, the same pattern described earlier with the training-deadline example.

Incident response testing is its own category, separate from simply having a plan. An incident response plan that exists only as a document, never rehearsed, does not satisfy an auditor. The plan existing and the plan being exercised are two different requirements, tested two different ways.

Documentation and evidence collection ties all of the above together. A control that ran perfectly but can't be evidenced gets treated exactly like a control that never ran. Manual collection, screenshots pasted into folders, spreadsheets updated by hand, is the root cause behind most evidence gaps, because recurring tasks get missed during busy quarters and only surface once an auditor asks to see proof.

Why the same control environment produces exceptions year after year

Exceptions rarely show up at random. They cluster around a handful of predictable organizational failure modes, and the same environment tends to produce the same kind of exception repeatedly unless something structural changes.

Policy-to-practice misalignment is the most common root cause. An organization adopts a generic policy template, never fully communicates it to the staff who have to follow it, and the written control drifts away from what actually happens day to day, with nobody noticing the drift until an auditor points at the gap.

Mid-period control changes deserve special attention, because they're arguably the most damaging root cause on this list. A control operates correctly at the start of the observation window, then something changes partway through, a tool gets swapped, a process owner leaves, a workflow gets automated, and nobody updates the documentation or re-tests the revised version. That single event can produce all three exception types at once: a description misstatement, because the write-up no longer matches reality; a design deficiency, if the new version wasn't built to meet the original objective; and an operating effectiveness failure, since the control wasn't consistently tested across the full period either way.

Evidence collection as an afterthought is its own pattern. Teams build the control itself but never build the habit of capturing proof alongside it. The absence of a screenshot or a log entry looks, to an auditor, exactly like the absence of the control, since there's no way to distinguish "we did this but forgot to save the record" from "we didn't do this," and auditors have to treat the two as identical.

Inter-departmental communication gaps round out the list. Compliance steps fall through the cracks whenever ownership is unclear, or when a handoff between two teams happens informally, over a Slack message instead of a documented process. One survey of risk leaders from 2024 found that 44% admitted struggling with risk visibility ahead of audits, and 27% flagged compliance as an urgent concern, numbers that suggest these conditions are widespread, not isolated to poorly run organizations.

What exceptions mean for customers, prospects, and the business relationships that depend on the report

Sophisticated enterprise buyers don't treat an exception as an automatic red flag. They read it in context, and the questions they ask tend to be consistent: which control failed, how often, and does management's written response actually address it, or does it wave the problem away?

An exception buried in a minor administrative control reads very differently in due diligence than one sitting inside CC6.1 or incident response. That's worth repeating, because it echoes the earlier point about which controls carry the most weight with auditors; the same hierarchy holds true for the customers reading the report afterward.

Management responses matter more than they might seem to at first. A credible service organization attaches a written response to each finding, laying out what got fixed or what's currently being fixed. When a significant finding shows up with no response attached at all, that absence is itself worth noticing.

The opinion category carries direct commercial weight. Most enterprise prospects require a clean, unqualified opinion before they'll sign a contract, and a qualified opinion, even one that's fully explained and bounded, can slow down or complicate a new business conversation.

There's a downstream wrinkle worth understanding too: complementary user entity controls, or CUECs. These are controls the service organization assumed the customer would put in place on their own end. If a customer never implements the CUECs their vendor's report assumes, that customer's own auditor may raise exceptions in the customer's report for that exact gap, regardless of how well the vendor's own controls performed. Some customers push vendors to trim their CUEC lists down, specifically to reduce their own compliance burden, and that's a tension worth watching for when reviewing or negotiating around a report.

One last point that gets missed constantly: a clean overall opinion is not the same thing as a clean detailed report. An unqualified opinion can still sit above a Section 4 full of exceptions, individual controls that failed or ran inconsistently but weren't pervasive enough to change the opinion category. Reading only the opinion paragraph and stopping there means missing most of the actual signal in the document.

How organizations respond to exceptions — remediation timelines and the path back to a clean report

Remediation isn't one-size-fits-all; the exception type dictates the path.

A design deficiency needs a fix at the policy or architecture level before re-testing means anything, since running the same flawed process more carefully doesn't close a structural gap; the structure itself has to change. An operating effectiveness deficiency calls for root cause work first: is this a staffing problem, a tooling problem, or a process that was simply too easy to skip? Once that's answered, the habit gets rebuilt and evidence accumulates across the next observation period, proving the fix held rather than just claiming it. A system description misstatement gets resolved by updating the documentation to match the environment as it actually runs, and the recurrence gets prevented by folding a documentation review step into whatever change management process already exists.

Timelines vary by severity, and they're worth setting expectations around early. Minor issues typically close out in something like 30 to 60 days, while significant control failures run longer, closer to three to six months. Issues that require a control to be rebuilt and then demonstrated operating consistently over time need six to twelve additional months before the next examination window can even show effectiveness.

That last point circles back to something covered earlier: operating effectiveness has to be demonstrated across a period, not proven true on a single date. Patching a control the week before an auditor arrives satisfies nothing under Type II standards; the fix has to precede the next full observation window, not scramble to catch up with it.

Engaging an experienced SOC auditor early, during a readiness assessment rather than waiting for fieldwork to expose the gap, changes the odds considerably. Firms with deep experience across specialized sectors, mortgage banking, multifamily housing, financial services, tend to spot the difference between a cosmetic documentation gap and a control environment heading toward qualified opinion language, often before the organization itself realizes there's a problem.

None of this points toward a report with zero exceptions, ever, as some kind of finish line. That's not really the goal, and treating it as one misses the point of the exercise. The goal is a report where exceptions stay bounded, get explained clearly, trend in the right direction year over year, and come attached to a management response that shows the organization actually understands what broke and why. That's the difference between an exception that erodes trust and one that, handled well, demonstrates it.