Finding Severity

What finding severity means

Finding severity is a prioritisation label, not a verdict. It tells readers how serious an issue is likely to be in context, usually by comparing the issue’s expected impact against other findings from the same audit, assessment, or review. The label helps teams sort work, but it does not by itself establish exploitability, scope, or business consequence.

That distinction matters because two findings can look similar on paper while carrying very different operational consequences. A severe label may reflect likely blast radius, control weakness, or exposure, while a lower label may still deserve attention if it sits on a critical path, affects many systems, or combines with other weaknesses.

How severity differs from impact, likelihood, and exploitability

Severity is often used as a shorthand for risk ranking, but it is not the same thing as risk itself. Impact describes what could happen if the issue is abused or left unresolved. Likelihood describes how probable that outcome is. Exploitability describes how feasible abuse would be given the current environment, exposure, and controls.

A finding can be rated high severity because the potential impact is large even when exploitation is not proven. Conversely, a finding can be technically exploitable yet still receive a moderate label if the likely effect is narrow or well contained. This is why severity should be read as a triage signal, not as a full risk assessment.

In practice, organisations get into trouble when they treat severity as a substitute for evidence. A label can speed decision-making, but it cannot answer whether an attacker can reach the weakness, whether compensating controls reduce exposure, or whether the issue meaningfully changes business risk.

Why severity scales vary across tools and teams

There is no single universal severity scale for all audits, scanners, or assurance functions. Some teams use four or five bands such as Critical, High, Medium, and Low, while others add Informational or Uncertain to capture findings that need review but not immediate remediation. The same label can therefore mean slightly different things depending on the methodology behind it.

That variability is why severity should always be interpreted with its scoring rules, scope, and assumptions. A severity model that weights external exposure, privilege, or data sensitivity will produce different outcomes from one that focuses mainly on control design or compliance gap. Without that context, readers may over-read the label or compare findings from different sources as if they were identical.

Clear severity definitions also improve handoff between auditors, engineers, and business owners. When teams know what a label does and does not mean, they can avoid false urgency on low-consequence issues and avoid complacency on findings that look mild but sit in a sensitive part of the environment.

How to use severity in remediation decisions

Severity is most useful when it sits inside a broader triage model. The best remediation decisions combine the severity label with asset criticality, exposure, control coverage, and the likely downstream effect of delay. That approach helps teams fix the right issues first rather than simply fixing the loudest ones.

For example, a medium finding on an internet-facing system may merit faster attention than a high finding on a tightly isolated asset with strong compensating controls. Likewise, repeated medium findings across many systems can indicate a systemic control gap that deserves priority over a single isolated defect.

Used well, severity becomes a common language between security and operations. It supports prioritisation, reporting, and escalation, but it works best when reviewers ask the next question: what is the actual consequence if this remains open?

Related resources from NHI Mgmt Group

• What do security teams get wrong about finding multiple low-severity vulnerabilities?
• Why do alert investigations need severity-based escalation instead of sending every finding to the SOC?
• When should teams re-evaluate severity after finding an initial bypass or SSRF?
• What is the difference between finding an AI agent and governing it?