Patch Management: What Happens in the Gap Between 'Available' and 'Applied'

A vendor ships a fix for a critical vulnerability on a Tuesday afternoon. The update sits in a queue, unapplied, while the business keeps moving: client calls, payroll, a product launch. Three weeks later, an automated scan built to find exactly that unpatched vulnerability finds it and gets in. Nobody made a decision to leave the door open for three weeks. It just wasn't anyone's specific job to close it fast enough, and by the time it became a problem, the most expensive kind of gap in IT had already done its work: the one between a patch being available and a patch being applied.

The Gap Has Been Widening, Not Closing

For years, the working assumption behind most patch management programs was that speed was a nice-to-have, since exploitation typically lagged behind disclosure by weeks or months. That assumption no longer holds, and the data on how slowly most organizations actually patch makes the risk clear.

The median time to patch a known vulnerability rose to 43 days in 2025, up from 32 days the year before, a 34% increase, according to Verizon's 2026 Data Breach Investigations Report. Even the organizations Verizon rates as top performers on patch management only close 30% to 40% of actively exploited vulnerabilities within the first week after they're flagged. Across the full dataset, only 26% of critical vulnerabilities were fully remediated in 2025, down from 38% the year before, even as the number of critical vulnerabilities organizations had to deal with grew by roughly 50%.

The same report found something that should reset how any growth-stage company thinks about its exposure: for the first time in the DBIR's 19-year history, exploiting a known vulnerability, not phishing, not stolen credentials, was the single most common way attackers got in, accounting for roughly 31% of the breaches analyzed.

Attackers Are No Longer Waiting for the Gap

The traditional patch management timeline assumed a buffer: a vendor discloses a flaw, ships a fix, and defenders have days or weeks to apply it before anyone weaponizes it. That buffer is gone. Google Cloud's Mandiant division, drawing on more than 500,000 hours of 2025 incident response investigations, found the mean time to exploit a vulnerability is now an estimated negative seven days, meaning exploitation is, on average, already underway before a patch is even public, according to M-Trends 2026.

The examples behind that number are specific. A critical on-premises SharePoint vulnerability was exploited within hours of Microsoft's fix shipping. A VMware vCenter flaw went from patch release to active exploitation by an advanced persistent threat group in five days, with hundreds of servers across dozens of countries compromised by day nine. Neither of these are fringe systems; SharePoint and vCenter both sit in the infrastructure layer that growth-stage companies depend on for file sharing and virtualization.

This is also why the CISA Known Exploited Vulnerabilities catalog keeps growing. CISA added 245 new vulnerabilities to the list in 2025, a 20% jump that brought the total past 1,484 entries, the sharpest expansion the catalog has seen in three years. Every one of those is a flaw with confirmed real-world exploitation, meaning the list of things that need patching immediately, not on the next scheduled maintenance window, keeps getting longer.

Why "We Have a Patch Policy" Isn't the Same as Patching Fast

Most companies in the 25-to-200-employee range already have some patching process in place, whether that's an internal IT hire running updates on a schedule or an MSP pushing them through an RMM platform. The problem is rarely that patching doesn't happen. It's that it happens on a cadence built around convenience rather than risk.

Edgescan's 2025 Vulnerability Statistics Report found that internet-facing critical vulnerabilities, the kind an attacker can find and target without ever touching the internal network, still took an average of 35 days to close. Across all high and critical severity findings, the average time to remediate came in at just under 55 days. Those numbers reflect a pattern that shows up in nearly every growth-stage environment: patches get applied in batches, on a monthly or quarterly cycle, regardless of how severe or exposed the underlying vulnerability is. A minor bug in an internal tool and a critical, internet-facing flaw discovered in the same week often get the same treatment and the same timeline.

A few specific gaps show up over and over:

No single owner. Patching gets split between an MSP, an internal admin, and whoever manages a handful of specialty systems, and no one person is accountable for whether the whole environment is current.
Third-party software gets skipped. Operating system patches often run automatically, but browsers, PDF readers, VPN clients, and firewall firmware, frequently the most exploited category, get missed because nothing forces them into the same update cycle.
Remote and hybrid devices fall off the schedule. A laptop that's rarely on the corporate network misses the update windows that trigger patches for on-site machines.
Patches that require a restart get deferred indefinitely. Anything that interrupts someone's workday tends to get pushed to later, and later often doesn't come.

A Framework for Closing the Gap

Closing the gap between available and applied doesn't require a bigger IT budget. It requires treating patch velocity as a business risk decision instead of a technical chore, and building a program around that. Six steps make up a workable framework for a company without a dedicated security team:

