Audit Findings vs Observations vs Exceptions in SOC 2 Reports

SOC 2 reports use three words, "observation," "finding," and "exception," that sound almost interchangeable but mean entirely different things to the auditor writing them. Confuse them and a procurement team either panics over nothing or waves through a vendor with a genuine control failure buried in Section IV. This piece untangles each term, shows exactly where it sits in the report, and explains what it should trigger in whoever is reading or responding to it.

What an observation is (and why it stays out of the report)

Start with the term that never actually makes it into the document most people are staring at. An observation, sometimes called a management letter comment, is a recommendation the auditor raises during the exam that falls outside the formal scope of what got tested. It is not a control failure. It does not touch the auditor's opinion. Think of it as the auditor tapping management on the shoulder after the meeting, not standing up in front of the room.

Here is the part that trips people up: the management letter is private. It goes to management, and it stays there. Nobody reviewing the SOC 2 report, no customer, no third-party risk analyst, ever sees it. Which raises a fair question: if a report shows zero exceptions, does that mean the auditor found nothing worth mentioning?

Not necessarily. It might mean the auditor's concerns went into a letter nobody outside the company will ever read. For buyers, that is worth sitting with. Absence of a documented finding is not proof of a spotless environment; it might just mean the concerns got recorded somewhere else. For the audited organization, the management letter is not a pass. It is closer to a warning shot: whatever's flagged there has a real shot at becoming a testable, reportable control failure next cycle if nobody acts on it.

What a deviation is and how it becomes an exception in the report

A deviation is small and specific: one sampled item that fails the test procedure. Say a control states new hires complete security awareness training within 30 days. The auditor pulls a sample, and one hire finished on day 35. That single instance (one person, one missed deadline) is a deviation.

An exception is what happens when the auditor writes that up formally. It names the control being tested, describes the deviation or the pattern of deviations found across the sample, and becomes part of the permanent record. A single deviation can be enough to generate an exception. So can five deviations scattered across one sample of forty. The exception is the auditor's documented conclusion, not a tally of individual failures.

Where does this live? In a Type 2 report, exceptions sit in the control testing matrix, Section IV, right next to the control they belong to. That section is doing more work than any other part of the report, and it rewards a slow read rather than a skim. Exceptions carry evidentiary weight precisely because they are auditor-verified. Observations are the auditor's opinion of what could be better. Exceptions are the auditor's documentation of what did not hold up under testing.

What a finding is and how it differs from an exception

"Finding" is the loose one. It is a wider category that includes exceptions but also covers risks, weaknesses, or general observations the auditor decides to surface, some of which never touch a specific control test. Every exception is a finding. Not every finding is an exception, and that asymmetry is exactly where confusion creeps in.

An exception is always narrow and evidence-backed: a named control, a documented test, a documented failure. A finding can be broader, more of an auditor's editorial comment stitched around one or more of those specifics. Miss that distinction and the risk runs in both directions. Read a general finding as though it were a formal exception, and perceived vendor risk inflates for no good reason. Read an actual exception as just another loose "finding," and an auditee might under-respond to something the auditor considered serious enough to write into the testing matrix.

Part of the mess here is that plenty of practitioners, and no small number of vendor security teams, use "finding" as a catch-all in conversation. Nobody is lying when they say it. They are just being imprecise, and imprecision is expensive when a vendor risk score depends on getting the category right.

The three types of exceptions the AICPA taxonomy recognizes

Not all exceptions are the same, and the AICPA taxonomy splits them into three buckets that call for three different fixes.

Design deficiency means a necessary control is missing entirely, or the control that exists cannot achieve its objective even when followed exactly as written. The problem is structural. Nobody did anything wrong; the control itself was built wrong.

Operating effectiveness deficiency is different: the control is designed correctly, but it broke down in practice. Vulnerability scans were configured on schedule, say, but several required scans got skipped during the audit window. The blueprint was fine. Execution wasn't consistent.

System description misstatement is the odd one out, because it is often not a control failure at all. It is a documentation failure, an error or omission in how the organization describes its own systems in Section III. A common version: the system description still references an on-premise data center months after the workload moved to a cloud provider. Nobody's access controls failed. The paperwork just didn't catch up to reality.

