KRIs for vulnerability management

A functioning vulnerability management program answers five questions continuously: what do we have, what's exploitable, what's critical to the business, what's being done about it, and is the program getting better? The KRIs in this domain measure the program against those five questions, not scanner output counts, but remediation outcomes, SLA performance, coverage discipline, and the risk reduction the program is actually producing.

If you are standing this up from scratch, start with how to build a KRI program and the consolidated KRI reference library, which maps every domain to one CIS-aligned catalog.

KRI inventory

1. Scan coverage rate

What to measure. Percentage of in-scope assets scanned for vulnerabilities within the defined scan frequency window, segmented by asset class (internet-facing, internal servers, endpoints, cloud workloads, network devices).

Why it matters. A vulnerability you haven't scanned for is a vulnerability you don't know you have. Coverage gaps are the program's blind spots, and they consistently cluster in the places most likely to be missed: recently provisioned assets without auto-enrollment, segmented network zones without scanner reach, cloud accounts added without updating the scan scope, and legacy systems where agents won't install.

• Vulnerability management platform (Qualys, Tenable.io, Rapid7 InsightVM, Wiz): scan job completion reports and asset coverage dashboards
• Asset inventory (CMDB, Axonius, Runzero): total in-scope asset count vs. scanned asset count
• Cloud inventory: compare total running compute instances to instances in scan scope
• Scanner deployment logs: agent-based coverage vs. agentless (credentialed scan) coverage per network segment

How to calculate. (Assets scanned within defined frequency window) ÷ (total in-scope assets) × 100 Define frequency by asset class: internet-facing = weekly or continuous; internal servers = weekly; endpoints = monthly; cloud workloads = continuous or at image build.

Status	Criteria
Green	>98% overall coverage; internet-facing assets on continuous or weekly scanning; auto-enrollment for new assets
Amber	90–97%; or internet-facing assets on monthly rather than weekly cadence
Red	<90%; or coverage gaps in internet-facing assets; or cloud workloads outside scan scope

2. SLA compliance rate by severity

What to measure. Percentage of vulnerabilities remediated within the defined SLA for each severity tier, measured across all asset classes and across the trailing 90 days.

Why it matters. SLA compliance rate is the single most direct measure of whether the vulnerability management program is producing outcomes. A program that finds thousands of vulnerabilities but remediates them slowly is accepting risk at the rate findings accumulate. SLA compliance measures whether the organizational commitment to remediation is being honored.

• Vulnerability management platform: finding creation date, severity, and remediation/closure date per finding
• Ticketing system (Jira, ServiceNow): vulnerability remediation tickets, creation date, SLA timer, resolution date
• Patch management platform (SCCM, Intune, Ansible, Chef): patch deployment dates cross-referenced with vulnerability findings
• Risk acceptance registry: findings closed as "accepted", should be excluded from SLA compliance calculation but tracked separately

How to calculate. By severity: (Vulnerabilities remediated within SLA in trailing 90 days) ÷ (total vulnerabilities reaching SLA deadline in trailing 90 days) × 100 Typical SLAs: Critical: ≤15 days; High: ≤30 days; Medium: ≤90 days; Low: ≤180 days

Status	Criteria
Green	>90% SLA compliance for critical and high; defined SLAs documented and agreed with asset owners
Amber	75–89% for critical/high; or SLAs defined but inconsistently applied across asset classes
Red	<75% for critical; or no defined SLAs; or SLA tracking not implemented

3. Mean time to remediate (MTTR) by severity

What to measure. Average days from vulnerability discovery (scan detection) to confirmed remediation, segmented by severity and by asset class.

Why it matters. MTTR is the metric that quantifies how long your organization remains exposed after a vulnerability is discovered. It reflects both the urgency of your remediation process and the operational friction between security findings and engineering action. MTTR trending upward over time is one of the clearest signals of a program that is losing ground to its finding backlog.

• Vulnerability platform: first_found and last_found/status_change timestamps per finding; calculate days delta for remediated findings
• Patch management: patch deployment timestamps cross-referenced with CVE remediation
• Asset class segmentation: MTTR for internet-facing vs. internal vs. cloud workloads often differs significantly

How to calculate. For all remediated findings in trailing 90 days: (Remediation date − First found date). Average by severity and asset class.

Status	Criteria
Green	Critical MTTR <15 days; High MTTR <30 days; trending stable or improving quarter-over-quarter
Amber	Critical 15–30 days; or MTTR trending upward for two consecutive quarters
Red	Critical MTTR >30 days; or MTTR not tracked; or internet-facing MTTR equivalent to internal (no prioritization by exposure)

4. Known exploited vulnerability (KEV) exposure rate

What to measure. Number of assets running software with CVEs listed on the CISA Known Exploited Vulnerabilities catalog, the subset of vulnerabilities with confirmed, active exploitation in the wild. Tracked as an absolute count and as time-to-remediation from KEV listing date.

