Vulnerability exceptions and risk acceptance

No organization fixes every vulnerability on time. Some systems cannot be patched without a vendor's approval, some fixes break critical applications, some software is end-of-life with no fix at all, and some deadlines collide with business events that nobody will move. The question is not whether exceptions happen, but whether they happen visibly, with a decision-maker, a rationale, compensating controls and an end date — or invisibly, as overdue findings that everyone has learned to ignore.

A good exception process is what makes SLAs credible. If there is a legitimate, lightweight way to say "not yet, and here is why", then an overdue finding really does mean something went wrong. This guide covers exception types, who approves what, compensating controls, expiry and review, and how to keep an exception register that leadership and auditors can trust.

Four things that are not the same

Teams often lump every "we're not fixing this" into one bucket. Separate them, because they have different owners, evidence and metrics.

The distinction between deferral and risk acceptance is worth keeping. A deferral says "we will fix it, later". A risk acceptance says "we will live with it", typically for end-of-life systems, vendor-controlled appliances or cases where the fix is more damaging than the risk.

When exceptions are legitimate

Legitimate reasons tend to fall into a few categories:

• No fix available yet from the vendor, and mitigations are in place.
• Fix breaks something — a regression confirmed in testing, with a plan to resolve it.
• Vendor or regulatory constraints — medical, industrial or certified systems that cannot be modified without the vendor's validation.
• Planned retirement — the system is being decommissioned soon, and the cost of fixing exceeds the residual risk over the remaining lifetime.
• Business freeze — a short, time-boxed change freeze around a critical business event.

"Not enough time" and "not our priority" are not exception reasons; they are capacity or prioritization problems that belong in the escalation path described in remediation SLAs.

Approval authority by risk

Match the approver to the risk. The matrix below is an example; align the roles with your own governance and the VOC RACI.

Two rules keep the matrix honest. First, the approver must be senior enough to own the consequence, which usually means the business side for anything above low risk. Second, some combinations should not be excepted at all; they are emergencies to escalate, mitigate or isolate.

What an exception request must contain

Keep the form short, but make every field mandatory:

• Affected findings (asset IDs and vulnerability IDs), or a clearly bounded scope.
• Type (deferral or risk acceptance) and reason category.
• Business justification in plain language.
• Compensating controls in place, with evidence.
• Remediation plan and target date (for deferrals).
• Requested expiry date — never "indefinite".
• Requester, approver and date of approval.

Compensating controls

A compensating control reduces the likelihood or impact of exploitation when the vulnerability itself cannot be removed. It should address the specific attack path, not general hygiene. Useful categories:

Verify controls rather than accepting them as claims: a firewall rule can be checked, a disabled service can be scanned, and a detection can be tested in a safe way by the SOC.

Expiry and re-review

Every exception expires. When it does, one of three things should happen: the finding has been remediated, a new exception is requested and approved with fresh justification, or the finding becomes overdue and enters escalation. Automatic renewal defeats the purpose.

Also re-review exceptions when the risk changes, not just when the date arrives. The most important trigger is exploitation status: when a CVE covered by an exception is added to the CISA KEV catalog, or your threat intelligence reports active exploitation, the exception should be re-evaluated immediately, usually by a more senior approver.

The exception register

Keep exceptions in a structured register that the VOC's pipeline can read, so metrics and ticket states reflect them automatically.

# exceptions/EX-2026-0142.yaml
id: EX-2026-0142
type: deferral                 # deferral | risk_acceptance
reason: vendor_validation      # no_fix | regression | vendor_validation | retirement | freeze
scope:
  assets: ["cmdb:ci:LAB-ANALYZER-07", "cmdb:ci:LAB-ANALYZER-08"]
  vulnerabilities: ["CVE-XXXX-YYYY"]
risk:
  tier_at_request: P2
  residual: medium
justification: >
  Instrument vendor must validate the OS update before installation.
  Validation scheduled; installation planned in the next maintenance window.
compensating_controls:
  - control: segmentation
    evidence: "Firewall rule FW-3312: only LIS server may reach analyzers"
  - control: monitoring
    evidence: "SOC detection DET-881 for exploitation indicators"
requested_by: lab-systems
approved_by: head-of-clinical-operations
approved_on: 2026-09-15
expires_on: 2026-11-15
review_triggers: [kev_added, exploitation_reported, scope_change]

A file-per-exception layout in a repository gives you review via pull requests and a full history; a GRC or ticketing tool works too, as long as the data is structured and linked to findings.

Anti-patterns

• Permanent exceptions. No expiry means no decision; it is just silence with paperwork.
• Blanket exceptions. "All findings on the legacy platform" hides new, more serious issues that arrive later. Scope to specific vulnerabilities, or to a tier ceiling with automatic review when something above it appears.
• Security approving business risk. The VOC is not the right owner for large residual risks.
• Exceptions as SLA relief valves. If a team requests exceptions for most of its findings, the problem is capacity or architecture, and it should be escalated as such.
• Missing controls evidence. A control that cannot be shown to exist should be assumed not to.

Metrics for exceptions

Report exceptions alongside remediation, not buried in an appendix:

• Number of active exceptions by tier and by owning team, trended monthly.
• Share of open high-priority risk that is excepted rather than scheduled for remediation.
• Exceptions expiring in the next 30 days.
• Exceptions re-reviewed because of a change in exploitation status.
• Median exception duration, and how many were renewed more than once.

These numbers belong in the same leadership report as time to remediate and SLA compliance — see reporting vulnerability risk to leadership — because accepted risk is still risk.