Can You Fail a SOC 2 Audit? Exceptions, Explained

No, you can't fail a SOC 2 audit, because there's nothing to fail. A SOC 2 examination doesn't end with a pass, a score, or a certificate. It ends with an auditor's opinion, plus a detailed section listing every control that didn't operate the way you said it would. Those are exceptions, and plenty of respectable companies have them. The questions that actually matter are different: which opinion did the auditor issue, how many exceptions landed in Section 4, and what story does your management response tell. We'll walk through all three, including the conversation nobody prepares you for, where a customer's security team finds an exception in your report and asks you to explain it.

Key takeaways

• There is no pass line. A SOC 2 examination ends in an auditor's opinion plus a section listing every control that did not operate as described, not in a score or a certificate.
• Unqualified does not mean exception-free. Most first-year Type II reports we see carry at least one exception and still carry an unqualified opinion.
• The two most common exception sources are timely deprovisioning of terminated users and periodic user access reviews, both in the CC6 logical access family.
• Opinions escalate on pervasiveness: how many controls are affected, the deviation rate in the sample, whether a compensating control operated, and whether a reader would be materially misled.
• Your management response is the part you control. Acknowledge the finding, explain the cause, name the compensating control that operated, and date the fix. Spin is what fails you with a customer's security team.

An audit ends in an opinion, not a grade

A SOC 2 engagement is an attestation performed by a licensed CPA firm, not a certification with a pass line. The auditor examines your system description and your controls against the AICPA Trust Services Criteria (the 2017 edition with 2022 points of focus, still current as of August 2026) and issues one of four opinions:

Here's the part people miss: unqualified does not mean exception-free. A Type II report lists every control tested, the tests performed, and the results. "No exceptions noted" next to most rows and "exception noted" next to a few is what a normal, honest report looks like. We see at least one exception in most first-year Type II reports that cross our desk, and the large majority of those reports still carry unqualified opinions.

Where exceptions actually come from

The two most common exception sources, according to soc2auditors.org, are timely deprovisioning of terminated users and periodic user access reviews. Both live in the CC6 logical access family of the Trust Services Criteria: credential removal at termination is tested under CC6.2 and CC6.3, and recurring access reviews under CC6.3.

Here's how the deprovisioning exception happens in practice. Your access control policy says accounts are disabled within 24 hours of termination. Okta is wired to your HRIS, so SSO access dies automatically, and you assume you're covered. Then the auditor pulls the full termination list from HR, samples 25 of the year's 60 departures, and cross-references every in-scope system, not just the ones behind SSO. Two of the 25 had a standalone PostgreSQL account that stayed active for six weeks, because the database predates your identity provider. That's an 8 percent deviation rate against a 24-hour commitment, and it's going in Section 4.

The access review exception is even more mundane. The control says managers review user access quarterly. Q1, Q2, and Q4 have signed review evidence. Q3's review happened three weeks late, or the "evidence" is a Slack message that says looks fine, or it never happened because the person who ran it resigned in August and nobody inherited the task. The control didn't operate as described for one quarter out of four. Exception.

Notice what these two have in common. Both are calendar-driven human tasks that straddle the HR-to-IT handoff, and both fail silently. Nobody notices a missed access review in the moment; you notice it eight months later when an auditor asks for the signed Q3 evidence and the room goes quiet.

The escalation ladder: exception, qualified, adverse

An exception is a data point. An opinion is a judgment about all the data points together. When your auditor decides whether an exception stays a footnote or escalates the opinion, they're weighing a few things: how many controls are affected and whether the failures cluster around one criterion, the deviation rate within the sample, whether any compensating control operated, and whether a customer relying on the report would be materially misled by an unqualified opinion.

Run the two ends of that spectrum. One late deprovisioning out of 25 sampled, caught within the period by a monthly dormant-account review, with logs showing the account was never accessed after termination: exception noted, unqualified opinion, life goes on. Deprovisioning broken all year, no access reviews performed at all, and no monitoring that would have caught either: the auditor can't conclude the CC6 criteria were met, and the opinion gets qualified "except for" logical access. Push further, to failures spread across multiple criteria in a report whose whole point is security, and you're in adverse territory.

A qualified opinion is damage, not death. It names the affected criteria, and everything outside them still stands. Sophisticated customers will read it, ask pointed questions, and often accept it alongside a credible remediation plan. An adverse opinion, in our experience, means you're re-doing the audit period before most enterprise deals move again.

