← Resources
Guide4 min read · updated May 9, 2026

Severity is not urgency

On this page
Severity is a property of the finding. Urgency is a property of your week.

Severity describes how bad a vulnerability would be if exploited — how much access it grants, how much data it exposes, how much damage it does. Urgency describes how soon you need to fix it given everything else on your plate. They are different scores. Treat them that way.

A critical-severity bug buried behind an IP allowlist on an internal admin tool is less urgent than a medium-severity bug on your unauthenticated signup form. The critical one is harder to reach; the medium one is exposed to the entire internet and being hit by bots right now. Severity tells you the blast radius if it goes off. Urgency tells you the probability someone is already pulling the trigger.

What severity actually means

Severity is a class score, not a business score. It answers one question: if an attacker successfully exploits this bug, how bad is the outcome?

CVSS — the scoring rubric most tools use — grades eight factors: where the attacker needs to be, how complex the exploit is, whether they need credentials, whether a user has to click something, and how much confidentiality, integrity, and availability are impacted. Combine those factors and you get a number between 0.0 and 10.0. A CRITICAL sits at 9.0 and above. A HIGH runs 7.0–8.9. A MEDIUM covers 4.0–6.9. Below that: LOW and INFO.

That number tells you about the vulnerability in the abstract. It does not know your network topology. It does not know your firewall rules. It does not know that only three employees can reach the affected endpoint. Severity is universal. Your environment is specific. Urgency lives in the gap between the two.

What urgency actually means

Urgency is how fast you actually need to move. It is a function of three things: exposure, attacker incentive, and exploit availability.

Exposure is who can reach the vulnerability. A bug behind your VPN is reachable by employees and anyone who has stolen employee credentials. A bug on your public login page is reachable by everyone. Exposure shrinks or expands the attacker population by orders of magnitude.

Attacker incentive is whether anyone cares enough to try. A stored XSS on a profile page that only other users see is annoying. A stored XSS on an admin dashboard that finance users visit every morning is a credential-theft vector that pays well. Same vulnerability class. Different incentive. Different urgency.

Exploit availability is how easy the attack is to execute. If public exploit code exists and works against your exact version, a motivated attacker needs ten minutes. If the exploit requires chaining three obscure behaviors and writing custom shellcode, the bar is high. Check whether the CVE has a published PoC before you decide how fast to move.

When they disagree

Severity and urgency disagree more often than most teams expect. Here are three patterns where the right move is not obvious from the severity badge alone.

Critical severity, low urgency: An unauthenticated remote code execution finding on your internal admin tool sounds like a five-alarm fire. But if that tool lives on a private subnet, is only reachable from office IPs, and your VPN has MFA — the attacker population is effectively zero unless someone has already compromised an employee device. You still fix it. You do not page anyone at 2 am to do it.

High severity, high urgency: A privilege escalation finding that requires a valid admin session sounds contained — an attacker would need to already be an admin. But a brute-force vulnerability on your login endpoint with no rate limiting means anyone can become an admin with a dictionary and patience. The privilege escalation is now one step away from any internet user. Fix the rate limit today.

Medium severity, higher urgency than the critical next to it: A stored XSS on a public user profile is a medium. A SQL injection in the admin-only reporting dashboard is a critical. If your reporting dashboard requires a paid subscription and two-factor authentication, and your public profile pages are indexed by search engines and visited by thousands of users a day — the medium gets your attention first. Surface area beats theoretical blast radius.

Three concrete examples

Walk through each scenario and score its urgency explicitly, separate from its severity.

Example 1 — RCE on an internal admin tool. CRITICAL severity. The finding is RCE, so the blast radius is total system compromise. Urgency analysis: reachability is a private subnet plus IP allowlist; attacker incentive requires a compromised internal account first; no public exploit code exists for this specific version. Urgency: medium. Put it in the next sprint, not the current oncall ticket. Increase VPN MFA requirements in parallel as a compensating control.

Example 2 — Privilege escalation requiring an admin session, vs. login brute-force. The privilege escalation is HIGH severity. The brute-force finding is MEDIUM severity. Urgency analysis: the brute-force finding is publicly reachable, has trivial exploit tooling (Hydra, Burp Intruder), and no rate limit means an attacker can run 10,000 attempts per minute. Once they have a valid session, the high-severity privilege escalation is one step away. The medium gets shipped today. The high waits until the medium is closed.

Example 3 — Stored XSS on a public profile, vs. SQLi in a paid feature. The SQLi is CRITICAL severity. The XSS is MEDIUM. Urgency analysis: the SQLi sits behind a subscription paywall and two-factor authentication. Attacker population: paying customers who have bypassed MFA. The XSS lives on a public profile page crawled by search engines and linked from social media. Attacker population: everyone. An attacker who drops a malicious script on a public profile can hijack sessions of any authenticated user who views it — including admins. Fix the XSS first. Escalate the SQLi next sprint with a compensating WAF rule in place.

A rule of thumb

Severity is fixed. It does not change based on your infrastructure. Urgency is variable. It changes every time you add a firewall rule, require MFA, or move a feature behind a paywall. The right habit: after every significant infrastructure change, re-score the urgency of your open findings. The severity column stays the same. The scheduling column should change.

Use severity to decide what to fix. Use urgency to decide when to fix it. Stop letting the badge color run your sprint planning.