Vulnerability Management Maturity Model

Most organisations run a vulnerability scanner, yet the backlog keeps growing, the same critical findings reappear every month and nobody can say whether the actively exploited ones were fixed in time. This vulnerability management maturity model scores a programme across eight dimensions, from asset coverage and scanning to ownership, risk-based prioritisation, remediation, exceptions, verification and reporting, on the five-level Ad hoc to Optimised scale used across NHI Mgmt Group maturity models. It maps each dimension to NIST SP 800-40 Rev. 4, CIS Control 7, NIST CSF 2.0 and CISA's Known Exploited Vulnerabilities (KEV) catalogue and BOD 22-01, and explains what risk-based vulnerability management (RBVM) looks like at each level without reference to any product. It is for vulnerability management leads, infrastructure and platform owners and CISOs who need an honest baseline and a staged roadmap. For how to run the programme day to day, see the Vulnerability Management Guide; this page is about measuring and improving it.

Key takeaways

• Score eight dimensions separately: asset coverage, scanning depth, prioritisation, ownership and workflow, remediation execution, exceptions and risk acceptance, verification, and metrics and reporting. A programme is only as mature as its weakest dimension on internet-facing systems.
• Coverage comes before speed. A fast patch cycle on 70% of the estate is not mature, because the unscanned 30% is where exploited vulnerabilities wait. NIST SP 800-40 Rev. 4 warns that unauthenticated scans "generally underreport vulnerabilities".
• Risk-based prioritisation is the dividing line between Level 2 and Level 3. Ranking by CVSS base score alone is Developing; ranking by known exploitation (KEV), exploitation likelihood (EPSS), asset exposure and business criticality is Defined.
• Ownership decides remediation speed. Mature programmes route every finding to a named asset owner with a due date set by policy, and treat not fixing as a recorded business risk decision rather than an IT backlog.
• Measure time and coverage together. The metrics that show maturity are KEV remediation within deadline, mean and median time to remediate by priority, authenticated scan coverage and the age of open exceptions, not the total number of open findings.

The five levels

The eight dimensions

Levels 2 and 4 sit between the descriptions shown. Use the table to score each dimension, then use the roadmap below to plan the next step.

Scanner credentials belong in the scoring for Scanning and assessment. Authenticated scanning needs privileged service accounts across the estate, which makes them some of the most powerful non-human identities you own. At Level 3 they are inventoried, vaulted, rotated and restricted to the scanner's source addresses. See the Service Account Security Guide.

Risk-based vulnerability management by level

RBVM means ranking remediation work by the likelihood that a vulnerability will be exploited and the impact if it is, rather than by technical severity alone. FIRST's CVSS v4.0 user guide is explicit that the CVSS base score "Measures Severity, not Risk" and "should not be used alone to assess risk". CVSS v4.0 splits scores into CVSS-B (Base), CVSS-BT (Base and Threat), CVSS-BE (Base and Environmental) and CVSS-BTE, and "The application of Environmental and Threat metrics is the responsibility of the CVSS consumer." Advisories and databases usually publish CVSS-B only, so sorting by the published number is sorting by severity.

Three public inputs supply the threat side. CISA's KEV catalogue lists vulnerabilities with a CVE ID, "reliable evidence that the vulnerability has been actively exploited in the wild" and a clear remediation action, and CISA states that organisations "should use the KEV catalog as an input to their vulnerability management prioritization framework". FIRST's Exploit Prediction Scoring System (EPSS) "estimates the probability that a published CVE will be exploited in the wild in the next 30 days", published daily for every CVE; its user guide warns that "EPSS should never be treated as a risk score" because it covers only the threat component. CISA's Stakeholder-Specific Vulnerability Categorization (SSVC), developed with Carnegie Mellon's Software Engineering Institute, turns exploitation status, technical impact, automatability, mission prevalence and public well-being impact into four decisions: Track, Track*, Attend and Act.

Choosing a method: a small team with one queue will get most of the benefit from a simple rule (KEV, then EPSS above an agreed threshold on exposed assets, then everything else by CVSS-BTE). A large organisation with many business units should adopt a documented decision tree such as SSVC, because it produces the same answer whoever runs it and gives auditors a traceable rationale. Whichever you choose, write it down: CIS Safeguard 7.2 asks for "a risk-based remediation strategy documented in a remediation process" with monthly reviews. For the wider exposure view that adds misconfigurations, identities and attack paths, see the Exposure Management and CTEM Guide.

