74% Struggle to Coordinate the Fix: What Happens After the Scanner Hands You the List

A vulnerability scan can identify the problem. It cannot approve a production change, schedule downtime, persuade a vendor to validate a patch, or assign an owner in another department.

That is where remediation gets hard.

In a 2026 survey conducted by Demand Metric for Adaptiva, 74% of respondents said coordinating vulnerability prioritization and remediation was their biggest security issue. The survey included more than 200 IT and security professionals. It points to a real operational challenge, but it is not a universal measure of every organization: the publicly available announcement does not provide enough detail to treat its findings as representative of all businesses. Read Adaptiva’s report announcement.

The finding still captures a familiar pattern: a scan produces a list, and the list runs into change approvals, business schedules, vendor dependencies, aging technology, and competing priorities.

Remediation is not just a patching task. It is a coordination process.

WHY “JUST APPLY THE UPDATE” ISN’T A PLAN

Some patches are straightforward. Others need testing, approval, a maintenance window, and a rollback plan. A server might support an application that cannot be restarted during business hours. A production system might depend on a third-party vendor to certify that an update will not disrupt operations. A legacy asset may no longer have a supported patch at all.

These are not reasons to ignore findings. They are constraints a mature vulnerability management program needs to make visible and manage.

Verizon’s 2026 Data Breach Investigations Report reports a 43-day median time to fully resolve vulnerabilities in CISA’s Known Exploited Vulnerabilities catalog. That is a median drawn from Verizon’s observed data, not a recommended deadline, a guarantee, or a measure of every organization’s performance. It does show how long the gap between identifying a known-exploited vulnerability and fully resolving it can remain open.

The practical question is not simply, “Why wasn’t this patched?” It is: What is preventing the fix, who owns the decision, and what protection is in place while the issue remains open?

FIVE OBSTACLES THAT CAN STOP A FIX

1. Change control meets too infrequently

A change control board that meets monthly can turn a routine patch into weeks of additional exposure. The issue is not the existence of a review process. It is a process that does not distinguish urgent security risk from ordinary change.

Create an expedited path for actively exploited or high-impact issues. Define what evidence approvers need, who can authorize an emergency change, and how teams document the decision afterward.

2. The application cannot be rebooted on demand

A patch may require a restart, but the application it supports may be essential throughout the workday. “Patch now” is not a viable instruction if it means interrupting revenue, patient care, production, or customer service without an agreed window.

Coordinate maintenance windows in advance. Confirm dependencies, notify affected owners, validate backup and recovery options, and plan a rollback before deployment. A scheduled, tested change is more reliable than an improvised one.

3. A vendor controls the update

This challenge is especially visible in operational technology (OT), where a software update can affect safety, uptime, or equipment performance. In TXOne Networks’ 2024 Annual ICS/OT Cybersecurity Report, 41% of surveyed organizations reported delaying OT patching until vendor support was available. The survey covered 150 C-level executives. Its findings describe OT environments, not all IT teams or businesses.

Vendor review can be a necessary safeguard. But it can also extend the time a known weakness remains unpatched. Establish a way to track vendor requests, escalation contacts, expected response dates, and interim protections. “Waiting for the vendor” should have an owner and a follow-up date.

4. The asset is genuinely unpatchable

Some systems cannot be patched without unacceptable operational or safety risk. In Palo Alto Networks’ 2026 critical-infrastructure cybersecurity report, 42% of surveyed critical-infrastructure leaders named legacy, unpatchable OT assets as their organization’s single biggest cybersecurity risk.

That figure reflects leaders’ reported top concern. It does not mean 42% of OT assets are unpatchable, and it should not be generalized to all IT environments. It does underscore that in some operational settings, patching alone cannot close every exposure.

For those systems, consider compensating controls: virtual patching where appropriate, restrictive access rules, enhanced monitoring, and segmentation that limits communication to what the asset needs. These measures do not make an unpatched system equivalent to a fixed one. They reduce exposure while the organization evaluates longer-term options.

5. Nobody has clear ownership

A finding can sit unresolved because the system owner works in another department, has other priorities, or never received a clear remediation request. Security may identify the risk; IT may manage the endpoint; a business team may own the application. If no one coordinates the handoff, the work stalls between teams.

Assign a named owner to each remediation action. That owner may not be the person applying the patch, but they should be accountable for coordinating the decision, update, or documented exception.

WHAT MATURE REMEDIATION LOOKS LIKE

A mature program does not pretend every vulnerability can be fixed immediately. It makes decisions visible, consistent, and reviewable.

Set remediation targets by risk band. Use severity as an input, alongside exploit activity, asset exposure, business importance, and operational impact. A universal deadline for every finding ignores real differences in risk and fix complexity.
Plan maintenance windows. Coordinate testing, approvals, notifications, deployment, and rollback before the change. Escalate urgent issues through a defined process rather than waiting for the next routine meeting.
Apply compensating controls where patching is not currently feasible. For genuinely unpatchable assets, use suitable measures such as segmentation, restricted access, monitoring, or virtual patching. Record why direct remediation is not viable and what reduces exposure in the meantime.
Document risk acceptance. If leadership decides to defer or accept a finding, record the reason, affected asset, compensating measures, named approver, and review date. Revisit the decision when the asset changes, a fix becomes available, or risk increases.
Validate the outcome. Confirm through a rescan or other appropriate evidence that the vulnerability is resolved, or that the planned mitigation is actually in place. Closing a ticket is not the same as closing the risk.

That documentation matters. “Unpatched because nobody looked” is not the same as “unpatched after a documented, approved decision with protections and a review date.” The first points to a breakdown in oversight. The second is a risk decision that can be examined and reconsidered. Auditors and insurers may ask how vulnerabilities are identified, prioritized, assigned, and tracked, not only whether a patch was installed.

TURN SCAN FINDINGS INTO OWNED ACTIONS

A useful remediation record should answer a few basic questions:

What asset is affected, and how important is it to the business?
What makes the vulnerability a priority now?
Who owns the fix or the decision to defer it?
What is the next action and its expected date?
If it cannot be fixed yet, what controls reduce risk, and when will the decision be reviewed?
How will the team verify remediation or mitigation?

This is where vulnerability management becomes an operating discipline, not a recurring exercise in exporting scan results. Security, IT, application owners, vendors, and leadership need a shared view of the work and the decisions behind it.

Cenova Cyber’s Vulnerability Management as a Service (VMaaS) is designed to connect discovery, risk-based prioritization, guided remediation, tracking, and validation. We work with your team to move findings toward resolution and make remaining risks visible, not simply deliver a report and leave the follow-up to you.

Our vCISO services can also help establish the governance behind the process: decision ownership, escalation paths, risk acceptance, and leadership reporting.

CLOSE THE GAP BETWEEN FINDING AND FIXING

You do not need a perfect environment to manage vulnerability risk responsibly. You need a clear process for deciding what happens next, who is accountable, and how interim exposure is controlled.

Contact Cenova Cyber to discuss VMaaS or request a free vulnerability baseline scan. We’ll help you identify where remediation is getting stuck, and build a practical path from findings to verified action.