The Monday report
Every security team I've worked with has some version of the same Monday report. Open findings went up again. Critical findings went up again. Someone asks why, and the answer is always some mix of a new scanner, a new cloud account and a new batch of published CVEs.
The number goes up because finding is cheap and fixing is expensive. A scanner can flag 4,000 hosts missing a patch in an hour. Patching those hosts needs a change window, an owner who agrees to the downtime, a test pass and someone to confirm the fix landed. The two sides of that equation will never balance.
So the backlog doesn't hit zero. The useful work starts once a team stops treating zero as the goal.
Severity is a weak sort key
Most backlogs are sorted by CVSS score. CVSS describes how bad a vulnerability could be in general. It says nothing about your environment.
A critical-rated flaw on an internal test server with no network path from the internet is a lower priority than a medium-rated flaw on your customer login page. Sorting by severity alone puts them in the wrong order, and teams spend weeks patching the test server first because the report says "critical."
Three questions do more sorting work than the severity score:
- Is it being exploited? Public lists of known-exploited vulnerabilities, such as the one CISA maintains, are short. A finding that appears on one goes to the top.
- Can an attacker reach it? Internet-facing beats internal. Internal with a path to sensitive data beats an isolated lab.
- What does the asset do? A payroll database and a kiosk PC with the same flaw are not the same problem.
Ownership is where findings stall
In most organisations the security team finds the problem and a different team fixes it. That handoff is where findings sit for months.
The pattern looks like this. Security opens a ticket against "infrastructure." Infrastructure says the server belongs to an application team. The application team says the server runs a vendor product and they can't patch it without breaking support. The ticket ages, the SLA lapses, and the finding shows up in next quarter's audit.
The fix is boring and it works: every asset gets a named owning team before a finding is raised against it. If no one owns an asset, that's the first finding. Raising vulnerability tickets against unowned assets only produces orphaned tickets.
Decide what stays open
A healthy programme makes three kinds of decisions on purpose:
- Fix now. Exploited, reachable, important. These get an emergency change if needed.
- Fix on schedule. Everything that fits the normal patch cycle. Most findings live here.
- Accept, with a date. The system is being retired in March. The vendor won't support the patch. A compensating control, like blocking the port, cuts the risk enough. Write it down, name who approved it, and set a date to look again.
Measure the right numbers
Total open findings is a poor headline metric. It rises whenever scanning coverage improves, which punishes the team for finding more.
The numbers I'd put in front of leadership instead:
- Time to fix for exploited, reachable findings. This is the one that matters most. Days, not quarters.
- Percentage of assets with a named owner. If this is low, every other number is unreliable.
- Accepted risks past their review date. Exceptions that nobody revisits turn into permanent holes.
- Scan coverage. The share of known assets scanned in the last 30 days.
Where to start
If your backlog feels hopeless, pick the 50 findings that are known-exploited and reachable from the internet. Confirm an owner for each one. Fix those this month.
Then build the habit: every new finding gets a priority from the three questions, an owner, and one of the three decisions. The backlog will still be large next quarter. It will also be sorted, owned and explained, and you'll be able to say what's left open and why.