Patch Management: Two Clocks, Not One

Patching is the least interesting part of security and one of the highest-leverage. It is also where the gap between written policy and daily practice is widest, because a patch policy takes an afternoon to write and a patch program has to survive contact with change windows, vendor release schedules, and a production system nobody is willing to restart.

The distinction that makes a program work is that there are two clocks, not one.

Clock one: the routine cadence

Planned, batched, and tested. Most organizations run this reasonably well, and the shape is unremarkable: monthly for servers and workstations, weekly rebuilds for container base images so patching happens in the pipeline rather than in production, and maintenance windows for operational technology where the vendor validates what is allowed.

Two details separate a cadence that works from one that stalls. Deploy in rings rather than everywhere at once, so a bad patch hits a pilot group instead of the company. And batch by asset class rather than by severity, because the change-management overhead is per-window, not per-patch, and fifty patches in one tested window is cheaper and safer than five windows of ten.

Clock two: the emergency path

This is the one that gets improvised, and improvisation under time pressure is where outages come from. An emergency path needs three things defined before you need it.

A real trigger. Not simply a critical CVSS score, which arrives too often to be actionable. The trigger is: actively exploited in the wild, on an asset you actually expose. That combination is rare enough to justify breaking your change process and common enough to plan for.

Pre-agreed authority. One named person who can approve an out-of-window change without assembling a committee. If your emergency path requires a meeting, your emergency path is a normal change with more shouting.

A mitigation option. Sometimes the patch does not exist yet, or it breaks something. Blocking at the edge, disabling the affected feature, or isolating the system are legitimate responses. Buying two weeks safely is a better outcome than an unplanned restart of a system you did not understand.

The test of an emergency path is whether it has ever run. If it has not, assume it does not work, and rehearse it against a low-stakes patch.

What to do about what you cannot patch

Every estate has some. End-of-life software the business depends on, an appliance whose vendor stopped shipping fixes, a machine controller whose warranty forbids changes. Pretending these will eventually be patched is how tickets stay open for three years and how auditors write findings.

The answer is a documented exception with four parts: a named owner senior enough to accept the risk, a compensating control such as network isolation or restricted access, an expiry date, and a review cadence. This is the same mechanism described in how to build a vulnerability management program, and it is what turns an embarrassing permanent gap into a decision on record.

Why patching alone is not vulnerability management

Patch management addresses vulnerabilities that have vendor fixes. A large share of what a penetration test finds has no patch at all: a permissive certificate template, a service account with an old crackable password, an over-permissioned cloud role, an API endpoint missing an authorization check. No amount of patching touches any of those.

That is worth being clear about, because organizations with genuinely excellent patch hygiene are sometimes surprised by an internal test. Patching is necessary and it is not sufficient, and the misconfiguration classes are covered in Active Directory attack paths and broken access control.

Metrics that tell you whether it is working

Patch latency by severity band, measured from vendor release to deployed rather than from ticket creation, because ticket creation is a metric you control. Percentage of the estate on a supported version. Deployment success rate, which is how you catch rings that silently fail. Exception count and exception age. And the number of emergency deployments per quarter, which should be small and non-zero; zero usually means the trigger is set too high rather than that nothing urgent happened.

Avoid reporting patches deployed as a headline number. It rises when Microsoft ships a big month and falls when they do not, and it tells the board nothing about exposure.

Where BD Emerson fits

Patch operations sit inside our vulnerability management practice, covering the routine cadence, the emergency path, and the exception governance that makes the unpatchable defensible. Because we also run continuous penetration testing, we can tell you which of your unpatched findings are genuinely reachable and which are already blocked by a control you forgot you had. The evidence feeds SOC 2 and ISO 27001 without a separate exercise.