---
{
  "title": "Alert triage",
  "summary": "Decide what the signal means, how urgent it is, and who owns the next step.",
  "topic": "soc",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    2
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Incident Response Recommendations, SP 800-61 Rev. 3",
      "url": "https://csrc.nist.gov/pubs/sp/800/61/r3/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Decide what needs attention

Alert triage is the first structured assessment of a security signal. An alert says that a rule or model observed something worth examining; it does not establish that an incident occurred. The analyst checks the supporting records, affected identities and services, plausible explanations, and potential harm before deciding whether to close, monitor, or escalate the case.

Urgency and confidence answer different questions. A suspected compromise of a critical administrator may deserve immediate attention despite incomplete evidence. A well-understood policy violation on an isolated test machine may be less urgent. Treating every vendor severity as a final organizational priority makes the queue harder to manage.

## Follow an account alert

In a fictional academy, a tutor's account signs in from an unfamiliar network. The alert includes a timestamp and an address, but those details alone are weak evidence. A corporate VPN, mobile provider, or inaccurate location estimate could explain the network change.

The analyst checks the account's recent authentication methods, known devices, session activity, and normal work pattern. They then discover a new mailbox forwarding rule pointing to an external address. That second event changes the assessment: the case now includes an action that could expose correspondence, rather than just an unusual sign-in location.

Contact the tutor through a trusted channel, not through the potentially compromised mailbox. Their answer is useful context, but the investigation still needs records showing which identity or application created the rule and whether messages were forwarded.

## Make a reproducible decision

A triage record should identify the alert source and query window, summarize relevant evidence, and explain why competing explanations were accepted or rejected. Reference stable event or case identifiers where possible. Another analyst should be able to understand the decision without guessing which dashboard was open.

[[log-correlation]] helps join authentication and mailbox events, but shared account names or close timestamps are not always enough. Check tenant identifiers, session details, and time zones before assuming that two records describe the same activity.

Escalation should include a concrete question or requested action. “Please investigate” is less useful than “Review whether the new forwarding rule exposed messages, and decide whether to revoke the active sessions.” Record who owns that next step and when it must be reviewed.

## A useful closure exercise

Create two fictional cases with the same location alert. In the first, a known VPN explains the network and subsequent activity matches the user's work. In the second, an unexplained rule change follows the sign-in.

Write a closure note for the first and an escalation note for the second. Include what was checked, the confidence supported, and the remaining uncertainty. [[indicators-of-compromise]] can guide additional searches, while [[incident-reporting]] makes the final reasoning understandable to the next person.