Ask a security team how vulnerability management is going and you often get a number. We have 40,000 open vulnerabilities. We closed 12,000 last quarter. The scanner found 300 new criticals this month. None of those tell a leader anything they can act on, and most of them move up and down for reasons that have little to do with whether the organization is actually safer.
A good part of my time as a BISO went into turning that kind of raw scan output into something a director or a VP could use. Here is what I came to believe about which vulnerability metrics are worth reporting, and why.
A metric has to change a decision
The test I apply to any metric is simple. If I put it in front of a leader and nothing they do changes as a result, it is not a metric, it is trivia. Raw vulnerability counts fail that test almost every time. The number is enormous, mostly noise, and a leader cannot tell from it whether to be worried, where to spend, or who to hold accountable. A metric worth reporting answers a question someone is going to make a decision on: are we keeping the commitments we made, is our exposure trending down, and where specifically do you need to step in.
The measures that earn their place
A handful of measures do that job. Most programs would be better off reporting these few clearly than reporting everything the scanner can produce.
- SLA compliance by severity. The share of findings remediated within the timeframe the organization committed to, broken out by severity. This is a commitment metric. It sidesteps the noise of how many vulnerabilities happen to be visible at a given moment and measures whether the organization is keeping its own remediation promises. On one portfolio, I helped improve SLA compliance from about 65% to about 99%, and it became the figure leadership trusted because it mapped to accountability.
- Aging of overdue findings. Not only how many are late, but how late, trended over time. A backlog that is shrinking and getting younger is a healthy program. One that holds steady while the average age climbs is a program quietly losing ground, even when the headline count looks flat.
- Risk acceptances and exceptions in flight. How much risk is being parked rather than fixed. This is the measure that keeps the others honest. A green SLA number sitting next to a growing pile of exceptions is not success, it is risk moving from one column to another. I have written separately about governing exceptions so they do not become a rubber stamp; the reporting side of that is putting the volume and age of accepted risk right next to the remediation numbers, where it cannot hide.
- Coverage. What share of the environment is actually being assessed. A 99% remediation rate on the 60% of the estate you can see is a comfortable illusion. Coverage tells a leader whether the other numbers can be trusted at all.
- Recurrence. How often a finding comes back after being closed. High recurrence points at a root-cause or process problem that no amount of faster patching will fix, and it is the kind of signal that justifies investment rather than more pressure on the same teams.
Report by owner and severity, not one big number
The other thing that makes metrics usable is how they are cut. One organization-wide vulnerability figure is close to useless for action. The same data, broken out by severity and by the team or application that owns the finding, turns into decisions. A leader looking at "these three business-critical systems are behind on high-severity remediation, and here is who owns each" knows exactly what to do. A leader looking at "the organization has N vulnerabilities" knows nothing. Cutting the data by ownership also puts accountability where it belongs, which is usually what moves the numbers in the first place.
What a dashboard does, and what it does not
It is worth being honest about what reporting accomplishes. A dashboard does not remediate anything. When that portfolio went from 65% to 99%, the dashboard did not fix a single vulnerability. What it did was make the gaps impossible to ignore, tie each one to an owner, and give leadership a reason to escalate the ones that were stuck. The recurring reviews and the escalations did the work. The metric made the case for the work and showed whether it was landing. That is the right relationship between measurement and action, and it is worth saying plainly, so a metrics program is never mistaken for a remediation program.
Watch the metric you can game
Any metric you reward gets optimized, sometimes in ways you did not intend. Measure closure count on its own and people close the easy findings while the hard, high-severity ones age, because ten trivial closures look better on a chart than one difficult fix. That is why the measures above work as a set rather than one at a time. SLA compliance by severity, aging, and exception volume together are hard to game, because improving the headline while deferring the real risk shows up somewhere else in the picture. A single number in isolation almost always creates the wrong incentive.
The one habit
If I had to reduce all of this to a single habit, it would be this: before you put a vulnerability metric on a slide, ask what a leader would do differently after seeing it. If you cannot answer that, cut it. The point of measuring vulnerabilities was never to produce impressive charts. It was to make the right work visible, owned, and hard to ignore, and to know whether exposure is genuinely going down. Everything that serves that belongs on the dashboard. Everything else is noise dressed up as insight.