Your SOC Reads 11,000 Alerts a Day. Most of Them Shouldn't Exist.

Cybersecurity

Alert fatigue is a detection-engineering problem, not a staffing problem. A practical look at the three-layer filter we use to cut queue volume by 60 to 80 percent without losing ground-truth signal.

By Arjun Raghavan, Security & Systems Lead, BIPI · April 18, 2026 · 7 min read

Ask any SOC lead what breaks first when a team scales, and the answer is boringly consistent. The queue. By the time an organisation has a mature SIEM, a dozen log sources, an EDR, and a cloud SIEM connector, the analyst on shift is looking at a queue deep enough that triage becomes a guessing game.

The industry benchmark is uncomfortable. Surveys from 2024 and 2025 put the average mid-market SOC at somewhere between 7,000 and 11,000 alerts a day, with a false-positive rate that hovers around 45 percent. IBM's 2025 Cost of a Data Breach report noted that a majority of breaches included at least one alert that was dismissed or closed out without deep investigation. The detection was there. The bandwidth wasn't.

Alert fatigue is a detection-engineering problem, not a staffing problem. Most SOCs fix it the wrong way.

The wrong fix: more analysts

The instinct, when the queue grows, is to hire. A fifth analyst. A sixth. A 24x7 shift rotation. Within three months the queue has grown again to fill the new capacity. The fundamental reason is that alerts are generated at the rate your log sources emit suspicious events, not at the rate your team can read them. Adding analysts linearly does not reduce volume.

What a larger team changes is triage latency, which matters for severity-critical alerts. But for the P3 and P4 volume, the stuff that makes up 80 percent of the queue, more eyeballs means more dismissal, not more investigation.

The three-layer filter

When we rebuild a client's alerting pipeline, we think in three layers. Each layer has a different job. Each one depends on the one above it.

Layer 1: Source tuning

This is unglamorous work. It is also where most of the queue volume lives. Over-broad detections usually come from vendor defaults. A rule like 'PowerShell child process of Office' will trigger thousands of times in a company with a Microsoft estate, most of which are normal automation.

Tuning looks like this:

• Suppressing alerts on signed, known-good parent binaries.
• Scoping by asset class: suppress on build servers, alert on endpoints.
• Re-baselining thresholds every 60 days instead of leaving them at default.

Ship this layer and you usually cut 40 to 55 percent of raw volume. Nothing fancy. Just discipline.

Layer 2: Correlation

The second layer is where isolated events become evidence. A Kerberos 4769 ticket request on its own is not interesting. A 4769 burst from a single source to seven service accounts inside a 30-second window is interesting. Correlation rules replace 'one alert per event' with 'one alert per attack chain.'

The practical constraint is engineering time. Correlation rules in most SIEMs are cheap to write and expensive to maintain. We keep a living inventory of them per client and retire ones that haven't fired in 90 days.

Layer 3: Enrichment and context

The third layer answers the question the analyst was going to ask anyway. Who is this user, what is this host, is this normal for them, has this been flagged before. We enrich at alert-time from asset inventories, HR feeds, vuln databases, and threat intel. Alerts arrive with answers instead of questions.

This layer does not reduce volume. It reduces time spent on each alert. In our most recent deployments the median triage time on a P3 alert dropped from 9 minutes to just under 2.

What 'good' looks like

A tuned SOC, in our experience, has these five properties.

1. Under 2,000 alerts per analyst per day, including P4s.
2. A false-positive rate below 20 percent for P2 and above.
3. A median triage time under 3 minutes for P3.
4. No more than 15 percent of alerts closed as 'duplicate.'
5. A quarterly detection-retirement cycle that measurably shrinks the rule inventory.

Numbers 1 and 3 are the ones most teams get wrong. Numbers 4 and 5 are the ones that let the team stay at good.

Closing

If your SOC is drowning, the fix is almost never another analyst. It is detection engineering as a practice. Disciplined source tuning, correlation rules with retirement policies, and enrichment at alert-time. None of this is new. The hard part is making it someone's actual job. Until you do, your team will keep reading the same noise faster.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.