Severity scores are one of the most useful tools in vulnerability management. They are also one of the most misused. The mistake is simple: treating severity as if it were priority.
What severity actually measures
A severity score describes the potential impact of a flaw in a generic setting. It is deliberately environment-neutral, so that the same score can be published once and used by everyone. That is its strength — and its limit. It cannot know whether the flaw is reachable in your network, whether the vulnerable code runs in your application, or whether the asset matters to your business.
What priority should measure
Priority is a local decision: given everything we know about our environment, what should we fix first to reduce the most risk? Severity is one input. Reachability, exploitability, business criticality, compensating controls and attack paths are the others.
The symptoms of confusing the two
- SLAs that are routinely missed because the "critical" bucket is too large to clear.
- Teams that are visibly busy while exposure on key services barely moves.
- Application owners who stop trusting security tickets because too many turned out not to matter.
A better ordering
Keep severity, but put it in its place. Rank first by whether an issue is reachable and exploitable in your environment, then by business impact, then by severity as a tie-breaker. Record why each item sits where it does. The result is a shorter queue, faster action on what matters and a ranking you can defend in front of a risk committee.