Case file 02 · Governance and remediation
65,000 findings.
Almost none of them exotic.
An auditor handed them a spreadsheet with more than sixty-five thousand vulnerabilities on it. The vast majority were systems that had simply never been patched or updated — in some cases for years.
Subject
A corporate fleet-management firm holding an external auditor’s spreadsheet of more than 65,000 identified vulnerabilities, most of them the accumulated result of systems never being patched or updated.
The situation
The list arrived from outside. An auditor produced it, which meant nobody internally had to be convinced the problem was real — it showed up pre-validated, with an audit finding attached. What the organization had was a number too large to look at directly and no agreement about which end of it to start from. Nothing on the list was exotic. It was mostly the ordinary consequence of patching never having been done.
Why it had not been solved
Because patching never wins an argument on its own merits. It produces no new capability, no feature anyone asked for and nothing anybody can demo, so it loses every time it is weighed against work that does. There was internal pushback, and it was the ordinary kind: everyone already had a full queue and this was not on it. The technical work was not difficult. It had simply never been at the top of anyone’s stack, and nothing about restating the finding was going to put it there.
What I did
Made the economic case to executive management rather than the security case. Patching and clearing the tech debt was the fastest route to where they had said they wanted to be, and it was also the cheapest one, because it consumes IT time and very little else — no new platform, no new licences, no procurement cycle. Framed that way it stops being a security request competing for budget and becomes the least expensive option on the table.
Executive buy-in was the whole unlock. Once it existed, patching went to the top of the priority stack, and the internal pushback stopped being decisive — not because anyone was overruled, but because the queue had been reordered by the only people who could reorder it.
Result
What this means for you
If your remediation backlog is not moving, it is probably not a technical problem and probably not a tooling problem. It is a priority problem, and priority is set above the people being blamed for the backlog. The argument that actually moves it is not the security one — it is that patching is the cheapest thing on the list, because it costs staff time rather than budget. That argument has to be made to the people who set the stack rank, and it is usually winnable in a single meeting.
Take the one-pager with you
The same case file as a single-page PDF, sized to forward to the person who actually has to approve the spend. Also gets you the seven-pillar scorecard structure the assessment produces.
One email, the PDF, and the monthly Dispatch. Unsubscribe whenever.