Your SOC 2 Report Came Back With Exceptions. What That Actually Means

Direct answer: An exception means the auditor tested a control and found an instance where it did not operate as described. It is not a failed audit, and most reports with a handful of exceptions are still perfectly sellable. What matters to a buyer is which control, how many instances, and what you did about it.

Exception, qualified opinion, adverse opinion

These get conflated constantly. An exception is a specific finding inside the report. The opinion is the auditor's overall conclusion. You can have several exceptions and still receive an unqualified opinion, which is the clean one.

A qualified opinion means the auditor concluded that one or more controls were not effective across the period. An adverse opinion, which is rare, means the control environment as a whole did not achieve the criteria. The distinction matters enormously when a buyer's reviewer opens the report, and founders often report the wrong one because they have not been told the difference.

How buyers actually read them

Reviewers look at where the exception sits. An exception in access management or change control gets attention, because those are the controls that stop the incidents they care about. An exception in a peripheral administrative control usually does not.

They also look at your management response, which is printed in the report alongside the finding. A response that names the cause, the fix and the date reads as a company that runs its controls. A defensive response, or none, reads as a company that will do this again.

What causes most exceptions

Almost never a missing control. Usually a control that exists but was not performed on schedule, or was performed and not evidenced. Access reviews done in month four and month eleven instead of quarterly. Onboarding checklists completed for nine of eleven new starters. Change approvals that happened in conversation and not in the ticket.

That is why the second report is usually cleaner than the first: the controls did not change, the discipline around evidencing them did.

What to do now

Fix the cause rather than the instance. If access reviews slipped because nobody owned the calendar, assign it and automate the reminder. Then make sure the next observation period contains a complete, dated record for every control that produced a finding.

Do not hide the report. Buyers who ask for SOC 2 are used to seeing exceptions, and a vendor who explains theirs clearly usually comes out ahead of one who stalls on sharing it.

None of this makes exceptions free. A qualified opinion invites questions in every security review that follows, and it is the mild version of what happens when evidence is thin. The harsher version is an engagement that never reaches an opinion at all, because the firm reaches fieldwork, finds nothing testable, and recommends pausing: what a stalled audit costs.

If exceptions came from evidence discipline rather than from the controls themselves, that is exactly what SOC 2 Evidence Collection is for, and our free Workspace keeps the evidence register in one place between audits.

What an exception looks like on the page

Exceptions live in section four of the report, the testing matrix, and each one occupies a row with four columns. The control as you described it. The test the auditor performed. The result. And, where there is a finding, your management response printed underneath.

A typical row reads something like this. Control: user access to production systems is reviewed quarterly by the engineering lead and inappropriate access is removed. Test: inspected access review documentation for a sample of quarters and inspected evidence of removals. Result: for one of four quarters tested, no evidence of a completed review was available. Management response: the Q3 review was not performed because the owner changed mid-quarter. Ownership has been reassigned to a named role, a recurring calendar item with a fifteen day completion deadline has been created, and completion is now tracked in the compliance register. The Q4 review was completed on time.

Read that as a buyer and you learn three useful things: the control exists, one instance out of four failed, and the company knows why. Read a row where the response says "management believes the control is operating effectively" and you learn that nobody has looked into it. The difference in how those two land is larger than the difference in the underlying failure.

Design deficiency versus operating deficiency, and why it matters more than the count

Two very different findings get called exceptions and they carry different weight.

An operating effectiveness deficiency means the control was well designed and did not run properly on some occasions. The quarterly access review that happened three times out of four. The onboarding checklist completed for nine of eleven starters. These are discipline problems. They are fixable with an owner and a calendar, and buyers generally treat them as such.

A design deficiency means the control, even performed perfectly every time, would not achieve the criterion. A change management control that requires peer review but excludes hotfixes, in a company that ships most production changes as hotfixes. An access review that covers the identity provider but not the three systems with local accounts. These are the ones that should worry you, because remediating them means building something new and then operating it long enough to be tested, which pushes into the next period.