Compensating controls: the language that contains an exception

You can't veto a finding, but you do get a voice. Management responses to exceptions typically appear in Section 5 of the report ("Other Information Provided by the Entity"), and the difference between a well-written response and a defensive one is the difference between an exception that reads as contained and one that reads as symptomatic.

A response that works has four parts: acknowledge the finding, explain the cause, name the compensating control that operated during the period, and date the fix. Something like:

> Management acknowledges that two of 25 sampled terminations retained database credentials beyond the 24-hour standard. During the period, a monthly dormant-account review (CC6.3) operated and disabled both accounts, and authentication logs confirm neither account was accessed after the termination date. Effective March 2026, the database was migrated behind single sign-on, and deprovisioning is now triggered automatically by the HRIS.

Each piece is doing work. The compensating control shows the failure sat inside a layered system rather than a void, and it's a factor your auditor weighs when deciding whether the exception threatens the opinion itself. The log evidence turns a control failure into a demonstrated non-event. And the dated fix hands a customer's security team something concrete to verify in next year's report.

Two things to keep out of the response: arguing with the auditor, and unsupported risk language. "Management believes the risk was low" with no evidence convinces nobody, and it signals that you'd rather minimize than measure.

What to tell a customer who finds an exception in your report

This is the part almost nobody writes about, and it's where reports actually get won or lost. Assume the person asking is a security engineer with forty vendor reports to review this quarter. They've seen hundreds of exceptions. They are not screening for perfection; they're screening for whether you understand your own failure.

Give the answer in three beats. First, state the finding plainly in your own words before they have to ask twice: "Two terminated contractors kept database accounts for six weeks because that system wasn't behind SSO yet." Second, quantify the blast radius with evidence, not adjectives: the accounts were never accessed post-termination, and here are the logs and the compensating review that caught them. Third, show the fix and its date, and point to where next year's report will prove it out.

What kills you is spin. "The auditor was being overly strict" tells a security reviewer that the next exception will be hidden better, not fixed. In our experience the vendor who says "yes, we missed it, here's why and here's the fix" clears security review faster than the vendor with a suspiciously silent report and a defensive posture.

And know when to concede the larger point. If your opinion is qualified on logical access and the prospect is a bank, the honest answer may be that this deal waits a cycle. Pushing a qualified report uphill into a regulated buyer burns credibility you will want back next year.

Can you clean things up before the report is issued?

Partially. A Type II report covers a fixed window, and what happened in the window happened; no amount of pre-issuance work removes a documented exception from Section 4. What you can do between fieldwork and issuance is remediate and get the remediation into your management response, dated, so the report carries the failure and the fix together. Auditors can also acknowledge post-period remediation as a subsequent event in some cases, and they'll verify it properly in the next cycle.

The higher-value move is catching failures yourself, mid-period. A control that failed in month two and then ran cleanly for ten months reads completely differently from one that was still broken when the auditor showed up. Internal spot checks in months three and nine, against the same populations your auditor will pull (the full HR termination list, the full user roster), cost a few hours and defuse most Section 4 surprises.

One honest note on prevention. The two most common exception sources are ownership problems, not tooling problems. If you have an ops-minded person who will genuinely own the compliance calendar, two recurring tickets (termination checklist, quarterly access review) prevent both of them for free, and you don't need to pay us or anyone else. Compliance as a service earns its fee when there's truly nobody to own that calendar, or when the control set has outgrown one person's spare cycles. It's not a substitute for someone caring.

Frequently asked questions

Does one exception sink our SOC 2 report?

No. A single isolated exception with a credible management response almost never changes the opinion, and most first-year Type II reports we review carry at least one. Opinions turn on pervasiveness: repeated failures clustered in one criterion, or failures with no compensating controls, are what push an auditor toward qualifying. Treat a lone exception as a customer conversation to prepare for, not a failed audit.

Can we fix findings before the report is issued?

You can fix the control, but you can't remove the exception for the period it covers; a Type II reports what actually happened during the window. Remediation finished before issuance belongs in your management response with a date, and the auditor can verify it next cycle or note it as a subsequent event. If you discover a failure mid-period, fix it immediately: one bad month followed by eleven clean ones reads far better than a failure that's still open at fieldwork.