What is the difference between severity and relevance in threat intel?

Why severity and relevance answer different operational questions

Severity tells you how serious a threat, vulnerability, or indicator is in the abstract. Relevance tells you whether that item matters to your environment, so the same intelligence can rank very differently depending on your assets, exposure, defensive controls, and adversary profile.

This distinction matters because severity is usually a property of the finding, while relevance is a property of the receiver. A feed item can be urgent in general but irrelevant if you do not run the affected technology, and a modest-looking indicator can be highly relevant if it touches a service, identity path, or supplier relationship that exists in your environment.

How to use severity without mistaking it for priority

Severity is most useful as a first-pass filter for triage. It helps analysts decide what may require fast handling, but it does not by itself answer whether the item should displace other work, trigger escalation, or be turned into a detection or response task.

For example, a high-severity event with no overlap to your stack may deserve only brief validation, while a lower-severity item that matches an exposed control plane, privileged account, or externally reachable service can justify immediate attention. In practice, the operational mistake is to treat severity as a universal queue position rather than as one input to prioritisation.

When teams evaluate intelligence quality, it helps to separate broad threat context from environment-specific applicability, as covered in Threat Intelligence Platform Buyer's Guide and Threat Intelligence Feed Evaluation Guide. One supports platform selection and the other helps assess whether a feed is contributing useful, non-duplicative value.

How relevance should drive action in a threat intel programme

Relevance should be judged against concrete questions: does the intelligence map to your infrastructure, your business-critical assets, your control gaps, or the way an attacker would actually reach you? That is why relevance often changes after internal context is added, even when the original indicator looked important.

This is also where false positives and overcollection become expensive. If a team cannot connect a report to an asset, identity, protocol, region, or attacker path it actually operates, the item should usually remain context rather than action. Conversely, intelligence with modest general severity can still be operationally important if it overlaps with a known exposure, weak control, or a path that your detections do not yet cover.

A practical way to reduce noise is to test whether the intelligence changes a decision: block, monitor, hunt, patch, segment, alert, or ignore. If it changes none of those decisions, it is probably low relevance even if it sounds severe. For feed quality and filtering discipline, the distinction is explored further in Threat vs Vulnerability vs Risk Guide and the Threat Intelligence Platform RFP Template.

Practitioner Guidance

What to verify: Before escalating an item, confirm both its intrinsic severity and its match to your own environment. The second check should include exposed services, control coverage, business criticality, and whether the indicator or technique is actually reachable from your attack surface.

Decision rule: If severity is high but relevance is weak, treat it as watchlist material unless new context changes that judgment. If relevance is high but severity is moderate, prioritise it when it touches exposed identity paths, crown-jewel systems, or controls you know are thin.

What to measure: Track how often high-severity items are later found to be irrelevant, and how often lower-severity items produce real detections, tickets, or mitigations. That split tells you whether your triage process is overweighting headlines instead of fit.

Practitioner takeaway: Severity helps you rank urgency, but relevance tells you whether the intelligence belongs in your operating picture at all, and the best programmes use both signals before they spend analyst time or force remediation.

Related resources from NHI Mgmt Group

• Who is accountable when a SOC misses a real threat hidden in low-severity noise?
• What do teams get wrong about scoring threat severity?
• Why do traditional threat intel workflows fail to improve detection quality in time?
• What happens when identity investigations rely only on manual log review and threat intel lookups?