Patching CVEs is a business decision, not just an IT task
Why vulnerability patching keeps getting delayed, what the real cost of that delay is, and how to frame it so it gets prioritised.
2015 has been a loud year for vulnerabilities. GHOST, FREAK, VENOM, Stagefright, and a long list of others - each one accompanied by advisories, vendor patches, and a wave of articles about whether companies are actually patching. Most are not, or not fast enough.
I see the same dynamic in almost every organisation I work with: the security team knows about the CVE, the IT team has the patch, and it still takes weeks or months to deploy. The bottleneck is rarely technical. It is organisational.
Why patches get delayed
The real blocker is almost always one of three things:
Change control windows. Many organisations run production changes on a fixed schedule - weekly or monthly. A critical patch arrives on Wednesday. The next window is three weeks away. The formal answer is "it will go in next cycle". The attacker's answer is different.
Regression risk. Patches break things. An OS update that changes library behaviour can affect application compatibility. A firmware update on a network device can change routing behaviour. The team knows this from experience, and "test first" becomes "test forever".
Unclear ownership. A vulnerability spans multiple systems. Who is responsible for patching the underlying library in the application server - the infrastructure team, the application team, or the vendor? When ownership is unclear, tickets sit in queues.
The cost of delay is not theoretical
The cost of an unpatched vulnerability is invisible until it is not. After a breach, the forensic timeline usually shows that the exploit was available and the patch existed for weeks before the incident. The question "why wasn't this patched?" then becomes very difficult to answer in front of an auditor, a regulator, or a customer.
For critical infrastructure - power, water, finance, transport - this is a regulatory question, not just a reputational one. But even outside regulated industries, the downstream cost of a breach from a known, patchable vulnerability is almost always higher than the operational cost of the patch cycle.
Framing it for the business
The mistake I see most often is framing patching as a maintenance cost - something IT needs to do, a cost centre, an interruption to "real" work. That framing loses every prioritisation fight against new features, customer deliverables, and revenue-related projects.
The correct framing is risk. A known, unpatched CVE with a public exploit is an open exposure with a calculable blast radius. The business decision is not "should we patch this" but "how much time are we willing to carry this exposure, and what is our response plan if it is exploited before we patch it?"
When the question is framed that way, most executives make a different decision than "put it in next month's change window".
A practical minimum
Three things that actually move patch cycles faster in practice:
- Separate the emergency track from the routine track. Critical CVEs (CVSS 9.0+, public exploit, exposed attack surface) go through an expedited process. Everything else goes through the normal change window. Mixing them means everything is slow.
- Pre-authorise the emergency track. The expedited process should not require the same approvals as routine changes. Define a pre-approved scope and procedure in advance, not at 11pm when the patch is needed.
- Track mean time to patch by severity. Make it a metric, report it, own it. What gets measured gets managed.
Patching is not glamorous. But an unpatched known vulnerability is a risk that the business is actively choosing to carry. Making that choice visible is the first step to making it rational.