End to end triage flow

Understanding the SOC triage workflow

Before designing any grouping logic, I mapped the complete alert lifecycle across SOC analysts, SOC managers, and detection engineers, the three roles closest to the problem, to understand where duplicate alerts multiplied work. The friction wasn't in detection itself: it accumulated in the handoffs, the repeated triage of near-identical alerts, and the engineering bottleneck every tuning request created.
Engineer
Detection rules fire across endpoints, users & cloud
→
Analyst
Queue triage: decide what deserves attention
→
Analyst
Investigate: flyout, correlations & Timeline
→
Analyst
Escalate to a case or dismiss as benign
→
Manager
Track workload, SLAs & request rule tuning

SOC analyst journey

11 steps · 5 pain points, as mapped in research
  • 1Start the shift and open the Alerts queue
  • 2Sort by severity and time; severity alone doesn't say what mattersPain
  • 3Scan hundreds of near-identical rows from the same detectionsPain
  • 4Open an alert flyout to read the reason and evidence
  • 5Compare it by hand against lookalike alerts in the queuePain
  • 6Jump across host pages, user pages & Timeline to rebuild contextPain
  • 7Conclude several alerts belong to the same incident
  • 8Acknowledge the duplicates one by onePain
  • 9Investigate the actual incident in Timeline
  • 10Escalate to a case or close as benign
  • 11Move to the next block of alerts and repeat
✓5 of 11 steps were pain points, and steps 3 to 8 repeated for every duplicate. Suppression collapsed each pattern into one representative alert with its evidence attached: investigation time dropped ~20%, time to first action ~18%.

Detection engineer journey

8 steps · 4 pain points, as mapped in research
  • 1Author a detection rule, set severity and risk score
  • 2Push to production and monitor alert volumes
  • 3Get pinged by the SOC that a rule floods the queuePain
  • 4Reproduce which field combination generates the duplicatesPain
  • 5Rewrite the query or hand-code exceptions per noisy sourcePain
  • 6Redeploy the rule and watch volumes again
  • 7Repeat for every noisy rule; tuning is an engineering ticketPain
  • 8Handle ML rules separately, where noise is hardest to reason about
✓4 of 8 steps were pain points. Suppression rule configuration turned tuning into a self-serve setting, up to 5 fields per rule with ML constraints stated honestly, so noise control no longer required a code change.

SOC manager journey

7 steps · 4 pain points, as mapped in research
  • 1Review the overnight queue before standup
  • 2Split inflated alert blocks across available analystsPain
  • 3Catch two analysts unknowingly triaging the same incidentPain
  • 4Rebalance workload as volume spikes during the day
  • 5Report MTTR and SLA numbers inflated by duplicate alertsPain
  • 6File tuning requests with engineering and waitPain
  • 7Review which detections earn their place in the queue
✓4 of 7 steps were pain points. A grouped queue meant one incident, one owner: duplicated effort disappeared, KPIs measured real incidents instead of raw alert counts, and tuning moved to the team itself.
SOC analyst Detection engineer SOC manager Select a role to explore its journey