Skip to main content
Regulaxy
Blog

The patch was ready in March. The window was in July

Four months between an available fix and an installed one is almost never a technical failure. Here are the five places it actually stops, and what moves each of them.

By
Gidi Rabi · Regulaxy engineer
Updated
4 min read
  • maintenance windows
  • coordination
  • patch management

The scanner did its job on time. The list was on the desk the day after disclosure, ranked by severity, with hostnames on it. Four months later two-thirds of it is still open.

This is not a story about missing tools. Most organisations I have seen have a good scanner, a deployment mechanism that works, and a team that knows how to install an update. What they do not have is a way to get thirty system owners to agree on when.

The list is not the bottleneck

It helps to separate two things that tend to get merged. Detection — what is exposed — is a solved problem. Deployment — how the file gets pushed — is a solved problem. What is left in the middle is a negotiation: who approves, when the system may go down, what happens if it does not come back up, and who is awake at three in the morning to check.

That negotiation runs today in a spreadsheet and a group chat. It works up to about twenty systems.

The five places it stops

1. Nobody knows who owns it

"Who approves an outage of this host?" looks trivial until you try to answer it across 400 of them. There is a name in the inventory, but it belongs to whoever ordered the machine seven years ago. They have changed role. Two other people believe they are responsible, and neither is certain.

Until one source says "this host belongs to this system, and this system has an owner with this name", every window begins with three emails and one reply that never arrives.

2. The approval stays verbal

The system owner said "yes, go ahead" in a corridor. A week later the system falls over during the window and nobody can reconstruct who approved what. This is not a trust problem — it is an evidence problem. Even where everyone is entirely honest, without a timestamped record there is no way to reconstruct the sequence.

3. The window is picked from the infrastructure team's calendar

The executing team plans around its own availability, then discovers that Tuesday evening is month end for the billing system. The window slips, and in slipping it loses its place in the queue. The next opening is a month out.

The right direction is the reverse: ask first when it is forbidden, then propose when it is possible. Change freezes, quarter ends, known peak days — all of these are knowable in advance. A system that does not know about them will always propose the wrong date.

4. Two connected systems go down the same night

This happens once or twice a year, and it is the expensive part. A database host is scheduled for three in the morning; that same night, unrelated, somebody else schedules the application server that depends on it. Both windows were properly approved. Neither approver knew about the other.

The knowledge exists — it sits in a dependency-monitoring tool and in two people's heads. It just never reaches the moment a date is chosen. We wrote about that separately: Two valid windows, one night.

5. Afterwards, there is nothing to show

The audit asks what was done. The answer is screenshots, an email thread and somebody who remembers. It also handicaps the next round: with no record of what happened, every window starts from zero.

What actually changes it

Four things, in the order they pay off:

  1. One source for ownership

    One host row that reconciles inventory, system and owner. Everything else depends on it.

  2. Group by patch, not by vulnerability

    One patch usually closes dozens of CVEs across dozens of hosts. The patch is the schedulable unit; the vulnerability is not.

  3. Approval that produces evidence

    A calendar invitation instead of an email. The record creates itself rather than depending on somebody remembering to write it.

  4. A collision check before you commit

    At the moment the date is picked, not afterwards. A warning that arrives after the invitation went out is history.

None of the four requires replacing the scanner or the deployment mechanism. They address the other half — the one between the list and the night the update actually goes on.

One line worth keeping

If your next patch takes four months, the reason will almost certainly not be that you did not know about it. It will be that you could not close a date.

Related