Track both. Time to fix describes the findings you have already closed, so it looks backward. Age of open findings describes what is still exposed today. If you can only show one to leadership, show the age distribution of open items past SLA, because it cannot be improved by ignoring hard work.
The survivorship problem
Any metric computed from closed items has a built in blind spot. The findings that never close never enter the average. A team can improve its reported time to fix every month while a pile of hard items grows older.
Age of open findings fixes that. Every unresolved item counts, every day, until it is done.
What to chart
Use an age histogram with buckets that match your SLA tiers, for example under 7 days, 7 to 30, 30 to 90, over 90. Colour the buckets that are past SLA. Plot it by severity or by priority tier.
Add two summary numbers:
- Median age of open items in the tier.
- Oldest open item, with owner and reason.
Naming the oldest item sounds harsh but it works. It prompts a conversation about whether the item should be fixed, mitigated or formally accepted.
When each metric is better
Use time to fix when you are judging process changes. If you introduce automated fix pull requests, time to fix for the affected class should drop. It is a good before and after measure.
Use open age when you are judging risk right now, or when reporting to people who care about exposure rather than process.
Use both when you worry about gaming. A rising oldest item next to a falling median time to fix is a classic sign of cherry picking.
Inflow and outflow
Pair the age chart with a simple flow view: findings opened per week versus closed per week. If inflow exceeds outflow, the backlog grows no matter how good the median looks. We cover the net view in net vulnerability debt.
Handle accepted risk visibly
Accepted risk items should stay on the chart in a separate colour, with an expiry date. If they vanish from the chart, the age metric becomes another way to hide problems. Review expiries on a schedule so accepted risk does not turn into forgotten risk.
Avoid resetting age on reassignment
Moving a ticket between teams, or re-creating it after a scan, should not reset the age. Key the finding on a stable identifier, such as asset plus package plus vulnerability, rather than on ticket id.
A short example
A team closes eight critical findings in a month, all within a week, so time to fix looks excellent. Meanwhile two critical findings from last year are still open because they need a framework upgrade. The closed metric says seven days. The open age says a median of 300 days for the stuck pair.
Both statements are true. Only the second one tells you where an attacker would look. Showing them on the same slide stops the conversation from being about the good news alone, and gets the upgrade planned.
Quick check
Does age of open findings replace SLA compliance?
No, but it adds what compliance rate hides: how far past SLA the late items are.
How often should the age chart refresh?
Daily is ideal because it is cheap, but review it weekly.
Last reviewed: 19 October 2026.
