Vulnerability Management Metrics: 12 KPIs for MTTR, SLA Compliance and Risk Burn-Down

Most vulnerability programmes report numbers that rise and fall with scanner coverage, not with risk, so the board sees activity and never sees whether exposure is shrinking. This guide sets out 12 programme outcome KPIs for vulnerability management: how each is calculated, what it tells a risk committee, and how to turn mean time to remediate (MTTR) and SLA compliance into a risk burn-down that leadership can act on. It is written for vulnerability management leads, CISOs and risk teams who already run scanning and remediation SLAs and now need a defensible scorecard. Operational hygiene checks (scan coverage, authenticated scan share, per-tier MTTR, reopen rate and similar) live in the Vulnerability Management Health Check; this page sits one level above them and does not repeat them.

Key takeaways

• Measure exposure, not volume. Counts of open findings grow when coverage improves; risk-weighted exposure and exposure-days fall only when real risk falls.
• Report time to remediate as a distribution. NIST SP 800-40 Rev. 4 pairs mean and median time to patch for a reason: a few stubborn findings drag the mean, and the tail is where breaches start.
• Burn-down needs a target line. A risk burn-down chart compares the open risk-weighted exposure against a planned trajectory agreed with the risk owner, so slippage is visible weeks before a deadline.
• Weight by exploitation and asset value. CISA KEV listing, EPSS probability and asset criticality turn a flat SLA percentage into a figure that reflects what attackers actually use.
• Tie at least one KPI to outcomes. Incidents whose initial access was a known, fixable vulnerability are the only direct measure of whether the programme prevents harm.

Why programme KPIs differ from operational metrics

Operational metrics answer "is the machinery working?": are assets scanned, are tickets closed on time, are exceptions current. Programme KPIs answer the questions a board and risk committee ask: is our exposure going down, are we fast enough on the vulnerabilities attackers are using, and where are we carrying risk above appetite? The two layers share data but differ in unit, audience and cadence.

NIST SP 800-40 Rev. 4 (Section 3.6) warns that simple counts, such as the number of vulnerabilities or the percentage patched, are not actionable on their own, and suggests cross-tabulating vulnerability importance against asset importance, with the percentage patched by deadline, mean time to patch and median time to patch in each cell. That matrix is the bridge between the two layers: the cells are operational, the shape of the matrix over time is a programme KPI. For the monthly reporting format itself, use the Vulnerability Remediation Report Template for Executives.

The 12 KPIs

The set is grouped into four families: exposure, speed, capacity and outcome. Each KPI is defined so that it cannot be improved by scanning less or by reclassifying findings.

Exposure family (K1 to K3)

• K1 weights: keep them simple and published. A common pattern is priority weights of 10 (KEV-listed or SSVC Act), 5 (Attend or critical with high EPSS), 2 (high), 1 (medium) and 0 for low, multiplied by asset criticality of 3 (tier 0 identity and control plane), 2 (crown jewels), 1 (supporting) and 0.5 (low value). Changing the weights resets the trend, so version them and restate history when they change.
• K2 scope: the CISA KEV catalogue lists vulnerabilities with reliable evidence of exploitation, and each entry carries a dateAdded, a dueDate and a knownRansomwareCampaignUse field. Split K2 by the ransomware flag: it is the most persuasive single line in a board pack. See the CISA KEV Catalogue Guide.
• K3 dependency: needs business services mapped to assets. If the CMDB cannot do that yet, start with the ten services the business impact analysis names as critical and grow from there.

Speed family (K4 to K7)

• K4 versus MTTR: a plain mean of closed findings rewards closing easy items and ignores findings still open. Cohort half-life follows every finding detected in a month until it is fixed, so long-running findings stay in the measure. Report the 50% and 90% points; the gap between them is the tail.
• K5 versus SLA compliance: the health check's per-tier SLA compliance (V5) tells the team where process fails. K5 collapses it into one leadership number weighted by the same model as K1, so a board sees one figure that cannot be gamed by closing low findings.
• K6 and K7: measure on the events that matter, typically 5 to 15 a year. Record start time as the earlier of KEV addition or the vendor's emergency advisory, and stop the K6 clock only when the affected asset list is complete, not when the first host is found. The Emergency Out-of-Band Patching Playbook sets the response steps these KPIs time.

