Most vulnerability management programmes can say how many findings are open, but few can prove that the scanning reaches the whole estate, that remediation targets are met, and that accepted risk is still being watched. This health check is a quarterly audit run sheet for the programme: twelve KPIs with formulas, data source types, thresholds and owners, plus a cadence table, a findings log and a remediation map. It is run by the vulnerability management lead, re-performed by internal audit or the second line, and signed off by the CISO. The programme design itself, from scanning strategy to prioritisation, is covered in the Vulnerability Management Guide; this page assumes that programme exists and tests whether it works.
What this health check covers
The Vulnerability Remediation Report Template for Executives is a monthly report for leadership. This page is different: it is the audit behind the report, with fixed formulas so two reviewers reach the same number, contiguous green, amber and red bands, and a findings workflow that turns a red result into an owned action. If you searched for vulnerability management KPIs, vulnerability SLA metrics or a vulnerability management audit checklist, this is the working version.
Scope is the programme across all asset types the organisation runs: servers, endpoints, network devices, cloud workloads, containers and internet-facing services. The health of the scanning tool itself (job success, scanner credentials, plugin feed freshness) belongs in the Vulnerability scanner health check, and the two pages share no metrics. Patching mechanics sit in the Patch Management Guide.
Key takeaways
- Coverage before counts: a falling number of open findings means nothing if scan coverage or authenticated scanning fell in the same quarter.
- Measure against your own SLAs: SLA compliance and mean time to remediate by severity show whether the targets in your policy are real.
- Known exploited vulnerabilities get their own clock: track KEV remediation time separately, because these are the flaws attackers are already using.
- Look at the tail, not only the average: 90th percentile vulnerability age and the overdue critical count expose the findings that averages hide.
- Accepted risk is still risk: exception count, exception age and the risk-accepted share show whether exceptions are decisions or a parking lot.
How to use this template
Copy the metrics table and the findings log into your own tracker, agree the severity tiers and SLA targets from your vulnerability management policy, then run this Vulnerability Management Health Check at the cadence below. Collect each figure from the data source types described, score it against the bands, and log every amber or red result as a finding with an owner and a due date. Keep each completed run so you can compare quarter on quarter: a trend of three amber quarters is a finding in itself. Where the thresholds do not fit your risk appetite, change them once, record why, and keep them stable so the trend stays comparable.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| KEV and overdue critical sweep (V6, V7) | Weekly | Vulnerability management analyst | Vulnerability management lead | KEV catalogue version used, open KEV findings list, overdue critical list with owners |
| Coverage and inventory reconciliation (V1, V2, V3) | Monthly | Vulnerability management lead | Head of IT operations | Asset inventory extract, scan target list, reconciliation sheet |
| Full KPI run (V1 to V12) | Quarterly | Vulnerability management lead | CISO | KPI workbook, findings log, sign-off record |
| Exception register review (V8, V12) | Quarterly | Risk owner for each exception | Risk committee | Exception register, compensating control evidence, renewal decisions |
| Independent re-performance | Yearly | Internal audit or second line | Audit committee | Re-performed samples, variance notes, threshold change log |
CIS Controls v8.1 Safeguard 7.2 expects the remediation process to be reviewed monthly or more often, and Safeguard 7.7 expects remediation on a monthly or more frequent basis, so a quarterly full run with monthly coverage checks fits that rhythm.
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "Critical" and "high" mean the tiers in your policy, whatever scoring feeds them (CVSS, EPSS, SSVC or a blend). All time metrics use first detection as the start and verified fix (rescan or configuration evidence) as the end.
| ID | Metric | Formula (numerator / denominator) | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| V1 | Scan coverage | In-scope assets with at least one completed vulnerability assessment in the last 30 days / in-scope assets in the asset inventory | Asset inventory or CMDB extract; consolidated assessment results from all scanning sources | ≥ 95% | 85% to below 95% | < 85% |
| V2 | Authenticated scan share | Assessed hosts whose last assessment ran with valid credentials or an agent / assessed hosts | Assessment results with authentication status field | ≥ 90% | 75% to below 90% | < 75% |
| V3 | Asset inventory match | Assets seen by scanning, cloud and network discovery that match an inventory record / all assets seen by discovery | Discovery results joined to inventory records | ≥ 98% | 90% to below 98% | < 90% |
| V4 | Mean time to remediate by severity | Sum of days from first detection to verified fix / findings closed in the quarter, reported per tier, with the median alongside | Findings history with detection and closure dates | Every tier within its policy SLA | One or more non-critical tiers above SLA by up to 25% | Any tier more than 25% above SLA, or critical above SLA |
| V5 | SLA compliance | Findings closed on or before their due date / findings that reached their due date in the quarter, per tier | Findings history; policy SLA table | Critical ≥ 95%, high ≥ 90% | Critical 85% to below 95%, or high 75% to below 90% | Critical < 85%, or high < 75% |
| V6 | KEV remediation time | Median and maximum days from the later of KEV listing date and first detection to verified fix, for KEV-listed findings closed in the quarter; plus KEV findings closed within the internal KEV target / KEV findings that reached that target | Findings joined to the KEV catalogue (dateAdded field) | 100% within target; none open on internet-facing assets | 95% to below 100% within target, all late items with interim mitigation | < 95%, or any internet-facing KEV finding past target without mitigation |
| V7 | Overdue critical count | Count of open critical findings past their due date and not covered by an approved exception | Open findings list; exception register | 0 | 1 to 5, each with a named owner and plan | > 5, or any on an internet-facing asset |
| V8 | Exception count and age | Active exceptions / open critical and high findings; and active exceptions past their expiry date / active exceptions | Exception register | Exceptions ≤ 5% of open critical and high; 0 expired | Above 5% to 10%, or 1 to 3 expired | > 10%, or more than 3 expired, or any without an expiry date |
| V9 | Reopen rate | Findings closed in the previous quarter that were detected again on the same asset within 90 days / findings closed in the previous quarter | Findings history keyed on asset and vulnerability identifier | ≤ 3% | Above 3% to 8% | > 8% |
| V10 | Vulnerability age p90 | 90th percentile age in days of open critical and high findings at the run date | Open findings list with first detection date | ≤ critical SLA plus 15 days | Above that to twice the high SLA | Above twice the high SLA |
| V11 | Patch latency | Median days from vendor patch release to deployment on 95% of affected in-scope assets, sampled across the quarter's critical patches | Vendor advisory dates; deployment or configuration management reports | ≤ 14 days | Above 14 to 30 days | > 30 days |
| V12 | Risk accepted share | Critical and high findings closed by formal risk acceptance / critical and high findings closed in the quarter | Findings history with closure reason; exception register | ≤ 5% | Above 5% to 10% | > 10% |
V1 and V2 follow the logic of the CIS Safeguard 7.5 measures, which count internal assets covered by a scanner and by an authenticated scanner. V6 uses the KEV catalogue as the trigger: under Binding Operational Directive 22-01, US federal civilian agencies must fix KEV entries by the due date in the catalogue, which by default is six months for CVE IDs assigned before 2021 and two weeks for others. Most organisations outside that scope set their own internal KEV target; record which one you measure against.
Reading the metrics together
- V1 down, V5 up: SLA compliance looks better because fewer assets are scanned. Treat the V5 improvement as unproven until coverage recovers.
- V4 green, V10 red: the average is pulled down by quick wins while a tail of old findings grows. Work the oldest first.
- V7 low, V12 rising: overdue counts are being kept down by accepting risk instead of fixing. Escalate to the risk committee.
- V9 above amber: fixes are not sticking, usually because of rebuilt images, configuration drift or rollbacks. Fix the gold image or pipeline, not the host.
How to collect the data
- Freeze the denominators first: take the asset inventory or CMDB extract on the run date, filtered to in-scope assets, and record the count. Every coverage figure uses this snapshot.
- Consolidate findings: export open and closed findings from every assessment source (network scanning, endpoint agents, cloud posture assessment, container image scanning) with asset identifier, vulnerability identifier, severity tier, first detected, last detected, closed date and closure reason. Deduplicate on asset and vulnerability identifier.
- Join to KEV: match CVE identifiers against the current CISA KEV catalogue, keep its catalogue version and the dateAdded field for V6.
- Join to exceptions: match findings to the exception register on finding or asset and vulnerability, carrying approver, expiry date and compensating control.
- Sample patch latency: pick the quarter's critical vendor patches, take release dates from the vendor advisories, and deployment dates from deployment or configuration management reports.
- Verify closures: sample at least 25 closed critical findings and confirm a later assessment no longer shows them. A closure without verification is not a fix.
Record the query or filter used for each metric in the workbook. Changing a filter between quarters breaks the trend without anyone noticing.
Red flags that need action now
- Any KEV-listed vulnerability open on an internet-facing asset past its internal target with no interim mitigation.
- Scan coverage below 85%, or a business unit, cloud account or network segment with no assessment at all in 30 days.
- Authenticated scan share falling by more than ten points in one quarter, which usually means expired or locked scanning credentials.
- Exceptions with no expiry date, no named risk owner, or an approver who is also the remediation owner.
- Critical findings closed as "risk accepted" or "false positive" without evidence attached.
- Assets discovered by network or cloud discovery that appear in no inventory and no owner can be found.
- SLA compliance reported only as an average across tiers, hiding a red critical tier.
- The same vulnerability reopened on rebuilt hosts quarter after quarter.
Exploitation of a known, unpatched flaw is a recurring root cause; the Exploited Vulnerability Breaches guide collects the lessons.
Findings log
| Finding ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-VM-01 | [Cloud account X has no assessment in 30 days] | V1 | [High] | [Cloud platform lead] | [DD/MM/YYYY] | [Open] |
| HC-VM-02 | [Authenticated share fell to 70% after credential rotation] | V2 | [High] | [VM lead] | [DD/MM/YYYY] | [Open] |
| HC-VM-03 | [Two KEV findings on edge devices past target] | V6 | [Critical] | [Network operations lead] | [DD/MM/YYYY] | [In progress] |
| HC-VM-04 | [Nine exceptions past expiry] | V8 | [Medium] | [Risk owners] | [DD/MM/YYYY] | [Open] |
| HC-VM-05 | [Reopen rate 11% on rebuilt web tier] | V9 | [Medium] | [Platform engineering lead] | [DD/MM/YYYY] | [Open] |
Severity of a finding follows the worst band reached and the exposure of the assets involved. Close a finding only when the metric is back in green for one full cycle.
Remediation map
| Finding type | Where to fix it |
|---|---|
| Coverage or inventory gaps (V1, V3) | CIS Control 7 Continuous Vulnerability Management Guide; Attack Surface Management Guide for internet-facing assets |
| Low authenticated share (V2) | Securing the vulnerability scanner itself, for how scanning credentials are held and rotated |
| SLA misses and slow remediation (V4, V5, V10) | Remediation SLAs and Vulnerability Exceptions Guide |
| KEV and overdue critical findings (V6, V7) | CISA KEV Catalogue Guide; Risk-Based Vulnerability Management Guide |
| Exception sprawl and risk acceptance (V8, V12) | Vulnerability Management Policy Template exception section |
| Reopens and patch latency (V9, V11) | Patch Management Guide; NIST SP 800-40 Rev 4 Patch Management Guide |
Framework mapping
| Metric group | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 |
|---|---|---|---|
| Coverage and inventory (V1 to V3) | ID.AM-01, ID.RA-01 | CM-8, RA-5 | 1.1, 7.5 |
| Remediation speed (V4 to V7, V10, V11) | PR.PS-02 | SI-2 | 7.2, 7.7 |
| Exceptions and accepted risk (V8, V12) | ID.RA-06 | RA-7 | 7.2 |
| Review and improvement (all) | ID.IM-01 | CA-7 | 7.2 |
In ISO/IEC 27001:2022 the programme sits under Annex A control 8.8, management of technical vulnerabilities. The UK NCSC's vulnerability management guidance makes the same point as V8 and V12: a decision not to update is a senior-level risk decision and belongs on the risk register.
Related guides
- Vulnerability Management Guide: the programme this health check audits.
- Vulnerability Management Maturity Model: where the programme sits overall; use it to set the next year's targets.
- Vulnerability Remediation Report Template for Executives: the monthly report fed by these numbers.
- Vulnerability scanner health check: the product-level check for the scanning platform.
- If your vulnerability scanner is compromised: the response playbook for the tool that holds credentials to the whole estate.
- Top 10 Vulnerability Management Mistakes: the common causes behind amber and red results.
References
- CISA: Binding Operational Directive 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities
- CISA: Known Exploited Vulnerabilities Catalog
- NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- CIS: Control 7, Continuous Vulnerability Management
- NCSC: Vulnerability management
Related NHI Mgmt Group resources: Vulnerability Management Guide · Vulnerability Management Maturity Model · Remediation SLAs and Vulnerability Exceptions Guide · CISA KEV Catalogue Guide