Let’s say you run a vulnerability scan and it finds 100 issues across your environment.
-
Ten are labeled critical
-
Fifteen are high
-
Twenty are medium
-
The rest are low or informational
The report helpfully tells you to fix everything immediately.
This is where reality kicks in.
Most organizations cannot patch every vulnerability the moment it is discovered. Resources are finite. Systems cannot always be rebooted. Business operations still matter. In practice, this leads many teams to prioritize vulnerabilities strictly by severity. Critical first. Then high. Then medium.
That approach feels rational, but it often misses real risk.
So how do you actually prioritize?
The answer starts by moving beyond severity scores and focusing on real-world risk.
Start With Exposure
Vulnerability severity, including CVSS scores, provides a rough indicator. It does not tell the whole story.
A medium-severity vulnerability on an Internet-facing system is often more dangerous than a critical vulnerability buried inside a segmented lab environment.
Start triage by looking at exposure.
Internet-facing systems
If a system is reachable from the Internet, it should always be near the top of the list. Public exposure means attacker exposure.
Internal systems with broad access
Shared file servers, identity systems, and intranet applications. If many users can access it, it can quickly become a launchpad for lateral movement.
Systems with sensitive data
Even with limited exposure, the impact of compromise can be severe. Think HR systems, financial platforms, R&D environments, or regulated data stores.
Exposure often matters more than severity.
Use the KEV List. It’s There for a Reason
The Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities (KEV) catalog. This list identifies vulnerabilities that are actively being exploited in the wild.
If a vulnerability appears on the KEV list, it should be treated as urgent.
Patch it.
Mitigate it.
Isolate it.
Do not debate the CVSS score.
Adversaries do not rely on critical vulnerabilities alone. They exploit what is available, which is often what is left unpatched.
Attackers follow opportunity, not scoring systems.
Stop Thinking in Terms of Just CVSS
CVSS scores are theoretical. Attackers are not.
Many real-world intrusions begin with medium-severity vulnerabilities that are chained together. At the same time, some critical CVEs have never been exploited at all.
Instead of asking only “How severe is this?”, ask better questions:
-
Is it being actively exploited?
-
Is it exposed?
-
What is the impact if it is compromised?
Risk lives at the intersection of exposure, exploitability, and impact.
A Practical Prioritization Model
Here is a simple structure that blends exposure, KEV status, and severity into something teams can actually act on.
In this model, sensitive data refers to vulnerabilities on systems that store or process sensitive information. Sensitive network segments refer to vulnerabilities on systems whose network position enables broader access or lateral movement.
| Priority | What It Means |
|---|---|
| P1 | Internet-facing system with a known exploited vulnerability (KEV), regardless of severity |
| P2 | Internet-facing system without a KEV, but with critical, high, or medium severity findings |
| P3 | Internal system containing sensitive data with a known exploited vulnerability (KEV) |
| P4 | Internal system in a sensitive network segment without known exploitation |
| P5 | Internal system with limited access and a known exploited vulnerability (KEV) |
| P6 | Any system without known exploitation and medium severity vulnerabilities |
| P7 | Any system without known exploitation and low or informational findings |
| P8 | No meaningful exploitability or risk. Informational noise. |
Final Thoughts
Vulnerability management does not have to be overwhelming, but it does have to be intentional.
Focus on what actually matters:
-
What is exposed?
-
What is being exploited?
-
What creates real risk to the business?
Patch with purpose.
Reduce noise.
And sleep better at night.
I will share more details on this approach in future posts. When I originally developed this model, I also built a set of simple prioritization calculators to help translate scanner output into actionable remediation tasks. The P1–P8 framework is a basic component of that work.
I will revisit those calculators, refine them, and share updated versions as part of a deeper series on practical vulnerability management. The goal is not more dashboards, but better decisions.
Stay tuned.