Incident triage is the rapid, structured assessment of security alerts and reported events that determines whether a real incident is occurring, how severe and widespread it is, and which response it receives and in what order. It converts a raw signal, such as an EDR alert or a user report, into a classified, prioritized and assigned case.
In incident response, triage sits at the start of the detection and analysis phase described in frameworks such as NIST SP 800-61. Its quality decides how quickly containment begins, how well scarce analyst time is spent, and whether regulatory notification clocks are recognized in time.
How the triage process works
Triage follows a repeatable sequence that answers a few decisive questions within minutes rather than hours. The goal is a defensible decision, not a complete investigation: deep root-cause analysis and digital forensics come later.
| Step | Key question | Typical inputs |
|---|---|---|
| Validate | Is the alert a true positive? | Raw event, detection logic, process tree |
| Enrich | What context surrounds it? | Asset criticality, user role, threat intelligence |
| Scope | How far does it reach? | Searches for the same IOC across hosts and accounts |
| Classify | What kind of incident is it? | Category taxonomy such as malware or unauthorized access |
| Prioritize | How urgent and severe is it? | Severity matrix and business impact |
| Assign and record | Who acts next, and what is known now? | Escalation path, case ticket, timeline |
Every triage ends with one explicit outcome: close as a false positive, close as a benign true positive with a tuning note, open an incident at a defined priority, or trigger immediate containment when the evidence shows active harm.
Severity and priority criteria
Severity describes how much damage an incident causes or could cause, while priority adds urgency and decides the order of work. A widely used basis, introduced in NIST SP 800-61 Revision 2, rates three impact dimensions independently.
| Dimension | Lowest rating | Highest rating | What it measures |
|---|---|---|---|
| Functional impact | None | High: critical services unavailable | Effect on business operations |
| Information impact | None | Integrity loss of sensitive data | Confidentiality and integrity of data |
| Recoverability | Regular: existing resources suffice | Not recoverable | Effort and possibility of recovery |
Organizations translate these ratings into a priority scale with response targets. The values below are a common pattern rather than a standard, and each organization should set them according to its staffing and risk appetite.
| Priority | Typical situation | Acknowledge within | Escalation |
|---|---|---|---|
| P1 critical | Active ransomware or confirmed data exfiltration | 15 minutes | Incident manager and leadership |
| P2 high | Compromised privileged account or server | 1 hour | Tier 2 and incident lead |
| P3 medium | Contained malware on a single workstation | 4 hours | Tier 2 queue |
| P4 low | Policy violation or blocked scan | Next business day | Tier 1 handling |
Roles and tooling in triage
In a security operations center, Tier 1 analysts usually perform first-line triage, Tier 2 analysts take escalated cases into investigation, and Tier 3 specialists handle complex intrusions and threat hunting. Smaller teams combine these roles, but the hand-off criteria should remain written down.
A SIEM correlates logs into alerts, EDR provides process and network telemetry from endpoints, and SOAR playbooks automate repetitive enrichment such as reputation lookups and user details. Automation can cut the time per alert sharply, yet the triage decision itself still needs human judgment for anything above low priority.
Incident triage compared with related activities
Triage overlaps with several neighboring incident response activities, and confusing them leads to either rushed conclusions or slow first decisions. The comparison shows how they differ in goal and timing.
| Activity | Main goal | Timing | Typical output |
|---|---|---|---|
| Incident triage | Decide what an alert means and who acts | Minutes after detection | Classified, prioritized case |
| Containment | Stop the spread and limit damage | Right after or during triage | Isolated hosts, blocked accounts |
| Digital forensics | Reconstruct what happened with sound evidence | Hours to weeks | Timeline and evidence report |
| IOC matching | Detect known malicious artifacts | Continuous | Alerts that feed triage |
| Threat hunting | Find threats that produced no alert | Planned campaigns | New detections and incidents |
Triage must also preserve evidence. Rebooting or reimaging a suspicious host during triage destroys volatile memory that forensic analysts may need, so isolation through the network or EDR is usually preferred to shutting the system down.
Regulatory clocks that triage can start
Triage often marks the moment an organization becomes aware of an incident, and several regulations count their deadlines from that point or from a materiality decision. Triage records should therefore capture exact timestamps and the reasoning behind every classification.
| Regulation | Trigger | First deadline |
|---|---|---|
| GDPR | Awareness of a personal data breach | 72 hours to the supervisory authority |
| NIS2 Directive | Awareness of a significant incident | 24 hours for an early warning |
| SEC cybersecurity disclosure rule | Determination that an incident is material | 4 business days for a public filing |
Common triage mistakes
Weak triage rarely fails on knowledge; it fails on process discipline and alert volume. The recurring problems are well known:
- Alert fatigue: thousands of low-value alerts per day push analysts toward fast closures, so true positives get dismissed.
- Closing on a single data point: one clean reputation lookup does not prove an alert benign.
- Severity inflation: if everything is critical, nothing is, and leadership stops trusting escalations.
- Trusting the tool score blindly: vendor risk scores lack business context such as asset criticality.
- Undocumented reasoning: decisions without notes cannot be reviewed, defended or used to tune detections.
- No feedback loop: false positives that are never tuned out return every day.
In simple terms
Incident triage works like the nurse at a hospital emergency desk. Many people arrive at once, and the nurse quickly decides who is fine, who can wait and who needs a doctor immediately.
Security teams receive a constant stream of warnings from their tools. Triage is the quick check that sorts real attacks from false alarms and makes sure the most dangerous problems are handled first, while the full investigation happens afterward.
A practical example
At 02:10, the SOC of a regional retail chain receives an EDR alert: an encoded PowerShell command has started on a workstation in the finance department. The Tier 1 analyst checks the process tree and sees that the command was launched by a spreadsheet macro and immediately connected to a domain registered three days earlier.
Searching the SIEM for that domain reveals two more finance workstations that contacted it in the last hour. The analyst classifies the case as malware with likely credential theft, rates it P1 because finance systems hold payment data, and escalates to the on-call incident lead with a short written summary and the three host names.
At 02:31, the incident lead isolates all three hosts through the EDR console without powering them off, which preserves memory for forensics. Twenty-one minutes passed from alert to containment, and the later investigation confirmed that the attacker had not yet reached the payment environment.