How to Build a Vulnerability Exception Process That Does Not Become a Black Hole
Every vulnerability program needs a way to say "not yet."
Some fixes break a critical application. Some vendors haven't shipped a patch. Some systems are scheduled for retirement next quarter. Forcing a patch in those cases can cause more harm than the vulnerability.
The trouble is what happens next. An exception gets approved, the ticket closes, and nobody looks at it again. Two years later, the system is still running, the vulnerability is still there, and the person who approved it has moved on.
A good exception process makes "not yet" a managed state, not a permanent one.
Define when an exception is allowed
Start with clear criteria. Exceptions should be for specific situations, such as:
- No fix available. The vendor hasn't released a patch or supported workaround.
- Fix causes unacceptable breakage. Testing shows the patch breaks required functionality, and a code or configuration change is needed first.
- Planned decommission. The asset is scheduled for retirement within a defined window.
- Operational constraint. A fix requires downtime that can't happen until a scheduled window.
- Not applicable. Evidence shows the vulnerable component or code path isn't present or reachable.
"We're busy" isn't on the list. Neither is "the team disagrees with the severity" without evidence. Those are prioritization conversations, not exceptions.
Require a complete request
An exception request should contain enough for someone else to evaluate it later:
- The finding: vulnerability, asset, affected component
- The reason, mapped to one of the defined criteria
- Evidence supporting that reason
- Compensating controls in place or planned
- The remediation plan and target date
- A named owner responsible for the risk
- A requested expiry date
If any of these are missing, the request isn't ready.
Compensating controls should be real
A compensating control is something that reduces risk while the vulnerability remains. Examples include:
- Network restrictions limiting who can reach the service
- A WAF rule blocking a known exploit pattern
- Disabling the affected feature
- Additional monitoring or detection for exploitation attempts
- Isolating the system on a separate segment
Each control should be specific and verifiable. "Monitoring is in place" isn't enough. "An EDR detection rule for this exploit technique is deployed on these hosts" is.
Where possible, verify controls automatically, such as confirming a firewall rule exists, and alert if they disappear.
Every exception expires
This is the most important rule. No exception should be open-ended.
Set expiry dates based on risk. A high-priority vulnerability on an exposed system might get weeks. A low-priority finding on an isolated system might get several months. Either way, there's a date.
When an exception expires, one of three things happens:
- The vulnerability has been fixed, and the exception closes.
- The owner requests a renewal with updated evidence and justification.
- The finding returns to the active queue with its original priority.
Renewals should be harder to get than the first approval. Escalate repeat renewals to a more senior approver.
Ownership and approval
The exception owner is the person accountable for the risk, usually the service or system owner, not someone on the security team. Security advises and reviews; the business owner accepts.
Approval levels should scale with risk. A low-risk exception might need only a team lead. A high-risk exception on a critical, exposed system should need sign-off from someone with authority over that business risk.
Record who approved what, and when.
Review cycles
Expiry dates catch individual exceptions. Regular reviews catch patterns.
On a recurring schedule, review:
- All exceptions approaching expiry
- Exceptions renewed more than once
- Exceptions whose compensating controls have changed or failed checks
- Exceptions on assets whose exposure or criticality has changed
- Totals by team and by reason
If one team holds most of the exceptions, or "fix causes breakage" keeps appearing for the same application, there's an underlying problem worth addressing directly.
Reassess when conditions change
Exceptions are granted under specific conditions. When those change, the exception should be reconsidered:
- The vulnerability is added to CISA KEV or shows active exploitation
- The asset becomes internet-facing
- A vendor patch becomes available
- The compensating control is removed
Automate these triggers where possible.
Where LLMs can help
LLMs can draft exception requests from findings and evidence, summarize the current state of an exception at review time, and flag inconsistencies, such as a request claiming no fix exists when the advisory lists one. They shouldn't approve exceptions or set expiry dates. Those are risk decisions that belong to people.
Measure the process
Track open exceptions by age and priority, the number past expiry, renewal rates, and how many exceptions end in remediation versus repeated extension. A process that works shows exceptions closing because the vulnerability was fixed.
The goal
An exception process should make temporary risk visible, owned, and time-bound. Clear criteria, real controls, firm expiry, and regular review keep "not yet" from quietly becoming "never."