A vulnerability metric is decision grade when it has a clear definition, a trustworthy source, an owner, a trigger, and known failure modes. Ask the ten questions below before a number reaches an executive slide. If three or more answers are weak, keep it on the team dashboard and fix the metric first.
The ten questions
- What exactly is counted? Write the rule in one sentence, including what is excluded.
- Where does the data come from? Name the tool and the query. Two people should get the same answer from it.
- When does the clock start and stop? Time based metrics are meaningless without both.
- What is the denominator? Percentages need a clear base, and the base can change when scope changes.
- Who owns the number? One named person answers questions about it.
- What decision does it support? If nothing changes when it moves, it is a vanity metric.
- What would make it look good without being good? Name the cheapest way to game it, then add a guard metric.
- How stable is it with the volume we have? With small counts, a single item moves the percentage a lot.
- What changed in the method? Scanner updates, scope changes, or new rules should be noted on the chart.
- How will we retire it? Every metric should have a review date and a reason to continue.
Score yourself
| Strong answers | Action |
|---|---|
| 9 to 10 | Ready for the executive page |
| 6 to 8 | Fix gaps, then promote |
| Under 6 | Keep with the team, rework |
The score is only a conversation starter. Its value is in forcing each metric through the same questions.
A short example
Take "percent of vulnerabilities fixed within SLA." Run the questions. The definition is unclear on which severities count and whether risk accepted items are excluded. The clock start is unspecified. The denominator changes as findings arrive. One easy gaming path is closing findings by dismissal. After revisions, the metric states its rules, adds a dismissal guard, and shows counts beside the percent. The same name now means something specific.
Where the questions usually fail
Most failures come from questions 3, 4, and 7. Clock rules and denominators are rarely written, and gaming paths are rarely discussed. If you only have time to fix three things, fix those.
Make it routine
Put the ten questions on a definition card that every new metric must fill in. Review the cards each quarter. A short habit like that beats a one time cleanup, because metrics tend to drift as tools and teams change.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Do all ten questions apply to every metric?
Most do. For simple counts, the denominator question is not needed, but definition, source, owner, and decision still apply.
Who runs this review?
The metric owner fills in the card and security leadership reviews it, ideally with one engineering leader who consumes the number.
Last reviewed: 19 October 2026.