Why it matters. CISA's KEV list is the highest-confidence signal in vulnerability management. These aren't theoretical risks, they're vulnerabilities that threat actors are actively using right now. Any organization with KEV exposure in internet-facing assets is accepting direct operational risk, not residual risk. KEV exposure is the first question sophisticated security teams and underwriters ask.

• CISA KEV catalog: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json, updated continuously, subscribe or poll daily
• Vulnerability platform: cross-reference open findings against KEV CVE list; most major platforms (Qualys, Tenable, Rapid7) now have KEV integration built in
• EPSS (Exploit Prediction Scoring System): probability-of-exploitation scores as a complement to KEV for prioritizing non-KEV findings
• Asset inventory: KEV findings filtered to internet-facing assets as highest priority

How to calculate.

• KEV-exposed assets: count of assets with open findings matching CVEs in the KEV catalog
• Internet-facing KEV exposure: subset of above on perimeter assets, this should be zero
• KEV MTTR: days from KEV catalog addition date to remediation for confirmed KEV findings

Status	Criteria
Green	Zero KEV findings on internet-facing assets; all KEV findings on internal assets remediated within 72 hours of catalog addition
Amber	KEV findings on internal assets with active remediation; or KEV MTTR 3–7 days
Red	Any KEV finding on internet-facing assets; or KEV MTTR >7 days; or no KEV integration in vulnerability platform

5. Vulnerability finding backlog age distribution

What to measure. Age distribution of the open vulnerability finding backlog, percentage of findings older than 30 days, 90 days, and 180 days, by severity. The backlog shape reveals whether findings are accumulating or being processed.

Why it matters. The backlog age distribution is the x-ray of your vulnerability program's health. A program with SLA compliance of 85% but a backlog skewed toward old high-severity findings is hiding a structural problem: findings are being remediated but the oldest, hardest ones are never getting closed. A rising proportion of findings in the >90-day bucket signals a program losing ground.

• Vulnerability management platform: export open findings with first_found date and severity; calculate age buckets
• Ticketing system: vulnerability tickets by creation date and severity, similar age distribution from a workflow perspective
• Qualys/Tenable aging reports: built-in aging dashboards by severity and detection age

How to calculate. For all open findings: group by severity × age bucket (0–30, 31–90, 91–180, >180 days). Calculate percentage in each bucket. Track quarter-over-quarter shift in the >90-day bucket as the primary trend.

Status	Criteria
Green	<5% of critical/high findings older than 30 days; >90-day bucket declining quarter-over-quarter
Amber	5–15% of critical/high older than 30 days; or >90-day bucket growing
Red	>15% of critical/high older than 30 days; or significant proportion of backlog >180 days without accepted exceptions; or trend consistently worsening

6. Risk acceptance rate and governance quality

What to measure. Percentage of vulnerability findings formally accepted (deferred indefinitely or for a defined period) rather than remediated, with a quality measure of whether each acceptance has documented rationale, appropriate approval, defined duration, and compensating controls.

Why it matters. Risk acceptance is a legitimate program decision. Not every vulnerability can be remediated immediately, and some may be accepted permanently due to compensating controls or low exploitability in context. The risk is when acceptance becomes the default disposition for hard-to-patch vulnerabilities, effectively transforming "risk acceptance" into "risk deferral without accountability." Governance quality measures whether acceptances are decisions, not deferrals.

• Vulnerability platform: findings with "accepted" or "exception" status, export with acceptance date, approver, and duration
• GRC platform / exception management system: formal exception records cross-referenced with vulnerability platform
• Asset owner attestations: signed acceptance records for critical/high severity acceptances

How to calculate.

• Acceptance rate: (Findings closed as "accepted") ÷ (total findings closed in period) × 100
• Governance quality: (Accepted findings with all four elements: rationale + approver + duration + compensating controls) ÷ (total accepted findings) × 100
• High-risk acceptance count: critical/high findings accepted with no compensating controls

Status	Criteria
Green	Acceptance rate <10% of closures; 100% of acceptances fully documented; no critical findings permanently accepted without compensating controls
Amber	10–20% acceptance rate; or governance documentation incomplete for some acceptances
Red	>20% acceptance rate (acceptance being used as a disposal mechanism); or critical findings accepted with no documentation or compensating controls

7. Patch management effectiveness rate

What to measure. Percentage of assets that are fully patched at the current patch cycle for their asset class, measured against an approved patching baseline, not against a rolling comparison.

Why it matters. Vulnerability management identifies what needs to be fixed; patch management delivers the fix. These are often run by different teams with different cadences, which creates accountability gaps. Patch management effectiveness measures whether the remediation function is keeping pace with the vulnerability identification function.

