If severity alone is not enough, what should you look at instead? In practice, six signals do most of the work of separating real risk from noise.
1. Exposure and reachability
Is the affected system reachable from the internet, a partner connection or a commonly compromised internal zone — or is it blocked by firewalls and segmentation? An unreachable flaw is not harmless forever, but it is rarely today's emergency.
2. Exploitability
Is there a known, practical way to exploit the flaw, and is the vulnerable component actually loaded and used by the application? A dependency that is installed but never called is a very different risk from one on the hot path.
3. Business criticality
Does the asset support a critical service, hold sensitive data or sit in production rather than test? The same weakness matters more on the system that takes customer payments than on a developer sandbox.
4. Compensating controls
Do existing controls — access restrictions, configuration hardening or network rules — already reduce the risk? Recognising them prevents duplicated effort, and documenting them makes the decision defensible.
5. Attack paths
Could the weakness be chained with others to reach high-value systems, even if it looks minor on its own? This is the signal that stops context-aware prioritisation from becoming complacent.
6. Ownership and change risk
Who owns the asset, what change windows apply and how safely can a fix be rolled out? A fix nobody can approve, or that will break a fragile service, is not really a fix yet.
Why all six
Each signal on its own can mislead. Reachability without attack paths misses chained risk. Exploitability without business criticality over-weights test systems. Together they give you a ranking that is short, explainable and hard to argue with — which is exactly what you need to get changes approved.