Capacity family (K8 to K10)

• K8: the leading indicator for K1. When arrivals outrun closures in risk-weighted terms, the burn-down will slip next quarter whatever effort is applied, which is the point at which to ask for automation, headcount or reduced scope.
• K9: the efficiency argument for rebuild-and-redeploy over per-host patching in cloud and container estates, and the KPI that justifies investment in golden images and dependency automation.
• K10: NIST SP 800-40 Rev. 4 (Section 2.1) lists four risk responses: accept, mitigate, transfer and avoid. Vendor-blocked findings can only be mitigated (segmentation, configuration changes, disabling features) or avoided (removing the software). Report what was done for each, not just the count.

Outcome family (K11 and K12)

• K11: external deadlines such as PCI DSS v4.0.1 Requirement 6.3.3 and CISA KEV due dates are not internal SLAs; a breach of them has legal or contractual consequences. The deadlines themselves are covered in the Remediation SLAs and Vulnerability Exceptions Guide.
• K12: requires incident response to record root cause consistently. The useful refinement is "days fix available at time of incident": a long figure is a programme failure, a short one points to emergency response (K7).

Building a risk burn-down

A burn-down chart plots open risk-weighted exposure (K1) each week against a straight or stepped target line from today's value to the agreed end-state. It is the single chart that turns MTTR and SLA attainment into a plan.

1. Freeze the model: publish the K1 weights, the asset tiers and the data sources. Version them. Any later change is restated across history so the line stays comparable.
2. Take the baseline: calculate K1 for the current estate, and separately for new scope (newly onboarded cloud accounts, acquisitions) so coverage growth does not look like regression.
3. Agree the target with the risk owner: for example, reduce K1 by 40% in two quarters and hold K2 at zero exposure-days for ransomware-linked KEV entries. The target is a risk appetite decision, recorded under NIST CSF 2.0 GV.RM-02.
4. Plot two lines plus arrivals: actual K1, target K1 and new risk weight arriving each week (the K8 numerator and denominator). Arrivals explain most slippage.
5. Annotate events: mark mass-exploitation events, change freezes and scope changes on the chart. A board reads annotations before it reads axes.
6. Set the escalation rule: two consecutive weeks above the target line by more than an agreed margin triggers a review with service owners; a quarter above it goes to the risk committee with a recovery plan.
7. Test it before you rely on it: run the calculation for the last two quarters from historical data and check that known bad periods show as bad. If they do not, the weights or data are wrong.

Rollback is straightforward: if the risk-weighted view proves unreliable, keep publishing the per-tier SLA view from the health check alongside it until the model is trusted. Never switch the board pack from one method to the other without showing both for at least one quarter.

Reporting to the board

NIST CSF 2.0 places performance review of the cyber risk programme under GV.OV-03. In practice a board pack needs five or six numbers, not twelve. Choose by audience.

• Lead with a decision: each board slide ends with what the board is asked to note, approve or fund. A K8 below 1.0 for a quarter is a resourcing decision, not a status update.
• Translate to services: "the payments platform carried a ransomware-linked exploited vulnerability for 19 days" lands; "1,412 high findings" does not.
• Show the method once a year: a one-page method statement (weights, tiers, data sources, exclusions) makes the KPIs auditable and stops debate about the numbers in every meeting.
• Link to financial risk where you can: if the organisation quantifies cyber risk, map K1 and K3 to the loss scenarios in the model. See the Cyber Risk Quantification Guide and the Board Cyber Risk Reporting Guide.

Choosing KPIs by organisation size and maturity