• Patch management platform (SCCM/Intune, Ansible, Puppet, Chef, AWS Systems Manager Patch Manager): patch compliance dashboard per asset class
• OS-level compliance: % of assets fully patched within N days of patch Tuesday / vendor patch release
• Cloud instances: patch compliance through SSM Patch Manager (AWS), Azure Update Manager, GCP OS Policy
• Third-party application patching: separate metric, OS patch rates often look good while third-party applications lag

How to calculate. (Assets with all approved patches applied within defined patch window) ÷ (total managed assets) × 100 Track separately: OS patching vs. third-party application patching vs. cloud workload patching

Status	Criteria
Green	>98% OS patch compliance; >90% third-party application compliance; cloud workloads patched via immutable image pipeline
Amber	90–97% OS; or third-party application patching not tracked separately; or cloud instances patched in-place rather than via image replacement
Red	<90% OS compliance; or no third-party application patching program; or patch compliance data not available

8. Vulnerability program efficiency ratio

What to measure. The ratio of new vulnerabilities introduced to vulnerabilities remediated per period, a measure of whether the program is net-reducing risk or treading water. Supplemented by cost-per-remediated-finding and analyst-to-finding ratios as operational efficiency signals.

Why it matters. A program that remediates 500 findings per month while 600 new findings arrive is losing ground regardless of SLA compliance on the ones it closes. The efficiency ratio is the program-level metric that tells leadership whether the investment in vulnerability management is producing net risk reduction.

• Vulnerability platform: new findings per period (opened) vs. resolved findings per period (closed), available in most platform dashboards
• Staffing records: VM analyst headcount and hours dedicated to remediation coordination
• Total finding counts over time: trend determines whether the program is reducing, maintaining, or growing the backlog

How to calculate.

• Efficiency ratio: (Findings remediated in period) ÷ (new findings in period), ratio >1.0 = net backlog reduction
• Finding-to-analyst ratio: total open findings ÷ VM analyst FTEs, benchmarks against peer organizations
• Program ROI: (Estimated risk reduction from remediated critical/high findings) ÷ (VM program cost)

Status	Criteria
Green	Efficiency ratio >1.0 for two consecutive quarters; backlog declining trend
Amber	Ratio 0.85–1.0 (roughly flat); or ratio fluctuating without clear trend
Red	Ratio <0.85 consistently (backlog growing faster than remediation); or efficiency ratio not tracked

Deriving these KRIs by source type

From Qualys

• Coverage: Qualys Asset Management API → /qps/rest/2.0/count/am/asset for total assets vs. /qps/rest/2.0/count/was/webApp for web apps; cross-reference with VM scan coverage report
• SLA compliance: Qualys Vulnerability Management API, query findings by severity and firstFound; filter to closed findings; calculate days delta
• KEV integration: Qualys TruRisk dashboard now integrates KEV natively; also available as custom search list by CVE ID list from CISA feed
• Aging report: QQL: severity:4,5 and status:Active and firstFound:<2024-01-01, adjust date for 90-day bucket

From Tenable (Tenable.io / Tenable.sc)

• Asset coverage: Tenable.io Dashboard → Asset Summary with scan frequency filters; API: GET /assets with last_scan_time filter
• SLA tracking: Tenable Vulnerability Management → export findings with first_seen, severity, state=fixed for MTTR calculation
• MTTR calculation: Export via GET /vulns/export with first_found and last_fixed fields; calculate delta in Python/Excel
• KEV: Tenable natively flags KEV vulnerabilities in the vulnerability list with a "Known Exploited" tag

From Rapid7 InsightVM

• Coverage gaps: InsightVM Asset Explorer → filter "not recently scanned" by scan window threshold
• SLA reporting: InsightVM built-in SLA goal tracking; configure SLA goals per severity in Goals & SLAs settings
• Remediation projects: Remediation Project tracking, assigned findings, owner, deadline, completion status → feeds SLA compliance calculation

From Patch Management (SCCM/Intune, Ansible, AWS SSM)

• Intune patch compliance: GET /deviceManagement/managedDevices with osVersion filter; compare against current OS patch baseline
• SCCM compliance: SQL query against SCCM database: SELECT * FROM v_UpdateSummaryPerCollection WHERE CI_ID IN (SELECT CI_ID FROM v_AuthListInfo WHERE ArticleID IN (<CVE-list>))
• AWS SSM Patch Manager: aws ssm describe-instance-patch-states-for-patch-group per patch group; calculate compliance percentage
• Ansible: Playbook run reports showing patch application success/failure rates per host

From CISA KEV Integration

• Daily KEV sync: curl https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json | jq '.vulnerabilities[].cveID', extract CVE list; cross-reference against open findings in vulnerability platform
• Webhook/automation: Configure CISA KEV RSS feed notification → trigger automatic Jira ticket creation for any KEV CVE found in open findings
• KEV age tracking: For each KEV CVE in open findings, record dateAdded from KEV JSON; calculate days exposed since KEV listing