Decision rule: write the reason patching is not happening now, the action that replaces it, the evidence that supports the decision, and the trigger that will reopen the decision.
No-Patch Decision Examples
No patch does not mean no action.
Use these examples when a normal patch ticket would be misleading because the fix is unavailable, unsafe, unsupported, unnecessary, or waiting on better evidence.
Vendor has not released a supported patch, so the team reduces exposure and watches for updates.
A patch exists, but outage, dependency, or change risk makes immediate rollout unacceptable.
The product family matches, but version, feature, platform, or deployment evidence removes relevance.
Vendor guidance, scanner output, or owner evidence is incomplete or conflicting.
Examples
Common no-patch decisions and the right replacement action
No vendor fix
Patch is not available yet
The advisory confirms exposure but lists only workarounds or says a fix is pending.
Unsupported system
Product cannot receive a supported fix
The affected asset is end-of-life, frozen for a migration, or running a vendor branch that no longer receives security updates.
Patch exists
Immediate patch would cause unacceptable outage risk
The fix is available, but the service needs testing, maintenance coordination, rollback planning, or vendor support before change.
Workaround stronger
Mitigation is safer than emergency patching
A narrow control blocks the vulnerable path quickly while patching would touch fragile production components.
Not affected
Broad product match does not apply to this environment
The asset is a different edition, unaffected branch, disabled feature, cloud-managed service, or fixed backport package.
Guidance unclear
Vendor or scanner evidence conflicts
The scanner says vulnerable, but advisory text, installed build, support response, or distro package data does not line up.
Decision Language
Use precise labels so no-patch work stays accountable
Mitigation first
Use when exposure reduction can happen now but remediation needs a later patch, vendor fix, or maintenance window.
Delayed patch
Use when a fix exists and will be applied, but timing depends on testing, rollout risk, dependency work, or change approval.
Exception accepted
Use when residual risk is deliberately approved for a time-bound reason with owner, compensating control, expiry, and review.
Vendor clarification
Use when the next decision depends on vendor, distro, cloud, or support confirmation.
Monitoring only
Use when action is not justified yet, but advisory changes, exploitation, scanner logic, or exposure changes could alter the decision.
Not affected
Use only when product, version, feature, reachability, or vendor-specific evidence disproves relevance for the named scope.
Evidence By Decision
What each example needs before it is defensible
No fix available
Vendor advisory, affected version proof, workaround or support case, temporary control, owner, and review trigger tied to vendor updates.
Patch delayed
Fixed version, blocked change reason, risk owner approval, patch window, rollback plan, compensating controls, and expiry date.
Unsupported platform
Lifecycle status, business dependency, replacement plan, isolation proof, accepted-risk owner, and retirement or migration target date.
Not affected
Installed version source, product or feature mismatch, vendor or distro reference, owner confirmation, and date validated.
Vendor unclear
Conflicting sources, exact clarification question, support ticket, temporary action, deadline for reply, and escalation owner.
Monitoring only
Reason to watch, monitored sources, telemetry or advisory owner, trigger conditions, and review cadence.
Copy Template
No-patch decision note
No-patch decision: [mitigation first / delayed patch / exception accepted / vendor clarification / monitoring only / not affected] Reason patch is not happening now: [no fix, unsafe change, unsupported platform, not affected, unclear guidance] Scope: [CVE/advisory, product, version, asset group, business service] Evidence: [vendor guidance, version proof, exposure proof, support case, owner confirmation] Replacement action: [control, monitoring, escalation, patch window, retirement plan] Owner and approver: [technical owner, risk/business owner] Review date: [date] Reopen trigger: [patch released, KEV change, PoC release, exposure change, vendor update, failed control]
Recommended route: choose the no-patch label, collect the evidence, pick a temporary control, then record the exception or closure outcome.