Risk Based Vulnerability Management: Fix What Attackers Can Actually Use
Risk based vulnerability management ranks your fixes by real-world threat and exposure, not by severity score alone. A severity score tells you how bad a flaw could be. It does not tell you whether anyone is using it, or whether it can reach your most important systems. This guide shows how to turn a long scan report into a short, defensible queue.
Why severity alone falls short
Most scanners report a severity score from the Common Vulnerability Scoring System, or CVSS. FIRST, the group that maintains CVSS, describes it as a way to capture the main characteristics of a vulnerability and produce a numerical score reflecting its severity. That score can be translated into low, medium, high and critical.
That is useful. It is also only one input. A severity score describes the flaw. It does not describe your environment, and it does not describe attacker behavior.
When a team sorts only by severity, two problems show up. The queue is huge, because many findings land in high or critical. And the queue is blind to context, so a critical finding on an isolated test system can outrank a high finding on an internet-facing server.
What risk based vulnerability management means
Risk based vulnerability management adds context to severity. For each finding, you ask three plain questions:
How likely is it to be exploited?
How exposed is the affected system?
How much would it hurt the mission if it were exploited?
The answers put findings in a different order. The goal is not to fix fewer things forever. The goal is to fix the right things first, and to be able to explain why.
A simple illustration
Imagine two findings. Finding A has a critical score, but it sits on an isolated lab system with no path from the internet and no sensitive data. Finding B has a high score, but it sits on an internet-facing server behind a customer-facing service, and it appears in the CISA Known Exploited Vulnerabilities catalog.
Sorted by score, Finding A comes first. Sorted by risk, Finding B comes first. Same scanner, same data, a very different queue. That difference is the whole point of the approach.
The signals worth combining
You do not need a complex model. Four signals cover most of the value.
Severity. Keep CVSS as the baseline. It is a published standard and your tools already report it.
Known exploitation. CISA maintains the Known Exploited Vulnerabilities catalog, which it describes as the authoritative source of vulnerabilities exploited in the wild. CISA also says organizations should use it as an input to their vulnerability management prioritization framework. A finding on that list moves up.
Exploit likelihood. The Exploit Prediction Scoring System, or EPSS, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. FIRST publishes a score from 0 to 1 for every CVE each day, free of charge. A high score is a reason to look sooner.
Asset context. This one comes from you, not from a feed. Is the system reachable from the internet? Does it hold sensitive data? Does a critical service depend on it? Your asset inventory and business owners supply the answers.
Build the queue in four steps
Start with the list. Pull findings from your scanners and match them to assets.
Tag each finding. Mark known exploited items, note the exploit likelihood, and add the asset's exposure and importance.
Set simple tiers. For example: fix now, fix this cycle, schedule, and accept with a note. Write the rules down so anyone can apply them.
Assign owners and dates. A ranked list with no owner is a report, not a plan. Each item needs a person and a target date.
Start with rules a small team can follow every week. You can sharpen them later.
Make the work visible to leadership
Leaders do not need a list of identifiers. They need to know which risks are open, which are shrinking, and what is blocking progress. Report trends in plain language: how many top-tier items are open, how long they have been open, and which ones need a decision. Keep the same measures month to month so progress is easy to see.
Common mistakes to avoid
Treating every critical score as an emergency.
Using a feed score without checking the asset it applies to.
Skipping the exceptions. When a fix is delayed, record who accepted the risk and until when.
Changing the rules every month, which makes trends meaningless.
Measuring effort instead of outcomes. Closed tickets matter less than reduced exposure.
Frequently asked questions
What is risk based vulnerability management?
It is a way of ordering vulnerability fixes using threat, exposure and business impact together, instead of relying on a severity score alone.
Does it replace CVSS?
No. CVSS stays as one input. Risk based vulnerability management adds exploitation data and asset context around it.
Do I need special tools to start?
No. You can begin with your scanner output, the free CISA KEV catalog, free EPSS data and a basic asset list. Tools can automate the steps later.
How often should the queue be reviewed?
Exploitation data changes daily, so review the top tier at least weekly and the full queue on a regular monthly cycle.
Next step
If your team has more findings than it can fix, a second set of eyes helps. KG Solutions can show you where your current process stands and what to change first.
If you want a clear view of where you stand, start with a vulnerability management maturity assessment. If you need steady help afterward, see our ongoing program oversight, continuous remediation support and other vulnerability management services.
Comments