Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

If…, then how…

If an exploited vulnerability can't be patched today, then what?

5 decision pointsThe pack behind this answer: Vulnerability & Exposure Management

Add to board memo

The short answer

Recommendation
Not patching today is normal; missing the deadline is the problem. Check first that the weakness has not already been used against you, set its priority, put a qualifying control in place within 72 hours for a Priority 1, and request an exception before the deadline if the fix still cannot be made.
Reasoning
Exploitation evidence means attackers are using the weakness somewhere, so the clock is short, but the pack gives a deadline and expects a control meanwhile. Blocking access, disabling the feature or isolating the system each change what an attacker can reach and can be confirmed. A firewall signature or closer monitoring changes none of the rating inputs; record it as evidence for an exception. A control protects against the next attempt and does nothing about one that already succeeded.
Considerations
  • The priorities and deadlines, 72 hours and 7 days for Priority 1 and 14 days for Priority 2, are the defaults in the CISO Times vulnerability pack. Your own standard may set different ones.
  • The control does not lower the priority or extend the 7-day fix. If it is removed or stops working, the finding needs a control restored at once. A promised vendor patch is not a control and does not move the deadline.
  • In the pack the vulnerability standard's approver decides Priority 1 exceptions, unless your exception standard sets a higher approver or a shorter duration, in which case the stricter rule applies.
  • Under that exception standard, an exception in the Critical band goes to the board, or a board risk committee it has delegated to; the management board in a two-tier structure; executive management where there is no board.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartAn exploited weakness can't be patched todayDecisionIs there any sign it has already been used against you?OutcomeTreat it as a possible incidentDecisionIs the system internet-facing, or rated Critical?OutcomePriority 1: control within 72 hours, fix within 7 daysOutcomePriority 2: fix within 14 daysDecisionCan you block access, disable the feature or isolate the system?OutcomeNo control at 72 hours: escalate at onceStepApply the control, confirm it, and record itStepReduce the risk while the fix is preparedDecisionAt each weekly triage, is the control still in place and working?DecisionCan the fix be installed by its deadline?StepInstall the fix, then rescanOutcomeFixed, confirmed by a rescanOutcomeRequest an exception before the deadline

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 15 steps.

  1. Start

    An exploited weakness can't be patched today

    The vendor may not have a patch yet, the change window may be days away, or the patch may need testing first. Exploitation evidence means attackers are using the weakness somewhere, so the clock is short. It does not mean the patch must go in today. The pack gives you a deadline and expects a control in the meantime.

    In the pack

  2. Decision

    Is there any sign it has already been used against you?

    Check the affected systems for the indicators the vendor or your national CSIRT has published, and for unexpected accounts, files or outbound connections. If you have not been able to check yet, treat the answer as yes. A control applied now protects against the next attempt. It does nothing about one that already succeeded.

    In the pack

  3. Outcome

    Treat it as a possible incident

    Tell the vulnerability standard's owner at once. Signs that the weakness has already been used against you are the pack's own example of when to raise it under your incident procedure. From here the patch is only one part of the response.

    In the pack

    See also

  4. Decision

    Is the system internet-facing, or rated Critical?

    Internet-facing includes anything reachable from networks you do not fully control, such as partner links and guest Wi-Fi. Critical means failure or compromise would stop a core business service or expose highly sensitive data. If either is unknown, answer yes.

    In the pack

  5. Outcome

    Priority 1: control within 72 hours, fix within 7 days

    These are the pack's defaults, both counted from detection. Tell the standard owner at once and open a Priority 1 ticket. It does not wait for the weekly meeting.

    In the pack

  6. Outcome

    Priority 2: fix within 14 days

    Exploited, on an internal system that is not rated Critical. An exploited weakness is never below Priority 2, whatever its severity score. The pack's default is 14 days from detection, with escalation to the asset owner's manager if it is still open on day 10.

    In the pack

  7. Decision

    Can you block access, disable the feature or isolate the system?

    These are the pack's examples of a Priority 1 compensating control. Each changes what an attacker can reach, and each can be confirmed: an external scan, a scan showing the feature is gone, or a firewall rule export. The vendor's published mitigation often does one of these. Measures such as a web application firewall rule or closer monitoring change none of the finding's inputs in the rating model; the pack treats them as evidence for an exception, not as grounds for a lower priority.

    In the pack

  8. Outcome

    No control at 72 hours: escalate at once

    A Priority 1 without a compensating control at 72 hours goes straight to the standard's approver and into the incident process. Escalation moves the decision to someone who can free up resources or accept the risk. Keep working on the fix and on any weaker control in the meantime.

    In the pack

  9. Step

    Apply the control, confirm it, and record it

    Record what was done and when. The control does not lower the priority or extend the 7-day fix. A lower priority needs the standard owner and a control that changes an input, such as removing internet exposure, and an exploited weakness on a Critical system stays at Priority 1 either way. The pack's gateway example shows a control that meets the 72 hours without lowering anything.

    In the pack

  10. Step

    Reduce the risk while the fix is prepared

    The pack sets no 72-hour control for Priority 2, but the same controls still reduce the risk and are worth applying where they are cheap. Weaker measures, such as a firewall signature or closer monitoring, do not change the priority. Record them anyway: they are evidence if you later need an exception.

    In the pack

  11. Decision

    At each weekly triage, is the control still in place and working?

    Controls get reverted during changes and forgotten when staff move on. The triage meeting checks each Priority 1's control is recorded and the fix is on track. This control did not lower the priority, so if it is removed or stops working the finding is a Priority 1 with no control, and needs one restored at once. A priority lowered because a control changed an input returns at once to its original priority and deadline if that control stops working.

    In the pack

  12. Decision

    Can the fix be installed by its deadline?

    Ask before the deadline, not after. If the vendor has not released a patch, check its advisory for a date. A promised patch is not a control and does not move the deadline.

    In the pack

  13. Step

    Install the fix, then rescan

    Report the fix early enough for a confirming scan before the deadline; for a Priority 1, run a targeted scan. Keep the control in place until the rescan confirms the fix.

    In the pack

  14. Outcome

    Fixed, confirmed by a rescan

    A finding is closed when a later scan no longer reports it, or other objective evidence shows the fixed state. A ticket saying 'patched' is not enough. The rescan shows the weakness is gone. It does not show nobody used it before the fix.

    In the pack

    See also

  15. Outcome

    Request an exception before the deadline

    Name a risk owner, list the controls and set an expiry. In the pack, the vulnerability standard's approver decides Priority 1 exceptions; where your exception standard sets a higher approver or a shorter duration, the stricter rule applies. That standard scores an exploited weakness at the top likelihood, and a control tested before approval lowers it by one step only. On a Critical system that gives a High or Critical band. A Critical band goes to the board or its delegated risk committee, the management board in a two-tier structure, or executive management where there is no board.

    In the pack

    See also

