Risk-Based Vulnerability Management: A Smarter Prioritisation Framework

Most vulnerability management programs still revolve around spreadsheets and CVSS scores. New CVEs appear, scanners flag them as critical, and patch teams race to reduce the number of reds on the dashboard.

In 2025, that approach is increasingly inadequate. CISA’s KEV catalog and commercial exploit data show that only a fraction of high-CVSS vulnerabilities ever see widespread exploitation. At the same time, some medium-scored flaws become key tools in attacker campaigns. Sonatype’s analysis of CVE submissions has also raised questions about the quality and consistency of severity scoring, pointing to potential over- and under-estimation across thousands of entries.

To make real progress, organisations need to move beyond CVSS alone and adopt a risk-based framework that aligns patching with actual business impact and adversary behaviour.

Why CVSS alone falls short

CVSS provides a useful, standardised way to describe technical severity. But it does not answer several critical questions:

• Is there a widely available exploit kit or active exploitation in the wild?
• Is the vulnerable system internet-facing or deeply buried in a test network?
• Does the system process sensitive customer data, or is it a low-value lab server?
• What compensating controls (segmentation, EDR, WAF) are already in place?

As a result, teams often:

• Spend large amounts of effort patching high-CVSS issues on low-risk assets.
• Miss exploited vulnerabilities that have moderate base scores but high real-world risk.
• Struggle to explain prioritisation decisions to business stakeholders in non-technical terms.

Risk-based vulnerability management addresses these gaps by incorporating exploitability, exposure and business value into prioritisation.

Key inputs for risk-based prioritisation

A pragmatic framework usually combines four categories of data:

1. Technical severity
   • CVSS v3.1/v4 base and temporal scores still matter, but they are one dimension.
2. Exploitability and threat intelligence
   • CISA KEV status and due dates.
   • Exploit Prediction Scoring System (EPSS) or vendor exploit probability metrics.
   • References in threat intel reports and incident write-ups.
3. Asset exposure and context
   • Internet-facing vs internal-only.
   • Presence in DMZs, OT networks or third-party connected zones.
   • Existence of mitigating controls (EDR, WAF, network segmentation).
4. Business criticality and data sensitivity
   • Mapping to critical business services and processes.
   • Data classification (for example, payment data, health data, trade secrets).
   • Regulatory implications if compromised.

DACTA Global’s Vulnerability Monitoring engagements align data from scanners with these contextual inputs to help clients turn long lists of findings into a small set of meaningful risk reduction actions.

Building a simple risk scoring model

You do not need a complex data science pipeline to get started. Many organisations begin with a composite score such as:

• Risk score = (CVSS band) + (exploitability band) + (exposure band) + (business impact band)

For example:

• CVSS 9.0+ → High
• Listed in KEV or EPSS probability above a defined threshold → High
• Internet-facing asset or accessible via partner networks → High
• Supports a critical business process or holds regulated data → High

A vulnerability that scores high in three or four of these dimensions becomes a top priority, even if its base CVSS is “only” 7.2. Conversely, a 9.8 in a fully isolated lab with no sensitive data and strong network controls might be deprioritised relative to more pressing issues.

Using KEV and exploit data as accelerators

CISA’s KEV catalog is one of the most actionable sources for risk-based prioritisation because it focuses on vulnerabilities with confirmed exploitation in the wild. Similarly, threat intelligence and vendor reports highlight which vulnerabilities attackers are actively using in campaigns.

Practical steps include:

• Automatically flagging any KEV-listed vulnerabilities in your scanner output as “must-fix” within the timeframes CISA recommends (often 2–3 weeks for federal agencies).
• Cross-referencing vulnerabilities in your environment with exploit probability scores from EPSS or vendor feeds.
• Subscribing to sector-specific advisories and mapping referenced CVEs to your inventory.

This keeps your patching backlog aligned with adversary interest, not just theoretical severity.

Embedding asset criticality into your process

To incorporate business impact effectively:

• Start with an application and service inventory, not just IP addresses.
• Classify assets into a small number of criticality tiers (for example Tier 0, Tier 1, Tier 2).
• Ensure your CMDB or asset database can link vulnerability findings to business owners and data classifications.

Common Tier 0 examples include:

• Identity platforms (Entra ID, on-prem AD).
• Backup and recovery systems.
• Key SaaS platforms and MFT appliances.
• Internet-facing portals connecting to core systems.

Vulnerabilities on Tier 0 assets almost always warrant higher urgency than identical vulnerabilities on less critical systems.

Operationalising risk-based vulnerability management

Moving from concept to practice requires changes in workflow:

• Scanning and data normalisation
  • Consolidate findings from multiple scanners into a single view.
  • De-duplicate issues and normalise names and CVEs.
• Prioritisation and assignment
  • Apply your composite risk score and automatically route top risks to the right application or infrastructure owners.
  • Set different SLAs based on risk bands, not just severity (for example, 7 days for “Critical Risk”, 30 days for “High Risk”).
• Exception handling
  • Document business or technical reasons for deferring remediation, along with compensating controls.
  • Ensure exceptions expire and are periodically reviewed.
• Board-level reporting
  • Report the number of open vulnerabilities above a certain risk threshold, not just total counts.
  • Show trends in risk reduction for Tier 0 and Tier 1 assets over time.

DACTA Global’s Ultimate Cybersecurity Toolkit for 2025 article highlights how integrating vulnerability data with risk management and governance processes can turn patching into a strategic function rather than an operational chore.

Common pitfalls to avoid

As organisations transition to risk-based approaches, several traps appear:

• Over-complicating the model. A scoring system that requires dozens of inputs and manual steps will not scale. Start simple and refine.
• Ignoring “boring” hygiene. Risk-based does not mean ignoring routine patching of widely used platforms like browsers, office suites and VPNs. These remain frequent entry points.
• Underestimating configuration issues. Vulnerabilities are only part of the story. Misconfigurations in SaaS, identity or network controls can undermine even aggressive patching strategies.
• Failing to involve application owners. Many critical vulnerabilities live in custom applications. Engaging dev and product teams early is essential.

Next steps for CISOs

A risk-based vulnerability management program does not need a complete rebuild of your tooling. You can start by:

• Identifying the ten to twenty most business-critical services and mapping their underlying assets.
• Flagging any KEV-listed vulnerabilities on those assets as immediate priorities.
• Defining a simple risk scoring rubric and testing it on a subset of your backlog.
• Aligning reporting with this new view, so executives see risk reduction rather than raw counts.

From there, you can refine models, integrate new feeds and automate more of the pipeline. Organisations that make this shift will find it easier to justify patching decisions, respond to emerging threats and demonstrate progress to stakeholders in a language they understand.

If you would like support designing or implementing a risk-based vulnerability framework, DACTA Global’s advisory and implementation teams can help translate these concepts into a workable operating model for your environment.