How this model relates to other frameworks

None of the primary sources defines a vulnerability management maturity model, so the levels here are NHI Mgmt Group's own. They are built on what the standards require. NIST SP 800-40 Rev. 4 defines enterprise patch management as "the process of identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades throughout an organization", and introduces maintenance groups ("a set of assets with similar characteristics") with routine and emergency maintenance plans. CIS Control 7 sets cadences: Implementation Group 1 needs a documented process, a risk-based remediation process and monthly automated patching; IG2 adds quarterly authenticated internal scans, monthly external scans and monthly remediation. NIST CSF 2.0 Tiers (Partial, Risk Informed, Repeatable, Adaptive) describe how rigorously risk is governed. As a rough guide, Level 1 resembles Tier 1, Level 2 Tier 2 and CIS IG1, Level 3 Tier 3 and CIS IG2, and Levels 4 and 5 Tier 4; that alignment is our judgement, not an official crosswalk.

BOD 22-01 is binding only on US federal civilian agencies, but it is the clearest public benchmark for exploited vulnerabilities: agencies had to update internal vulnerability management procedures within 60 days and remediate KEV entries within two weeks, or six months for CVEs assigned before 2021. CISA's Cross-Sector Cybersecurity Performance Goals take a softer line for everyone else: goal 1.E asks that KEV entries "in internet-facing systems are patched or otherwise mitigated within a risk-informed span of time".

Self-assessment questions

Score each dimension from 1 to 5 using evidence you can produce today, not intent. Your overall level is the lowest score among the dimensions that cover internet-facing and business-critical systems, not the average.

• Coverage: what percentage of assets in your inventory were scanned with credentials in the last 30 days, and how many assets did the last external discovery find that were not in the inventory?
• Scanning: do cloud workloads, container images, network appliances and SaaS-managed components appear in the same queue as servers, or in separate tools nobody correlates?
• Prioritisation: if a CVE is added to the KEV catalogue tonight, who learns about it, how, and how long until you know which of your assets are affected?
• Ownership: what percentage of open critical findings are assigned to a named team rather than to "IT" or the security team?
• Remediation: for the last five KEV entries that affected you, how many days passed from catalogue listing to verified fix on internet-facing systems?
• Exceptions: how many open exceptions have passed their expiry date, and who approved the oldest one?
• Verification: what share of tickets closed as fixed last quarter reopened at the next scan?
• Reporting: can you show the median time to remediate exploited vulnerabilities for each of the last six months, by business unit?

Moving up a level

A small organisation with mostly managed laptops and SaaS can reach Level 3 with built-in update tooling, one scanner, KEV and EPSS lookups and a shared ticket queue. A large organisation with data centres, several clouds and OT will need a central aggregation layer that de-duplicates findings from many sources, maps them to an asset and owner, and applies one prioritisation policy; the hard part there is ownership data, not scanning. NCSC's advice applies to both: "It's often best to start in a small or focused way and then grow the process to scale", for example with critical systems first.

From Ad hoc to Developing

1. Write a short vulnerability management process (CIS Safeguard 7.1): scope, scan cadence, severity tiers, deadlines and who decides exceptions. Review it annually.
2. Build the first asset list from directory, endpoint management, cloud account inventories and DHCP, and compare it with what the scanner actually reached. See the Attack Surface Management Guide for the external side.
3. Turn on automated operating system and browser updates for managed endpoints (CIS 7.3, 7.4). See the Patch Management Guide.
4. Schedule recurring scans, internet-facing assets first.

From Developing to Defined

1. Move internal scanning to authenticated scans, starting with one server maintenance group as a pilot, checking scan load and account lockouts before widening. Vault and rotate the scan credentials.
2. Replace CVSS-only ranking with a written RBVM policy: KEV first, then EPSS and CVSS-BTE adjusted for exposure and criticality, each tier with a deadline. Run the new ranking in parallel with the old one for a month and compare what each would have fixed before switching.
3. Attach an owner and criticality to every asset and route findings automatically into each owner's ticket queue, grouped by fix rather than by CVE.
4. Define routine and emergency maintenance plans per maintenance group, using SP 800-40 Rev. 4's model of canary assets, early adopters and a forced install "after a grace period has ended". Keep a tested rollback (snapshot, previous image or uninstall package) for each group.
5. Introduce exceptions with business owner sign-off, compensating controls and an expiry. See the Security Exceptions and Risk Acceptance Guide.
6. Close tickets only when a rescan confirms the fix.

