Risk-Based Vulnerability Management (RBVM) Guide

Most vulnerability programmes say they are risk-based, but few can show the risk model, the asset context or the governance that would make that claim true. Risk-based vulnerability management (RBVM) is the operating model that turns public signals such as the CISA Known Exploited Vulnerabilities (KEV) catalogue, FIRST EPSS, CVSS v4.0 and SSVC into decisions that reflect your assets, your business services and your risk appetite. This guide covers the programme view: how to build and document a risk scoring model, how to classify asset criticality and business context, who decides what, which metrics prove risk is falling, and how to validate that the model works. It is for vulnerability management leads, risk managers and CISOs. How each signal works in detail is covered in the Vulnerability Prioritisation Guide, and scanning, SLAs and remediation workflow in the Vulnerability Management Guide.

Key takeaways

RBVM is a governance decision, not a tool feature. A vendor risk score is only risk-based if you can explain its inputs, tie them to your asset data and show who approved the thresholds.
Asset context carries half the model. KEV, EPSS and CVSS describe the vulnerability; exposure, criticality and the credentials an asset holds describe what compromise would cost you, and only you can supply them.
Keep evidence and estimate separate. KEV is evidence of exploitation, EPSS is a 30-day probability estimate and CVSS is severity. FIRST says EPSS is not a risk score, so build a decision model rather than a single multiplied number.
Measure risk, not ticket counts. NIST SP 800-40 Rev. 4 says simple counts are not actionable; report deadline compliance and time to remediate by asset importance and priority.
Validate the model. Back-test against KEV additions, sample "not exploitable" decisions with testing, and review thresholds at least yearly, because both the threat data and your estate change.

What makes a programme risk-based

Risk in the simplified model FIRST uses is a function of threat, vulnerability and impact. FIRST's EPSS user guide states that EPSS addresses only the threat component and should not be treated as a risk score. CVSS v4.0 says the Base score reflects intrinsic characteristics under a reasonable worst case, and that consumers should add Threat and Environmental values for "a more comprehensive input to risk assessment". A risk-based programme therefore needs four things that a scanner on its own does not provide:

A documented model: written rules that combine exploitation evidence, likelihood, severity, exposure and business impact into a priority tier, with the rationale for every threshold.
Trusted asset context: every finding joined to an asset record with owner, environment, internet exposure, business service and criticality. NIST CSF 2.0 ID.AM-05 asks that assets are prioritised by classification, criticality, resources and impact on the mission.
Risk ownership: the NCSC says the choice not to update is a senior-level risk decision that belongs in the organisation's risk register, not a call for the engineer who received the ticket.
Feedback: metrics and validation that show whether the model is sending effort to the vulnerabilities that are later exploited.

The table shows how RBVM differs from severity-based programmes and from exposure management.

Dimension	Severity-based VM	Risk-based VM	Exposure management (CTEM)
Unit of work	CVE finding	Finding on an asset in a business context	Exposure or attack path, including misconfigurations and identities
Primary sort key	CVSS Base score	Tier from documented model (KEV, EPSS, CVSS-BTE, criticality, exposure)	Validated attack paths to critical assets
Who sets priorities	Scanner vendor defaults	Security with business risk owners, under a signed policy	Security, business and IT jointly, per scoping cycle
Main metric	Open criticals, tickets closed	Deadline compliance and time to remediate by tier and asset importance	Exposure reduction on scoped attack surfaces
Validation	Rescan	Rescan plus back-testing and sampled exploitability checks	Adversarial validation (BAS, penetration testing)

RBVM sits inside a wider exposure programme rather than competing with it. See the Exposure Management and CTEM Guide.

Designing the risk scoring model

The model has two halves. The vulnerability half comes from public sources and changes daily; the asset half comes from your inventory and changes when the estate changes. Keep them as separate, stored inputs so you can explain any tier and recompute it when either side moves.

Input	Source	Role in the model	Stored as
Known exploitation	CISA KEV (CVE ID, reliable evidence of exploitation, clear remediation); your threat intelligence	Override: forces the top tiers regardless of score	Boolean plus date added and source
Exploit likelihood	FIRST EPSS, daily 30-day probability	Promotes non-KEV findings above a threshold you choose	Probability, score date and model version
Severity	CVSS v4.0 vector from the CNA or vendor	Technical impact and attack conditions (AV, PR, UI)	Full vector string, not just the number
Decision outcome	SSVC (CISA tree), using CISA ADP data for exploitation, automatable and technical impact	Explainable action label: Track, Track*, Attend, Act	Decision point values and outcome
Exposure	Attack surface data, firewall and cloud security group analysis, reachability analysis	Raises internet-facing and user-reachable assets; lowers proven isolation	Exposure class with evidence and date
Asset criticality	CMDB, business impact analysis, data classification	Sets CVSS CR, IR and AR and SSVC mission prevalence	Criticality tier per asset or asset group
Identity blast radius	Identity inventory, secrets inventory, attack path tools	Raises assets that hold privileged credentials or tokens	Flag per asset with linked identities

