The Decision Burden Behind SOC Alert Fatigue and How Experts Would Reduce It
Published
Question: A recent Fortinet report lists increased alert volume and overwhelmed SOC operations among the top contributors to cybersecurity risk. Is today's problem primarily that security tools generate too many alerts, or that they struggle to understand context? If you were designing the next generation of SIEM, XDR, or SOC platforms, what capabilities would you introduce?
FalconFeeds | Command Zero | KELA | TrendAI
Nandakishore Harikumar, Founder and CEO, FalconFeeds
The framing of “too many alerts” versus “not enough context” is a false choice. Both are symptoms of the same design decision: our tools are built to detect, not to decide.
Detection logic is tuned for recall because vendors and detection engineers are terrified of missing something; the safe move is always to fire the alert and let a human sort it out.
Volume is the predictable result. Context is missing not because the data does not exist, but because it is scattered across a dozen consoles that were never meant to talk to each other.
The analyst becomes the integration layer, manually stitching together identity, endpoint, network, and cloud signals that the platform could have correlated but did not.
So, the honest answer is that today’s problem is neither volume nor context in isolation. We have offloaded the expensive cognitive work gathering evidence, ruling things out, and deciding what matters onto the cheapest, most fatigued part of the system: the tier-1 analyst.
Alert count is the metric everyone quotes, but the number that actually predicts burnout and missed threats is decisions per analyst per shift. Almost nobody measures that.
Who feels it most? Not the well-funded SOCs with named detection engineers and real 24/7 coverage. It is the
- Two- and three-person teams
- The MSSP and MDR analysts carrying dozens of clients,
- And increasingly the cloud and identity teams hit by an entirely new alert class they were never staffed to handle.
And yes, we are collecting more telemetry than humans can use. Worse, we collect more than we can afford to store, so ingest and retention get trimmed for budget reasons, quietly creating blind spots.Volume of data is not the same thing as signal.
Where current SIEM and XDR tools fall short is depressingly consistent. Correlation is still mostly brittle, rule-based logic.
“XDR” too often means single-vendor lock-in with better marketing rather than genuine cross-domain reasoning.
Risk scores are arbitrary and unexplainable; no analyst can act on “malicious: 87%.”
- And there is no memory: the platform learns nothing from the ten thousand times an analyst dispositioned this exact pattern as benign.
If I were designing the next generation, I would invert the unit of work.
- Stop presenting alerts; present cases built around
- an entity,
- an identity,
- a host, or
- an asset with the narrative already assembled.
- Let automation do the boring 80% of investigation:
- enrich,
- pivot,
- pull the related events, and
- rule out the obvious.
Reserve the human for judgment. Make every detection ship with confidence, explainability, and native suppression, and close the loop so analyst dispositions automatically tune the detection that produced them. Decouple detection from storage so cost stops dictating visibility.
The narrative I would push back on hardest is that AI will fix this by summarizing alerts faster.
- Point a language model at a firehose, and you get a well-written firehose.
- The goal is not prettier alerts; it is fewer decisions for a human to make.
- Any tool that adds a summary without removing a decision has made the problem worse.
What should organizations do differently now?
- Measure decisions and false-positive disposition rates, not alert counts.
- Treat detection engineering as a product, with a backlog and a retirement policy for noisy rules.
- And buy fewer tools, integrated deeply, rather than a shelf of best-of-breed consoles that nobody has time to pivot between.
Alfred Huger, CPO & Co-Founder, Command Zero
Security tools generate too much noise. The noise problem and the context problem are the same problem. Vendors need alerts to fire during evaluations. That pushes them toward detections that trigger easily, not detections that matter.
Analysts end up buried in policy violations dressed up as security events, minor privilege changes, small behavioral blips. Real signal sits in that pile. It just gets buried with it.
Context fixes this two ways. It separates real threats from noise. It also links weak signals into a strong one. One alert means little alone. The same alert, tied to three others across the stack, tells a different story. Tools that skip that assembly work just hand the noise to the analyst.
If I were rebuilding the SOC stack today, I would not build a SIEM. SIEMs never made a good foundation for a SOC program. They won for one reason: they were the only place data lived centrally enough to query. That was an accident of market history, not a design strength.
Even that centralization came at a cost. SIEM pricing punishes you for landing everything you need. Most SIEM data arrives incomplete, transformed, or missing outright. Garbage in, garbage out. An investigation is only as good as the data behind it.
I would treat the investigation, not the alert, as the unit of work. The alert is just an input. The platform's job is to gather evidence and reach a verdict — benign, malicious, or needs escalation — backed by proof. It should work where the data already lives, not funnel a lossy copy into another lake.
SIEMs still earn their place for GRC and compliance reporting. Cheaper storage handles that job just as well today.
Lewis Henderson, Director of Intelligence Communications at KELA Cyber Threat Intelligence
The alert fatigue conversation usually starts in the wrong place: the platform. SIEM, XDR and SOC platforms are all fed data; they do not create it.
That is the root of the problem. There are genuinely good innovations in this sector, but they all do one thing: aggregate multiple data sources really well. If the data flowing into them is outdated, sub-optimal or irrelevant, no amount of platform engineering can recover the return on investment
Recent industry research shows the scale of the resulting failure.
- Security teams face an average of 960 alerts per day
- Around 40% of alerts are never investigated at all
- And 61% of teams admit they have ignored alerts that later proved critical
Operational data from 25 million alerts triaged across live enterprise SOCs in 2025 found that over 60% of alerts never get reviewed.
On the intelligence side, a 2025 Google Cloud study found "too many feeds" is the single most cited barrier to actioning threat intelligence, with 82% of security leaders concerned they are missing real threats in the volume.
The reason is structural. Most threat feeds come from aggregators who buy data from multiple sources and fire it at their customers as a feed.
In my own experience working with Fortune 500 security teams, it is common to see 50, 60, sometimes 70 or more feeds being ingested, each requiring integration and development time.
Teams then have to: de-duplicate across them, process the data, enrich it, and build their own context. It is complex, and it is expensive, and the volume it produces is exactly what the statistics above describe.
KELA approaches this from the other end of the pipeline. We are a CTI Originator: we create intelligence from first-hand observation of cybercrime ecosystems rather than buying and reselling data. Our inclusion in the inaugural Gartner Magic Quadrant for Cyber Threat Intelligence validates how we differ.
When an observation enters our platform, customers can act on it directly and immediately, with minimal decay. That is why governments, law enforcement organizations and global enterprises rely on this class of intelligence; they have to make informed decisions and take decisive actions that get results, and they cannot do that with sub-optimal data.
The More Mature Teams in the Private Sector Feel this Pressure the Most
These are the organisations that have reached saturation in terms of threat feeds and have built automation as their foundation.
Automation was supposed to be the fix; Instead, it has compounded the problem for Tier 1, 2 and 3 analysts,because volume has increased with little to no reduction in false positive rates. Automating the processing of poor data just delivers poor data faster.
The Challenge is Not the Platform, It is the Data
The problem of poor data has become so acute that SIEMs are increasingly seen as a drag on security teams rather than an enabler.
Reaching a Point Where Organisations Collect More Telemetry than Humans can Realistically Use
When over 60% of alerts are never reviewed, collection has decisively outrun human capacity. This is the core of the challenge. Too much of the wrong data, and even AI cannot dig you out of the hole it creates.
Organisations need to review and assess each of their sources of threat and risk, and break the current models they use to assess integrity.
Mean Time to Detection is a vanity metric; a decrease just says you discovered a failure faster than you did yesterday. Each threat feed has to be assessed on whether it moves the needle to prevent an attack or build better defences. If it does not, its value, facing an AI-enabled adversary, is extremely low.
Rethinking How Alerts are Prioritised
I would change what we measure, starting with the feeds themselves. Two measures, in priority order:
Primary: Prevention Rate. For each threat feed, how often did a ticket it raised lead to a positive action that enabled an attack to be avoided entirely?
Prevention Rate = tickets leading to attack-avoiding action / total tickets raised by the feed
Secondary: Early Detection Rate. How often did a ticket lead to a positive action that detected an in-progress attack? This should be measured from the nearest point of blast radius working away:
- Closest will be across compromised supply chains
- Then from industry peer group victims
- Moving outwards towards unrelated or disconnected third parties
Early Detection Rate = tickets leading to detection of in-progress attacks (supply chain, victims, third parties) / total tickets raised by the feed
The whole measurement system for threat and risk quantification needs a rethink: start from earlier in the attack cycle, and from the nearest point of potential blast radius.
Change the objective from: "How do I detect threats faster" to "How do I stop attacks sooner in the attack cycle"
Organizations need to start to develop their own tables for their own varying levels of critical assets, similar to this:
Sharda Tickoo, Country Manager for India & SAARC at TrendAI
SOC Teams or Analysts Feeling the Pressure
Adversaries increasingly leverage AI to attack faster than ever before, and the pressure is not uniform. It is concentrated where complexity meets resource scarcity.
The greatest strain is no longer confined to Tier 1 analysts. It now runs across the entire detection and response lifecycle.
Every SOC function, from alert triage to threat hunting to incident response, must operate at machine speed while still maintaining human oversight.
Analysts inherit tickets from automated systems, often lacking the context to triage effectively or the authority to escalate meaningfully.
But the deepest pressure sits with seasoned analysts managing hybrid environments. They may see threats across identity, cloud, OT, and supply chain simultaneously, but their tools force them to investigate in silos.
The structural problem is that as attack surfaces expand, (identity compromise, insider risk, supply chain poisoning), SOC staffing did not.
Organizations added detection capability without adding investigation capacity. The result is a widening gap between what we can see and what we can actually respond to.
Where Today's SIEM, XDR, and SOC Platforms Still Fall Short
Today's SIEM, XDR, and SOC platforms are significantly better than they were five years ago.
- They collect more telemetry
- Correlate events across environments
- And detect threats faster
But the challenge has shifted. The limitation is no longer collecting data—it's turning that data into timely, confident decisions.
The deeper gap exists in identity and behaviour. Organizations can detect that a compromised account accessed a sensitive file, but most platforms cannot answer:
- Whether that access was anomalous for that user
- Whether it was part of a larger attack pattern
- Or what the actual impact was
Even worse, supply chain and third-party risks remain largely invisible. A vendor's compromised API token may sit in the logs as noise until damage is discovered.
The trade-off organizations face is brutal. They have been deploying more detection tools and suffocating analysts in noise or disable alerts and miss real breaches.
Moving from reactive threat management to proactive monitoring and adding risk context is what makes SOC’s decision complete. This defines the shifts from a SOC to Cyber Risk Operations Centre (CROC).
Reaching a Point Where Organizations Collect More Telemetry Than Humans Can Realistically Use
Modern enterprises collect telemetry from endpoints, identities, cloud workloads, networks, applications, SaaS platforms, and increasingly AI systems. The volume is simply beyond what human analysts can manually process, and this is one of the defining challenges of modern cybersecurity.
The nuance is that the problem isn't too much telemetry; it is too little intelligence applied to it. It is extracting the right insight at the right time. Security teams don't need another billion events; They need to know which five deserve immediate attention.
The operational reality is that analysts developed filtering strategies that are now liabilities. If you filter out 95% of alerts as "baseline noise," you are also filtering out the slow, careful attacks.
Ransomware operators understand this. They move deliberately, generate minimal alerts, and wait months inside networks while defenders ignore the signal underneath the noise.
The current model assumes high-confidence detection is possible at scale. It is not. We need to accept that and change how we approach investigation entirely.
The future of the SOC won't be measured by how much telemetry it collects, but by how quickly it turns telemetry into trusted, actionable decisions.
Rethinking How Alerts are Prioritized, Investigated, or Presented
Today's SOC still revolves around alerts:
- An analyst receives an alert
- Gathers context from multiple tools
- Determines whether it's real
- Assesses business impact
- Decides what to do
AI can eliminate much of that manual work. If I could change one thing, I would stop asking analysts to investigate alerts and start presenting them with decisions.
Instead of hundreds of disconnected alerts, analysts should receive a small number of AI-generated cases that already answer the key questions:
- Is this a real attack?
- How did it happen?
- Which assets and identities are affected?
- What's the business impact?
- What evidence supports this conclusion?
- And what actions should we take next?
Prioritization should also move beyond static severity scores. It should consider exploitability, active attacker behaviour, business criticality, compensating controls, and the organization's risk appetite.
That way, analysts spend their time on what truly matters rather than what's merely rated as ‘Critical’.
Organizations should stop buying more detection tools and start investing in a unified AI-powered platform that can:
- Correlate signals
- Behavioural analytics that reduce false positives
- Provide single-pane visibility across risk surfaces and orchestration that lets analysts focus on reasoning about intent, not scrolling through logs
Ultimately, the goal isn't to build a faster alert queue. It is to build a SOC where humans make the important decisions while AI handles the repetitive analysis, correlation, and evidence gathering.
Related
