Severity, Escalation, and When To Hand Off
Summary
This note explains how to think about alert severity, escalation, and when a case should be handed off rather than held too long. The goal is to make security work feel more structured and less reactive.
Why this matters
- alert severity is often misunderstood as the same thing as real impact
- escalation decisions become weak when they are based only on alert labels
- a clear handoff point is part of good analysis, not a sign of failure
Environment / Scope
| Item | Value |
|---|---|
| Topic | escalation decision-making |
| Best use for this note | deciding whether to close, monitor, or hand off a security case |
| Main focus | severity, evidence quality, confidence, scope, next-step decision |
| Safe to practise? | yes |
Core idea
Think about the decision like this:
alert severity
plus evidence quality
plus scope and impact
plus analyst confidence
-> next actionThe alert label is only one input. It should not decide the case alone.
Severity vs impact
| Signal | What it means |
|---|---|
| Severity | how serious the detection logic thinks the event may be |
| Impact | what the event could actually affect in the environment |
| Confidence | how strongly the available evidence supports the interpretation |
An alert can be:
- high severity but weakly evidenced
- medium severity but high impact
- low severity but worth tracking if it is part of a bigger pattern
Decision workflow
1. Check the alert label, but do not stop there
Record:
- rule severity
- source system
- host or user involved
- what behaviour triggered the alert
2. Check how strong the evidence actually is
Ask:
- do the raw events support the alert clearly?
- is the context complete enough to trust the signal?
- is this one event or part of a broader pattern?
3. Estimate likely scope and impact
Think about:
- one host or many
- one user or many
- internal noise or meaningful security risk
- test or expected behaviour versus real threat path
4. Decide the next action
Typical outcomes:
- close as benign
- monitor and wait for more context
- investigate further yourself
- escalate or hand off for deeper analysis
Good reasons to escalate
- evidence suggests broader scope than first thought
- the affected system is important enough that delay increases risk
- the required analysis is beyond current visibility or authority
- containment or admin action may be needed quickly
- the signal is incomplete but the potential impact is too high to ignore
Good reasons not to escalate yet
- the alert is still too weak to explain
- a small amount of additional validation could resolve it cleanly
- the event is likely benign but needs one more supporting check
- there is not enough evidence yet to justify interrupting someone else
Handoff checklist
Before handing off, try to record:
- what fired
- why it matters
- what was already checked
- what evidence supports the concern
- what is still unknown
- what action you think should happen next
Common misunderstandings
| Misunderstanding | Better explanation |
|---|---|
| ”High severity always means immediate escalation” | the quality of evidence still matters |
| ”If I hand it off, I failed to investigate” | good handoff is part of disciplined analysis |
| ”Low severity means ignore” | repeated low-severity signals may still matter together |
| ”Escalation is only about technical complexity” | scope, impact, confidence, and authority also matter |
Decision test
Before escalating, ask:
- can I explain what happened so far in plain language?
- is the likely impact bigger than my current scope?
- do I already have enough evidence to justify handoff?
- would waiting create more risk than escalating now?
Key takeaways
- severity is a signal, not the whole decision
- escalation should be based on evidence, confidence, and likely impact
- a good handoff is clear, concise, and evidence-backed