Zero exceptions is not automatically a red flag, but it invites a follow-up question: is the register empty because everything is fixed on time, or because deviations happen without being recorded? Be ready to show scanner coverage, finding closure data, and your policy.
Most real engineering teams carry at least a few findings they decided not to fix immediately. A truly empty list is possible in a tiny codebase. In a larger one it more often means the process is bypassed.
What an empty register could mean
| Explanation | How to show it |
|---|---|
| Everything fixed within the policy window | Closure times, no overdue findings |
| Scope is small and scanning is tight | Asset inventory and scan coverage report |
| Deviations are handled outside the process | This is the bad one |
| Findings are dismissed instead of excepted | Dismissal counts in the scanner |
The last two are what an auditor is looking for. If your tooling lets engineers click "dismiss" with no approval, you have an exception process in practice, just without controls.
Check for hidden exceptions
Before the audit, look in four places:
- Scanner suppressions, ignore files, and dismissed alerts.
- Overdue findings that sit open past the policy window with no ticket.
- Pull requests merged over a failing security check.
- Pinned old versions with a comment such as "do not upgrade".
Each of those is a decision to live with a risk. If the decision has no record, write one now with today's date, rather than pretending it never happened.
What to say to the auditor
Short and factual works well. Something like: "We had no approved exceptions in the period. Here is the scanner coverage, here are findings by age, and here is the count of dismissals with reasons." Then hand over the data.
Do not manufacture an exception to look normal. Equally, do not claim zero exceptions if the dismissal queue says otherwise.
Make the number meaningful
A zero is only worth stating if it is paired with context. Pair it with the share of repositories scanned, the median time to fix, and the oldest open finding. EPSS, published by FIRST, estimates the probability a CVE will be exploited in the next 30 days, and some teams use it to explain why a low-probability finding was fixed in the normal cycle rather than excepted. Treat it as one input, not a verdict.
Where Safeguard fits
Safeguard's dependency scanning and asset discovery help show what is actually in scope, and its policies and gates record decisions on each finding, so an empty register can be backed by data instead of assertion.
Quick check
Is one exception better than none?
Neither is better by itself. A small number with clean records is normal. An empty list is fine only if you can show nothing is bypassing the process.
Do dismissals count as exceptions?
If a dismissal means "we know and will not fix it", treat it as an exception and give it an owner and reason.
Sources
Last reviewed: 19 October 2026.
