The same CVE on two different systems is not the same risk.
Vulnerability Risk Model (VRM) 3.0 is a context-aware approach to vulnerability management. It blends technical severity (CVSS), exploit probability (EPSS), and enterprise business context to reduce noise, accelerate remediation, and focus effort on the vulnerabilities that matter most.
Base is CVSS, Risk is EPSS (or equivalent), and Context captures data sensitivity, system criticality, OS lifecycle, vulnerability density, and age.
One CVE. Two assets. Different risk.
routine → emergency
start where you are
Traditional severity models miss the business.
Most vulnerability programs still rely on static scores like CVSS or broad assumptions such as "our EDR will catch it." Those signals are important, but on their own they don't answer the questions that matter most to the business: How likely is this to be exploited? and What happens to our data, operations, and compliance posture if it is?
CVSS: impact, no likelihood
Generic technical severity. Doesn't know which systems face the internet, store PHI/PII, or sit on critical business workflows. Thousands of "critical" findings hide the handful you need to fix first.
EPSS: likelihood, no impact
Data-driven exploit probability: "Will this be exploited in the next 30 days?" Still generic. Doesn't know where the asset lives, what data it holds, or what breaks if it goes offline.
Risk = likelihood × impact
ISO 31000 and NIST already treat risk this way. VRM 3.0 applies the same principle to vulnerabilities by combining CVSS (impact), EPSS (likelihood), and asset context into one dynamic score.
No model is perfect. Remapping keeps humans in the loop.
VRM 3.0 cuts noise and aligns prioritization with business risk. No algorithmic model is flawless, though. Outliers exist in every environment. A mature vulnerability management program includes a review process for the edge cases the model misses.
When models miss critical context
No model predicts every scenario. Think MS08-067 or Log4Shell: widespread, under active exploitation, devastating. Yet EPSS can initially score them at 1–2% because threat intelligence lags behind the attack. Your team knows the landscape. When VRM gets it wrong, you remap.
Two remapping modes
- Full override. Fixed criticality, no modifiers applied. Use when you're confident of the risk level regardless of context.
- Partial override. New base score, modifiers still layered per system. Use when the base is wrong but context still counts.
Document every override. Review periodically. Feed lessons back into the model.
When findings lack a CVE
Misconfigurations, internal flaws, and vendor-specific advisories often lack CVSS or EPSS. When either input is missing, the base calculation can't run. Fall back to tool-native severity and apply context modifiers on top. These scores land higher by design: without exploit-probability data, the model errs on the side of caution.
Recommended handling
- Use tool-native severity as the starting criticality. Most scanners and DAST/SAST tools assign their own levels.
- Apply Stage 1 context modifiers on top. Business context still matters without a CVE.
- Flag for internal analysis. These findings often need static remapping (full or partial override).
- Transition to full VRM scoring as data becomes available. See the full non-CVE deep dive.
VRM makes the impossible manageable
No team patches everything. Treat all "critical" findings the same, or lean on vendor severity alone, and the queue wins.
VRM 3.0 doesn't promise perfection. It promises consumability: a shorter queue, a clear first fix on each asset, and effort aimed at the vulnerabilities most likely to bite. Remapping handles the outliers. You get both algorithmic efficiency and human judgment.
The Vulnerability Risk Model (VRM) 3.0
VRM 3.0 orchestrates existing inputs. It takes CVSS and EPSS, layers on business context, and returns a criticality score for each vulnerability on each system that reflects how your organization operates.
Core equation- Base (CVSS): technical severity (0–10). OWASP or equivalent scores can substitute.
- Risk (EPSS): probability of exploitation in the next 30 days (0–100%). Other threat-informed sources can substitute.
-
Context Modifier: additive modifiers reflecting how this specific system is used.
Suggested +1 per factor; tailor to your risk tolerance.
Common context factors
- Presence of PHI, PII, or other sensitive data
- System business criticality and dependencies
- OS end-of-life status
- Vulnerability density on the asset
- Age of the vulnerability in your environment
A dynamic score. It changes as your assets, your data, and the threat landscape change. No static label frozen the day the CVE was published.
Base calc
+ Context
+ Age
CVSS × EPSS = Base Risk
Multiply CVSS Base by EPSS likelihood for a risk-informed criticality score. No CMDB needed. Your vulnerability scanners already expose both values.
Context modifiers
Layer in business context from your CMDB for each factor that applies. Suggested: +1 per factor. Tailor to your environment (some teams bump an entire criticality level for externally facing systems).
- +1 if the system processes PII, PHI, or sensitive data
- +1 if externally facing
- +1 if running on End-of-Life OS
- +1 if vulnerability density is high (5+ CVSS Base ≥ 5.0)
Why transparency matters
Document which factors contributed to each score. When owners can see why their system scored higher than the one down the hall, they have reason to keep your CMDB accurate.
Age modifiers
Add CVE age to pressure "forever findings" out of the backlog. Start: +1 per decade the CVE has existed. Goal: +1 per year. Long-lived vulnerabilities climb the priority list on their own, so the backlog stops hiding them.
Why VRM 3.0 adds two levels beyond Critical
In most organizations, "Critical" means wake someone up on a Saturday. IT teams hear "Critical" and think incident response, all-hands-on-deck, drop everything. But traditional vulnerability scoring uses "Critical" for findings that carry a 15-day SLA. Hardly an emergency. That disconnect erodes trust: when everything is critical, nothing is.
VRM 3.0 solves this by expanding the scale with two additional levels above Critical. This lets organizations map vulnerability urgency directly to their existing business-impact tiers without redefining what "Critical" means to IT operations.
Risk moves with your business
Risk is not static. A vulnerability that looked harmless last quarter may become critical today because:
- An app starts processing PHI/PII because a new feature or AI initiative went live.
- An OS hits end-of-life and loses vendor support.
- Attackers start chaining a once-obscure CVE, and EPSS jumps.
VRM 3.0 tracks this. As context and threat signals change, so does the criticality score.
Rethinking SLAs for dynamic risk
Static SLAs assume severity never changes. VRM 3.0 scores fluctuate, so should your SLA clock. Instead of fixed deadlines, let the clock tick faster at higher criticality:
- Critical (1.0×): 1 calendar day = 1 SLA day
- High (0.5×): 2 calendar days = 1 SLA day
- Medium (0.25×): 4 calendar days = 1 SLA day
- Low (0.1×): 10 calendar days = 1 SLA day
Set a universal threshold (e.g., 20 SLA days). A vulnerability that moves between Medium and Critical accumulates time in proportion to each state. No retroactive punishment. No benefit to waiting for scores to drop.
Try it: use the SLA Clock Calculator to model both time-weighted clocks and grace-period approaches. The VRM Calculator also shows traditional static SLA benchmarks for comparison.
VRM 3.0 rewards the habits you already want.
VRM 3.0 is a set of habits wrapped in math. The context modifiers reward the practices security, IT, and application teams already want: good inventory, clean architectures, and prompt closure of long-lived risk.
Less noise, clearer first moves
- Fewer "critical" findings that aren't urgent
- Clearer guidance on what to fix first on each asset
- Tighter alignment with business outcomes: data protection, operational continuity, and compliance (HIPAA, PCI DSS, FedRAMP)
System owners stop drowning in dashboards. They see a prioritized list of what to fix first.
Good habits, built into the model
Context modifiers nudge teams toward mature behaviors:
- Data classification. Where PHI/PII lives starts driving risk directly.
- Asset and app inventory. You can't assign criticality without knowing what depends on a system.
- Lifecycle management. EOL OS and high vuln density raise risk, so modernization pays off in lower scores.
- Timely remediation. Stage 2 age modifiers make "forever findings" more expensive to keep around.
Ready to implement VRM 3.0?
Start with Stage 0 today. Most vulnerability management platforms already expose CVSS and EPSS; you multiply the two. Stage 1 adds suggested context modifiers from your CMDB (use what you have, and tune the values to your environment). Stage 2 adds age-based modifiers for mature teams.
We'll publish follow-on guidance for Stage 1 (context modifiers) and Stage 2 (age modifiers) as organizations adopt and refine their implementations.