48,185
CVEs Published
in 2025
~6%
Actually Exploited
in the Wild
5 Days
Avg Time-to-
Exploit
55 Days
MTTR for
Exploitable Vulns
$4.88M
Avg Breach Cost

Your security team is patching as fast as they can. They're working down the list - CVSS 9.8s first, then the 9.0s, then the 8.5s. It feels logical.

Here's the problem: most of those "critical" vulnerabilities will never be exploited. And while your team burns through them, the ones attackers are actually using sit in the queue.

In 2025, 48,185 new CVEs were published - a 20% increase from 2024's 39,962.

Security teams can realistically remediate a fraction of their vulnerability backlog. The rest sits in the queue, aging.

Meanwhile, the window for exploitation keeps shrinking.

In 2021, the average time-to-exploit was 32 days. By 2025, it's down to 5 days.

Attackers are faster, more automated, and they're not waiting for you to work through your CVSS-sorted list.

What's Actually Happening

Your current approach relies on CVSS scores - a technical severity rating that measures how bad a vulnerability could be in a perfect attack scenario. A CVSS 9.8 means this is theoretically very dangerous.

But CVSS doesn't tell you:

  • Is this vulnerability on a system that matters to your business?
  • Are attackers actually exploiting it in the wild?
  • Is it even exposed in a way that's exploitable in your environment?

The result: Your team treats every high-CVSS finding as urgent, regardless of actual risk.

The Real Cost

Security analysts spend roughly 60% of their time remediating vulnerabilities that pose minimal actual risk.

For a three-person team on $130K each fully loaded, that's roughly $235K a year chasing vulnerabilities that will never be exploited - while the CVSS 7.5 on your customer-facing payment server, the one attackers are actively exploiting, sits in the queue for weeks.

When those missed vulnerabilities get hit, the average breach costs $4.88 million (IBM, 2024). Not because you didn't scan. Because you fixed the wrong things first.

A Recent Example

In December 2021, Log4Shell (CVE-2021-44228) hit with a CVSS score of 10.0 - maximum severity. Every organization started emergency patching. But a CVSS 10.0 meant very different things depending on where it lived:

CVE-2021-44228 Log4Shell — Remote Code Execution
10.0CVSS
E-commerce Platform
Customer-facing · $5M/mo revenue
Internet-facing Public API Payment data Asset: 5/5
CRITICAL
SLA: 24 hours
CRM System
Internal · Customer data
Internal only Customer PII SaaS-hosted Asset: 4/5
HIGH
SLA: 7 days
Internal HR System
Internal · No external access
Internal Only Employee PII On-premise Asset: 3/5
MEDIUM
SLA: 30 days
Dev Sandbox
Isolated · No sensitive data
Isolated No prod data Ephemeral Asset: 1/5
LOW
SLA: 90d / Accept
Same CVSS 10.0 · Same CVE · Four different business risk levels · This is risk-based prioritization.

The pattern: CVSS tells you the severity. It doesnt tell you which systems you cant afford to lose.

What Risk-Based Prioritization Actually Means

Risk-based vulnerability prioritization isn't a new tool. It's a methodology that adds context to vulnerability data you already have.

Instead of asking 'how severe is this vulnerability?' you ask 'what's the actual risk to my business if this gets exploited?'

That question breaks down into three factors.

Factor 1: Business Context

Not all systems are equal. A critical vulnerability on your test environment is annoying. The same vulnerability on your payment processing system could shut down revenue.

Criteria
What to consider
Example
Revenue contribution
Does it generate or support revenue?
Direct revenue generation, transaction processing, or business operations that stop if this system goes down
E-commerce platform processing $5M/month 5/5
Internal HR system with no revenue impact 2/5
Business function dependency
Can the business operate without it?
How many processes, teams, or customers are blocked if this system is unavailable for 24 hours
Payment gateway down — business stops 5/5
Marketing site down — bad, not catastrophic 2/5
Data sensitivity
What's the worst-case data exposure?
Customer PII, financial data, health records, intellectual property, or regulated data subject to disclosure requirements
Customer payment data 5/5
Public marketing content 1/5
Operational continuity
What does downtime cost?
Hourly cost of an outage — including lost revenue, SLA penalties, manual workarounds, and recovery effort
Manufacturing controls — $100K/hour 5/5
Archive file share 1/5
Score every asset 1–5 using these criteria. Start with your top 20% by revenue contribution.

Factor 2: Exploitability

A vulnerability's technical severity (CVSS) tells you what's possible. Exploitability tells you what's probable.

CISA Known Exploited Vulnerabilities (KEV): This is a catalog maintained by the U.S. Cybersecurity and Infrastructure Security Agency of vulnerabilities confirmed to be exploited in the wild. If a CVE is on the KEV list, attackers are actively using it. Treat every KEV entry as urgent.

Exploit Prediction Scoring System (EPSS): EPSS uses machine learning to predict the probability that a vulnerability will be exploited in the next 30 days. Scores range from 0% to 100%.

