What happens when a SOC 2 audit finds exceptions

Search this question and most of what comes back answers a different one. The four opinion types get defined, what a bad one does to a live deal gets skipped, and the page closes on a demo booking. The bad outcome is why you searched. It happens to teams with good engineers and honest intentions, usually over a calendar problem rather than a security one. Below is what actually happens, including the parts that are bad for us.

An opinion, not a grade

A CPA firm does not certify you. It examines what you asserted about your own system and reports whether that assertion holds up under testing. There are exactly four things the resulting opinion can say, and the distance between the first two is smaller than the anxiety around them suggests.

Unqualified

The clean opinion, and the outcome a completed examination is aimed at. Your description is fairly presented, your controls were suitably designed, and for a Type 2 they operated effectively across the period. It can still contain exceptions in the test results. The opinion and the test results answer different questions.

Qualified

Everything holds except one named thing. The opinion paragraph carries an except-for clause pointing at the criterion or the control that did not hold. The report is still a real report, and buyers still read it.

Adverse

The description or the controls are materially misstated. This is rare. It means the problem was pervasive rather than isolated, so a reader could not rely on the description as written.

Disclaimer of opinion

The auditor cannot form an opinion at all, almost always because the evidence needed to test simply was not there. A scope limitation rather than a verdict, and the one outcome that is genuinely worth avoiding.

A qualified opinion is not a rejection letter. It is a disclosed limitation, and the security reviewer on the other side is trained to read one. What kills deals is a surprise, not a qualification.

What an exception actually is

The auditor works from samples. For a Type 2 they take the population of events over the period, select instances, and check whether the control fired the way your description says it fires. An instance that does not hold up is an exception.

It is granular. It attaches to one test of one control, not to your company. Four access reviews were required across the period and two were performed: that is an exception, written into the test results with the count and the auditor note beside it. Nobody is grading your character.

Type 1 works differently. It opines on design as of a single date, so there is no sample to pull and no operating exception to record. What a Type 1 can carry is a design deficiency, a control that would not meet the criterion even if it ran perfectly every time. Those normally get fixed before issuance rather than surviving into the report. How long a SOC 2 actually takes lays out where each examination sits and how much room you have to fix things first.

How to have fewer exceptions before anybody tests you

Most exceptions are not security failures at all. They are cadence failures, and the cadence is set at the moment somebody writes the policy.

Two things get tested. The auditor tests your policy against the criterion, then tests you against your policy. Take the access review above. Quarterly was your own word, so the auditor looked for four and found two. An annual policy performed once would have cleared that second test, provided annual still meets the criterion for your scope. For access review under CC6 it often does not.²

Nothing about your security posture changes between those two policies. One of them manufactures an exception. The other does not. Write the cadence you can hold in your worst quarter, then beat it if you can, because beating your own policy is never a finding.

1. Check that cadence against the criterion before you commit. Loosening a cadence past what the criterion requires trades an operating exception for a design deficiency, which is worse.
2. Put a named human on every recurring task. A shared calendar is not an owner, and a task nobody owns is the one the sample lands on.
3. File evidence as it is produced rather than at period close. Keep everything for one control in one place, so the ticket, the export and the approval are already together when the auditor asks.
4. Read your own policies before the period opens. Once, out loud if it helps. What you find is usually a cadence you cannot hold, and you can still change it at that point.

Five control failures covers the ones that show up over and over, and Type 1 versus Type 2 covers which examination your buyer is asking for in the first place.

Will your customers see them? Yes

Anyone you send the report to can read every exception in it. A SOC 2 report has a fixed shape, and the test results are printed inside it.³ There is no edited copy for buyers.

Enterprise security reviewers read Section 4 hardest, because it is the only part of the document that can tell them something they did not already assume. Section 1 is a paragraph of standard language. Section 4 is the evidence.

Which is better news than it first sounds. A reviewer who finds two exceptions and a competent management response beside them generally keeps moving. A reviewer who finds forty controls tested and not one deviation sometimes wonders how hard anybody looked.

Section 5 is where you get to answer

Management response belongs to you. The auditor does not write it and does not opine on it,¹ which makes it the only part of the report where your voice appears next to a finding. Use it.

There are limits. You cannot use Section 5 to argue the test result was wrong, and a response that reads as a rebuttal makes a small exception look like a governance problem. You also cannot claim a remediation that the auditor never observed, because everything you write there is still your own assertion sitting inside a report a CPA firm put its name on.

1. State what happened in the same neutral register the auditor used. No adjectives and no defensiveness.
2. Name the cause concretely. A process that had no named owner reads far better than the phrase human error.
3. Give the fix and the date it landed. If it landed after the period closed, say so plainly instead of blurring the timeline.
4. Say how you will know it holds. The alert, the recurring ticket, the named owner. This is the sentence reviewers actually weigh.

You cannot edit an exception out of an issued report

An issued SOC 2 is a signed work product of a CPA firm, covering a period that has already closed. You do not amend it to remove a finding. The finding was true when it was written.

The path back is the same every time. Fix the control. Operate it correctly across a new period. Examine that new period, and the new report carries a clean result for the control that deviated in the old one. That is the entire mechanism, and it is why nobody in this market can sell you a fix for a report that already exists.

Nothing gets erased, and that turns out to matter to a buyer. Two consecutive reports showing an exception and then its absence are a stronger artifact than one report that never had a deviation in it. The second one shows a control environment that catches itself.

One last thing about price. A cheap examination does not buy you fewer exceptions, and an expensive one does not buy you a cleaner opinion; the test results are what your controls did. Whether a cheap audit is legitimate takes that apart properly, including how to check a firm with its state board before you sign anything.