Patch Tuesday from an MSP's chair: why patch timing policy matters as much as patch coverage

Most MSPs measure patch performance one way: coverage. What percentage of devices are current. It's a reasonable number to track, and it's also an incomplete one, because it says nothing about when those devices got current relative to when the patch actually mattered. A fleet that's 98% patched, three weeks after a critical CVE started being actively exploited, is a worse security outcome than a fleet that's 90% patched within 48 hours of the same disclosure.

Timing is the dimension coverage numbers hide. Two patches released on the same Patch Tuesday can carry completely different urgency — one closes a theoretical vulnerability with no known exploit, the other closes one already being used in the wild — and treating both on the same monthly cadence is a policy choice, whether or not anyone wrote it down as one.

Two speeds, not one

• Standard cadence: routine patches move through rings on a predictable monthly rhythm — a soak group first, then wider promotion after a defined window with no regressions. This is where most patches belong, and where the "boring is good" discipline lives.
• Fast track: a patch for an actively exploited or high-severity vulnerability does not wait for the standard ring schedule. It gets prioritized, tested against the smallest viable soak group, and promoted faster — deliberately trading some of the soak-time safety margin for reduced exposure window, because the risk calculus for an actively exploited flaw is different from a routine update.

Timing policy also means deciding when not to patch immediately

The instinct to always patch as fast as possible ignores the other side of the timing question: a Friday-afternoon deployment to a client whose only IT support is you, with no weekend on-call, is a bad time even for an important patch, unless it's actively being exploited. Maintenance windows exist for exactly this reason — they turn "when can we reboot" from an ad hoc negotiation into a policy that already accounts for the client's actual schedule, not just the vendor's release calendar.

Coverage tells a client every device is patched. Timing tells them whether they were exposed for six hours or six weeks. Only one of those numbers is on most MSPs' scorecards.

This is the same rings-and-windows structure we've written about before as the antidote to 2am patch surprises, applied specifically to the timing axis: the ring model gives you a fast track and a standard track without collapsing either one into "patch everything the moment it's released" or "patch everything on the same monthly clock regardless of severity." Patch policy sits in the endpoint-management module in Nexus; the platform page carries the current, honest state of what's live versus still building.