When an automated compliance check fails, pick one of three paths and record it: fix the underlying control, document a justified exception with an accountable owner, or correct the check if it tests the wrong thing. Never silence a failing check without a written reason. An auditor will ask why it failed and what you did.
First, find out why it failed
A red result has four common causes:
- The control really is not working, such as a user without MFA.
- The control works but the evidence is missing, such as a log that was not exported.
- The check is wrong or too strict for your environment.
- The system is out of scope or retired and the check should not apply.
Spend ten minutes sorting the failure into one of these. The remedy follows from the cause.
The three paths
| Path | Use when | Record |
|---|---|---|
| Fix | The control is not operating | Ticket, change record, date fixed, retest result |
| Explain (exception) | The gap is real but you accept it for now | Reason, compensating control, owner who may accept it, review date |
| Correct the check | The test is wrong or the scope has changed | What changed in the test, who approved, why it is valid |
Fix: do it and prove it
Fix the cause, then rerun the check and keep the passing result. Link the ticket to the failing and passing results. An auditor sampling the failure wants to see detection, response and verification in one trail.
Explain: make acceptance legitimate
Some risks you accept for a period. In ISO 27001 terms, risk acceptance belongs to the risk owner, with a record. One published guide describes a common audit finding as a high risk marked accepted by someone who lacked the authority. Use the same logic for exceptions in any framework: a named owner with authority, a reason, a compensating control and a firm review date. See who can accept a risk.
Correct the check: carefully
Tests can be too strict, or they can miss how your environment works. If so, change the check, but record who approved the change and why. Do not edit a check on the day before the audit to turn a result green. That looks like what it is.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a failing result shows up and what you would record next.
Treat failures as information
The Journal of Accountancy advises management to treat findings as opportunities to improve controls, not failures to avoid. A failing check caught and fixed by your own team, with a record, is evidence that your monitoring works. A failure nobody saw is the bigger concern. For what happens when a control fails inside a Type 2 period, see what to do when a control fails during the window.
Quick check
Should we delete the check if it keeps failing?
Only if it is wrong or out of scope, and with a recorded approval. Deleting it to avoid noise leaves an unexplained gap in your evidence.
Do all failures need an exception?
No. Most should be fixed. Use exceptions only for real, accepted gaps with a plan.
Safeguard's compliance and evidence automation can keep the failing and passing results together with the related change. Decisions on exceptions stay with your named owners.
Sources
- Journal of Accountancy, promises of fast and easy threaten SOC credibility
- ISO 27001 clause 6.1.3, risk treatment plan and Statement of Applicability
Last reviewed: 19 October 2026.
