To triage an alert, ask seven things: what fired and why, which user and asset are involved, whether the activity is normal for them, whether it spread, how sure you are, what the impact could be, and what you will record. Answer them in order, and write the answer down even if the alert is harmless.
The seven questions
1. What fired, and why?
Read the rule, not just the title. What exact condition matched? Which log lines? A rule that says "suspicious PowerShell" may match on a specific encoded flag. Knowing the trigger tells you what to check next and whether the rule is likely noisy.
2. Who and what is involved?
Name the user, host, account type and business owner. Is it a server or a laptop? A service account or a person? A domain administrator or a contractor? The same event means different things on each.
3. Is this normal for them?
Compare with history. Has this rule fired on this host before? Does this user usually run this tool? Is there a change ticket, a patch window or a known project? Normal for one person can be strange for another.
4. Did it spread?
Search for the same indicator, command or behavior on other hosts and accounts in the last day or week. One host is a different problem from ten. Check for new logins and new processes around the same time.
5. How sure are you?
Pick a label: false positive, benign true positive, suspicious, confirmed malicious, or unknown. Be honest about unknown. Escalating unknown with your notes is better than closing it to clear the queue.
6. What could the impact be?
If this is real, what can the attacker reach? Credentials, customer data, production, other systems? Impact decides urgency, not just alert severity. A medium alert on a domain controller beats a high alert on a lab machine.
7. What do you record?
Write what you checked, what you found and why you closed or escalated, in a few lines a colleague can follow. Add the rule name so someone can tune it. If you excluded something, say why.
Containment decisions
Do not isolate or disable on a hunch if your runbook says to ask, but do not wait for approval on something clearly destructive. Agree beforehand which actions an analyst may take alone and which need an owner's approval.
Using the checklist to improve the rule
Count how often a rule closes as a false positive. If the answer is nearly always, either tighten it with a reasoned exclusion or retire it. Alerts nobody acts on are noise, and they train analysts to ignore the queue.
Quick check
Should I close an alert I cannot explain?
Not silently. Mark it unknown, record what you checked and escalate or ask the asset owner.
How long should triage take?
It depends on the alert type. Set a target per category in your runbook, and review outliers rather than rushing every case.
Last reviewed: 19 October 2026.