Practical checklist

  1. Check the affected systems for published indicators and unexpected accounts, files or outbound connections; if you cannot check yet, treat it as a possible incident.
  2. Set the priority: exploited and internet-facing or Critical is Priority 1, otherwise Priority 2. Treat unknown exposure or criticality as yes.
  3. Notify the standard owner at once for a Priority 1, and open a ticket.
  4. Block access, disable the feature or isolate the system within 72 hours, confirm it, and record what was done and when.
  5. Escalate to the approver and the incident process at once if no control is in place at 72 hours.
  6. Check at each weekly triage that the control is still in place and the fix is on track.
  7. Install the fix and keep the control until a rescan confirms it.
  8. Request an exception before the deadline if the fix cannot be installed in time.

Evidence to have ready

  • The ticket with the detection date, priority and deadline.
  • The control record: what was done, when, and its confirmation, such as an external scan or a firewall rule export.
  • Triage records showing the control was checked each week.
  • The confirming rescan for the fix.
  • Any exception, with its risk score, approver, risk owner, compensating controls and expiry.

Assumptions

  • You have already confirmed the weakness is exploited: it is in a known-exploited catalogue, or a vendor or CSIRT reports real attacks.
  • The priorities and deadlines shown are the defaults in the CISO Times vulnerability pack. Your own standard may set different ones.

Not covered here