Patching Is Not a Project

Every few months a business calls us after something has gone wrong, and asks the same question: how sophisticated was the attack?

Usually, not very. The vulnerability was public. The patch had shipped. Nobody applied it, because patching had been treated as a project with an end date rather than a process with a rhythm.

The gap that matters

The number worth tracking is not "are we patched" but how long it takes you to go from a patch being released to it being deployed everywhere. Attackers work on that same clock, and they are faster than they used to be — public exploit code for a serious vulnerability often appears within days.

A reasonable target for most businesses:

Severity	Target window
Critical, internet-facing	48 hours
High	2 weeks
Everything else	Monthly cycle

If you cannot say what your current window is, that is the first thing to fix.

Why it slips

In our experience it is rarely negligence. It is:

1. No inventory. You cannot patch what you do not know you own. Shadow hardware and forgotten VMs are the usual suspects.
2. Fear of breakage. One bad update years ago turned into an informal policy of waiting. The waiting never got revisited.
3. No owner. Everyone assumes it is covered by someone else — often by a provider whose contract does not actually include it.

Making it routine

The fix is boring, which is why it works:

• Maintain a real asset inventory and reconcile it monthly.
• Patch a small pilot group first, then everything else 48 hours later. This catches the bad update without stalling the whole cycle.
• Report the window, not the activity. "97% of endpoints within 14 days" tells you something. "Patching performed" does not.
• Put it in writing with whoever runs your IT, including who is accountable when the window is missed.

None of this is sophisticated either. That is rather the point.

Want to know what your current patch window looks like? Talk to us — it is usually the first thing we measure.