The core problem in patch management is a timeline mismatch: public exploitation of a disclosed vulnerability can begin quickly, while a full rollout across servers, endpoints and appliances usually takes far longer. Every day inside that gap is live exposure to a known, public issue. Timings vary by vulnerability, so measure your own: time from vendor release to full deployment, by asset class.
Good patch management starts with an accurate asset inventory. You cannot patch what you don't know you're running, and "we think we know our environment" is a common source of the servers, forgotten VMs and shadow devices that never make it into a patch cycle at all.
On one estate, patching ran on a fortnightly ring model: ring 0 was IT and a few test servers, ring 1 a low-risk slice of production a few days later, then everything else. When a critical out-of-band patch landed, the rings were compressed to days rather than skipped, and any host that failed to report compliance showed up on a dashboard instead of in the next audit.
Prioritisation should be risk-based, not just severity-based. A CVSS score alone doesn't account for whether a vulnerability is being actively exploited, whether the affected asset is internet-facing, or whether a compensating control already reduces the practical risk. Layering exploit intelligence and exposure onto the raw severity score produces a much more useful patching order than working straight down a vulnerability scanner's default list.
Testing before broad deployment still matters, but it should be scoped to the systems most at risk from that patch, not used as a blanket excuse to delay everything by weeks. A defined, short testing window on a representative subset of systems, followed by automated rollout to the rest, closes the exposure gap far faster than a fully manual, sequential process.
Set a target for critical patches applied within a defined window, agree it with the business, and report the actual number. That figure is the real measure of how exposed the environment is on any given day. Where the process is manual, the fix is usually design: patch rings, automated deployment and reporting owned by whoever operates the platform.
Need security controls built and verified, not just reported? Security Engineering
All resources