Exploitation Leads as Patch Backlogs Grow: Why Fix Everything Fails
Exploitation is now the leading route into many organisations, and the gap between discovery and remediation is widening. Verizon’s Data Breach Investigations Report 2026 reports exploitation at 31%, making it a dominant method in cyber incidents. At the same time, only 26% of CISA Known Exploited Vulnerabilities are fully fixed, with a median fix time of 43 days.
That combination should concern both technical and financial leaders. Attackers are not waiting for perfect conditions. They look for exposed systems, known weaknesses, and delayed fixes. When those three factors meet, a vulnerability stops being a line item in a scanner and becomes a business risk.
The problem is not a lack of effort. Many security and IT teams are working through large queues of patches, service tickets, exceptions, and ageing systems. The problem is that the traditional goal, “fix everything,” no longer matches the pace, volume, or business reality of modern exposure.
Exploitation has moved from one risk among many to the leading concern
Verizon’s 2026 finding that exploitation accounts for 31% of incidents is more than another annual statistic. It signals a shift in attacker behaviour. When public proof of a flaw exists, when exploit code circulates, or when a weakness appears in an internet-facing system, attackers can act at scale.
That matters because many organisations still treat vulnerability remediation as a technical hygiene exercise. Scan. List. Patch. Repeat. This works only when the number of findings is manageable and the business can absorb constant downtime, testing, and change approval.
Modern environments do not look like that. They include cloud workloads, remote access tools, software supplied by third parties, internet-facing portals, old databases, and systems that support time-sensitive operations. Each part adds exposure. Each dependency adds delay.
The Intruder Attack Surface Management Index 2026 adds another warning signal: 42% of organisations have an exposed database. An exposed database is not always breached, and not every exposure contains sensitive data. But the risk is direct. Databases often hold customer records, financial information, supplier data, intellectual property, or operational logs. If an exposed database also has a known exploited vulnerability, the remediation clock is no longer theoretical.
The PwC Digital Trust Insights 2026 report points to the governance gap behind the technical gap. Only 6% of organisations have fully implemented the surveyed data risk measures. That means most organisations are still building the controls, processes, and accountability needed to manage data exposure well. Weak data controls raise the likely impact of exploitation because a successful attacker reaches information that the business cannot easily replace or fully recover.
These three data points connect:
Exploitation is common, at 31%.
Known exploited vulnerabilities remain unresolved, with only 26% fully fixed.
Data exposure remains widespread, with 42% of organisations exposing a database and only 6% fully implementing surveyed data risk measures.
The result is a larger blast radius. A single unpatched system can create technical disruption, regulatory reporting duties, customer notifications, legal costs, and business interruption.
Patch backlogs are growing faster than teams can clear them
A patch backlog is not just a queue of missed updates. It is deferred risk. The longer it grows, the harder it becomes to tell which items matter and which can wait.
Several forces drive this growth.
New vulnerabilities arrive continuously. Vendors release fixes on different schedules. Cloud services, appliances, operating systems, and applications all produce their own alerts. Security tools often report the same weakness in different ways, which increases noise. Some patches need regression testing to make sure they do not break a business process. Some systems have narrow maintenance windows. Some assets have unclear ownership.
This causes a practical problem. A team may know a vulnerability exists, know a patch is available, and still be unable to deploy the fix quickly. In regulated sectors or operational environments, change control may require testing, approval, rollback planning, and communication to service owners.
Verizon’s reported 43-day median fix time for known exploited vulnerabilities shows how wide the window can remain. A median of 43 days means many fixes take longer. For a weakness already known to be exploited, that is a long exposure period.
The backlog also creates distorted reporting. A monthly chart might show that thousands of vulnerabilities were closed. That sounds positive. But if the closed items were low-risk internal findings while internet-facing exploited flaws stayed open, the business risk may not have improved.
This is where operational metrics and risk metrics split apart.
Common operational metrics include:
Number of vulnerabilities closed.
Average time to patch.
Percentage of endpoints compliant.
Number of overdue tickets.
Useful risk metrics ask different questions:
Which exposed systems support critical business services?
Which vulnerabilities are already being exploited?
Which assets contain sensitive data?
Which fixes reduce the most probable loss?
Which systems lack compensating controls while a patch is delayed?
A growing patch management backlog is not automatically a failure. It becomes a failure when the organisation cannot separate urgent risk from routine maintenance.
The “fix everything” approach fails because it ignores business constraints
“Fix everything” sounds responsible. It is also incomplete.
It assumes that every vulnerability deserves equal urgency. It assumes that every asset has the same value. It assumes that patching is always the best first response. It assumes that the organisation has unlimited maintenance time, testing capacity, and system owners ready to act.
None of those assumptions hold.
A low-severity software issue on a public login service can be more urgent than a high-severity flaw on an isolated test machine. A database exposure can matter more than a routine desktop patch because the business impact is greater. A vulnerability with active exploitation deserves faster treatment than a theoretical weakness with no known attack activity.
This does not mean low-risk issues should be ignored forever. It means they should not compete equally with vulnerabilities that attackers are already using.
The “fix everything” model also creates fatigue. IT teams receive long lists that do not reflect business reality. Service owners push back because patching requires downtime or carries operational risk. Finance teams struggle to fund remediation because the request is broad and hard to connect to loss avoidance. Security teams then become the group that escalates everything, which reduces trust when a truly urgent issue appears.
A better approach uses risk-based vulnerability management to connect remediation work to exposure, exploitation, and business impact. That shifts the question from “How many findings do we have?” to “Which fixes reduce the most risk this week?”
Remediation should be ranked by exploitation and business impact
The most effective remediation plans combine threat evidence with asset value. The aim is not to produce a perfect score. The aim is to make better decisions under pressure.
The following ranking gives a practical order for remediation, based on likely business impact and actual exploitation risk.
Rank | Remediation focus | Why it comes here | Typical action |
1 | Actively exploited flaws on internet-facing systems | Attackers can reach them now, and evidence shows the weakness is being used | Patch immediately, remove exposure, or block access |
2 | Known exploited flaws on systems holding sensitive data | Impact rises when customer, financial, employee, or operational data is involved | Patch, restrict access, add monitoring, validate data controls |
3 | Exposed databases and identity systems | These systems can lead to data loss, account takeover, or service disruption | Remove public exposure, require strong access controls, review logs |
4 | Critical systems with available exploits but no confirmed activity | Risk can rise quickly once exploit activity spreads | Patch in the next approved window, prepare emergency change if exposure increases |
5 | High-volume internal vulnerabilities with limited exposure | They matter, but they usually pose less immediate external risk | Batch fixes, align with maintenance windows, track ownership |
6 | Low-impact findings and configuration clean-up | Useful for hygiene, but often less urgent than exploited weaknesses | Fix through routine cycles and baseline hardening |
This ranking supports vulnerability prioritization without pretending that a single score can replace judgement. It also maps well to the CISA KEV, the United States government catalogue of known exploited vulnerabilities. Even outside the United States, the CISA KEV list is useful because it reflects real exploitation, not just theoretical severity.
The key is to avoid treating the catalogue as the only input. A known exploited vulnerability on a retired internal system is not the same as the same vulnerability on a public payment application. Business context stays essential.
Cyber risk needs financial language as well as technical evidence
Technical severity alone rarely answers the question most leaders need answered: what can this cost the business?
A vulnerability on a system that processes invoices can delay payments. A weakness on a customer portal can trigger incident response, customer notifications, and loss of trust. An exposed database can create regulatory duties under European data protection rules if personal data is involved. Even when no fine follows, the investigation and recovery costs can be material.
This is where cyber risk quantification helps. It does not need to be complex at the start. A useful model can group risks by likely business outcome:
Service outage.
Data exposure.
Fraud or account misuse.
Regulatory reporting.
Contractual breach.
Recovery and response cost.
For each high-priority vulnerability, teams can estimate the business service affected, the data involved, the exposure path, and the likely cost range of an incident. Those estimates will not be perfect. They will still improve budget discussions because they connect patch decisions to financial exposure.
For example, compare two issues:
A critical flaw on an internal tool used by ten employees, isolated from the internet.
A known exploited flaw on a public file transfer system used to exchange customer documents.
A simple severity-only model may rank both highly. A business-led risk model puts the second issue first because the exposure path is clearer and the impact is higher.
This helps finance leaders make better trade-offs. Funding an urgent remediation project becomes easier when the case shows which business service, data set, and loss scenario are being reduced.
A practical operating model for reducing the backlog
Reducing the backlog requires process discipline, not just more scanning. The following operating model keeps the focus on exploitation and impact.
Build a trusted asset view
A patch decision depends on knowing what the asset is, who owns it, what it supports, and whether it faces the internet. This does not require perfect inventory on day one. Start with critical services, public systems, databases, and identity platforms.
Separate emergency work from routine work
Known exploited vulnerabilities on exposed systems need a fast lane. Routine patching should not block urgent remediation. Emergency fixes still need approval and rollback planning, but they should not wait behind low-risk maintenance tickets.
Use compensating controls when patching takes time
If a patch cannot be applied quickly, reduce exposure. Remove the system from the internet, restrict access, disable a vulnerable feature, apply a vendor workaround, or add monitoring for known attack patterns. These steps are not permanent fixes, but they reduce risk during the 43-day kind of window that many organisations face.
Measure risk reduction, not only closure volume
Track how many exploited vulnerabilities remain open, how long they have been open, and which business services they affect. Report the number of internet-facing critical risks reduced in the last month. This shows whether the organisation is safer, not just busier.
Make exceptions visible and owned
Some systems cannot be patched immediately. That is common. The risk should still have an owner, a reason, an expiry date, and a review cycle. Permanent exceptions quietly recreate the backlog under another name.
The board-level takeaway is clear
The current state of exploitation changes the patching conversation. Verizon reports exploitation at 31%, while only 26% of known exploited vulnerabilities are fully fixed and the median fix time is 43 days. Intruder reports that 42% of organisations have an exposed database. PwC reports that only 6% have fully implemented the surveyed data risk measures.
Taken together, these figures show a clear pattern: attackers are exploiting known weaknesses faster than many organisations can remove them, and the data behind exposed systems is often not protected well enough.
The answer is not to demand that teams “fix everything.” That creates noise, delay, and poor trade-offs. The answer is to rank remediation by real exploitation, exposure path, asset value, and business impact.
If your vulnerability list keeps growing faster than your team can fix it, we can help you prioritize by real business risk through Security Risk & Decision Management. The organisations that improve fastest will not be the ones with the longest patch lists. They will be the ones that know which risks matter most, and act on them first.