Rules that keep the model honest

Evidence overrides estimates: KEV records observed exploitation, while EPSS is a forecast. A KEV entry can never be lowered by a low EPSS or a medium CVSS score; only proven compensating controls or isolation can change its handling, and only through a recorded exception.
Use the CVSS environmental fields rather than inventing your own: CR, IR and AR take Low, Medium or High, and Not Defined is treated as High. Setting them from asset criticality lets the standard formula reflect business importance. Set Exploit Maturity from KEV and threat intelligence; Not Defined is treated as Attacked, so the score only falls when you assert P or U.
Use EPSS aggregation for posture, not for single findings: FIRST's user guide notes that 100 vulnerabilities each at 5% give about a 99.4% chance that at least one is exploited. Aggregated per business service, it is a trend line for executives, not a ticket priority.
Record versions: store the EPSS model version and score date, the CVSS version and the KEV catalogue version used for each decision, so a later audit can reproduce it.

Asset criticality and business context

Asset context is where most RBVM programmes fail, because it requires business input that security cannot generate alone. NIST SP 800-40 Rev. 4 asks organisations to track each asset's role and importance along with applicable regulations, contractual limits and outage restrictions, and to put every asset into a maintenance group with similar characteristics rather than treating hard cases as exceptions.

Criticality tier	Definition	Typical examples	CVSS CR/IR/AR	SSVC mission prevalence
Tier 0: identity and control plane	Compromise gives control of other systems	Identity providers, domain controllers, PAM and secrets vaults, CI/CD, hypervisor and backup consoles, VPN and SSO gateways	H/H/H	Essential
Tier 1: crown jewels	Directly delivers a mission-essential function or holds regulated data	Payment systems, customer databases, ERP, clinical or OT supervisory systems	Set per service, usually H for the dominant property	Essential
Tier 2: supporting	Supports essential functions but is not one itself	Internal line-of-business applications, build agents, monitoring	M	Support
Tier 3: low value	Little impact if compromised and isolated from higher tiers	Lab, kiosk and short-lived test systems with no production credentials	L	Minimal

Assign criticality to services, then inherit it: tag the business service once and let hosts, containers and cloud accounts inherit its tier through the CMDB or cloud tags. See the Asset Inventory and CMDB Security Guide.
Use the SSVC definitions when owners disagree: CISA defines Essential as directly providing at least one mission-essential function, Support as supporting such functions, and Minimal as neither. In CISA's mission and well-being table, Essential always yields High.
Add public well-being impact where it is real: for safety and critical infrastructure systems, SSVC's Material and Irreversible values raise the outcome even for Minimal-prevalence components.
Default unknown assets to high, not low: an asset with no owner or tier should be treated as Tier 1 for prioritisation and routed to a triage queue. This mirrors the CVSS convention that Not Defined requirements score as High.
Record regulatory drivers separately: CVSS v4.0 notes that regulatory requirements, customers affected and reputational impact sit outside CVSS. Hold them as asset attributes so mandatory deadlines follow the asset.

Where identity fits

Many exploited edge vulnerabilities are serious because of the credentials the device holds. In CitrixBleed 2, a memory over-read in NetScaler returned live session tokens and the nsroot administrator's token, letting attackers resume sessions without MFA; patching did not invalidate tokens already stolen. RBVM models should treat identity blast radius as an explicit input:

Flag credential-bearing assets: anything storing service account passwords, API keys, machine keys, OAuth refresh tokens or session state for other systems is Tier 0 or Tier 1 by default.
Extend the remediation definition: for findings that can disclose memory, files or configuration, "remediated" includes terminating sessions and rotating the secrets the asset held. See the Secrets Rotation Runbook Template.

Governance and operating model

BOD 22-01 is a useful template even outside the US federal sector. It required agencies to update their vulnerability management procedures within 60 days to cover remediation of KEV entries, roles and responsibilities, prompt response actions, internal validation and enforcement, and tracking and reporting. Those five elements map well to any RBVM policy.

