A patch exception register is a list of assets that cannot follow their normal patching plan, each with a reason, an owner, a compensating control and an end date. NIST SP 800-40 Rev 4 says to closely track and monitor all exceptions and review them regularly.
Why you need one
Exceptions happen. A vendor patch breaks an application, a system cannot be rebooted before a release, or a product is end of life. What hurts is the exception nobody remembers. A written register turns "we will get to it" into a dated decision with a name on it.
NIST says maintenance groups should be defined to keep exceptions to a minimum, but that having some is inevitable. It asks that every exception be reviewed regularly to determine whether the maintenance plan can be implemented now.
Fields to record
Keep the table short enough that people will fill it in.
- Asset and group.
- Vulnerability or patch affected, with identifier.
- Reason the plan cannot be met.
- Compensating control in place, for example isolation or a disabled feature.
- Risk owner, who accepted the exposure.
- Date granted and expiry date.
- Review date and the result of the last review.
- Exit condition: what must happen for the exception to close.
The expiry date is the field that matters most. An exception without an end date is a permanent decision made by accident.
Review rhythm
NIST does not set a frequency, only "regularly." A monthly review of the full list, plus a check whenever a new vulnerability affects an excepted asset, is a sensible default. A new flaw in an asset that already has an exception may need a different mitigation than the one you recorded.
At each review ask three questions:
- Can the plan be applied now?
- Is the compensating control still working and still enough?
- Should this asset move to a different group?
Watch for repeats
If several assets share the same long-term exception, NIST suggests moving them into a separate maintenance group with its own plan. Repeat exceptions usually mean the groups are wrong, not that the assets are special. See how to define maintenance groups.
Assets with no patches at all
Where the vendor ships no patches, the register is where the long-term plan lives. NIST says to periodically reevaluate alternatives to patching in two ways: a risk assessment to see whether the alternatives still reduce risk enough, and a cost-benefit analysis to see whether the assets are worth the extra cost of mitigating, transferring or accepting the risk. For software dependencies specifically, see managing end of life dependencies.
Who signs
Name a person who can accept the risk on behalf of the business, not only the engineer who found the problem. Auditors tend to ask who approved the exception, so the signature also serves compliance work. Safeguard's compliance and evidence automation can hold this kind of evidence, and its policies can flag components past their allowed age.
Quick check
How long should an exception last?
The sources do not give a figure. Choose a short default, set it per severity, and require a fresh decision to extend.
Is a risk exception the same as a false positive?
No. A false positive says the vulnerability does not apply. An exception says it applies and you are accepting it for a stated time.
Sources
Last reviewed: 19 October 2026.
