Patching Everything Is Not a Strategy

One key takeaway from the 2026 Verizon DBIR confirms what anyone running patch management already knows. You cannot patch it all. And the backlog is going in the wrong direction. The real question is how you choose.

The report makes uncomfortable reading for anyone who runs a vulnerability management program. Exploited vulnerabilities are now the number one way attackers get in. Nearly a third of breaches.

The defense is losing ground at the same time.

The Verizon report highlights that even the best organizations fully fix only 30 to 40% of known-exploited vulnerabilities in their first week. That's the best case.

There is only one conclusion based on the numbers. Choosing which vulnerabilities to fix must be the strategy. “Or guessing” is the alternative the report offers, which unfortunately too many companies will follow.

Security teams are already living this. There are too many vulnerabilities and not enough time. Yet few are willing to admit the logical conclusion. If you cannot patch everything, something gets fixed first and something waits.

The question is whether that choice is deliberate or de facto. In most organizations the honest answer is a severity score, a scanner's default sort order, and whatever is easiest to close before the next report.

That is not prioritization. That is a critical decision without an owner.

Here are the seven ways it goes wrong.

CVSS rates the vulnerability. That score knows nothing about your business. The score for a flaw is the same whether it sits on a forgotten dev server or on the platform your revenue runs through. A 9.8 on the first is a smaller problem than a 6.5 on the second, but a severity-sorted queue will always put the 9.8 on top.

Severity is a property of the bug. Exposure is a property of your business. They are not the same number.

The known-exploited list is where attackers operate. Most critical vulnerabilities are never exploited in the wild. Yet a severity score cannot tell you the difference. The score rates how easy an exploit would be, not whether anyone is using it.

That signal has to come from threat activity and your own exposure. A program that treats a theoretical event the same as a known exploit is wasting effort.

The scanner sees IPs and software. It cannot see that a few of those systems carry your order-to-cash process and the rest carry nothing that would stop the business for a day.

Risk lives in the processes your organization depends on, not in the host count. Until your priorities incorporate which systems sit under which processes, you are protecting hardware, not the business.

Four hundred easy low-priority patches closed looks like progress. One hard fix on the billing platform hardly moves the count. The difference only shows up when the work is measured in money, and the money does not live in the patches. It lives in the systems they protect.

Those four hundred tickets sat on machines that carry little loss. The billing platform carries revenue, so the same hour of work removes orders of magnitude more risk. No count of closed tickets can surface that gap. But teams will optimize around what is counted. Weight the queue by what each system would cost the business, and it starts chasing loss instead of volume.

The backlog grew 50% last year and the median fix took 43 days. A plan that assumes the queue will be cleared is not a plan.

When no one chooses explicitly, people default to their own order, most likely age and ease. The oldest and simplest items get done, while the hardest and most consequential ones wait. That's backwards. Reversing the process requires knowing which systems and processes the business cannot afford to lose, and that knowledge does not usually sit with the security team.

Patch counts and SLA percentages tell the board you are busy. They do not tell the board you are effective, and they give a CFO nothing to weigh a budget request against.

Tracking in currency against exposures removed does both. It's the only number that survives the question “what did we get for the money”.

A scan with no or low-CVSS vulnerabilities is an achievement. It is not a risk position. The Verizon report puts the human element in 62% of breaches, stolen credentials in 39% of attacks, and third parties in 32% of breaches. None of those appears in vulnerability scanner output.

Those risks represent how people work, who holds access, and who you depend on. Vulnerability management covers one path into the business, and covering it well can still leave most of your loss exposure standing. It is a piece of a cyber risk program. All too often the growing vulnerability list consumes the entire program.

Every one of these mistakes has the same root. The patch queue is ordered by properties of the vulnerability when it should be ordered by consequences for the business.

Fixing that requires a way to express consequences. Color codes will not do it. The unit that works is currency, not a patch count.

Cordaata models your loss exposure using the data about your environment. Specifically, the systems and business processes that actually carry your revenue. Each threat scenario is evaluated based on how much it could cost.

Each control and each fix carries the exposure it removes, so the patch queue, the wider remediation plan and the budget case become the same document. The board sees exposure against appetite in money. The CFO sees where the next investment removes the most loss, and where returns stop. And because the model covers people, process, systems and data, a clean scan is never mistaken for low risk.