Operating Under Load: Triage, Prioritisation and Escalation
What is it?
Operating under load is managing more alerts than analysts without missing what matters. It rests on prioritisation by risk — combining severity, the value of the affected asset, and confidence — so the queue is worked worst-first, not first-in-first-out or loudest-first. It also means deciding fast per alert (drop, watch, work, or escalate) and knowing when to pull the cord and escalate to incident response or ask for help.
Why it matters
Every real SOC is over capacity — the alerts always outnumber the hours. Without a risk-based method, analysts work whatever is newest or noisiest and the genuinely dangerous alert on a critical asset waits in the queue behind trivia. Good prioritisation is what makes a finite team cover an infinite queue safely, and knowing when to escalate stops one analyst from quietly sitting on a major incident.
Where you see it
Prioritisation shows up in how the alert queue is ordered and worked, in severity and asset-criticality fields, and in escalation paths and on-call rotations. Under load the analyst constantly triages: this is noise (drop), this is low-risk (watch), this needs work now, this is beyond my tier or clearly major (escalate).
What normal looks like
Healthy load management works the highest-risk items first — a high-severity, high-confidence alert on a crown-jewel asset jumps the queue over a low-severity one on a kiosk. Low-value noise is dropped or tuned out, uncertain items are watched, and anything beyond the analyst's tier or clearly a major incident is escalated promptly, not hoarded.
What suspicious looks like
Poor load management works first-in-first-out or chases the loudest alert, so a critical-asset compromise sits untouched behind trivia. It also shows as an analyst sitting on something beyond their authority out of pride, or drowning in false positives no one tuned — until fatigue means real alerts are dismissed unread.
How analysts investigate
Rank the queue by risk — severity × asset value × confidence — and take the worst first. For each alert make a fast, explicit decision: drop the noise, watch the low-risk, work the real, escalate the major or the out-of-scope. Escalate early rather than late; a false escalation costs minutes, but a hoarded major incident costs the business. Tune recurring false positives so the queue stays workable.
Common beginner mistakes
- Working the queue first-in-first-out or by loudest alert instead of by risk.
- Sitting on an alert beyond your tier out of pride instead of escalating early.
- Letting untuned false positives pile up until fatigue buries the real alerts.
What you will be able to do
- Prioritise an alert queue by risk — severity, asset value and confidence.
- Make a fast drop/watch/work/escalate decision per alert.
- Escalate early when an alert is major or beyond your tier.
There is never enough time for every alert, so the question is not 'can I work them all?' but 'which do I work first, and which can I safely not work now?'. The answer is risk: severity times the value of the affected asset times your confidence it is real. A quiet, high-confidence alert on a domain controller outranks a loud, low-confidence one on a lobby kiosk every time.
| Alert | Severity × asset × confidence | Decision |
|---|---|---|
| Encoded PowerShell on a domain controller, high confidence | High × critical × high = top | Work now / escalate |
| Malware blocked by AV on a kiosk, resolved | Low × low × done = bottom | Watch / close |
| Repeated benign scanner alert, untuned | Noise | Drop and tune the rule |
Worked example — order the queue
1) low-severity adware, blocked, on a lobby kiosk
2) high-confidence encoded PowerShell on DC-01 (domain controller)
3) a noisy, known-benign vulnerability-scanner alert (fires hourly)
4) medium-severity phishing email, user did not clickThe answer: work #2 first, immediately, and likely escalate it — high confidence, high severity, on a domain controller is the maximum of severity × asset × confidence, and a compromised DC threatens the whole domain. Then #4 (real phishing, but no click, so lower urgency — confirm and monitor). #1 is low on every axis and already blocked — watch or close. #3 is pure noise — drop it and tune the rule so it stops consuming attention. Notice you did not work first-in-first-out, and the loudest, most frequent alert (#3) got the least effort. Risk, not order of arrival or volume, sets the queue.
Recap
- Rank the queue by risk — severity × asset value × confidence — worst first.
- Decide fast per alert: drop, watch, work, or escalate.
- Escalate early; hoarding a major incident out of pride is the costly mistake.
Sign in to save your progress on the server.