Patching without a maintenance window you cannot get

Patching is the least controversial thing in infrastructure management and one of the least consistently done. The reason is rarely disagreement about whether it matters. It is that patching needs downtime, downtime needs a window, and every window belongs to someone who would rather it did not happen.

Stop treating all patches the same

The first improvement is to stop asking one question about a category that contains very different things:

• Actively exploited vulnerabilities on internet-facing systems.These are an incident, not a change. They get an emergency window, and the conversation is about how, not whether.
• Serious vulnerabilities on internal systems.Weeks, on the normal change process, prioritized by exposure.
• Everything else.Monthly or quarterly, batched, routine.

Most organizations have one process for all three, sized for the third, and then bypass it for the first. Naming the tiers explicitly makes the emergency path legitimate rather than exceptional.

Prioritize by exposure, not by score alone

A CVSS score describes the vulnerability, not your risk. The same score means very different things on a public web server and on a machine reachable only from an admin subnet.

Three questions order the list better than the score does: is it reachable from the internet, is there a working exploit in the wild, and what does it touch if compromised. A high-scoring flaw in a component you do not have enabled is genuinely less urgent than a medium one on a front door — and being able to say that with evidence is what keeps the list credible.

Reducing the window rather than requesting it

The most productive direction is usually to need less downtime rather than to negotiate for more.

• Rolling updates behind a load balancer.Patch one node at a time with traffic drained. No user-visible downtime, and it is the single largest change available for most web estates.
• Live kernel patching.Where the platform supports it, this removes the majority of the reboot requirement on Linux.
• Replace rather than patch.Build a new image, deploy it, retire the old instance. In an environment that can do this, patching stops being a window question entirely.
• Split the stack.The database may need a window; the application tier may not. Patching what can be done without one keeps the backlog from accumulating on everything.

Make the risk of not patching visible

Where a window genuinely must be requested, what usually fails is the framing. “We need four hours on Sunday” invites a negotiation about the four hours. What changes the conversation is the exposure: which systems, reachable from where, and what is known to be exploited against them.

Keeping a standing list — systems, their outstanding vulnerabilities by tier, and how long each has been outstanding — reported to whoever owns the risk, does more for patching cadence than any tooling. It moves the decision to the person who should be making it.

Test enough, not exhaustively

“It might break something” is the other blocker, and it is legitimate. It is also usually addressed with a process that is too heavy to run monthly, which is why patches accumulate.

Proportionate testing: a staging environment that matches production closely enough for the components that matter, an automated smoke test of the main paths after patching, one canary host first where the estate allows, and a rollback that has actually been performed rather than documented.

A rollback plan nobody has executed is a paragraph, not a plan.

The forgotten systems

Every estate has them: the appliance with a web interface nobody has logged into for two years, the build server, the monitoring system itself, the firmware on switches and drive controllers, the developer laptops. They rarely appear on the patching list because they are not in the server inventory, and they are disproportionately represented in real incidents.

An honest inventory is the prerequisite for a patching program, which is why the two projects usually have to happen together.

A working shape

1. Three tiers, named, with different processes and different approval paths.
2. Priority by exposure, reported monthly to whoever owns the risk.
3. Architecture that reduces the window — rolling, live patching, replacement.
4. Proportionate testing with a rollback that has been exercised.
5. An inventory that includes the appliances and the firmware.

Our infrastructure managed services run patching on that tiered basis with the exposure report going to the customer rather than staying with us, because the decision about accepting a risk belongs on your side of the relationship.