Show teams the numbers they can change this week: open findings they own, age, scan time and fix rate. Show the board three or four trends tied to risk: exposure to known exploited issues, time to fix, coverage and exceptions. One dashboard for both audiences serves neither.
Different questions, different numbers
A team lead asks: what should I work on today? A board member asks: are we getting safer, and where is the gap? A metric that answers one rarely answers the other.
| Audience | Question | Good metrics | Poor metrics |
|---|---|---|---|
| Engineers | What do I fix next? | Findings I own, ordered by priority; age; scan time | Company wide totals |
| Engineering managers | Is my team on track? | Fix rate within window, open exceptions, coverage of their repos | Raw counts without a denominator |
| Executives and board | Are we reducing risk? | Time to fix for exploited issues, repo coverage, aged exceptions, trend | Number of scans run, number of findings found |
Metrics for teams
Keep them local and live. Teams should see their own list, sorted by priority, with the owner and age. Add scan duration so people can raise it when it grows. Avoid ranking teams against each other in public; it invites gaming and hides context such as an older codebase.
Metrics for the board
Choose few. Four good ones:
- Exposure to known exploited vulnerabilities. Use CISA's KEV catalog as the reference list, and report how many affect your assets and how long they stay open.
- Time to fix by priority. Report the median and the slow tail, not only an average.
- Coverage. What share of repositories and assets has a recent scan, and which are missing.
- Exceptions. How many accepted risks, how many past their expiry.
Pair each number with a plain sentence about what it means and what you plan to do.
Beware the denominator
A fall in the count of open findings may reflect fewer scans, not fewer problems. Always show coverage next to counts. A percentage with no total hides a lot, so state both.
Beware vanity
Counts of scans run, alerts raised or training completed describe activity, not risk. When a measure becomes a target it tends to stop being a good measure, so check how each metric could be gamed before you promote it.
Keep a stable definition
Write down how each metric is calculated and when the clock starts. If the definition changes, mark the break in the chart. Trends are only useful when the ruler stays the same.
Quick check
How many metrics should a board see?
Three to five, each with a trend and a one line explanation. More than that turns the review into a data tour.
Should engineers see company wide numbers?
Yes as context, but their working view should be their own findings and the actions that move them.
Sources
Last reviewed: 19 October 2026.
