- Alert volume, not attacker sophistication, is the most common reason a real signal gets missed in a SOC.
- Compliance-driven "enable everything" rule sets are what create the noise that trains analysts to ignore warnings.
- Fixing it is a tuning and governance exercise, not a reason to buy a new platform.
Why analysts stop trusting the console
A SIEM only works if the people watching it believe what it shows them. When most of what fires is a routine admin login, a scheduled backup, or a patch job flagged by a generic out-of-the-box rule, analysts learn fast that the console cries wolf. That learned response is rational: nobody can investigate every alert at full attention for eight hours a day. The problem is that the same learned response also applies to the alert that matters. Once a team has been trained to expect noise, a genuine lateral-movement pattern that looks similar to the background chatter gets the same shrug as everything else.
This is not a discipline problem with individual analysts. It is what happens to any team asked to sustain constant vigilance against a mostly-false signal. The fix has to change the signal, not lecture the people reading it.
The compliance trap behind over-alerting
NESA and CBUAE expectations push UAE banks and government entities toward demonstrating that suspicious activity is detected, and the safest-looking way to satisfy an auditor is to turn every available rule on. It reads well in a compliance report. It performs badly in a SOC. A rule set built to answer "did we detect this category of event" rather than "does this specific alert deserve a human's time" produces exactly the fatigue described above, and a tired analyst pool is not what any regulator actually wants.
The honest reading of these frameworks is that they expect evidence of monitoring and response capability, not evidence that every default rule shipped with the product is switched on. A smaller set of correlated, high-fidelity rules that a team can actually act on satisfies that intent better than a wall of low-value triggers that nobody has the capacity to work through.
What unmanaged fatigue costs a SOC
The visible cost is burnout and turnover: analysts rotating out of roles that feel impossible rather than demanding. The less visible cost is worse. When a queue is dominated by low-value noise, the alert that represents early-stage credential dumping or outbound data staging sits in the same queue, competing for the same tired attention, with no mechanism to make it stand out. Detection gaps widen not because the SIEM failed to log the event, but because nobody with the capacity to notice was still paying attention by the time it appeared.
Mean time to respond is the metric that usually reveals this first. A SOC where response time keeps climbing even as headcount holds steady is often not short-staffed. It is drowning in alerts that should never have fired.
Pruning the rule set without guessing
Fixing this does not require a new platform. It requires deciding, rule by rule, whether each one earns its place. A workable starting discipline: any rule that fires repeatedly without ever producing a real incident is a candidate for disabling or rewriting, not for tolerating because it was there when the SIEM shipped. Tuning a SIEM rule set is slower than accepting the defaults, but it is the only route to a queue analysts can actually work through.
Correlation matters more than single events. One failed login is noise. Ten failed logins from one source address followed by a successful login from a device that has never authenticated before is a pattern worth a human's attention. Rules built around sequences and context produce far fewer, far more useful alerts than rules built around individual events.
Automation as triage, not replacement
Manual triage does not scale once alert volume passes a team's capacity, and it never will. Automation earns its place here as a filter, not a decision-maker: check whether a flagged IP address is internal, already known, or tied to a scheduled job, and close the alert automatically when the answer is yes. Escalate to a human when it is not. That kind of playbook removes the mechanical, repetitive triage that burns out analysts without removing the judgement calls that still need a person.
This is also where a properly resourced SOC platform earns its cost. Teams running FortiSIEM or an equivalent platform with strong correlation and automated enrichment built in are working from a materially smaller, higher-fidelity queue than teams relying on default rule packs and manual review.
Training analysts to triage, not just recognise a template
Generic security-awareness slides do not prepare an analyst to make a fast, correct call on an ambiguous alert. What does is practising triage against realistic scenarios: credential stuffing, lateral movement, staged exfiltration, and the day-to-day noise that surrounds them. Analysts who have worked through that kind of exercise learn to separate signal from pattern-matching much faster than analysts who have only read about it.
Feedback loops matter as much as the training itself. A recurring review of every missed or falsely dismissed alert, with no blame attached, is one of the more effective and least expensive ways to keep a rule set and a team's judgement aligned over time.
Is your SIEM helping or hiding real threats?
If analysts routinely silence a dashboard, mute a category of alert, or roll their eyes at a notification type, that is diagnostic information, not a discipline problem to manage around. Ask which alerts get dismissed without investigation and why. An endpoint rule that fires on every USB insertion, including approved and encrypted transfers, is a common example: it looks like vigilance and functions as noise. Reconfiguring it to check for encryption status and data volume rather than the event itself usually removes the bulk of the false positives without losing the detection it was meant to provide.
Reviewing SOC output against the metrics that actually indicate whether a team is keeping up, rather than raw alert counts, is a better way to judge whether tuning work is succeeding.
A decision rule for GCC security teams
Before adding another data source or another out-of-the-box rule pack, ask whether the current queue is one an analyst can work through with attention intact. If it is not, tuning comes before expansion, every time. A well-structured SOC is judged by how much of what it surfaces actually deserves a response, not by how much it logs. Fewer, better alerts beat more of them, and that is a governance decision an organisation can make regardless of which platform it has already bought.