From Defined to Managed

1. Subscribe to KEV updates and set an emergency path for exploited vulnerabilities on internet-facing systems; use BOD 22-01's two weeks as the outer limit and aim for days on edge devices such as VPNs and firewalls. See the Zero-Day and Exploited Vulnerabilities Guide.
2. Report coverage, deadline compliance and mean and median time to remediate monthly by business unit, with named owners for missed deadlines.
3. Fix recurring findings at source: rebuild golden images and base container images, retire unsupported software and remove unused packages, which SP 800-40 Rev. 4 calls avoiding the risk by "eliminating the attack surface".
4. Add post-patch steps for vulnerabilities that leak credentials or sessions: rotate exposed keys and secrets and end active sessions as part of the fix.

From Managed to Optimised

1. Move from scheduled scans to continuous, event-driven assessment in build pipelines, registries and cloud APIs.
2. Add reachability and attack path context and validate the highest-risk exposures with testing. See the Penetration Testing Guide.
3. Fold vulnerability data into a continuous exposure management cycle alongside misconfigurations and identity exposures.
4. Use trend data and post-incident reviews to set next year's targets (CSF ID.IM-01, ID.IM-03).

Metrics that show maturity

NIST SP 800-40 Rev. 4 recommends measuring the percentage of assets patched by deadline alongside "the average (mean) time and median time for patching", and warns that "Metrics that are too simple are generally not actionable because they do not provide enough information." Report each metric by priority tier and business unit.

• KEV deadline compliance: percentage of KEV vulnerabilities on internet-facing assets remediated or mitigated within your policy deadline (target 100%).
• Time to remediate: mean and median days from detection (or KEV listing) to verified fix, per priority tier.
• Authenticated coverage: percentage of inventoried assets assessed with credentials or an agent in the last 30 days.
• Unknown asset rate: assets found by discovery that were not in the inventory, per month.
• Exception health: number of open exceptions, how many are past expiry and the age of the oldest.
• Reopen rate: percentage of findings closed as fixed that reappear at the next scan.

See the Security Operations Metrics Guide for how to present them and the Board Cyber Risk Reporting Guide for the board view.

Common failure patterns

• Counting findings instead of exposure: a falling total of open findings looks like progress while one exploited vulnerability on a VPN appliance stays open. Edge devices were the entry point in the Ivanti Connect Secure exploitation, where two VPN zero-days exposed credentials, service accounts and sessions.
• Patched but still compromised: in CitrixBleed 2023 stolen session tokens outlived the patch, and in ToolShell stolen ASP.NET machine keys kept attackers inside after patching. Verification at Level 3 and above must include ending sessions and rotating exposed secrets.
• Unauthenticated scanning reported as coverage: the asset is counted as scanned, but missing patches inside it are not seen.
• Exceptions that never expire: temporary acceptance becomes permanent, with no compensating control checked since it was granted.
• Security owns the backlog: when findings are assigned to the security team rather than to asset owners, remediation waits on persuasion instead of policy.

Practitioner checklist

• Set Level 3 as the 12-month target, with Level 4 for internet-facing and business-critical systems.
• Reconcile the asset inventory against scan results monthly and chase every gap.
• Write the RBVM policy down: KEV first, then EPSS and CVSS-BTE adjusted for exposure and criticality, with deadlines per tier.
• Give every finding a named owner and a due date from policy, not from negotiation.
• Run an emergency maintenance plan for KEV entries on edge and internet-facing systems, and test it before you need it.
• Require rescan verification, plus secret rotation and session termination where a flaw exposes credentials.
• Report KEV deadline compliance, median time to remediate and authenticated coverage monthly. When choosing tooling, use the Vulnerability Management Buyer's Guide.

Standards and references

• NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology
• CISA: Known Exploited Vulnerabilities Catalog
• CISA: BOD 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities
• FIRST: Exploit Prediction Scoring System (EPSS) User Guide
• FIRST: CVSS v4.0 User Guide
• CISA: Stakeholder-Specific Vulnerability Categorization (SSVC)
• CIS: Controls Assessment Specification, Control 7 Continuous Vulnerability Management
• NIST: The NIST Cybersecurity Framework (CSF) 2.0

Related NHI Mgmt Group resources: Vulnerability Management Guide · Vulnerability Management Buyer's Guide · Exposure Management and CTEM Guide · Exposure Management Buyer's Guide · Attack Surface Management Guide · Attack Surface Management Buyer's Guide