Decision	Proposed by	Approved by	Review cadence
Risk model, tiers and EPSS threshold	Vulnerability management lead	CISO, with risk committee endorsement	Annually and after a material model change (new EPSS model, CVSS version, KEV policy)
Asset criticality tiers	Service owners, guided by security	Business service owner	At service onboarding and annually
Remediation targets per tier	Security with IT operations	CISO and CIO jointly	Annually
Exception or risk acceptance	Asset owner	Named business risk owner at the level your risk policy requires	On expiry, or on KEV listing or exposure change
Emergency (P1) response	Vulnerability management or SOC	Incident lead, with leadership informed (SSVC Act)	Per event, with a post-incident review

Link to risk appetite: NIST CSF 2.0 GV.RM-02 calls for risk appetite and tolerance statements. Express them in RBVM terms, for example "no KEV finding on an internet-facing Tier 0 or Tier 1 asset older than 7 days", so breaches of appetite are measurable.
Choose the response explicitly: SP 800-40 Rev. 4 lists accept, mitigate, transfer and avoid, and notes that risk is accepted by default when nothing is done. Every aged finding is therefore an unrecorded acceptance until someone records it. See the Security Exceptions and Risk Acceptance Guide.
Write it into policy: the model, tiers and approval rules belong in the vulnerability management policy so they survive staff changes. See the Vulnerability Management Policy Template and the Remediation SLAs and Vulnerability Exceptions Guide.

Implementing RBVM

Baseline the current queue: export open findings with CVSS, asset and age, and record how many are KEV, how many have EPSS above 0.1 and how many cannot be joined to an owned asset.
Fix the asset join first: agree the criticality tiers, tag business services, and make inheritance work for cloud accounts, clusters and images. Do not switch prioritisation on until most findings resolve to an owned asset with a tier.
Ingest the feeds: load the KEV JSON feed, the daily EPSS file (log the model version on its first line) and CVSS v4.0 vectors and SSVC values from CVE records. Recompute tiers daily.
Run in shadow mode: for one or two patch cycles, compute the new tiers next to the old severity queue without changing tickets. Compare effort (how many findings each approach flags), coverage of KEV entries and coverage of findings later added to KEV.
Pilot with one owner group: pick a team that owns internet-facing infrastructure, collect feedback on false urgency and tune thresholds.
Publish and sign the policy: get the model, targets and exception rules approved as in the governance table, then switch ticket priority to the new tier for all teams.
Automate promotion and notification: a daily job re-tiers open findings when KEV, EPSS or exposure changes and alerts owners of promotions, so a finding's priority is never fixed at discovery.
Keep a rollback path: retain the original CVSS fields and version the rule set, so you can revert the queue view without losing data.

Decision guidance

Vendor risk score or your own model: a commercial score is acceptable if its inputs are documented and you can override asset criticality. If you cannot explain a score to an auditor, wrap it in your own tiers that keep KEV and exposure visible.
SSVC or a scored matrix: SSVC suits organisations that already map assets to business functions and want explainable, defensible decisions. A matrix suits teams whose tooling can only sort by number; keep each input visible so it does not become another opaque score.
Large or regulated organisations: drive CVSS-BTE from CMDB attributes, use SSVC mission prevalence from business impact analysis, add attack path and reachability analysis for choke points, and report quantified exposure to the board. See the Cyber Risk Quantification Guide.
Software you build: for first-party code and open-source dependencies, add code and runtime reachability so that "present but not called" components do not dominate the queue. See the Reachability Analysis Guide.

Validating the model

Risk-based vulnerability validation means checking that the model's judgements are right, in both directions: that what it calls urgent is exploitable, and that what it deprioritises is not.

Back-test against KEV: each month, list CVEs newly added to KEV and check what tier they held in your environment beforehand and how long they had been open. A model that left new KEV entries in P4 for months needs a lower EPSS threshold or better exposure data.
Measure coverage and efficiency: FIRST defines coverage as the share of exploited vulnerabilities that a strategy prioritised and efficiency as the share of prioritised vulnerabilities that were exploited. FIRST's October 2023 example shows CVSS 7 and above giving 82.2% coverage at 3.96% efficiency, and an EPSS threshold of 0.1 giving 63.2% coverage at 65.2% efficiency. Compute both for your own rules.
Sample deprioritised findings: have penetration testers or breach and attack simulation check a sample of findings marked unreachable, mitigated or low priority. See the Breach and Attack Simulation (BAS) Guide.
Test compensating controls, not just record them: a WAF rule or segmentation claim that lowers a tier should be tested. In the ShinyHunters FBI breach claim, Mandiant reported that the group evaded string-based WAF rules for a patched PeopleSoft flaw by encoding a single character, so organisations relying on WAF rules alone stayed exposed (the FBI has not confirmed this flaw was used against it).

