Exception is not closure
A temporary exception records a reason remediation is deferred and how residual risk will be managed until review. Permanent acceptance is a governance decision with its own policy requirements. Neither removes the finding, proves the asset is safe, or substitutes for a technical remediation plan. This page is practical guidance, not legal advice.
When an exception may be considered
Consider an exception only after the finding, affected scope, exposure, vendor guidance, remediation options, and operational constraints are understood well enough to describe residual risk. Examples include a patch that would disrupt a critical service, an unavailable vendor fix, a fixed maintenance window, or a dependency that requires staged change. Document why ordinary remediation is deferred and what will be done instead.
Exception record template
- Finding, source, affected asset, product, version, and owner.
- Business owner and technical owner.
- Exposure, threat evidence, asset criticality, and current controls.
- Reason remediation is deferred and alternatives considered.
- Additional controls, monitoring, evidence location, and control owner.
- Expiration, approval, revalidation date, closure criteria, and escalation trigger.
Review workflow
- Validate the local facts before asking for acceptance.
- Describe residual risk in bounded language, including unknowns.
- Make controls specific: scope, owner, evidence, expected duration, and limitations.
- Set an expiration and review trigger such as a vendor update, exposure change, or new exploit evidence.
- Close, renew, or replace the exception only after revalidation.
Common mistakes
Do not use an exception as a place to lose a finding, omit the asset owner, or claim a compensating control eliminates risk. Avoid open-ended approvals and treat a change in product version, exposure, KEV status, or vendor guidance as a reason to revisit the record.