Usually not. A hard cap on exceptions does not reduce risk, it moves the decisions out of sight, into side channels and undocumented workarounds. Track the age, reason, and renewal of each exception instead, and make exceptions expire by default so that every one gets a second look.
What an exception is for
An exception is a recorded decision to live with a known risk for a stated time, for a stated reason, with a named owner. Done well it is a healthy part of a security program. It admits that some fixes take longer than any policy window, and it keeps that fact visible.
A cap tries to improve the count of exceptions. Once the count is a target, Goodhart's law applies: when a measure becomes a target, it ceases to be a good measure. The thing people can still control is whether they write the exception down.
How a cap backfires
- Teams ask for one broad exception that covers many items, to stay under the limit.
- Teams stop asking and fix the item the cheap way, for example by hiding the finding from the scanner, which is worse than a recorded exception.
- Reviewers feel pressure to reject, so legitimate requests go unrecorded.
- The exception queue shrinks while real risk stays the same.
The DORA guidance on delivery metrics warns about the closely related trap of treating a metric as a goal and about measuring complex systems with a single number. Both fit here.
Track the quality of exceptions instead
| Signal | Why it matters |
|---|---|
| Age of each open exception | Old ones usually mean a forgotten decision |
| Share with an expiry date | Open ended exceptions become permanent |
| Share with a named owner and reason | Without these, nobody can review them |
| Renewals per exception | Repeated renewals mean the real fix is stuck |
| Share of exceptions covering exploited or reachable issues | These deserve the shortest lifetimes |
These tell you whether the exception process is working. The raw count mostly tells you how many things are hard.
Rules that keep exceptions honest
- Every exception expires. Choose a default window and require a fresh decision to extend it.
- Every exception names an owner, a reason, and a compensating control if one exists.
- Exceptions for items that are known to be exploited need a higher level of approval and a shorter window.
- Reviewers get a service level for answering, so teams are not tempted to bypass the process while they wait.
- Sample a few exceptions each month and check that the reason is still true.
Reviewers should also be allowed to say yes quickly. A slow, uncertain process is the real cause of most bypassing.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how exploitability changes the weight of a finding, which is the kind of fact an exception review should consider.
Safeguard's policies and reachability analysis can support exception decisions by showing whether a vulnerable code path is reachable. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Is a growing exception count always bad?
No. It can mean people are recording decisions instead of hiding them. Judge by age, expiry, and renewals.
What is a sensible default expiry?
It depends on your risk and capacity. Pick a window short enough that someone must look again, and tighten it for exploited issues.
Sources
Last reviewed: 19 October 2026.