Metrics and reporting

SP 800-40 Rev. 4 says counts such as the number of vulnerabilities and the percentage patched are not actionable, and recommends a matrix by asset importance and vulnerability severity showing the percentage patched by deadline and the mean and median time to patch. It also warns that monthly scans understate exposure and unauthenticated scans under-report vulnerabilities, so the data quality behind the metric matters.

Metric	Definition	Audience	Signal that it is working
KEV exposure window	Median days from KEV listing (or fix release, if later) to remediation, for Tier 0 and Tier 1 assets	CISO, board	Falls and stays inside the appetite statement
Deadline compliance by tier	Percentage of findings remediated within target, split by criticality tier and priority tier	IT and service owners	Highest compliance on the highest tiers, as in SP 800-40's example (95.2% for critical vulnerabilities on high-importance assets)
Time to remediate	Mean and median days to remediate per tier; report both, because a few long-lived findings distort the mean	Operations	Median falls; gap between mean and median narrows
Risk debt	Count and age of open P1 and P2 findings past target, plus active exceptions by expiry	Risk committee	Declining, with no expired exceptions
Context coverage	Percentage of findings joined to an owned asset with a criticality tier	VM lead	Above 95% and rising

Tailor reports by audience, as SP 800-40 recommends. See the Board Cyber Risk Reporting Guide.

Framework mapping

RBVM element	NIST CSF 2.0	NIST SP 800-53 Rev. 5	Other
Asset criticality and inventory	ID.AM-05	CM-8 System Component Inventory, RA-9 Criticality Analysis	CIS Control 1
Identify and record vulnerabilities	ID.RA-01	RA-5 Vulnerability Monitoring and Scanning	CIS Safeguards 7.5 and 7.6; ISO/IEC 27001:2022 A.8.8
Risk scoring with threat, likelihood and impact	ID.RA-05	RA-3 Risk Assessment	CIS Safeguard 7.2 (risk-based remediation process)
Risk response and exceptions	ID.RA-06	RA-7 Risk Response, SI-2 Flaw Remediation	BOD 22-01 required actions
Risk appetite and strategy	GV.RM-02	PM-9 Risk Management Strategy	ISO/IEC 27001:2022 clause 6.1
Metrics and model review	GV.OV-03, ID.IM-01	CA-7 Continuous Monitoring	SP 800-40 Rev. 4 metrics matrix
Threats the model prioritises against	ID.RA-05	RA-3	MITRE ATT&CK T1190 Exploit Public-Facing Application, T1133 External Remote Services

Common failure patterns

A black-box score nobody can explain: the tool's score drives SLAs, nobody can say why a finding is 780 rather than 640, and owners dispute every ticket.
Criticality left at the default: asset tiers were never set, so every host carries the same weight and the "risk-based" queue is the CVSS queue under a new name.
Waiting for KEV: KEV lags exploitation. CitrixBleed 2 was disclosed on 17 June 2025, exploitation was reported from around 20 June and the CVE was added to KEV on 10 July. Internet-facing Tier 0 gateways need a rule that acts on credible exploitation reports and high EPSS before the listing arrives.
Patched but still compromised: the ticket closes on version change while stolen sessions, machine keys or service account passwords stay valid. See the Zero-Day and Exploited Vulnerabilities Guide.
Thresholds never revisited: the EPSS threshold chosen at launch is kept through model changes and estate growth, and nobody measures coverage again.

Practitioner checklist

Document the risk model: inputs, tier rules, EPSS threshold and the rationale for each, approved by the CISO.
Define four criticality tiers with business service owners and make assets inherit them from services and cloud accounts.
Treat identity providers, vaults, CI/CD, gateways and backup consoles as Tier 0 and flag every credential-bearing asset.
Ingest KEV, EPSS and CVSS v4.0 and SSVC data daily, and store versions and score dates with each decision.
Run the new model in shadow mode for at least one patch cycle and compare effort and KEV coverage before switching.
Express risk appetite as measurable RBVM statements and route breaches to the risk committee.
Record every risk acceptance with a named owner, compensating control evidence, expiry and KEV or exposure triggers.
Back-test monthly against new KEV entries and sample deprioritised findings with testing.
Report KEV exposure window, deadline compliance by tier, median time to remediate and risk debt, not ticket counts.
Review the model, thresholds and tiers at least yearly and after any material change to EPSS, CVSS or your estate.

Risk-Based Vulnerability Management Guide: Using KEV, EPSS and Context to Prioritise