Inventory everything that needs patching. Operating systems and productivity software are the obvious targets. The bigger risk usually sits in what gets forgotten: network and firewall firmware, VPN appliances, browser extensions, and the admin consoles for cloud platforms like Microsoft 365 or Google Workspace.
Tier vulnerabilities by severity and exposure, not severity alone. A critical vulnerability on an internal, isolated system carries different risk than a medium-severity flaw on something internet-facing. Exposure should move a patch up the queue as much as severity does.
Set an explicit SLA for each tier, and hold whoever executes patching, whether that's internal staff or an MSP, accountable to it.
Automate what can be automated. RMM platforms and patch management tools can apply low-risk updates automatically and stage higher-risk ones for a tested rollout, cutting the manual workload that causes delays in the first place.
Track compliance, not just deployment. A patch being pushed and a patch being successfully applied are two different events. Confirm the second one, not just the first.
Review patch performance at the leadership level monthly, not just inside IT. If the person accountable for the business never sees how the environment is actually performing against its SLA, nothing is pushing the gap closed.

A simple SLA table, tied to severity and exposure rather than a flat monthly cycle, gives that framework something concrete to measure against:

Severity Tier	Target Patch Window	Example
Critical, internet-facing	72 hours	Internet-facing VPN or firewall CVE
Critical, internal only	7 days	Server-side flaw on an isolated system
High	14 days	Privilege escalation bug on a workstation
Medium/Low	30 days	Non-exploitable configuration weakness

The specific windows matter less than the principle: severity and exposure set the clock, not the calendar.

What the Gap Actually Costs

The financial case for closing the gap isn't hypothetical. IBM's 2025 Cost of a Data Breach Report put the global average cost of a breach at $4.99 million, and breaches that began with exploitation of a vulnerability, as opposed to phishing or stolen credentials, averaged $4.24 million. Those figures span organizations of every size in IBM's study, so they aren't a precise stand-in for what a 50-person firm would pay, but the direction matches what growth-stage companies actually experience: incident response, forced downtime, client notification, and lost business cost far more than the patching program that would have prevented them.

The historical pattern behind that math isn't new. When Microsoft shipped the patch for the vulnerability behind the WannaCry ransomware outbreak in March 2017, organizations had 59 days before the attack started spreading that May, according to CISA's advisory on the incident. The organizations that got hit weren't unaware a patch existed. They simply hadn't applied it yet, and the gap between those two states is where the damage happened. Nine years and a much faster exploitation cycle later, that same kind of gap is more expensive to leave open, not less.

Where This Fits Alongside Your Existing MSP or IT Team

Patch management is execution work, and execution belongs with whoever already runs it: an internal IT hire, an MSP, or some mix of both. What's usually missing isn't the technical capability to apply patches. It's someone above that function who owns the SLA, tracks whether it's actually being met, and raises it as a business risk when it isn't.

That's the role fractional IT leadership plays here. Elevaire doesn't replace the MSP or internal team pushing updates; it sets the patch SLA the environment should be held to, confirms compliance is tracked rather than assumed, and brings patch performance into the same leadership conversation as budget and growth planning. Your existing provider keeps the environment running. Elevaire makes sure someone is accountable for how fast it's actually being secured.

Frequently Asked Questions

How much does closing the patch management gap actually cost?

Most of the cost isn't new spending, it's redirected effort. A company already paying for an MSP or an internal IT function is already paying for patching; the gap usually comes from a missing SLA and missing oversight, not a missing tool. Where a real gap exists, such as no RMM platform or no inventory of third-party software, closing it typically costs a few thousand dollars a year in tooling, far less than a single incident response engagement.

Does closing this gap mean replacing our MSP or IT provider?

No. Fractional IT leadership sets the standard the patching program should meet and holds it accountable; your MSP or internal team still does the actual patching. The two roles work together rather than compete.

What's a realistic patch SLA for a company with no dedicated security team?

The tiered targets above, 72 hours for critical internet-facing flaws, seven days for critical internal ones, 14 days for high severity, and 30 days for medium or low, are achievable for most growth-stage companies once patching is automated and tracked by severity instead of handled as a flat monthly cycle.

How do we know if our current patch cadence is actually working?

Ask for a report showing what percentage of known critical vulnerabilities in your environment were closed within your target window over the last quarter, not just how many patches were deployed. If nobody can produce that report, that's the answer.

What's the actual difference between a patch being "deployed" and being "applied"?

Deployed means the update was pushed to a device. Applied means it installed successfully and the device restarted where required. A meaningful share of environments that look fully patched have devices where deployment succeeded but installation silently failed, often because of a pending restart nobody forced through.

How do we get started?

Start with an inventory of everything in the environment that receives updates, followed by an honest audit of how long it currently takes to close a critical vulnerability once one is identified. That baseline makes it possible to set a realistic SLA and measure progress against it from day one.