A patch-window coordination playbook

This assumes the technical half already works. You have a scanner, you have a deployment mechanism, and somebody knows how to install an update. What does not work is agreeing a date — which is what this is about.

Seven steps, ordered by return. Each is useful on its own, and anyone who stops after the third has captured most of the benefit.

Where most estates start

The following is true in a great many organisations and there is no criticism in it. It is simply what happens when nobody designs the process on purpose.

The vulnerability list arrives as a file. Someone filters it by severity, pastes it into a spreadsheet and starts sending emails. Some replies come back. Dates are agreed verbally, land in the coordinator's calendar only, and sometimes slip. After the window, whoever executed writes a summary — or does not. Three months later nobody can say with confidence which of the original list actually closed.

The gap is not effort. It is that every step depends on one person's memory.

Step 1 · One source for ownership

Everything else rests on this, which is why it is first.

You need one row per host that says: which system it belongs to, who owns that system, their email and phone, and when it was last patched. One row — not three inventories that disagree.

When the sources disagree

That is the normal state, not the exception. Two rules that work:

• A real answer beats a weak one. If one source says "Tier 1" and another leaves it blank, the tier wins. Blank is not data.
• When two sources genuinely differ, take the more severe. A host one source calls external and another calls internal is treated as external. The two error directions are not equivalent.

Step 2 · A remediation-target matrix

A single blanket target is always wrong in both directions. Use a small matrix: patch severity on one axis, asset criticality on the other, days in each cell.

	Critical asset	Secondary asset	Non-critical
Critical severity	days	days	days
High severity	days	days	days
Medium severity	next cycle	next cycle	next cycle

The numbers are deliberately blank. Directive 364 does not name any, and a vendor offering you off-the-shelf figures is doing you a disservice — the targets have to come from what you can genuinely execute, and be defensible to an auditor.

What must be true: the targets are written, approved, and measured against. An unmeasured target reads in an audit as exactly what it is.

Step 3 · A standing window calendar, booked ahead

This step changes the most for the effort it costs.

Most organisations start looking for a window after the list arrives, which guarantees every cycle begins behind: negotiating a date with thirty owners takes weeks.

Invert it. Book the recurring windows a year out, before they have content. Every system has a standing window at its own cadence. When the list arrives, it goes into a window that already exists.

A window you booked and did not need is cancelled with one message. A window you have to build from nothing costs a fortnight.

What feeds the calendar

• Cadence per system — derived from tier and criticality (see patch cadence).
• Freeze periods — quarter ends, year end, known business events.
• Known release dates — the vendors' monthly cycles.

Step 4 · Approval that produces its own evidence

One rule: the approval must be a by-product of the action, not a separate task.

An email asking for approval creates a separate task — someone has to read it, reply, and someone else has to keep the reply. A calendar invitation creates the evidence by itself: there is a timestamp, there is a button, and the answer is stored on both sides without anyone doing anything extra.

Step 5 · Check for collisions before you commit

The expensive failure in this category is not a window that slips. It is two perfectly valid windows on the same night, across systems that depend on each other.

The check has to run at the moment the date is picked, not afterwards. A warning that arrives once the invitation has gone out is a report, not a warning.

What the check needs to know is which systems are connected to which. Pull it from a dependency-monitoring tool if you have one, and from a hand-written list if you do not. Twenty hand-written system pairs are worth far more than nothing, and take an hour to write.

Step 6 · An execution checklist closed in real time

At three in the morning, at the end of a shift, memory is not a working tool.

The checklist has to be short enough to actually be filled in. Six to ten items, not twenty-five. The ones that must be there:

1. Backup taken and verified

   Not "taken" — verified. An unchecked backup is an assumption.

2. Tested in a separate environment

   This is an explicit requirement of §61.4. If it is not recorded beside the window, it cannot be demonstrated two months later.

3. Service stopped and restored

   With times. Two lines that produce the actual outage duration.

4. Verified afterwards

   Who checked, and what they checked. "It came up" is not a check.

5. Outcome, including failure

   An unrecorded failure is the finding somebody else will make. A window that failed and was documented is a process that works.

When the checklist closes, a summary should go automatically to the owner, the contacts and the coordinator. That closes the loop without anyone remembering.

Step 7 · Three measures, not a dashboard

Measure three things. Nobody will look at more.

1. Median time from detection to fix, by severity. Not the mean — a mean breaks on three outliers.
2. Share of windows that happened on the date agreed. This is the one that measures coordination itself.
3. Number of windows postponed, and why. The reason matters more than the count: postponed for a freeze is a planning failure, postponed because an owner did not reply is an ownership failure.

Template: a one-page maintenance-window policy

If you do not have this document, here is the skeleton. It should fit on one page.

1. Scope — which systems, which change types.
2. Cadences — frequency by tier and criticality.
3. Remediation targets — the matrix from step 2.
4. Who approves — the system owner for a normal window; who approves an emergency change, by name.
5. Freeze periods — the dates, and the single exception that crosses them.
6. What must be recorded — the list from step 6.
7. Rollback — who decides, and at what time you stop trying.

Four things not to do

• Do not build a board that discusses every patch. It becomes a queue, and the queue is why windows slip. The board approves policy; the individual window runs under it.
• Do not measure by vulnerability count. See above.
• Do not document after the fact. Documentation assembled after the audit is not an audit trail, and it shows.
• Do not start at step 3. A window calendar without clear ownership produces windows nobody approves.

Roughly what each step costs

In an estate of a few hundred hosts: step 1 is a quarter of real work in most places, steps 2 and 3 are a fortnight of decisions, and steps 4 to 7 depend on tooling. There is no shortcut through the first one — and it is also the step that, done alone, starts everything else moving.