Home / Knowledge hub / Risk-based prioritisation
Knowledge hub
Risk-based prioritisation
Ordering fixes by real-world risk, not just by the raw severity score.
What it means
Risk-based prioritisation means deciding what to fix first by weighing how likely a flaw is to be used, how much it would cost you if it were, and how exposed the affected system is. A raw CVSS score is one input. It is not the answer on its own.
The idea is simple. A list sorted by severity treats a critical flaw on a forgotten test server and a critical flaw on your payment API as equals. A risk-based list does not. It asks what is reachable, what data sits behind it and whether anyone is using the flaw.
Why it matters
Every team has more findings than hours. If fixing order follows the score only, effort goes to the loudest numbers, and a modest-looking flaw that exposes customer data waits. Prioritising by risk puts the same hours against the problems most likely to cost you money, customers or a failed audit.
It is also easier to defend. When you can say that a fix came first because the flaw was reachable from the internet, held personal data and appeared on the CISA known exploited list, leadership and auditors can follow the reasoning and challenge it.
How it shows up
In practice you combine a few signals: severity, likelihood from sources such as EPSS, whether the asset faces the internet, how sensitive its data is, and whether a working exploit has been shown. Some teams use a simple weighted rule. Others use the SSVC decision tree, which ends in a plain action such as act or track.
The mistakes are over-engineering the formula before anyone trusts the inputs, and ignoring evidence from your own system. A flaw that testing has shown can be exploited against your running app outranks one that only looks possible. Keep the rule short enough that everybody can explain it.
Questions people ask
Risk-based prioritisation, answered
What is the difference between severity and risk?
Severity describes how bad a flaw is in itself. Risk adds context: how likely it is to be used and what it would cost you in your situation.
The same flaw can carry high severity and low risk, or the reverse, depending on where it sits.
What factors go into risk-based prioritisation?
Common ones are severity, exploit likelihood, whether the asset is exposed, how sensitive its data is, and whether a working exploit exists.
Business importance of the system also counts, such as whether it takes payments.
Is risk-based prioritisation the same as SSVC?
SSVC is one method for it. It uses a decision tree with inputs such as exploitation status and mission impact, and ends in an action.
You can also build your own rule from the same ideas. The principle is the same.
Does it mean low-severity findings are ignored?
No. They are scheduled later, not dropped. A low finding can become part of a chain that is much worse.
Review the lower queue regularly so it does not become a graveyard.
How do I start without special tools?
Add two columns to your findings list: is it reachable from outside, and what data does it touch. Sort by those before severity.
Even this crude step usually changes the top of the list.
Sources
Where this comes from
Related
Terms that sit next to this one
SSVC
A decision tree that tells you whether to act on a vulnerability now or later.
Exploitability
How easily and reliably a flaw can be used in practice.
Vulnerability backlog
The growing list of known flaws a team has yet to fix.
Attack path
A chain of small steps that together take an attacker to something valuable.
Business impact
What a flaw would cost in money, customers, uptime or trust if used.
Which finding do you fix first?
Our findings keep severity and confidence apart, and carry proof of what was exploited, so the order of fixes can follow evidence instead of guesswork. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.