Why does the category matter so much? Because the fix is entirely different in each case. A design deficiency means rebuilding the control from scratch. An operating deficiency means enforcement and better evidence collection, not a redesign. A misstatement means updating the documentation, full stop. Get the category wrong and the remediation effort goes toward fixing something that was never actually broken, leaving the real gap open for the next audit cycle.

How exceptions actually appear across real SOC 2 reports

Numbers help ground this. CBIZ CPAs' 2024 SOC Benchmark Study found that 54.9% of SOC 2 reports contained at least one control exception, up from 51% the year before. At the same time, the average number of exceptions per report actually dropped, from 2.7 down to 1.73. Read that combination carefully: more reports had at least one exception, but each report that did have one tended to have fewer of them. More scrutiny, tighter results, in a sense.

The same study broke down where exceptions cluster most: business approvals and reviews at 16.5%, user access reviews at 15.6%, terminations at 12%, change management at 11.7%. A separate finding in that dataset showed a small handful of exception categories accounting for roughly 70% of everything material. The same controls keep failing, across different companies, in different industries, year after year. That's a pattern worth its own section below.

Worth noting too: 23% of reports reviewed in that 2024 study contained more than 150 security controls. Run the math on any environment with 150-plus controls tested across a sample, and the odds of at least one exception showing up start looking less like bad luck and more like basic statistics. A report with one or two exceptions is not an outlier. It is close to the expected outcome. A perfectly clean report deserves a second look, not because it's suspicious, but because it might reflect a narrower audit scope rather than a flawless environment. Neither interpretation should be assumed automatically.

Where each term appears in the report's structure

Reading a SOC 2 report top to bottom without knowing what lives where wastes time. Section I holds the auditor's opinion: unqualified, qualified, adverse, or a disclaimer. It's the summary verdict, and it is not where the detail lives, so don't linger there looking for specifics.

Section III is the system description, the organization's own account of its systems and services. This is where a description misstatement would originate, since it's the company's narrative, not the auditor's test result.

Section IV is the control testing matrix, and this is where exceptions actually live: each one sits next to the control it belongs to, with the auditor's description of the deviation. This is the section that rewards close reading over skimming.

Section V is the management response, and here's the catch worth repeating: it is not subject to auditor verification. The auditor does not attest to a word of it. A strong response names a root cause and a corrective action with a timeline attached; a vague one is itself information, telling a reader something about how seriously the organization treats its own failures.

Observations, as covered above, never make it into any of these sections. They stay outside the formal report, visible only inside the company.

For a buyer working through a vendor's report, the order that actually makes sense: Section I for the opinion, Section IV for the exceptions themselves, then Section V to see how the organization talks about its own failures. Skip that order and it's easy to anchor on the opinion alone, which, as the next section shows, tells you less than it seems to.

How an exception escalates to a qualified opinion (and what that actually signals)

Here's a distinction worth sitting with: an unqualified, or "clean," opinion does not mean zero exceptions. Exceptions and qualification are not the same axis. A report can carry an unqualified opinion and still list two or three documented exceptions in Section IV, because the auditor judged those exceptions weren't severe enough, collectively, to cast doubt on the organization meeting its Trust Services Criteria.

A qualified opinion is the auditor saying otherwise: the exceptions, taken together, are material enough that one or more criteria weren't met. That qualification is always scoped to something specific, never a blanket statement about the whole company.

Three things push an auditor toward qualifying an opinion: how severe the failure was, whether it was a one-off or a recurring pattern across the sample, and whether a compensating control caught what the primary control missed. Picture a termination test: the auditor samples ten departures, finds one where access wasn't revoked in the required window. Logged as an exception. If it's isolated, not material, and nothing else in the sample looks similar, the opinion stays clean. If a compensating control (say, a quarterly access recertification that would have caught the leftover account anyway) demonstrably worked, the auditor can note the exception and still leave the opinion untouched.

Adverse opinions, meaning pervasive, significant failures across the whole environment, are rare. Auditors typically work with an organization toward a better outcome before things get to that point; nobody wants to be the one issuing it, and few organizations let it get that far without remediating first. A disclaimer of opinion is different: it means the auditor was restricted from the access or information needed to reach any conclusion at all. That's a process failure, not necessarily a control failure, though it should still raise an eyebrow.

The hierarchy, then: a qualified opinion is a heavier signal than any single exception. Adverse or disclaimer sits in its own category and deserves escalation. An exception inside an unqualified report is a data point that needs investigating, not a verdict waiting to be read.

