The uncomfortable fact about patch management is the timeline mismatch: attackers routinely begin exploiting a disclosed vulnerability within days, sometimes within 24 hours, while many organisations still take on the order of months to fully remediate the same critical vulnerability across their environment. Every day inside that gap is a day of live exposure to a known, public issue.
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.
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 genuinely risk 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.
The target worth aiming for is roughly 95% of critical patches applied within a defined SLA window, tracked and reported on — not as a compliance exercise, but because that number is the actual measure of how exposed the environment is on any given day.
All technical perspectives