A vulnerability exception should last only as long as the reason behind it holds. Give every exception an end date, match that date to the reason, and review it early if exploitation evidence changes. NIST's patching guidance says exceptions should be tracked and reviewed regularly, not filed and forgotten.
Why open ended exceptions go wrong
An exception without an expiry becomes a permanent decision made by someone who may have left. The reason that justified it (no fix yet, a release freeze, a vendor delay) quietly stops being true, and nobody notices because nothing forces a look.
NIST SP 800-40 Rev. 4 puts it plainly: exceptions to maintenance plans should be closely tracked, and all of them should be reviewed regularly to see whether the plan can be followed now. It also suggests that assets with similar long-term exceptions may deserve their own maintenance group with its own plan.
Match the end date to the reason
The length is not a fixed number. It follows the blocker.
| Reason for the exception | What should end it | Sensible review trigger |
|---|---|---|
| No fix published yet | A fix or vendor workaround appears | Check the advisory on a set rhythm, and on any exploitation news |
| Fix exists but needs a planned change window | The change window | The date of that window |
| Fix breaks something and needs engineering work | A ticket with an owner is closed | The sprint where the work is scheduled |
| Component is end of life and cannot be patched | Replacement or isolation | A shorter cycle, since risk only grows |
| Vulnerable code is not reachable in your build | The code path changes | Any change to the affected module |
The pattern is simple. Exceptions that wait on something external can follow that event. Exceptions that wait on your own work should be tied to a dated commitment.
What every exception should record
Keep the record short enough that people fill it in:
- The vulnerability, the affected asset, and who owns the asset.
- The reason, in one or two plain sentences.
- The compensating control, if any (isolation, a disabled feature, a gateway rule).
- The approver, who should not be the person asking.
- The end date and the event that would trigger an earlier review.
Reviews should be able to change the answer
A review where the outcome is always "renew" is a rubber stamp. At each review ask three questions. Has the fix status changed? Has exploitation evidence changed, for example if the issue was added to a known exploited list since the last review? Is the compensating control still in place and tested?
If the answer to the second question is yes, treat it as a new decision with a short clock, not a routine renewal. CISA's SSVC guide describes exploitation as a point in time state that should be time stamped, which is a good reason to date every review.
Limit how often an exception can renew
Decide in advance how many times one exception can be renewed before it moves up to a more senior approver. Repeated renewal is a signal that the real answer is a project, a replacement, or an explicit acceptance of risk by someone with authority to accept it.
Quick check
Is there a standard length for a vulnerability exception?
No standard length applies everywhere. Tie the end date to the blocker, and keep it short enough that someone looks again before the circumstances change.
Who should approve an exception?
Someone with authority over the risk, who is not the requester. Higher severity or longer exceptions should go to more senior approvers.
Does a compensating control remove the need for a review?
No. The control can fail or be removed, so the review should confirm it is still in place.
Sources
- NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- CISA, Stakeholder-Specific Vulnerability Categorization (SSVC) guide
Last reviewed: 19 October 2026.
