The Security Metric That’s Failing You
Security teams have measured patch rates for so long that somewhere along the way, the metric became the strategy. It works well on a dashboard. It gives leadership something concrete to track. Peter Drucker is often attributed as saying, “What gets measured gets managed.”
But the gap between a clean patch report and a secure environment is where most of the real risk lives. Misconfigured systems, outdated access permissions, and network segments set up during an acquisition and never reviewed again will never show up in a patch report.
Most of the environments I work with run Oracle, SAP, or VMware. When I look at where risk sits, it is rarely in the patch queue, and it’s rarely solved by patching either.
The Timing Problem No Patch Cycle Can Solve
According to Zero Day Clock, last year, the window between a vulnerability being disclosed and active exploitation was around 23 days, which was long enough for most enterprise change control processes to function. A team that stayed on top of things could assess the vulnerability, test it in the environment, get it through approval, and deploy before it was widely weaponized.
That window is now closer to 15 hours. By the time a vulnerability has been assessed, tested in the environment, approved, and scheduled for deployment, someone has already used it. The patch-first model assumed defenders would always have enough time to respond, and that has not been true for a while now. By the time you’re ready to act, the vulnerability is already being exploited.
And we’re going to see that get even tighter — with the advent of Claude Mythos and Project Glasswing, we are about to see an unprecedented number of vulnerabilities exposed — we are now firmly in the AI-speed vulnerability discovery era.
Where Things Go Wrong
The security incidents I see in enterprise environments rarely trace back to a sophisticated attacker who found something no one else had noticed. They usually trace back to operational problems that had been building quietly for a while.
A common example: a patch gets pushed before testing is complete because the closure date was the priority. Something downstream breaks as a result. What started as a security response becomes an outage, and the team spends the next two days recovering instead of dealing with the original problem. In another scenario, an incident hits overnight and the response stalls because nobody can quickly answer who owns the affected system, what changed in the last few weeks, or who currently has access to it. Time that should be spent on containment gets spent on piecing together basic information that should have been readily available.
Support contracts are worth examining closely before something goes wrong. Most enterprise support agreements are built around response time, meaning how quickly someone acknowledges the ticket. Knowing the environment and being able to resolve the problem are not part of that agreement. The engineer picking up a critical issue at 2 a.m. on a weekend is often working from a script with no prior knowledge of the systems involved. By the time most organizations understand that gap, something serious has already gone wrong.
What Vendor Pressure Is Doing to Security Programs
The vendor relationships that enterprise IT depends on have changed significantly over the past few years. Oracle, SAP, and VMware are pushing faster upgrade cycles while support quality has declined. Teams are being asked to absorb more change with roughly the same internal capacity they had before.
Most IT leaders know exactly what this feels like. Staying current with the vendor means taking on the operational risk of changes that have not been adequately tested in the environment. Falling behind means running software the vendor no longer fully supports from a security standpoint. There is no clean path through that, and while teams are figuring out which way to go, the security work that would reduce risk tends to wait.
What Security Controls Look Like in Practice
Real security shows up in how the environment is designed and operated day to day. A web application firewall should be inspecting traffic before it reaches your systems, and network segmentation should increase the difficulty of a breach while also limiting how far a breach can travel if something gets through. Access permissions accumulate drift over time and need to be reviewed regularly enough that what people can access reflects what they do today. Systems should be stripped of services that are not in use, and monitoring should reflect what is happening in the environment rather than a baseline that was set at initial configuration and never updated. Getting all of this to work together is an operational problem, and staff changes, competing priorities, and vendor upgrade cycles are what tend to pull it apart.
The organizations that manage this well are not always the ones with the largest security budgets. They tend to be the ones that made careful decisions about these controls and have dedicated staff that maintain them. Security disciplines that get treated as a completed project tend to degrade quietly until an audit or an incident makes the gaps impossible to ignore. Organizations that are positioned to come out ahead in the near term tend to have clear visibility into their assets, a secure development lifecycle, the ability to triage efficiently, and strong discipline around security controls. Those falling behind are often already struggling with gaps in exposure management and limited capacity to remediate risks quickly.
What AI Is Doing to Existing Risk
Employees are already using AI tools across most enterprise environments, often through external platforms or personal accounts, and that is not something that can be easily tracked. AI doesn’t create new risk as much as it exposes and accelerates what’s already there. The exposure depends on what those tools can reach inside the environment. Accounts with broader permissions than they should have and data that has never been properly classified become harder to manage when AI tools can find and surface information at scale in ways nobody thought to plan for when the governance policies were written. The organizations handling this reasonably well are mostly the ones that already had clean access controls and clear data ownership in place and are applying that same discipline as AI tools get introduced across the business. All of these points point to a larger shift.
Control Is What Matters
As CISA puts it, organizations should “implement industry standards and best practices rather than relying solely on compliance standards or certifications.” That is the difference between reporting security and exercising control.
Control is what matters. Right now, most organizations believe they’re in control because the reports look right. Systems are patched. Tools are in place. The boxes are checked.
But the environment has already changed. The window to respond has collapsed. Vendor support is less reliable. AI is accelerating everything, including the risk. And most teams are still operating as if they have time, they no longer have.
That’s where the real exposure sits.
The organizations that hold up are not the ones doing more. They’re the ones operating differently. They understand their environment, reduce exposure in practical ways, and build layers that hold when something inevitably slips through.
Because at this point, security isn’t about reacting faster. It’s about control.
And control isn’t assumed. It’s built.
Compliance may reassure the board, but only control actually protects the company.