A report with six operating deficiencies and no design deficiencies describes a company with real controls and sloppy record keeping. A report with one design deficiency in access management describes a gap. Reviewers who read many reports can tell the difference, and the count on its own tells them nothing.

How sampling manufactures exceptions

Most first-time exceptions come from a mechanism founders have not thought about. The auditor does not inspect everything. They take a population, agree its completeness with you, and draw a sample proportionate to how frequently the control operates.

Rough shape: a control that runs annually gets tested once, quarterly four times across a twelve month window, monthly a subset of months, and a continuous or event-driven control such as change approval or user provisioning gets a sample drawn from the whole population. For event-driven controls the sample size grows with population size, and for a company deploying several times a day that can mean twenty-five or more changes pulled at random across the year.

Two consequences follow. First, one failure inside a small sample looks proportionally worse than the same failure inside a large one. Missing one of four access reviews is a twenty-five percent failure rate on that control. Missing one of forty change approvals is not. Second, and more important, population completeness is itself tested. If you hand the auditor a list of thirty-eight new starters and their HR export shows forty-one, the exception is not about the checklist. It is about the reliability of the list, and that is a harder finding to write your way out of, because it makes every other population you provided look questionable.

This is the single most useful thing to prepare. Before fieldwork, generate each population from the authoritative system rather than from memory or a spreadsheet somebody maintains. Users from the identity provider. Changes from the repository. Starters and leavers from the HR system. Vendors from procurement or accounting. If the authoritative system and your list disagree, resolve it before the auditor finds it.

When an exception moves the opinion

Auditors are not counting. They are judging whether the deviations, individually or in aggregate, mean a control did not achieve the applicable criterion across the period. Several factors push a finding toward affecting the opinion.

Rate within the sample. One in forty is an isolated deviation. Six in twenty-five suggests the control does not really operate.

Where it sits. Logical access, change management and, where applicable, the controls around production data are the load-bearing ones. A deviation in security awareness training completion rarely troubles an opinion. A deviation in privileged access removal frequently does.

Whether other controls compensate. If quarterly access reviews slipped but every termination triggered same-day automated deprovisioning with evidence, the risk the review addresses is partly covered elsewhere. Auditors will consider that if you raise it, and they will not go looking for it on your behalf.

Clustering. Four unrelated deviations across four criteria read differently from four deviations that all trace back to nobody owning the compliance calendar between May and September. Aggregation is where a set of individually minor findings turns into a qualification.

Whether you knew. A deficiency you identified yourself, recorded, and were remediating before fieldwork started is treated differently from one the auditor discovered. Self-identification is evidence that your monitoring works, which is itself a criterion.

Writing the management response

Your response is the only part of section four you control, it is printed permanently, and most companies write it in twenty minutes at the end of a long engagement. It deserves better, because it is what every prospective customer's security reviewer will read for the next twelve months.

Four elements, in plain language. The cause, stated specifically rather than as "a process gap". What changed, described as a mechanism rather than an intention, meaning a named owner, an automated trigger, or a system control rather than "increased focus". When it changed, with a date. And whether it has been operating since, which is the sentence buyers look for.

Things to avoid. Do not dispute the finding in the response; if you disagree, argue it during fieldwork, and if you lose, accept it cleanly. Do not blame an individual by name or role in a way that identifies them. Do not promise a remediation date in the future without saying who owns it, because an unowned future date reads as a finding you will see again next year. Do not use the response to market: a paragraph about your commitment to security in the middle of a testing matrix reads badly to exactly the audience you are trying to impress.

Disagreeing with your auditor

Sometimes the finding is wrong, or right for the wrong reason, and there is a narrow window before the report is issued when that can be resolved.

The productive disagreements are factual. The evidence existed and was provided in a different format than requested. The sampled item was out of scope under the boundary already agreed. The control as written in the description covers a different activity than the one tested, which usually means the description needs correcting rather than the test. Bring the artefact, not the argument, and bring it during fieldwork rather than after the draft.

