On a Tuesday afternoon in the operations center of a mid-size financial services firm, a security analyst finishes her weekly vulnerability scan and scrolls to the top of the results. The finding near the top isn’t alarming in an unusual way: a remote code execution flaw with a CVSS score of 9.8, a patch available for more than a month, but no indication that anyone had applied it. She creates a ticket, logs the asset identifier from her scanner as PRODWEB-042, marks it P1, assigns it to IT operations, and moves down the list.
Two weeks later, the ticket is still open. The IT team didn’t ignore it; they looked at it three times. The difficulty was that nobody on that team could locate a system called PRODWEB-042. The CMDB listed the same machine under a different name: WebServer-Production-East-2. Same physical box, same vulnerability, two different identifiers in two different systems, with no bridge between them.
Closing the ticket requires someone to reconcile those records, confirm which team owned the asset, and verify that it falls within the current patch window. That’s work nobody has scheduled. It’s unplanned labor that would have to squeeze past everything else in the queue. So, it waits. While the finding sits, the clock keeps ticking.
“The problem wasn’t that IT was slow. They couldn’t find the asset the ticket was asking them to fix.”
Neither team failed in any obvious way. Security found the vulnerability quickly, and IT responded when they could. The failure happened in the seam between two competent groups, both working from legitimate but incompatible representations of the same environment.
That seam is where most enterprise breaches actually begin. Not in an unknown zero-daythreat that slipped through the defenses, but in the finding that was discovered, logged, handed off to exactly the right team, and sat in the queue for weeks while nothing moved.
The Window Is Closing Faster Than Anyone Thinks
The gap between IT and Security has always existed. What is changed is how much time organizations have to cross it.
Back in September 2017, Equifax disclosed that attackers had accessed the personal records of 150 million Americans. A patch had been available for two full months before the breach. Equifax knew about it but never applied it. The organization became a symbol of remediation failure, and the lesson most enterprises took from the episode was straightforward: you must move faster.
For a while, that felt like enough. In those days, the average time between a vulnerability’s public disclosure and its active exploitation in the wild was 756 days (about 2 years). That 2-year buffer absorbed a hefty amount of organizational friction. IT could take weeks to track down the asset, sort out ownership questions, and work through an already crowded queue. There was still time.
Unfortunately, that math doesn’t hold anymore. AI-assisted exploit development has compressed the timeline faster than most enterprise security programs have adapted.
Today, the average time from disclosure to active exploitation has dropped to under ten hours. The informal assumption that defenders would have months to catch up has given way to something closer to a footrace where one side starts with a significant and growing head start.
In 2018, the average time to exploit a newly disclosed vulnerability was 756 days. Today it’s under 10 hours. The remediation process hasn’t changed nearly that much.
Meanwhile, the remediation side of the equation has moved in the opposite direction. The median time to fully remediate a critical vulnerability still exceeds 60 days. That& isn’t because IT teams are inattentive. It’s because the handoff between detection and vulnerability remediation involves a series of friction points that erode days and weeks before the actual work can begin.
The result is a 55-day gap between when organizations typically resolve critical findings and when attackers can exploit them. Against a 2-year exploitation window, that gap was survivable; against a 10-hour window, it is a fundamentally different risk environment.
In hindsight, the Equifax breach looks patient by comparison. Two full months passed before anyone exploited what was sitting there. Organizations fielding critical vulnerabilities today measure that exposure in hours. The handoff problem between Security and IT has not gotten smaller. The time available to survive it has.
Why Findings Don’t Move
The experience at our fictional financial services firm is not unusual. What typically happens is something like this: a critical finding arrives in IT’s queue, the asset identifier in the security ticket does not match anything in the inventory, and the first task becomes figuring out what the ticket refers to. Someone asks Security for clarification, and they come back the next morning with an IP address that maps to a CMDB entry.
The listed owner is a team that was reorganized eighteen months ago. The person who used to run that team is not sure whether the system stayed with them or transferred with a project that moved departments. By the time all that gets sorted out, if it gets sorted out at all, two weeks have passed, and the actual remediation work has not started.
This isn’t an edge case or a symptom of organizational dysfunction. It’s a typical experience in mid- to large-sized enterprises, and it happens because Security and IT operations teams are always working from different asset data that was never designed to stay synchronized. Vulnerability management scanners see the environment through network exposure and software fingerprints: what is listening on which port, what software version is running, what known flaws that version carries. CMDBs see the environment through configuration records and ownership assignments, built over years of IT management and updated in ways that vary enormously across organizations.
These two views of the same environment almost never fully agree. Asset names drift as systems age and teams change. IP addresses are reassigned without anyone updating the records. Systems are provisioned outside normal channels and never make it into the CMDB at all. As a result, two datasets exist, each internally coherent but incompatible precisely where they need to connect.
The breakdown tends to happen at the same four failure points, with enough regularity that they look less like failure points and more like structural features of how most enterprises are organized.
Security Risk Remediation
Want to see this gap in your own environment?
See what a shared view of your assets makes possible.
Why Do IT-Security Handoffs Break Down?
The handoff between IT and Security teams often breaks down at one of four following failure points:
1. Asset identity mismatch The finding references an asset IT cannot locate by that name.
2. Ownership ambiguity No clear record of who is accountable for the affected system.
3. Scope uncertainty IT cannot confirm the asset is live and within patch scope.
4. Tool disagreement The scanner and CMDB report conflicting data on the same asset.
Asset identity mismatch. The vulnerability references an asset by a name or identifier that doesn’t appear in the IT inventory. Figuring out that a scanner hostname and a CMDB record point to the same system should take five minutes. In practice, it often takes days of manually cross-referencing across systems, because nobody has a single authoritative lookup that connects the two.
Ownership ambiguity. No clear record exists of who is accountable for the affected system. This is most common for assets older than three years, or assets that have changed hands during a reorganization without a formal ownership transfer. The system exists and is presumably running, but no one is formally responsible for it.
Scope uncertainty. IT can’t confirm whether the asset is live and within the current patch scope. Decommissioned systems that still appear in scanner results and generate findings that waste remediation effort. Active systems missing from the CMDB create exposure that goes untracked and untreated. This confusion compounds over time: Edgescan reports that close to half of enterprise vulnerabilities remain unpatched after twelve months, and 17% of those are rated high or critical severity, not because they went undetected, but because the handoff broke before anyone could confirm the scope.
Tool disagreement. The vulnerability management scanner and the CMDB report conflicting configurations for the same asset, and nobody acts until someone reconciles them by hand. That reconciliation is unplanned work and falls to whomever has the most context at that moment, not necessarily someone who has the most available time.
After teams examine stalled remediation efforts, assigning responsibility is difficult. Security is working from one representation of the environment; IT is working from another. Each team may be accurate within the limits of their own system, but neither record is complete enough to support a clean handoff under time pressure.
According to Panaseer, only 37% of CISOs report full visibility across their IT estate, which means the other 63% of organizations are navigating the handoff from behind an incomplete map. The breach record reflects that. Helpnet Security reports that eighty percent of organizations that experienced an application security incident in the past year were hit through a vulnerability their own security team had already identified and cataloged. They weren’t attacked by a zero-day threat or some novel technique, but through a finding that was already on the list, assigned and waiting for a handoff that was never completed.
37% of CISOs say they have full visibility across their IT estate. In the other 63%, IT and security are working from different maps of the same environment.
Here’s an example. Last July, Microsoft patched two chained vulnerabilities in SharePoint Server. Government agencies and healthcare organizations were explicitly notified and instructed to apply the fix. By the time researchers completed their analysis of the breach activity that followed, 396 SharePoint systems had been compromised.
The patch was available and the organizations knew about it, but somewhere in the space between knowing and fixing, the process stopped.
That is not a story about awareness failing. It is a story about the mechanics of turning awareness into action inside an organization where the asset data doesn’t hold up under pressure.
The pattern holds across industries and organization sizes: a critical finding arrives. A fix is available, the handoff between security and IT encounters friction, and the fix does not get applied before an attacker exploits the vulnerability.
In 2025, vulnerability exploitation overtook credential theft as the leading breach vector, according to the Verizon DBIR. Bad actors do not need a novel technique or an unknown exploit. They just need a vulnerability finding that no one closed.
80% of organizations were breached through a vulnerability their own security team had already found. The problem isn’t detection. It’s what happens after detection, when the finding has to cross from one team’s system into another.
Explore the Approach
Want to see how Lansweeper closes this gap?
Explore the full approach connecting risk findings to IT execution.
What “From Finding To Fixed” Actually Requires
When organizations look at data like this, the typical response is to reach for process: Tighten remediation SLAs, add mandatory escalation steps, hold weekly syncs between security and IT operations, build a remediation dashboard, and review it in the monthly governance meeting.
These interventions aren’t useless, but they don’t address what’s actually causing the delay. Tighter remediation SLAs applied to broken data do not speed remediation. They just result in faster escalation of the same underlying problem, which tends to generate friction between teams without resolving anything for the affected assets.
When a security analystidentifies a vulnerability on a specific asset, the security remediation process can only move as fast as IT can answer three questions:
- What is this asset?
- Who owns it?
- Is the asset currently in scope for patching?
If those answers require manual investigation across multiple systems that don’t agree with each other, the process stalls, regardless of the ticket’s urgency.
Organizations that are genuinely narrowing this gap have not simply added more governance to the handoff. They have built a shared, continuously validated picture of the environment before the finding arrives. They have a single inventory with an authoritative view of the technology estate, so no reconciliation is required at the moment of urgency.
“When the finding arrives, the asset is already understood. The question isn’t ‘where is this?’ It’s ‘how fast can we get to it?’”
In practice, that means every device and system in the environment is known and kept current, not just the assets that IT manages through normal provisioning channels, but the ones that arrived through acquisitions or are provisioned outside normal channels, and those that have been running quietly for years without anyone thinking to update their records.
Each asset carries the context that makes remediation possible: who owns it, what it connects to, what configuration state it’s in, and where it sits in the patch lifecycle. An inventory that’s six months out of date isn’t a managed inventory. At best, it is a historical record that creates a false sense of coverage while real exposure accumulates in the gaps.
Lansweeper enables Cyber Asset Intelligence by providing organizations with a shared,trusted, continuously validated understanding of the technology estate that both security and IT can work from, without first having to reconcile individual, disparate datasets. When that foundation exists, the handoff changes in character.
- The finding arrives and the asset is already there.
- The owner is already identified.
- The scope is already confirmed.
What used to require two weeks of back-and-forth between two teams comparing incompatible records becomes a work order that IT can act on immediately. That is not a modest efficiency gain: at a 10-hour exploitation window, it is the difference between exposure that gets closed and exposure that becomes a breach.
Lansweeper is built around this idea: organizations need a single, continuously validated view of their technology estate before they can act on it with confidence. When a security finding arrives and the asset is already known, owned, and in scope, IT can move directly to the work rather than spending two weeks establishing the preconditions for it.
That shift in sequence, from investigation to execution, changes the remediation timeline. The 10-hour exploitation window is not a reason to panic. It is a reason to close the gap between finding and fixing that most organizations have been quietly tolerating for years.
The Ticket Is Still Open
Go back to the analyst at the financial services firm. Fourteen days in, PRODWEB-042 is still in the queue, unpatched, while automated scanners probe for that exact CVE across the internet. They did their job. The IT team isn’t ignoring it. The organization has a problem that neither team has the data to solve on their own.
The situation is a data problem, and data problems are solvable.
The organizations closing this gap are the ones building a shared, continuously validated picture of the environment before findings arrive, so when a ticket lands, teams already understand the asset, the owner is already identified, and the scope is already confirmed.
For most organizations, that’s closer to a solvable problem than the backlog numbers suggest. The findings and the fixes are both there. The gap is in the foundation, and unlike the exploitation window, the foundation is something you can actually build.
Security Risk Remediation
Want to see this gap in your own environment?
See what a shared view of your assets makes possible.
FAQs
-
What does it mean to close the gap between finding a vulnerability and fixing it?
Closing the gap means eliminating the delays between the time Security identifies a vulnerability and IT starts remediation. Those delays typically happen when Security and IT work from different asset inventories and ownership records. When both teams share one continuously validated view of the technology estate, findings arrive with the context they need to begin remediation immediately, because they no longer need to spend time and effort confirming basic facts about the affected asset.
-
Why did the average time to exploit a vulnerability drop from 756 days to under 10 hours?
Advances in AI-assisted threat exploitation have made it faster and easier for attackers to weaponize new vulnerabilities. They now have automated tools that can identify vulnerable systems, generate working exploit code, and begin attacks within hours. Meanwhile, many organizations still take more than 60 days to remediate critical vulnerabilities, leaving a significant window of exposure between discovery and remediation.
-
What changes when Security and IT work from a shared asset foundation?
A shared asset foundation ties every vulnerability to a trusted source of truth, a designated owner, and the business context they need to prioritize and begin remediation. Instead of spending valuable time reconciling conflicting inventories or ownership information, Security and IT can work together to fix issues right away. A platform like Lansweeper’s Cyber Asset Intelligence Platform delivers a unified and validated view of the technology estate, so both teams can work from the same trusted source of truth.
-
What’s the difference between a vulnerability scanner and a CMDB, and why do they disagree?
A vulnerability scanner identifies exposed systems based on network observation and software fingerprints. A CMDB tracks ownership and configuration data maintained by IT teams. Both systems can be accurate within their own scope, yet fall out of sync with each other. Why? Because assets get renamed, IP addresses change, and some systems are deployed outside of IT oversight entirely. With a shared, continuously validated asset foundation, teams can reconcile those differences and act quickly when a new vulnerability is discovered.
-
What happens if organizations don’t fix the Security-IT handoff?
Attackers can now exploit newly disclosed vulnerabilities in less than 10 hours, while remediation often takes more than 60 days. That gap leaves known vulnerabilities exposed for too long, increasing risk. Improving the handoff between Security and IT can help reduce the exposure window by helping to ensure any findings related to the vulnerability are shared quickly to help with remediation.
-
What does it look like to have a shared view of your technology environment?
When there is a shared asset foundation, Security and IT have a continuously validated inventory with configuration details, ownership information, and remediation status, and both teams work from the same trusted information. Lansweeper’s Cyber Asset Intelligence Platform provides this shared foundation, helping to accelerate remediation while improving visibility and accountability across teams.
