Measure ASPM by outcomes, not by finding counts: time from detection to fix, the share of findings with a named owner, how many duplicates were removed, and how many policy violations were caught before merge. If those improve over a quarter, the program is working.
Why finding counts mislead
A total that goes up can mean you see more, which is good. A total that goes down can mean a scanner broke. Raw counts move for reasons unrelated to risk, so they make a poor headline number.
Better metrics describe how work flows, because that is what the platform is meant to improve.
Six metrics worth tracking
| Metric | Plain definition | Direction you want |
|---|---|---|
| Time to remediate | Days from first detection to verified fix | Down |
| Owned findings | Share of open findings with a named team | Up |
| Dedup ratio | Raw findings divided by unique issues | Shows consolidation |
| Aging exploited items | Open items known to be exploited, past your target date | Down to zero |
| Pre merge catches | Policy violations stopped in a pull request | Up, then stable |
| Reopen rate | Fixes that came back | Down |
Time to remediate should be split by priority tier. A single average hides the fact that critical items may be fixed fast while the rest rot.
How to set targets
Take a baseline over the last 30 to 90 days, before the platform changes anything. Then set targets as a change from that baseline. Avoid industry numbers you cannot trace to a source, because your codebases, team sizes and release cadence are different.
For the aging item, CISA maintains the Known Exploited Vulnerabilities catalog, described as the authoritative source of vulnerabilities exploited in the wild. Many teams use membership in that catalog as a trigger for a shorter deadline. Check CISA's current guidance for the details rather than copying a number from a blog.
How to collect them without extra work
- Export ticket data weekly from your tracker, including created and closed dates.
- Take ownership share from the platform's own report.
- Record dedup ratio once per month, since it changes slowly.
- Pull pre merge catches from your pull request checks.
- Put all of it in one page that fits on a single screen.
Watch for gaming
Any metric can be gamed. If time to fix is rewarded, teams may close tickets without fixing. Pair it with the reopen rate. If owned findings is rewarded, teams may assign everything to a default group. Sample a few assignments by hand each month.
Reviewing with leadership
Show the trend over three or four months, and one sentence per metric on what you changed. Leaders rarely need the full table, but they do need to see that the direction is steady.
A worked example with made up numbers
The figures below are invented to show how to read the metrics. They are not benchmarks.
| Metric | Quarter 1 | Quarter 2 | Reading |
|---|---|---|---|
| Median days to fix, top tier | 30 | 18 | Faster, good |
| Median days to fix, lower tiers | 70 | 80 | Slower, worth a look |
| Findings with an owner | 55 percent | 85 percent | Routing is working |
| Exploited items past due | 9 | 2 | Urgent work is getting done |
| Reopen rate | 4 percent | 9 percent | Rising, check quality of fixes |
Read as a whole, this quarter tells a clear story: urgent items improved, ownership improved, but lower tier work slowed and more fixes are coming back. A one line summary could be "We fixed urgent items faster and now need to check fix quality and lower priority backlog."
Notice what the summary does not say. It does not claim success because one number went up.
Step by step: building the first scorecard
- Choose four metrics from the table earlier in this post. More than six becomes noise.
- Write a one sentence definition for each, and who owns the number.
- Pull a baseline for the last quarter, even if the data is rough, and label it as rough.
- Decide the review cadence and put it on calendars.
- After the first review, drop any metric nobody used in a decision.
Pitfalls in definitions
Time to fix needs a clear start and end. Start at first detection, not when a ticket was created, otherwise delays in triage vanish from the number. End at verified fix, not at ticket closure, otherwise closing without fixing looks like success.
Ownership share needs a clear rule too. A default group name should not count as an owner. Decide this up front and apply it consistently.
Qualitative signals
Numbers miss some things. Ask developers once a quarter whether findings are clearer, whether duplicates have decreased, and whether the tool helps or gets in the way. A short survey with three questions is enough, and the answers often explain a metric that moved unexpectedly.
Where Safeguard fits
Safeguard provides policies, gates and guardrails, plus compliance and evidence automation, which can supply the pre merge and reporting data above. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how status and priority sit side by side.
Quick check
Is there one metric to rely on?
There is no single one. If you must pick one, use time to remediate by priority tier, and pair it with the reopen rate.
How often should we review the metrics?
Weekly for operations, monthly for trends, quarterly for leadership.
What if the baseline data is poor?
Label it as rough, start recording properly now, and compare against your own improved data after one quarter. A rough baseline is still better than none.
Sources
Last reviewed: 19 October 2026.
