Report the fewest metrics that change a decision. A small team needs open count and oldest age. A mid-size group adds time to close and aging by owner. A large organization adds exception share and trend by business unit. More metrics than that usually measure the dashboard, not the risk.
Start from the decision
A metric earns its place if someone will act differently when it moves. Open alert totals alone rarely do that, because the number can rise for good reasons, such as onboarding a new repository or a wave of new advisories.
Ask of each metric: who reads it, how often, and what would they change?
Metrics by size
| Team size | Report | Skip for now |
|---|---|---|
| 1 to 5 | Open count, age of oldest, fixed this month | Per-team breakdowns |
| 6 to 25 | Plus time to close, share past clock | Trend by quarter |
| 26 to 200 | Plus aging by owning team, dismissals reviewed | Cross-unit comparison |
| 200 plus | Plus exception share, expired exceptions, KEV time to fix | Raw alert volume as a headline |
Metrics worth defining carefully
Time to close. Say when the clock starts: when the advisory is published, when your tool raised it, or when someone triaged it. They give different numbers. See when does the SLA clock start.
Share past clock. Of open items, what fraction exceeded the fix window for their tier. It tells you whether the windows are realistic.
Time to fix for known exploited items. CISA's guidance recommends all organizations prioritize remediation of vulnerabilities in the Known Exploited Vulnerabilities catalog, so tracking how long those take is a natural, specific measure.
Dismissal review rate. The share of dismissals someone sampled. GitHub's documentation notes that automatic dismissals appear in the audit log and APIs, so reporting on them is possible without new instrumentation.
Metrics that mislead
- Total open alerts as a score. It punishes teams that scan more.
- Alerts per engineer. Hides ownership problems.
- Average severity. FIRST's CVSS guidance states the Base score measures severity and should not be used alone to assess risk, so an average of Base scores is a weak risk measure.
- Zero as a goal. New advisories land daily. A zero count reflects only the moment of measurement.
Small numbers need care
At small team sizes one or two alerts swing a percentage wildly. Prefer counts and ages over rates, and compare with your own history, not with another company's. For more, see small numbers: noise versus signal.
A one-page template
- Open count by tier, with last month beside it.
- Oldest open item and its owner.
- Closed this month.
- Share past clock.
- Exceptions expiring in the next 30 days.
That fits on one slide and drives a ten minute conversation.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which numbers update on their own as new findings arrive.
Safeguard's compliance and evidence automation can produce these views from one inventory, and the free scan at gold.safeguard.sh/scan gives a first baseline to measure against.
Quick check
What is the single most useful alert metric?
For most teams, the age of the oldest open item that has an owner. It exposes stuck work quickly.
Should we compare our numbers with other companies?
Be careful. Definitions differ. Compare against your own earlier months.
Sources
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
- FIRST, CVSS v4.0 User Guide
- GitHub Docs, Dependabot auto-triage rules
Last reviewed: 19 October 2026.
