What do teams get wrong about scoring threat severity?

They often treat numeric scoring as objective even when the underlying assumptions vary between reviewers. A score only becomes useful when the team agrees on what damage, exploitability, and discoverability mean in its own environment and validates the result against business impact.

Why This Matters for Security Teams

Threat severity scoring influences triage, escalation, patch prioritisation, and executive reporting, so a weak score can distort decisions across the whole security programme. The main failure is assuming the number is neutral when it is really a judgement call built from local assumptions about impact, exposure, and confidence. That becomes more visible in AI-enabled environments, where an automated system may generate a plausible score without reflecting business context or attack path reality. Guidance from sources such as CISA cyber threat advisories is most useful when teams translate generic severity language into their own asset criticality and response thresholds.

The biggest mistake is treating severity as if it were a property of the vulnerability alone. In practice, the same finding can be low priority in one environment and urgent in another because identity trust, network placement, data sensitivity, and compensating controls all differ. Mature teams score the issue, then test whether the score still makes sense once the affected business service, exposure path, and likely attacker intent are added. In practice, many security teams encounter severity drift only after a noisy queue has already buried the issue they most needed to act on.

How It Works in Practice

A useful severity process starts by separating technical scoring from operational prioritisation. The technical score describes the weakness; the operational decision asks whether the weakness matters enough to interrupt normal work. That distinction is especially important when organisations use CVSS-like numbers as though they were a complete answer. Current guidance suggests combining the base score with environmental factors, asset value, exposure, and exploitability in the local context, rather than letting the base score drive response on its own.

Teams usually get better results when they define a small set of scoring inputs and apply them consistently:

• Damage potential: what business process, data set, or identity system is affected.

• Exploitability: whether the weakness is reachable, automatable, and already being abused.

• Discoverability: how easy it is for an attacker to identify the target and validate success.

• Control coverage: whether PAM, segmentation, alerting, or compensating controls reduce the real risk.

• Confidence: how much evidence supports the finding, especially for scanner-generated or AI-generated assessments.

In AI-heavy environments, scoring also needs to account for model behaviour, prompt injection potential, and downstream tool access. A severity label on an AI system is incomplete if it ignores whether the system can reach secrets, change records, or trigger actions through an agentic workflow. For that reason, teams increasingly cross-check vulnerability scoring with AI threat mapping such as the MITRE ATLAS adversarial AI threat matrix when the issue affects models, retrievers, or autonomous agents. Where AI-assisted tradecraft is relevant, reports like Anthropic on the first AI-orchestrated cyber espionage campaign show why exploitability can change quickly once attacker workflows become more automated. These controls tend to break down when teams mix scanner scores from multiple tools without a shared rubric because the same number then means different things in different queues.

Common Variations and Edge Cases

Tighter severity governance often increases review overhead, requiring organisations to balance faster triage against the cost of more human judgment. That tradeoff is unavoidable, and there is no universal standard for it yet. Some teams prefer strict formulas; others allow analyst override. The best practice is evolving toward calibrated scoring with documented exceptions, especially where the business impact is not captured by technical exposure alone.

Edge cases usually appear in three places. First, internet-facing issues are not always the highest priority if they sit behind strong identity controls and have no path to valuable assets. Second, a low-scoring issue may be operationally severe if it affects a crown-jewel service, a privileged workflow, or an AI agent with tool access. Third, exploitability can change after public disclosure or attacker automation, so the score should be revisited when threat conditions shift. Teams should also be careful not to let AI-generated prioritisation override analyst review, since model output can be persuasive even when it is only partially grounded in current evidence.

Practitioners should document when severity is being used as a triage aid versus a release-blocking criterion, and they should revisit that distinction during incident reviews. The key question is not whether the score looks precise, but whether it leads to the right action at the right time.

Related resources from NHI Mgmt Group

• What do security teams get wrong about threat detection in IAM?
• What do security teams get wrong about using AI agents for threat hunting?
• What do fraud teams get wrong about shared threat intelligence?
• What do security teams get wrong about vendor risk scoring?