The controls that produce exceptions most often and why

Some controls generate exceptions more than others. Access controls and system operations generate a large share of exceptions, and the failure modes repeat with almost boring consistency: terminated employees keeping system access for days or weeks past their last day, shared credentials or generic admin accounts used by more people than anyone can name, reviewers approving their own access requests, a segregation-of-duties gap that a second reviewer would fix in an afternoon.

Change management (CC8.1) runs a close second. Industry analysis consistently places it right behind access and operations, and the root cause is almost never technical. It's process. Someone approves a production change in a Slack thread or a group chat, and that approval has no permanence, no audit trail, nothing an auditor can actually sample against. The change might have been perfectly reasonable. It just left no evidence behind.

Business approvals and reviews, user access reviews, terminations, and change management: those four, per the 2024 CBIZ benchmark data, are the top sources of exceptions industry-wide. The same pattern holds across industries: the controls that fail most often are not the exotic ones, but the routine processes every organization relies on.

Why do these categories keep failing? They're not exotic. Every organization needs access reviews, offboarding, and change approvals; there's no shortcut around them. But they all depend on humans doing the same thing consistently, every time, for months on end. That's exactly the gap between a control that looks fine on paper and one that holds up under a sample of forty records. Exceptions are born right there, in that gap between design and habit.

What a management response to an exception should actually contain

Section V exists so the organization gets the last word, sort of. It's unaudited, which means the auditor hands it over without checking a single claim in it. Read as a claim, not a verified fact; that's the honest way to treat it.

A response that's actually useful names four things: the root cause, specifically, not vaguely; the corrective action taken; a timeline or completion date; and what stops the same failure from happening again.& Co. documented a clean example of this: one of ten sampled workstations turned up unencrypted because of an isolated monitoring tool failure. When a response is done well, it demonstrates that the organization understood the failure, acted on it, and built something to prevent recurrence. That is a response that shows an organization actually managing its controls in real time, not scrambling to write something plausible after the fact.

Compare that to the weak version: a vague acknowledgment, no named root cause, no specific action, no date attached to anything. A reader is going to interpret that vagueness as a signal about how the whole organization handles failures, and honestly, that's a fair read. If an exception got fixed between the finding date and the report's issuance, the auditor has no way to retest it until the next cycle rolls around; the management response is the only place that remediation gets communicated at all. Which is exactly why the quality of what's written there carries more weight than its unaudited status might suggest.

How to read exceptions and opinions when evaluating a vendor's SOC 2 report

Third-party risk is not an abstract concern here. Research on breach patterns consistently finds that a significant share of data breaches trace back to third-party compromises. A vendor's SOC 2 report is one of the main tools available for assessing that exposure before it becomes a headline.

A short list of low-severity, remediated exceptions sitting inside an unqualified opinion is a normal outcome, and often a credible one. It suggests the auditor actually looked closely rather than rubber-stamping the engagement. The questions worth asking when an exception shows up: which control failed, and does it sit in a high-risk category like access, terminations, or change management? Is it isolated, or does it show up across multiple samples? Was there a compensating control in place? Does the management response name a specific root cause and a specific fix, or does it just gesture vaguely at "process improvements"? And has this same exception shown up in prior years' reports, because a repeat exception signals a systemic problem rather than a one-time slip.

Opinion type works as a first filter. Unqualified with exceptions: go investigate those exceptions directly, don't stop at the opinion. Qualified: figure out which specific criterion is affected and whether that criterion touches the relationship at hand. Adverse or disclaimer: treat it as a category-level risk signal that needs escalation past whoever is doing the first-pass review.

What a spotless report cannot tell anyone: whether observations went into a private management letter, whether controls held up consistently outside the narrow window the audit actually tested, or whether the scope was drawn tightly enough to avoid the controls most likely to fail. None of that shows up in a report with zero exceptions, and none of it should be assumed just because the page is clean.

Teams handling vendor SOC 2 reviews at any real scale, whether that's a homegrown spreadsheet process or a more structured compliance workflow, tend to do better with a consistent scoring framework: one that separates exception type, severity, and the quality of the management response, rather than treating every exception as a single binary pass or fail. The report was never built to be read that way. Neither should the risk decision that follows it.