The report said 41,000 open vulnerabilities. The number had been roughly 41,000 for eight months, which should have been the first clue that nobody was working the list.
I have seen this in a pharmacy benefits environment, in a payments platform, and in a manufacturing estate that still had Server 2012 quietly running a line. The details differ. The shape never does. The scanner works perfectly. It runs on schedule, it authenticates, it produces beautifully sortable output. And the backlog does not move, because at no point does any finding acquire a name — a specific person who is accountable for the specific host, who has both the authority to schedule an outage and the budget to absorb one.
Leadership reads the flat backlog as a discipline problem. It is almost never a discipline problem. Engineers patch things constantly. What they do not do is patch a server when they cannot tell whether it belongs to them, cannot tell what breaks when it reboots, and cannot find anyone who will sign off on the window.
The finding has no addressee
A vulnerability finding arrives with an IP, a CVE, a CVSS score, and nothing else that matters operationally. Turning that into work requires answers to three questions the scanner cannot answer: what runs on this host, who is accountable for that service, and what is the approved path to take it down.
In most estates, question one is answerable with effort, question two is folklore, and question three does not exist. So the finding routes to whoever last touched the box, or to a shared queue, or to the infrastructure team by default — and the infrastructure team owns the operating system but not the application, which means they cannot consent to the outage that patching requires. The ticket ages. The scan re-runs and produces the finding again, now with an older first-seen date, and everyone agrees it is important.
This is why remediation SLAs written against severity almost always miss. “Critical in 15 days” assumes the clock starts when the work becomes assignable. It actually starts when the scan completes, and the interval between those two moments is unmeasured and frequently longer than the SLA itself.
Fix the register, not the deadline
The instinct is to tighten the SLA, escalate the overdue items, and put the backlog trend on an executive slide. That produces motion in reporting and none in the estate. The intervention that works is duller: make ownership a property of the asset, recorded before the finding arrives, and treat an unowned asset as its own severity-one defect.
Concretely, the register has to answer:
- Which named individual — not team, not distribution list — accepts risk decisions for this host, with a named deputy.
- Which business service the host supports, so an outage request goes to someone who can weigh the tradeoff.
- The approved maintenance window, agreed in advance, not negotiated per ticket.
- The decommission date, if the asset is meant to be gone — because a third of most backlogs sits on machines nobody intended to still be running.
- Who signs a deferral, and for how long, so “we accept this risk” becomes a dated, revisitable decision rather than an unspoken permanent state.
An asset that cannot answer all five is not a patching problem to be scheduled. It is a governance gap, and it should be reported as one, separately from the vulnerability count.
What changes when ownership is real
The backlog stops being a single number. It splits into remediable findings, which move at whatever pace the maintenance windows allow, and unowned assets, which go to a different audience entirely — because the fix is organisational, not technical, and no amount of engineer diligence will resolve it.
That split is uncomfortable, which is precisely why it is useful. It converts a vague operational failing that reflects badly on the security team into a specific, assignable set of decisions that belong to service owners and their leadership.
Stop reporting how many vulnerabilities are open. Start reporting how many assets have nobody to tell.