It's alert 34 of the shift. The last 30 were PowerShell execution alerts from the same finance laptop running a legitimate reporting macro, and you closed every one as a false positive within about four seconds. Alert 34 looks the same at a glance: PowerShell, encoded command, medium severity. You're already moving the cursor to close it when something makes you pause, maybe nothing, maybe the start of a ransomware deployment. This is the moment SOC analysts actually live in, and it is nothing like the clean "investigate the incident" scenario training decks show. It's a judgment call made under fatigue, with a queue behind it, and the two ways to get it wrong (miss a real one, or escalate everything and get ignored) are both career-relevant.
The fix isn't "pay closer attention." Attention runs out. What actually holds up under a long queue is a repeatable decision process you run the same way on alert 3 and alert 34.
Read what the rule is actually detecting before you judge the alert's title. A severity label and a one-line summary tell you almost nothing. Open the actual detection logic: what command line pattern, what process lineage, what threshold triggered it. Half of triage mistakes come from reacting to the alert's name instead of the condition it fired on.
Establish whether this is normal for this specific host and user, not "PowerShell in general." A finance laptop running a signed, scheduled reporting macro that spawns PowerShell every morning at 9am is a different animal from a receptionist's machine spawning PowerShell for the first time ever, at 2am, with an encoded command tail. Same process, same alert rule, completely different baseline. Triage without checking the baseline is just triage by vibes with extra steps.
Follow the process lineage, not just the flagged process. What actually spawned this? winword.exe -> powershell.exe -> encoded command is a documented macro-malware pattern worth escalating. explorer.exe -> powershell.exe from a user who opens PowerShell as part of their job is usually nothing. The command line and its parent are the real signal; the process name alone almost never is.
Make the call and write down why, every time, even when you're sure. "Closed as FP: parent process matches known scheduled task, host baseline shows this daily" takes ten seconds and means the next analyst who sees the same pattern doesn't have to re-litigate it from zero. This is also how you catch yourself when your reasoning doesn't actually hold up.
If you escalate, scope the blast radius before you page anyone. What else does this host talk to, what account is logged in, has this signature shown up anywhere else in the last 24 hours. Escalating with "this looks suspicious" gets deprioritized. Escalating with "this host, this account, these three other machines show the same pattern" gets acted on immediately.
If you close it, feed it back into the detection so it stops asking you the same question. A false positive that fires the same way every week isn't a tuning backlog item, it's a debt against your own attention, and it is exactly what alert fatigue is made of. Turning a recurring FP into a suppression rule or a better detection condition is the difference between triage staying sustainable and triage slowly eating the rest of your shift.
This progression, triage discipline into detection engineering, is exactly the arc Codelivly's SOC Analyst Book Bundle: L1 + L2 + L3 Playbooks is built around, going from "how do I make this call correctly" to "how do I stop having to make it manually at all." If you want to run this exact decision process against a real alert queue first, the free SOC Fundamentals learning path and the SOC Intro Workflow lab put an actual triage queue in front of you before you spend anything.
