RBVM Guide

Risk-Based
Vulnerability Management

The complete guide to moving from vulnerability noise to business risk clarity — and why it's now required by NIS2, DORA, and ISO 27001.

What is Risk-Based Vulnerability Management?

Risk-Based Vulnerability Management (RBVM) is a disciplined approach to prioritising which vulnerabilities to fix first — based on the actual risk they represent to your business, not just their raw technical severity.

Traditional vulnerability management programs generate thousands of findings every month. When everything is ranked by raw severity scores like CVSS, nearly everything looks critical. Security teams get overwhelmed, patch fatigue sets in, and the genuinely dangerous vulnerabilities get buried.

Centraleyezer takes a different approach. Instead of relying on generic, internet-wide signals like CVSS or EPSS, it scores each finding using DREAD, the asset's criticality to the business, the asset's network exposure, exploitability, CTI signals, and a Human-AI feedback loop that learns from how quickly the asset's owner actually responds to findings. The result is a ranked list where the top 10% of findings represent 80%+ of your actual risk — based on your environment, not the internet's average.

Traditional VM vs. Risk-Based VM

Traditional VM

  • Ranks by raw severity (e.g. CVSS) alone
  • Thousands of "critical" findings
  • No business or operational context applied
  • Teams overwhelmed, nothing gets fixed
  • Compliance evidence manual and fragmented
  • Asset inventory often stale or incomplete

Risk-Based VM (RBVM)

  • Contextual risk score: DREAD + asset criticality + network exposure + exploitability + CTI + Human-AI feedback
  • Top 10% of findings drive 80%+ of risk
  • Business and operational context built into scoring
  • Clear prioritised remediation queue
  • Automated compliance evidence collection
  • Continuous asset discovery and criticality scoring

How Centraleyezer's contextual risk scoring works

Centraleyezer calculates a contextual risk score for every vulnerability by combining six factors that describe the finding, the asset it lives on, the threat landscape, and the people who own remediation:

Note: CVSS, EPSS, and CISA KEV are deliberately not used as scoring inputs — they describe internet-wide severity or exploitation probability, not the actual risk to your specific environment. CVE/CWE data is still ingested for traceability and reporting.

DREAD Score

Damage, Reproducibility, Exploitability, Affected users, Discoverability — a structured threat-modelling score that captures the inherent severity of the finding in a way that maps to real attacker behaviour.

Asset Criticality

Business importance of the affected asset — set per asset, from low to critical. The same finding on a payment-processing host scores higher than on a developer sandbox.

Network Exposure

Where the asset lives in your network — internet-facing, DMZ, internal, or fully isolated. An exposed asset elevates the risk of every finding it carries.

Exploitability

How practical it is for an attacker to actually weaponise the finding given your asset configuration — not a generic probability across the whole internet.

CTI Signals

Cyber threat intelligence about the finding and the asset technology — relevant active campaigns, threat actors, and targeting context drawn from CTI feeds.

Human-AI Reaction Loop

Centraleyezer learns from how the asset owner actually responds: acknowledgement time, remediation time, and risk-acceptance patterns. Slow-responding owners raise the operational risk of their assets; fast-responding owners lower it.

RBVM is now a regulatory requirement

European regulations have made structured vulnerability management mandatory for many organisations. Here's what each framework requires:

NIS2

Article 21 mandates "vulnerability handling and disclosure" as one of the 10 minimum security measures. Organisations must have a documented, risk-based process.

How we cover it →
DORA

Article 9 requires "ICT risk management" including vulnerability scanning, risk assessment, and documented remediation processes with SLAs for financial entities.

How we cover it →
ISO 27001

Annex A control A.8.8 (Vulnerability Management of Technical Vulnerabilities) requires a systematic approach to identifying and remediating weaknesses.

How we cover it →
PCI-DSS v4

Requirement 6 mandates timely patching of vulnerabilities, with specific SLAs for critical (1 month) and high (3 months) severity findings.

How we cover it →

Frequently asked questions

What is Risk-Based Vulnerability Management (RBVM)?

RBVM is an approach to vulnerability management that prioritises remediation efforts based on the actual business risk each vulnerability poses — rather than treating every CVE with the same urgency. Centraleyezer combines DREAD scoring, asset criticality, the asset's network exposure, exploitability, CTI signals, and a Human-AI feedback loop that adapts risk based on the asset owner's reaction time, producing a contextual risk score per finding.

How is RBVM different from traditional vulnerability management?

Traditional VM ranks vulnerabilities by raw severity (typically CVSS), which leads to thousands of "critical" findings that overwhelm security teams. RBVM adds business and operational context: how critical is this asset? Is it internet-exposed or isolated? Has the owner historically responded fast or slow to similar findings? This narrows the list to the vulnerabilities that genuinely threaten your business.

Does Centraleyezer use CVSS, EPSS, or CISA KEV in its risk scoring?

No. Centraleyezer's contextual risk score is built from DREAD, asset criticality, the asset's network exposure, exploitability, CTI (cyber threat intelligence) signals, and a Human-AI feedback loop. CVSS, EPSS, and active-exploitation feeds (such as CISA KEV) are deliberately not used as scoring inputs — they reflect generic technical severity or exploitation probability across the whole internet, not the actual risk to your environment. CVE/CWE data is still ingested for traceability, but the prioritisation comes from the contextual model.

Does RBVM help with NIS2 compliance?

Yes. NIS2 Article 21 explicitly requires organisations to implement "vulnerability handling and disclosure" as a technical security measure. A risk-based approach demonstrates that you have a structured, documented process for identifying, prioritising, and remediating vulnerabilities — which is exactly what NIS2 auditors look for.

What is the "Human-AI" component in Centraleyezer's scoring?

Risk scores are not static. Centraleyezer learns from how each asset owner actually reacts: how quickly findings on their assets get acknowledged, remediated, or accepted. An asset owned by a slow-responding team is treated as a higher operational risk than the same asset owned by a fast-responding team — even when the underlying vulnerability is identical. This gives security leaders a more realistic picture of where risk really sits in the organisation.

How quickly can we implement RBVM?

With Centraleyezer, you can connect your existing vulnerability scanners, import your asset inventory, and see risk-prioritised findings within hours. No rip-and-replace of your existing tools is required.

Is RBVM suitable for small security teams?

Especially so. Small teams cannot act on every vulnerability — RBVM tells them exactly which 5–10% of findings represent 80%+ of their actual risk, making limited resources dramatically more effective.

Ready to implement RBVM?

Book a personalised demo and see how Centraleyezer maps to your specific compliance requirements.

What is Risk-Based Vulnerability Management (RBVM)? | Centraleyezer