EPSS Score — Probability of exploitation in next 30 days
>40%
High Likelihood
Treat as urgent
10–40%
Moderate
Prioritize by asset criticality
<10%
Low Likelihood
Schedule or monitor
Why EPSS over CVSS alone? Same exploit coverage, 8× less effort
CVSS 7+ strategy — CVEs to patch 50.7%
50.7% of all CVEs
EPSS v4 strategy — CVEs to patch 6%
Source: EPSS v4 / FIRST, March 2025

CVSS asks "how bad could this be?". EPSS asks "how likely?".
Combining both provides the foundation for risk-based prioritization.

Factor 3: Environmental Context

A high-severity vulnerability on a critical asset can still be lower risk if attackers can't reach it to exploit it.

It is determined by these factors:

Factor
What it affects
Examples
Network exposure
Can attackers reach it?
How easily an attacker can route to the vulnerable service from outside your perimeter
Internet-facing
Internal network only
Isolated network
Access requirements
What does an attacker need?
The prerequisites an attacker must have before they can exploit the vulnerability
No authentication required
Requires valid credentials
Requires physical access
Compensating controls
What's already protecting it?
Existing protections that reduce the likelihood or impact of successful exploitation
WAF protecting the service
Network segmentation
Intrusion detection
Multi-factor authentication

Financial Impact of Risk-Based Prioritization

Your current CVSS-only approach has two major cost drivers: wasted effort on vulnerabilities that don't matter, and missed threats on systems that do.

Here are real implementation results from a mid-sized financial services company.

Real Implementation: 90-Day Results
Mid-size Financial Services · 2,500 employees
Metric
Before RBVM
After RBVM
Change
Backlog
4,200 findings
240 high-risk
94% ↓
MTTR (critical)
38 days
6 days
84% ↓
Attack surface
Baseline
68% reduction
68% ↓
Audit prep
120 hours/cycle
40 hours
67% ↓
Team size
4 analysts
4 analysts
Same
Same team, measurably better outcomes.

What Implementation Actually Looks Like

RBVM isn't a software purchase. It's a process change using data you already have.

Timeline: 30-90 days depending on organization size.

Phase 1 Wk 1–3
Business Context
  • Identify crown jewels
  • Score: revenue, dependency, data sensitivity, business continuity
Phase 2 Wk 3–5
Data Integration
  • Integrate CISA KEV
  • Utilize EPSS v4 scores
  • Connect with CMDB
Phase 3 Wk 5–8
Score & Define SLAs
  • Classify assets into risk tiers: Critical / High / Medium / Low
  • Set SLAs: 24hr / 7d / 30d / 90d
  • Remediate Critical/High
  • Measure MTTR against new SLAs
Phase 4 Wk 8–12
Operationalize
  • Automate assignment by risk tier
  • Establish risk-based reporting
  • Train team on new prioritization workflow
  • Define risk acceptance and exception process
Who: Security + Business
Who: Security Engineering
Who: Security + IT Ops
Who: Security + IT + Leadership

Getting Organizational Buy-In

RBVM requires alignment across multiple stakeholders.

CISO
Cares about: Risk reduction
"How does this improve our security?"
Board
Cares about: Risk and Liability
"How does this reduce our liability?"
CFO
Cares about: Budget efficiency
"What does this cost?"
Show them:
  • Risk reduction on critical assets
  • Lower MTTR for critical vulnerabilities
  • Audit-ready remediation evidence
Show them:
  • Formalized prioritization framework with defined reporting cadence
  • Risk acceptance process with board visibility and exception tracking
  • Direct alignment with SEC, EU DORA, and NIS2 requirements
Show them:
  • Process change using existing tools and team — not a new purchase
  • Measurable reduction in remediation costs
  • Lower audit prep costs and stronger insurance posture

Why Boards Are Starting to Care

Three regulatory developments are pushing vulnerability management up the board agenda.

  • SEC cybersecurity disclosure rules require documented risk management processes - CVSS-only triage is hard to defend as mature methodology.
  • EU DORA (January 2025) requires vulnerability handling proportionate to business risk, not just technical severity.
  • NIS2 expands this across essential and important EU entities, with fines up to €10M or 2% of global turnover.

Quick Assessment

Is Your Vulnerability Programme Risk-Based?
Answer five questions. Get your score instantly.
1
Can you identify which 20% of your assets generate 80% of revenue or hold your most sensitive data?
2
Does your remediation SLA differ based on whether a vulnerability is internet-facing vs internal, or on a payment gateway vs a test server?
3
Do you use CISA KEV or EPSS data to decide which vulnerabilities get patched first?
4
Could your team explain to an auditor why they patched vulnerability A before vulnerability B using business risk — not just CVSS?
5
Can you report to the board the % of exploitable vulnerabilities on revenue-critical systems — not just total open findings?
Answer all five questions to see your result

Final Thoughts

Your team already knows the backlog is unwinnable. They've known for years. What they're waiting for is a clear mandate: to stop treating every vulnerability equally, and to focus on what actually threatens the business.

That's a leadership decision, not a technical one.