Exception rule: an exception is not a parking lot. It needs an owner, reason, compensating control, expiry date, review cadence, evidence quality, and proof that risk is not silently increasing.
Exception Register
Track the vulnerability work that cannot be safely fixed right now.
Use this when patching is delayed, no fix exists, a change window is blocked, mitigation is temporary, or leadership needs to accept residual risk with evidence.
Owner
Namedbusiness, asset, patch, or risk ownerControl
Compensatingisolation, access limits, monitoring, WAF, hardeningExpiry
Requiredreview date, not open-ended acceptanceEvidence
Attachedversion, exposure, scanner caveat, vendor, telemetry, approvalWhen To Use
Common exception cases and the safest next page
No fix exists
Vendor has not released a supported patch
Document affected versions, vendor guidance, mitigation, residual risk, monitoring, and review date.
Patch blocked
Business or change risk delays remediation
Capture why the change is blocked, who approved delay, what control reduces exposure, and when the decision expires.
Mitigation first
Control change is faster than software change
Use isolation, access controls, firewall rules, WAF rules, feature disablement, or monitoring while patch planning continues.
Risk acceptance
Residual risk must be owned explicitly
Make acceptance time-bound and evidence-backed. Avoid accepting vague risk without exposure validation, scanner context, proof boundary, or review cadence.
Register Fields
What every exception should capture
Scope
CVE or advisory ID, product, affected version, asset group, business service, environment, and internet-facing status.
Decision
Patch delayed, mitigation accepted, no patch available, monitoring only, vendor escalation, or formal risk acceptance.
Owner
Patch owner, asset owner, risk approver, SOC contact, business owner, and backup contact if the owner is unavailable.
Controls
Compensating controls, validation evidence quality, deployment date, expected coverage, and any known gaps or bypass limits.
Expiry
Review date, target fix date, approval expiry, and condition that forces re-review such as KEV addition or public PoC release.
Evidence
Source references, vendor advisory, affected/fixed version notes, scanner caveats, exposure evidence, SOC telemetry scope, proof boundary, and approval record.
Review Cadence
Exceptions should get stricter as pressure rises
24 hours
KEV, exploited, public PoC, internet-facing, or ransomware-relevant
Review daily until patch, mitigation, isolation, or accepted residual risk is confirmed by the accountable owner.
7 days
High severity with uncertain exposure
Review weekly until product, version, reachability, owner, and compensating controls are confirmed.
30 days
Mitigated but not remediated
Review monthly to confirm controls still work, scanner or telemetry caveats remain accurate, vendor guidance has not changed, and the target fix date remains realistic.
Immediate
Trigger-based re-review
Reopen the exception if exploitation begins, KEV status changes, public PoC appears, patch guidance changes, or exposure expands.
Copy Template
A simple exception note format
Exception request: [CVE/advisory] affects [asset group/product/version]. Decision: [patch delayed / no patch / mitigation first / risk accepted]. Reason: [business blocker, vendor blocker, change risk, unsupported platform]. Compensating controls: [access restriction, isolation, WAF, monitoring, feature disabled]. Owner: [name/team]. Approver: [risk/business owner]. Review date: [date]. Expiry condition: [patch available, KEV change, PoC release, exposure change]. Evidence: [vendor advisory, exposure proof, version proof, scanner caveat, telemetry scope, evidence quality, ticket/reference].
Recommended next move: use No Patch or Mitigation Operations to find candidates, Evidence Checklist to validate scope, then Action Tracker and Brief Builder to keep the exception visible.