The unproductive disagreements are judgement calls. Whether one deviation in a quarterly control is material. Whether a compensating control is sufficient. You can present evidence and reasoning, and the auditor decides. Pushing hard on judgement calls with a firm you want to use again for several years is rarely a good trade, and reviewers can often tell when a report has been negotiated into vagueness.

If the disagreement is structural, for instance the firm is testing against a control set that does not match your environment, that is a scoping failure that should have been caught before fieldwork. It is also the point at which engagements stall rather than fail, and a stalled audit is more expensive than a report with exceptions in it.

What buyers ask after they see one

Assume your report will be read by someone who reviews several a month. The questions that follow an exception are consistent enough to prepare answers for.

Has it recurred since the period ended, and what evidence do you have. Was it isolated to one team or one system. Did any customer data get exposed as a result, which is usually no and should be answered directly rather than deflected. What is the current state of the control, meaning today, not at the report date. And, if the finding sat in access management, whether privileged access specifically was affected.

Prepare a one-page note covering each exception with those answers, keep it current, and give it to your sales team alongside the report under the same non-disclosure agreement. The alternative is that a deal pauses for a week while somebody schedules a call to explain a single row in a table. Reviewers rarely reject a vendor for an exception. They reject vendors who cannot explain one.

The same note handles the gap between your report period and today. A bridge letter covers the interval formally by asserting no material changes to the control environment, and it is a management representation rather than an audit product. Buyers accept them routinely for three to six months and get uncomfortable beyond that.

Why a report with no exceptions can read badly

Experienced reviewers occasionally treat a first Type II with a clean testing matrix as a reason to look harder rather than as reassurance. Three things usually explain a perfectly clean first report, and only one of them is good news.

The scope was narrow. Fewer systems, fewer criteria, a short observation window of three months rather than twelve, and a control set that avoids anything difficult. Reviewers check the boundary section and the period dates before they read the matrix, and a three month window ending conveniently before a renewal tells its own story.

Or the controls were written to be passable rather than meaningful. A change management control that says changes are tracked, without saying they are approved by someone other than the author, is easy to pass and proves very little. Auditors test what you wrote.

Or, genuinely, the company ran its controls well for a year. That does happen, and it is more common in a second or third cycle than a first. If it is your situation, the way to make it credible is a broad scope and a full twelve month period, not a bigger claim.

Exceptions in somebody else's report

You will also read exceptions rather than only writing them, because your own vendor management control requires you to review your subprocessors' reports. Two things to do with a finding you see in a vendor's report.

Record what you concluded. Not that you obtained the report, which is what most vendor registers show, but what the exceptions were and whether they affect the service you consume. An exception in a vendor's physical security control for a data centre you do not use in a region you do not operate in is noise. An exception in their access provisioning is not.

Check the complementary user entity controls section while you are there. That section lists what the vendor is relying on you to do. Companies routinely file the report as evidence and never read that part, and it is where your own auditor will find a gap.

When to stop working on this

The honest counterweight to everything above. Not every exception is worth remediating, and a compliance programme that chases every row costs more than the risk it removes.

If a finding sits in a peripheral administrative control, no buyer has ever raised it, and closing it properly means building a process somebody has to run every month forever, the correct decision may be to accept it, record the acceptance in your risk register with a rationale and an approver, and spend the effort on the access and change controls that reviewers actually read. That is a defensible position and auditors respect it when it is documented. What they do not respect is the same finding appearing for a third year with a fresh promise attached.

Equally, if your report has one operating deviation, a clear response, and an unqualified opinion, you do not need help with it. Do not hire a consultant to remediate a single missed quarterly review. Assign it, automate the reminder, and move on. The free Workspace will hold the calendar and the evidence register for that without anyone billing you.

Where outside help earns its cost is narrower: a qualified opinion you need to clear before a renewal, a design deficiency that requires building a control rather than remembering to run one, a repeat finding that has survived two remediation attempts, or a first report where several exceptions cluster around one absent owner. Those are the situations where a retainer that owns the cadence changes the outcome, and where readiness work is worth buying rather than improvising. If you are not in one of them, keep the money.