Skip to main content

Preview build: sign-in and grading run on the server. MFA is not enabled, and storage is in server memory so it does not survive a restart.

LearnDefend
Cybersecurity & SOC Fundamentals
TheoryEasy15 minIncident TriageAnalyst Reporting

Triage: Deciding What to Open First

What is it?

Triage is ordering a queue of alerts by the damage they could represent, then working that order. It is a prioritisation discipline borrowed from emergency medicine, and it assumes you will never have time to treat everything at once.

Why it matters

Queues are always longer than the shift. The analyst who works top-to-bottom in timestamp order will eventually spend an hour on a low-severity scanner alert while a domain controller alert waits underneath it.

Where you see it

Every SIEM queue and every case management board. Most tools supply a severity field, but that field is set by the rule author, not by your environment's reality.

What normal looks like

A healthy queue drains during the shift, with the highest-impact items closed first and low-severity noise batched or suppressed at the rule level.

What suspicious looks like

A queue that grows faster than it drains usually signals a badly tuned rule, not an attack. Investigate the rule before investigating each alert individually.

How analysts investigate

Rank by asset criticality, then by credibility of the signal, then by how recent it is. A medium-severity alert on a domain controller outranks a high-severity alert on a lab workstation, because the blast radius differs.

Common beginner mistakes

  • Trusting the tool's severity field as the final word instead of adjusting for asset criticality.
  • Working strictly in timestamp order, which optimises for tidiness rather than risk.
  • Leaving an alert open with no note, so nobody knows whether it was examined.

A workable triage order combines three questions: what could this reach, how believable is the signal, and how fresh is it? Asset criticality dominates, because it determines the worst case.

  PRIORITY = asset criticality  x  signal credibility  x  recency

  domain controller  >  file server  >  workstation  >  lab host
  correlated signal  >  single rule   >  reputation-only
  active now         >  today         >  last week

Ordering a real queue

Three alerts land at once. Tool severity is in brackets. Put them in the order you would open them.

  1. A [HIGH] 'known-bad IP' hit on LAB-PC-03, a throwaway test machine.

    High severity, but the asset is disposable and the signal is reputation-only (weakest kind). Low blast radius.

  2. B [MEDIUM] correlated failed-then-success logon on DC-01, the domain controller.

    Only medium severity, but the asset is the crown jewel AND the signal is correlated (strong). Highest blast radius in the queue.

  3. C [HIGH] malware-download alert on FIN-FILESRV-02, a finance file server, from last Tuesday.

    Important asset and a credible signal, but a week stale — the damage, if real, is already done; it needs work but not first. Order: B → C → A. Asset criticality × credibility beat the raw severity label every time.

Quick check

Why does alert B (MEDIUM, domain controller) outrank alert A (HIGH, lab PC)?

A quick self-check — it doesn't affect your XP or progress.

Sign in to save your progress on the server.