Prioritising vulnerabilities by real risk
In short: There are always more vulnerabilities than time to fix them. Risk-based prioritisation focuses effort on flaws that are being exploited, are reachable by attackers and affect important systems, rather than simply working down the list of highest CVSS scores.
Why CVSS alone is not enough
A typical organisation's scanners report thousands of open findings, and a large share are rated high or critical. Teams cannot fix them all at once. If you simply sort by CVSS base score, you may spend weeks on severe-sounding flaws that nobody exploits, while a medium-rated flaw on your VPN gateway is being actively used by ransomware groups. Risk-based prioritisation asks a better question: which of these is most likely to hurt us, and how badly?
The factors to weigh
- Active exploitation: is it on the CISA KEV list or reported in threat intelligence? This is the strongest single signal.
- Likelihood: EPSS estimates the chance of exploitation in the next 30 days; public exploit code also raises likelihood.
- Severity: the CVSS score describes what an attacker could achieve.
- Exposure: is the system reachable from the internet, from user networks, or only from an isolated management network?
- Asset value: does the system hold sensitive data, support critical services or control identity (such as a domain controller)?
- Compensating controls: is the vulnerable feature disabled, blocked by a firewall rule or watched closely?
Some organisations use the Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree promoted by CISA, which uses similar questions to reach one of a few actions such as "track" or "act".
A worked example
| Finding | CVSS | Exploited? | Exposure | Asset | Priority |
|---|---|---|---|---|---|
| VPN appliance flaw | 7.5 | Yes, on KEV | Internet | Remote access for all staff | Emergency: fix within days |
| Database server flaw | 9.8 | No, low EPSS | Internal server VLAN only | Customer data | High: next patch cycle, restrict access meanwhile |
| Browser flaw on kiosks | 8.8 | Exploit public | Users browse internet | Low value, isolated | Medium: normal monthly rollout |
| Printer web UI flaw | 6.5 | No | Isolated printer VLAN | Low value | Low: fix when convenient or accept |
Notice that the highest CVSS score is not first on the list.
Making it routine
- Tag assets with criticality and exposure in your inventory so the data is ready when findings arrive.
- Pull KEV and EPSS data into your scanner or ticketing tool automatically.
- Agree priority levels and due dates in policy (for example, emergency, high, medium, low).
- Record compensating controls with evidence, and review them when the environment changes.
- Look for one fix, many findings: a single upgrade can close hundreds of items.
Tip: compensating controls are temporary help, not a permanent excuse. Record an expiry date and still plan the real fix.
Practice
Why might a CVSS 7.5 flaw be fixed before a CVSS 9.8 flaw?
Name three factors besides CVSS used in risk-based prioritisation.
What should you record when you rely on a compensating control?
Key takeaways
- Sorting by CVSS alone wastes effort on flaws nobody exploits.
- Active exploitation (KEV) is the strongest signal of urgency.
- Weigh likelihood, severity, exposure, asset value and compensating controls.
- Tag assets with criticality and exposure in advance.
- Compensating controls are temporary and need review dates.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.