No-Patch Response Planning

Summary

No patch currently recorded is not the same as no patch exists. It may mean an advisory is pending, a product is unsupported, a vendor has not published a statement, or available sources are incomplete. A defensible response reduces relevant exposure, records uncertainty, assigns ownership, and schedules reassessment without presenting generic controls as vendor-confirmed guidance.

Why it matters

Teams can overreact by declaring an emergency patch impossible, or underreact by treating missing data as safety. Neither conclusion follows from an empty field. Mitigation may reduce a path to exploitation but does not necessarily remove the underlying vulnerability.

When to use this guidance

Use this after applicability review when a fixed version is not currently recorded, an update cannot be scheduled, a product is unsupported, or vendor guidance remains incomplete.

Prerequisites and core concepts

Capture the source state precisely: no advisory found, vendor investigation pending, unsupported product, or explicit no-patch statement.
Separate environment-specific compensating controls from vendor recommendations.
Identify service owner, risk owner, technical action owner, review date, and escalation path.

Practical workflow

Confirm product applicability, exposure path, data sensitivity, and business dependency.
Reduce exposure where approved: isolate a service, restrict access, disable an unnecessary feature, or change configuration after testing.
Add monitoring and detection appropriate to the environment; document gaps and avoid claiming detection is complete.
Review identity controls, backups, recovery readiness, and vendor escalation options.
Create a time-bound exception or risk-acceptance decision where required, with reassessment triggers.

Decision points

An internet-facing, owner-confirmed deployment may justify an accelerated change decision; a product match with unknown reachability may first need validation. KEV or exploit reporting can affect urgency, but neither proves local compromise. Risk acceptance is a decision process, not remediation.

Evidence to collect

Product/version and owner evidence, exposure and feature-state observations, and source timestamps.
Vendor communication, mitigation test results, access-control changes, monitoring coverage, and backup/recovery evidence.
Decision owner, due date, reassessment trigger, migration or replacement plan, and residual-risk statement.

Common mistakes

Do not write "no fix exists" when the safer statement is "no fixed version is currently recorded." Do not call a firewall, WAF, IPS, or configuration change vendor-confirmed unless the vendor says so. Do not let a temporary mitigation become an unreviewed permanent exception.

Worked example

A fictional internet-facing service has an owner-confirmed affected component, uncertain exploit maturity, and no confirmed vendor patch at intake. The team restricts administrative access, disables an unneeded integration after testing, adds focused monitoring, opens a vendor case, and sets a seven-day reassessment. A long-term replacement decision has an accountable owner. The record says exposure reduction is in progress; it does not claim the underlying issue is removed.

Closure or output expectations

The output is a time-bound response plan: source state, applicability, controls tested, owners, decision record, monitoring, vendor case, reassessment date, and criteria for patch, migration, or closure review.

Limitations

Compensating controls can fail, create operational impact, or cover only part of an attack path. Source information can change. Reassess when vendor guidance, exploit reporting, asset scope, or control evidence changes.