• Small organisations (a few hundred assets, no dedicated team): start with K2, K6/K7 and K12. They need only the KEV catalogue, a reliable asset list and incident records. Skip weighting until asset tiers exist.
• Mid-sized organisations: add K1 with a simple two-factor weighting, K4 and K8. These are the minimum for a credible burn-down.
• Large or regulated organisations: run all 12, split by business unit, and add K11 per regulated scope. Expect to need a data pipeline joining scanner, CMDB, ticketing and threat intelligence feeds.
• Cloud-native estates: weight K9 heavily and measure K4 on images and templates rather than running instances, since instances are replaced rather than patched.

Weighting with exploitation data

Three public sources make weighting defensible rather than arbitrary:

FIRST frames prioritisation strategies by effort (share of vulnerabilities prioritised), efficiency (share of prioritised vulnerabilities that were exploited) and coverage (share of exploited vulnerabilities that were prioritised). Computing efficiency and coverage for your own prioritisation once a year, using KEV additions as ground truth, is a useful meta-KPI: it shows whether the weighting behind K1 points teams at the right findings. The Risk-Based Vulnerability Management Guide covers the prioritisation model in depth.

Data quality and measurement

• First detection date: K4 depends on the date a finding was first seen, which many tools reset when a host is re-imaged or an agent reinstalled. Key findings on asset identity plus CVE and keep the earliest date.
• Verified closure: count a finding as fixed only after a rescan or agent check confirms it, never on ticket closure.
• Deduplication: the same CVE seen by a network scanner, an agent and a container scanner is one finding for K1. Double counting inflates exposure and makes burn-down look steep.
• Exclusions: publish them. Assets out of scope, accepted risks and informational findings must be listed in the method statement, or the KPIs will be challenged.
• Lineage: keep the query and data extract behind every reported figure for at least one audit cycle, mapped to NIST SP 800-53 Rev. 5 PM-6 Measures of Performance and CA-7 Continuous Monitoring.

Common failure patterns

• Celebrating a falling count after a scanner outage: open findings drop when coverage drops. Always show coverage alongside K1, using the health check's coverage metric as a gate.
• Mean-only MTTR: a mean that improves because hundreds of trivial findings closed fast hides the critical that has been open for a year. Use cohort half-life and the 90% point.
• Closing on patch when the fix needs more: some exploited vulnerabilities leave stolen keys or persistence behind. In the ToolShell SharePoint exploitation, patching closed the entry point but attackers who had read the ASP.NET machine keys could return until the keys were rotated. For KEV-listed findings, "fixed" should include any vendor-directed rotation or hunting step.
• Weights that change every quarter: each change breaks the trend line. Version the model and restate history.
• Twelve KPIs on one board slide: the board stops reading. Pick four, explain them once, keep them stable.
• No outcome measure: without K12 the programme can hit every target while attackers walk in through an unscanned edge device.

Framework mapping

NIST SP 800-55 Vol. 1 (December 2024) is the general method for selecting and prioritising security measures and is the right reference for the method statement. For programme maturity, see the Vulnerability Management Maturity Model.

Practitioner checklist

• Write and version a one-page method statement: weights, asset tiers, data sources, exclusions.
• Map at least the top ten business services to their assets so K3 can be calculated.
• Ingest the CISA KEV catalogue and FIRST EPSS daily and record the ransomware use flag.
• Store first detection date per asset and CVE and verify closure by rescan.
• Back-calculate K1 and K4 for two prior quarters and check known bad periods show as bad.
• Agree the burn-down target with the named risk owner and record it as a risk appetite decision.
• Time K6 and K7 on every mass-exploitation event and review them in the post-incident meeting.
• Add root-cause tagging for known vulnerabilities to incident records so K12 is reliable.
• Limit the board slide to four KPIs, each ending in a decision or a note.
• Review prioritisation efficiency and coverage annually against KEV additions.

Standards and references

• NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• NIST: SP 800-55 Vol. 1, Measurement Guide for Information Security
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• FIRST: EPSS Model
• CIS: Control 7 Continuous Vulnerability Management
• NCSC: Cyber Security Toolkit for Boards

Related NHI Mgmt Group resources: Vulnerability Management Guide · Vulnerability Management Health Check · Vulnerability Remediation Report Template for Executives · Board Cyber Report Template