Fix in this order: vulnerabilities listed as known exploited, then anything exposed to the network or many users, then those with a high exploit probability score, then the rest by severity. CISA's KEV catalog and the EPSS score are free inputs for the first and third steps.
The problem with sorting by severity alone
A department with one or two sysadmins can face thousands of findings after a first scan. Severity scores describe how bad a flaw could be, not how likely anyone is to use it against you. Sorting only by severity sends effort to issues that may never be attacked.
You need a few extra signals, and they should be cheap.
Signal 1: known exploited
CISA describes its Known Exploited Vulnerabilities catalog as a list of vulnerabilities that have been exploited in the wild, and advises organizations to use it as an input to their vulnerability management prioritization framework. Entries carry a date added, a due date and whether the vulnerability is known to be used in ransomware campaigns.
CISA presents the catalog as one input, not the whole process. Use it as the top of your list: if something you run is in it, fix or isolate it first.
Signal 2: exposure
Ask where the system sits. Reachable from the internet or the whole campus? Used by hundreds of students? Holds sensitive or human subject data? A medium finding on an exposed system can outrank a high finding on an isolated one.
Signal 3: likelihood
EPSS, the Exploit Prediction Scoring System, is maintained by a special interest group at FIRST. It estimates the probability that a published CVE will be exploited in the wild in the next 30 days. Each CVE gets a value from 0 to 1 plus a percentile, published daily, and the data is free through downloads and an API.
Use it to break ties inside a group, not as an on and off switch. A low score is a probability, not a guarantee.
The working order
| Rank | Question | Action |
|---|---|---|
| 1 | Is it in the KEV catalog and do we run it? | Fix or isolate now |
| 2 | Is it exposed to the network or many users? | Fix this cycle |
| 3 | Is the EPSS score high? | Pull forward |
| 4 | Is it reachable in how we use the software? | Keep, otherwise defer |
| 5 | Everything else | By severity, in routine patching |
Make it routine
Pick one weekly slot of thirty minutes. Check new KEV additions against your inventory. Check the top EPSS scores in your findings. Patch or write down a decision. A short written decision protects you more than a long backlog does.
What to tell people who ask why something waits
Keep a one sentence reason for every deferral, for example: not reachable from the internet, no known exploitation, fix scheduled for the next maintenance window. When a researcher or a manager asks why a finding is still open, you can answer in seconds. It also helps the next person who inherits the queue to see that the order was a decision, not an accident.
Try it yourself
Open the exploitability check demo and see how adding exploit information changes which finding looks most urgent.
Click through it at your own pace, or open it full screen.
Safeguard's reachability analysis helps with rank four by showing whether vulnerable code is actually called. A free scan shows how that looks on a real project.
Quick check
Is a KEV entry always urgent for us?
Only if you run the affected product. Match entries against your inventory first.
Does a low EPSS score mean ignore it?
No. It is a probability for the next 30 days. Combine it with exposure and what the software holds.
Sources
Last reviewed: 19 October 2026.
