The metrics that show whether a vulnerability management programme is actually reducing risk — mean time to remediate, vulnerability density, SLA attainment, reopen rate and risk reduction over time — each with its formula, how to read it honestly, and how it fails when reported alone.
Most vulnerability programmes report volume: findings opened, findings closed, patches applied. Volume answers how busy the team was, not whether the organisation is safer. The metrics below are the ones a board, an auditor or a regulator can act on, because each one connects work done to exposure removed. Every definition here is a standard, publicly used formula — the numbers you put into it come from your own estate, so treat any external benchmark with caution and trend against your own history instead.
Time-based metrics are the most requested and the most easily gamed. Report them split by severity and by whether exploitation is confirmed, never as a single blended average across everything open. Mean time to remediate (MTTR): The average elapsed time between a finding being detected and the fix being verified as effective. The verification step is what separates remediation from ticket closure. Formula: MTTR = sum of (verified fix date − detection date) for all findings closed in the period ÷ number of findings closed in the period How to read it: Trend it per severity band and separately for findings confirmed exploited in the wild. A programme with a 20-day overall MTTR but a 60-day MTTR on exploited findings is inverted, and the blended number hides it. Where it goes wrong: Closing tickets without re-testing shortens MTTR while leaving the vulnerability in place. Measure from the verification event, and count a reopened finding against the original detection date. Mean time to detect (MTTD): The average time between a vulnerability becoming publicly known and your programme discovering it on your own assets. It measures coverage and scan cadence, not remediation effort. Formula: MTTD = sum of (first detection date − public disclosure date) ÷ number of findings in the period How to read it: A rising MTTD usually means scan coverage has drifted behind new deployments rather than that scanning got slower. Cross-check against asset coverage before changing scan schedules. Where it goes wrong: Assets no scanner reaches never enter the calculation, so poor coverage can make MTTD look excellent. Always publish it next to a coverage figure. SLA attainment: The share of findings remediated inside their agreed deadline, measured per severity band and per owning team. This is the metric most regulatory and contractual timelines translate into directly. Formula: SLA attainment = findings remediated within their SLA window ÷ all findings whose SLA window closed in the period × 100 How to read it: Read it by owning team. A single team at 40% while the organisation sits at 92% is a capacity or tooling problem for that team, and a blended figure will never surface it. Where it goes wrong: Extending or re-baselining an SLA to rescue the percentage destroys the metric's meaning. Record deadline changes as exceptions with a named approver so the trend stays honest. Remediation capacity ratio: Whether the programme closes findings at least as fast as new ones arrive. Also called the open/close or burn-down ratio. Formula: Capacity ratio = findings closed in the period ÷ findings opened in the period How to read it: Sustained values above 1.0 mean the backlog is shrinking. Values below 1.0 mean every other metric will degrade eventually, regardless of team effort. Where it goes wrong: Adding a new scanner temporarily pushes the ratio below 1.0 for reasons that have nothing to do with performance. Annotate the chart when coverage changes.
Speed metrics describe the process. Exposure metrics describe the estate, and they are what a board should be asked to make decisions about. Vulnerability density: Open findings per asset, per application, or per thousand lines of code — a normalised measure that lets you compare a 40-asset business unit with a 4,000-asset one. Formula: Density = open findings in scope ÷ number of assets in that scope How to read it: Compare density between teams and environments rather than raw counts. Rising density with flat headcount is the clearest early signal that remediation capacity is being outrun. Where it goes wrong: Duplicate findings from overlapping scanners inflate density and make comparison meaningless. Deduplicate at intake, on a canonical identity, before anything is counted. Known-exploited exposure: The count and age of open findings whose vulnerability appears in a public exploited-vulnerability catalogue, such as CISA's KEV list. The smallest slice of the backlog and the one that matters most. Formula: KEV exposure = open findings matching a known-exploited vulnerability; report alongside the oldest open item's age in days How to read it: This is the number to lead with in an executive update. It is small, defensible, and directly tied to public evidence of real-world attacks rather than a theoretical score. Where it goes wrong: Catalogue membership describes the world, not your estate. Confirm the affected version is deployed and reachable before treating every match as an emergency. Critical backlog age: The age distribution of open high-severity findings, reported as a median plus the oldest open item — not an average. Formula: Backlog age = median of (today − detection date) for open high-severity findings, reported with the maximum How to read it: The oldest open critical is the single most useful number in an audit conversation, because it is the one an assessor will ask for first. Where it goes wrong: Averages hide long tails. One 400-day-old critical finding matters more to a regulator than a comfortable mean. Asset and scan coverage: The proportion of known assets that a security tool actually assesses, and how recently. It bounds the credibility of every other metric on this page. Formula: Coverage = assets assessed within the expected interval ÷ total known assets × 100 How to read it: Publish coverage next to every other KPI. A 98% SLA attainment figure over 60% coverage is not a strong result, and stating both prevents that misreading. Where it goes wrong: Counting only assets the scanner already knows about produces 100% coverage by definition. Reconcile against an independent inventory source — cloud accounts, CMDB, external attack-surface discovery.
These metrics catch the failure modes that speed and volume reporting cannot see: fixes that did not hold, findings nobody owns, and decisions nobody can reconstruct. Reopen rate: The share of closed findings that reappear on the same asset within a defined window, usually 90 days. It is the direct measure of remediation quality. Formula: Reopen rate = findings reopened within the window ÷ findings closed in the same period × 100 How to read it: A rising reopen rate alongside an improving MTTR almost always means findings are being closed administratively rather than fixed. Read the two together, never separately. Where it goes wrong: Reopening as a brand-new finding resets the clock and hides the problem. Preserve identity across closure so the reopen is attributable. Ownership coverage: The share of open findings with a named accountable owner and a routed ticket. Unowned findings do not move, whatever the process diagram says. Formula: Ownership coverage = open findings with an assigned owner ÷ all open findings × 100 How to read it: Track it weekly. It is usually the cheapest metric to improve and it lifts every downstream time metric at once. Where it goes wrong: Assigning everything to a shared queue or a group mailbox satisfies the metric without creating accountability. Require an individual or an on-call rota. False positive rate: The share of findings a triager dismisses as not applicable, not reachable, or wrong. It measures tooling and correlation quality, not team performance. Formula: False positive rate = findings dismissed as invalid ÷ findings triaged × 100 How to read it: Break it down by scanner. One noisy source usually accounts for most of the number, and the fix is configuration, not more analyst hours. Where it goes wrong: Do not confuse 'not exploitable in our context' with 'wrong'. Record the two dispositions separately, or you will eventually suppress something real. Evidence completeness: The share of remediated findings with a retained record of what was found, who decided what, when the fix was verified, and by whom. It is what turns a metric into something an auditor accepts. Formula: Evidence completeness = closed findings with a complete decision and verification trail ÷ all closed findings × 100 How to read it: Sample it rather than trusting the aggregate: pull ten closed findings at random and try to reconstruct each decision from the record alone. Where it goes wrong: Screenshots in a shared drive are not a trail. Records that can be edited after the fact lose most of their evidential value.
A board does not want a scanner report. It wants to know whether exposure is going up or down, what the worst open item is, and what would change if the programme were funded differently. Four numbers usually carry a quarterly update: known-exploited exposure with the age of the oldest open item; risk reduction over the quarter; SLA attainment split by the teams that own the work; and coverage, so the first three can be read in context. Everything else belongs in an appendix. Present trends across at least three periods, state the coverage the figures rest on, and label estimates as estimates — a single unqualified percentage invites a question you cannot answer, and losing that credibility costs more than an uncomfortable number.
Individual KPIs answer narrow questions; a board asks whether risk went down. VulnTrek expresses that as the VulnTrek Risk Index — a technical exposure score alongside a monetary exposure figure in euros — so a quarter's work can be shown as exposure removed rather than tickets closed. The inputs are the same ones described on this page: exploitation evidence, asset context and reachability, ownership and SLA state, and verified closure. Because findings are deduplicated at intake on a canonical identity, the same vulnerability reported by four scanners counts once, which is what makes density and closure figures comparable between teams. Framework and regulatory mappings are presentation-only: attaching one changes which references appear next to a finding, and never its severity, deadline, status, totals or history.
“We closed 12,000 findings this quarter.” Volume scales with scanner count and duplication, not with risk removed. The same number is achievable by adding a noisy scanner and changes nothing about exposure. “Our average CVSS score fell from 7.2 to 6.8.” Averaging severity across an estate is arithmetically meaningless — closing many low findings improves the average while every exploited critical stays open. “We are 99% patched.” Unqualified by coverage, this says only that the assets you scan are patched. The 1% frequently contains the internet-facing, unowned systems that matter most. “MTTR is 14 days.” One period is not a trend and a blended figure hides severity inversion. Report at least three periods, split by severity and exploitation status.