Building a patch cycle that holds

Most organisations do not have a patching problem so much as an exceptions problem. The routine servers get patched. What accumulates is the set of systems that were skipped once for a good reason and then skipped every month afterwards because skipping had become the default.

A patch cycle that holds is one where the exceptions are visible, owned and time-limited. That is more about process than tooling.

Agree the windows before you need them

The most common cause of a patch cycle collapsing is that each month's window is negotiated separately. That turns a routine activity into a monthly argument, and arguments are won by whoever most wants to avoid downtime.

Set standing windows, agreed once, in writing:

• Which day and time, per system group. Different groups can have different windows; a finance system should not be patched on the last day of the month.
• How much notice is given before a window is used.
• What happens if the window is missed: does it move to the following week, or wait a month? A month is usually too long.
• Who can cancel one, and what has to be true for that to be reasonable.

That last point matters most. If any system owner can cancel unilaterally, cancellation becomes the path of least resistance.

Group systems by consequence, not by type

Patching everything on the same schedule is either too slow for the exposed systems or too fast for the fragile ones. Three groups is usually enough.

Exposed. Anything reachable from the internet, plus the systems that handle authentication. These need the shortest interval between patch release and deployment, because the window between disclosure and exploitation is shortest here.

Standard. The bulk of the estate. A monthly cycle is normal and defensible.

Sensitive. Systems where an unexpected restart has significant business consequence, or where a vendor certifies specific patch levels. These get a longer cycle, more testing, and, importantly, a named owner who is accountable for the additional risk that the delay creates.

The point of the third group is not to excuse it. It is to make the trade-off explicit and attached to a person.

Make the emergency path different from the routine one

Out-of-band patching for actively exploited vulnerabilities has to work differently from the monthly cycle, and it has to be agreed before you need it.

Define it in advance:

• What triggers it. Usually evidence of active exploitation, or a critical severity on an internet-facing system.
• Who can invoke it, and who they need to inform rather than ask.
• What the target is. A number of hours or days, not "as soon as possible".
• What testing is skipped, and what the rollback plan is.

An emergency process invented during an emergency is slow and produces mistakes. One agreed in a quiet week is fast.

Handle exceptions as risk decisions

Every estate has systems that cannot be patched on the normal cycle. The problem is not their existence; it is that they are usually undocumented and permanent.

Treat each as a record with four fields: what is not patched, why, what compensating control is in place instead, and when this is reviewed.

Compensating controls are the part most often skipped. If a system cannot be patched, something else should be reducing the exposure: network segmentation, restricted access, additional monitoring on that host. An exception with no compensating control is not a managed risk; it is an unmanaged one with paperwork.

Set review dates and honour them. An exception that has been reviewed and renewed three times is telling you something about the system that deserves a larger decision.

Prove it happened

Patching that cannot be evidenced is a problem at audit time and, more importantly, a problem when you need to know whether you were exposed.

What you want to be able to produce, without a research project:

• Current patch level per system, from a source that is not the patching tool's own claim of success.
• The list of systems that failed to patch this cycle, and what happened to them.
• The current exception list with dates and owners.
• Time from patch release to deployment, for the exposed group.

Verification from a second source matters. Patch management tools report what they attempted. A vulnerability scanner reports what is actually present. When they disagree, the scanner is usually right, and the disagreement is where the risk lives.

The failure modes to watch for

Reboot avoidance. Patches applied but not activated because the restart never happened. The tool reports success and the vulnerability remains. Track pending reboots as a separate metric.

The forgotten estate. Systems that were never enrolled in patch management: a virtual machine built for a project, an appliance, something in a branch office. Reconcile the patching tool's inventory against your asset register regularly. The gap is always non-zero.

Third-party software. Operating system patching is usually solved. The browser plugins, runtimes, database clients and utilities installed on endpoints frequently are not, and they are a common initial access route.

Silent failure. A patch job that stopped running months ago and reported nothing because it reported nothing. Alert on the absence of a successful run, not just on failures.

A reasonable target

You do not need to be perfect. You need to be able to state, honestly:

• What proportion of the estate patched on schedule this cycle.
• Which systems did not, and why.
• How long the exposed group takes from release to deployed.
• That every exception has an owner and a review date in the future.

An organisation that can answer those four questions is in decent shape, even if the numbers are imperfect. One that cannot answer them is usually in worse shape than it believes.