A SOC 2 exception is a case where the auditor tested a control and found it did not operate as described, for example a change merged without the required review. Fix the cause, document what happened and what you changed, and tell the auditor early. One exception does not automatically fail the report.
What counts as an exception?
Your description of controls says what you do. The auditor tests whether you did it for the sampled items during the period. If a leaver kept access past your stated deadline, or a quarterly access review was done in the fifth month, that is a deviation from the description and is reported as an exception in the test results.
Exceptions come from three places: a control that was not performed, a control performed late or incompletely, and evidence that cannot be produced. The third one is common and avoidable. If the review happened but nobody saved it, the auditor cannot count it.
Does an exception mean a failed audit?
Not by itself. In a Type 2 report, the auditor describes tests and results, and then forms an opinion on whether controls were suitably designed and operated effectively to meet the criteria. A single exception in a control that has strong backup controls may be reported with no effect on the opinion. A pattern, or an exception in a control central to a criterion, can lead to a qualified opinion for that criterion. The auditor judges, and you cannot negotiate the result.
Management typically adds a response alongside an exception in the report, which is where your fix and your honesty show.
How should you respond in the moment?
When you spot a failure, whether from monitoring or from the auditor, work through five steps.
- Contain. Fix the live problem: remove the access, roll back the change, run the missed review now.
- Record the facts. What control, which item, what dates, who was affected, and whether any data was exposed.
- Find the root cause. Ask why it was possible. A missed approval is usually a missing technical block, not a careless person.
- Change the control. Add a gate, an alert or an owner. Evidence of the fix, with a date, is the point.
- Look for siblings. If one leaver kept access, check all leavers. Report what you found.
This follows the intent of CC4.2, which expects deficiencies to be evaluated and communicated to those responsible for corrective action, and CC7.4, which expects defined incident response.
What about compensating controls?
If a primary control failed but another control would have caught the problem, such as a monitoring alert that reviewed the unapproved change the next day, say so with evidence. The auditor decides whether it is adequate. A compensating control must be real and must have operated, not be invented afterward.
Should you tell the auditor?
Yes, and early. Surprises hurt trust. An exception you discovered, investigated and fixed before the auditor sampled it reads very differently from one they found. Keep the discovery record dated.
Mistakes to avoid
- Changing the policy to match what happened. If the policy says quarterly, a late review is still late.
- Fixing only the one failing item, not the process.
- Deleting evidence of the failure. That is worse than the failure.
- Arguing about the sample instead of the cause.
What to do
- Build an internal exceptions register: date found, control, cause, fix, owner, closed date.
- Review it monthly with leadership, and keep minutes.
- Add technical blocks for the top three recurring causes, such as required reviews on merges.
- Set alerts for controls that depend on a calendar, such as access reviews.
- Before fieldwork, run your own sample test on high volume controls.
- When an exception occurs, send the auditor a short factual note with the fix.
Quick check
Can we fix the problem during the audit period?
Yes, and you should. The exception remains for the earlier item, but a dated fix shows the control now operates.
What is the difference between an exception and an incident?
An exception is a control that did not operate as described. An incident is a security event. One can cause the other, but they are tracked separately.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence and continuous monitoring, so a control that stops operating, such as a missed review or a failing automated test, can be seen when it happens and not at fieldwork. Evidence is collected from connected systems and your real code and dependencies, which gives you a dated record of the fix. Autonomous remediation can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and with what approval. The independent auditor still decides on exceptions and opinion. Book a call.
Sources
- AICPA, Trust Services Criteria (2017, with 2022 points of focus): CC4.2 and CC7.4, paraphrased.
- AICPA description of Type 2 reports: tests of operating effectiveness over a period.
Last reviewed: 18 October 2026.
