Who can approve deferring a patch, and for how long?

Start

A patch may not be installed by its deadline

A deferral moves the date a patch is due. It does not lower the priority, and the finding stays open until a rescan confirms the fix. Because it lets a known weakness stay open past the deadline the organisation set, it is approved in advance as an exception, by someone other than the person who wants it.

• Then: Will it be installed and verified on every system by the deadline?

Decision

Will it be installed and verified on every system by the deadline?

The deadline is the vulnerability standard's, counted from first detection on each system; where systems differ, use the earliest. A release date plus a month is not the deadline. If you cannot be sure a window will make it, answer no and decide now, while there is still time to ask.

• Yes: No deferral: move it to a later window inside the deadline
• No, or not known: Has the deadline already passed?

Outcome

No deferral: move it to a later window inside the deadline

Moving a patch to a later window that is still inside its deadline is not a deferral and needs no form or approver. Reschedule it by name and chase it to a clean rescan.

Decision

Has the deadline already passed?

Nobody can approve a deferral after the fact. An exception takes effect from the day it is approved, never earlier, so a request made after the deadline is too late.

• Yes: Too late: report it overdue and install it
• No: Is the reason on the accepted list?

Outcome

Too late: report it overdue and install it

It is reported as overdue and escalated as your vulnerability standard sets: in the pack's defaults, to the asset owner's manager, and to the standard's approver if still open 14 days later. Install it as soon as possible.

Decision

Is the reason on the accepted list?

The pack accepts five: the patch failed a test with a confirmed fault or the vendor withdrew it; the supplier has not certified it; the system cannot restart in time without stopping a critical service and nothing else works; no patch exists; or the system is being retired before the next window. A busy or short-staffed team, no test system, a missed window and "internal only" are never reasons.

• No: No approver can grant it: install by the deadline
• Yes: Is the patch Priority 1?

Outcome

No approver can grant it: install by the deadline

A request for a reason that is never accepted is refused. Install the patch by the deadline, or it is reported overdue and escalated. A team short of people is escalated to the Head of IT for the people, and tracked as a risk treatment.

Decision

Is the patch Priority 1?

Priority 1 is an exploited flaw on an internet-facing or Critical system, with a 7-day deadline in the pack's defaults. Its deferral has extra conditions on top of the band.

• Yes, or not known: Mitigation in place within 72 hours; senior approver
• No: Request it on the form, with a tested control and a date

Step

Mitigation in place within 72 hours; senior approver

The 72-hour mitigation must be in place before the request. The approver is the vulnerability standard's approver, or the band's approver where that one is more senior: the more senior approver and the shorter duration always apply. A Priority 1 deferral that scores Critical goes to the top body for your structure.

• Then: Request it on the form, with a tested control and a date

Step

Request it on the form, with a tested control and a date

The system owner requests it with the patch owner: systems by inventory name, the deadline, the reason with evidence, the options tried, each compensating control with its test date and result, and the date the patch will go in. An incomplete request is returned. Send it before the deadline, early enough for the approver's decision time.

• Then: Score it: impact times likelihood after tested controls

Step

Score it: impact times likelihood after tested controls

The Head of Information Security scores it with the exception model: impact and likelihood each from 1 to 4, with likelihood one step lower for a tested control, never below 1. An untested control does not lower the score. Low is 1 to 3, Medium 4 to 6, High 8 to 9 and Critical 12 to 16.

• Then: Which band does the score fall in?

Decision

Which band does the score fall in?

The band sets the approver, the decision time in working days from a complete request, and the longest the deferral may run. The longest is the shorter of the exception standard's maximum and the vulnerability standard's 90 days, so in the pack's defaults no patch deferral runs longer than 90 days, or 30 for Critical.

• Low (1–3): Low: the control owner, within 5 working days, 90 days at most
• Medium (4–6): Medium: Head of Information Security, within 10 working days
• High (8–9): High: security head with the accountable executive, 90 days
• Critical (12–16): Critical: the top body for your structure, 30 days at most

Step

Low: the control owner, within 5 working days, 90 days at most

The exception standard would allow 365 days for a Low exception, but the vulnerability standard caps a patch deferral at 90. The control owner for a patch is usually the patch owner, the person who runs the patching, so the next check often moves the decision up a level.

• Then: Did the approver request it, or do they run the patching?

Step

Medium: Head of Information Security, within 10 working days

The exception standard would allow 180 days for Medium; the vulnerability standard caps the deferral at 90 days.

• Then: Did the approver request it, or do they run the patching?

Step

High: security head with the accountable executive, 90 days

Both sign: the Head of Information Security and the accountable executive who owns the risk, within 10 working days. The maximum is 90 days under both standards.

• Then: Did the approver request it, or do they run the patching?

Step

Critical: the top body for your structure, 30 days at most

The board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management. The decision is due within 5 working days, so check that body can decide that fast, at a scheduled meeting or by written procedure. A renewal beyond the band's limit goes higher still, to the level your exception standard names.

• Then: Did the approver request it, or do they run the patching?

Decision

Did the approver request it, or do they run the patching?

Nobody approves a deferral they requested, or one for patching they run. Most patch deferrals score Low or Medium once a tested control is in place, and the band's approver is then often the person who runs the patching. Name in advance who signs in that case.

• Yes: The decision passes to the next level up
• No: Is the risk left outside appetite, or scored Critical?

Step

The decision passes to the next level up

In the pack's warehouse example the deferral scored Low, but the control owner was the IT Operations Manager, who runs the patching, so the Head of Information Security approved it. Where the Head of Information Security also runs the patching, name on the form who signs instead, before you adopt it.

• Then: Is the risk left outside appetite, or scored Critical?

Decision

Is the risk left outside appetite, or scored Critical?

A deferral is an exception, not a risk acceptance. But where it leaves a risk outside the appetite your risk process sets, or the score is Critical, the approver that process requires for that position signs the same exception as well, and the stricter of the two always applies. Only one exception is raised.

• Yes, or not known: risk approver signs too: Approved to a date no later than the band's limit
• No: Approved to a date no later than the band's limit

Outcome

Approved to a date no later than the band's limit

The approver may refuse, shorten it or add conditions, never extend it past the limit. In the pack's example a Low deferral that could have run 90 days was approved for one week, to the next Sunday window. It goes into the one exception register and closes on the rescan. Running late again needs a new request before expiry, on a new score.