What Automation Actually Does to a SOC Team

2026-09-01 · Omar A.

About a quarter of security alerts are never investigated, and 60% of teams have had one of those turn into a real incident. Here is what changes when you automate the work, with real numbers.

The numbers

  • 28% of security alerts are never investigated [1] Median 22%. Two in five teams leave 30% or more untouched.
  • 60% of teams had an ignored alert become a real incident [1] A third had three or more such incidents in twelve months.
  • 75 min average time to investigate a single alert [1] Median 45 minutes. Before that it waits about 55 minutes to be picked up.
  • 73% name false positives their top detection problem [2] Teams reporting "very frequent" false positives rose from 13% to 20% in a year.
  • $1.9M lower breach cost for teams using security AI and automation extensively [3] Those teams also closed out a breach 80 days faster. The global average breach cost $4.44 million.

The problem is not your team, it is the arithmetic

An alert fires and waits about 55 minutes before anyone opens it. The person who opens it spends 45 to 75 minutes on it. Roughly seven in ten turn out to be nothing, and about a quarter are never opened at all. No amount of effort fixes a queue that arrives faster than it can be worked.

What the queue costs

A team triaging 40 alerts a day at 20 minutes each, where 70% are false positives, spends about 47 hours a week on alerts that were never incidents. Over a working year that is more than one full-time analyst, spent entirely on non-events. The article carries a calculator that runs this on your own figures.

What changes when you automate

Enrichment and scoring happen in seconds instead of an hour. Context is attached before a human opens the alert. Known-benign patterns close themselves with an audit trail. Every alert gets a first pass instead of a quarter being skipped. Destructive actions stay a human decision behind an approval gate.

What automation does not do

It does not replace an analyst, it removes the first ten minutes of their work. It does not fix a bad detection rule, and automating a noisy rule produces automated noise. It should not make irreversible decisions on its own. It is not maintenance-free: an unmaintained workflow stops working in about six months, usually silently.

Where to start

Count one week of your noisiest rule before building anything. Automate the first ten minutes rather than the decision. Put an approval gate on anything you cannot undo. Give every workflow an owner and an error alarm.

Before and after, step by step

  • An alert fires. Before: It waits about 55 minutes before anyone opens it. After: Enriched and scored in seconds, before a human looks at it.
  • Gathering context. Before: Six tabs: the SIEM, threat intel, the asset inventory, the user directory. After: Already attached. One summary names the host, the user and what the indicator is known for.
  • The obvious non-events. Before: Seven in ten are nothing, and each one is read and closed by hand. A quarter are never opened. After: Known-benign patterns close themselves with an audit trail. Every alert gets a first pass.
  • The monthly report. Before: Two days of screenshots and copy-paste. After: Generated and sent on schedule.

What happened in our own SOC

The research above describes the industry. This part describes one deployment: the Wazuh alert triage workflow that is now the most-bought thing in the store, running in the SOC it was built for.

  • Alerts reaching a human each day: ~40 to ~12
  • Average time from alert firing to first triage: ~50 minutes to Under 1 minute
  • Time spent per alert that turned out to be nothing: ~15 minutes to 0, closed automatically with an audit trail
  • Alerts left unreviewed at end of shift: Routine to None
  • Monthly reporting: ~2 days to Scheduled, no manual work

Between 20 and 30 analyst hours a month came back, and they came back from the least valuable part of the job. One environment, one SIEM, one team. Your ratio of noise to signal is the thing that decides your result, and it is different from ours.

The limits

  • It does not replace an analyst. It replaces the first ten minutes of their work, forty times a day. The judgement stays human.
  • It does not fix a bad detection rule. Automating a noisy rule gets you automated noise. Tune the rule first.
  • It should not make your irreversible decisions. Isolating a host or disabling an account: prepare it automatically, then wait for a human to approve.
  • It is not free, and it is not finished. APIs change and credentials expire. An unmaintained workflow stops working in about six months, usually silently.

Four steps

  • Count one week before you build anything. Take your noisiest rule and count how often it fired versus how often it was real. That ratio tells you what to automate.
  • Automate the first ten minutes, not the decision. Enrichment, scoring and a written summary. That is where almost all the recoverable time is.
  • Put a gate on anything you cannot undo. Prepare containment automatically and require a human to approve it.
  • Give it an owner and an alarm. Route its errors somewhere a person reads, and put one name against keeping it alive.

Sources

Mentioned in this article

Browse the workflows · Deployment and managed plans · ← Back to blog