How to Tune Your Security Operations Centre and Conquer Alert Fatigue

What is SOC alert fatigue?

SOC alert fatigue occurs when security analysts are exposed to such a high volume of security alerts that it becomes increasingly difficult to identify and prioritise genuine threats.

The problem is partly a consequence of improving security coverage. Threats do not stand still, so neither can SOC detection capabilities. A SOC relying on exactly the same detections and analytics it deployed several years ago will struggle to identify newer attack techniques. SOC teams therefore need to continuously add and adapt detection capabilities.

That creates an uncomfortable equation: more detection coverage can mean more alerts, while the number of analysts available to investigate them may remain relatively static.

It is also important to understand that not every alert means the same thing. Endpoint detection and response (EDR) tools might identify known malware or suspicious process behaviour, while a SIEM can correlate activity across different systems to identify anomalies that would otherwise be difficult to spot.

Other alerts may simply identify potentially risky administrative activity. Deleting cloud resources, for example, could indicate malicious activity – or it could be a legitimate administrator doing their job.

The challenge for a mature SOC is determining which events deserve immediate human attention and which can be handled differently.

What causes unnecessary SOC alerts?

Some alert noise is unavoidable. Other noise can be reduced by addressing how the underlying environment is configured and operated. One significant cause is configuration drift. A server may have been configured according to best practice when it was deployed, but years later that configuration may no longer reflect modern security recommendations. Changing it may not be straightforward either: a legacy application might depend on the existing configuration.

Operational communication matters too. Consider penetration testing. If a business deliberately runs a penetration test without informing its SOC, analysts may spend significant time investigating activity that is entirely non-malicious. Testing whether the SOC detects an attack can have value in the right scenario, but simply creating avoidable alerts wastes analyst time that could be spent investigating genuine threats.

Some noise can also be stopped before it reaches the SOC. If an organisation operates exclusively in the UK and employees do not routinely travel internationally, for example, it may be possible to restrict access from countries where legitimate authentication should never originate. Rather than asking the SOC to repeatedly investigate those login attempts, preventative controls can block them upstream.

This is why SOC tuning cannot be treated purely as a SIEM exercise. Effective tuning requires you to understand the environment producing the alerts in the first place.

What does good SOC tuning actually mean?

At its simplest, SOC tuning involves adjusting detection rules and the processes surrounding them so analysts receive useful, actionable alerts without unnecessarily reducing security coverage.

Imagine an analytic designed to detect repeated failed login attempts. If it creates an alert after three failures, analysts may repeatedly investigate users who have simply mistyped their passwords. You could change the threshold to five failures and remove much of that noise, but there is a catch: every time you tune out activity, you potentially create a detection gap.

If you continually increase thresholds because alerts are inconvenient, eventually the detection may become so narrow that an attacker can operate below it. The SOC might achieve an impressively low false-positive rate while simultaneously becoming less effective at identifying suspicious behaviour.

Think of detection like the aperture on a camera lens. Narrow the aperture and you can focus tightly on activity you are highly confident is malicious. Widen it and you have a better chance of catching unusual behaviour, but you also capture considerably more noise. Neither extreme is inherently right.

The correct balance depends on factors including the organisation’s risk appetite, operational requirements, and the number of alerts its SOC can realistically investigate.

How often should you tune your SOC?

SOC tuning should be a continuous process rather than a one-off implementation exercise. New systems are introduced. Configurations change. Threat actors develop new techniques. Employees work differently. Detection capabilities improve. Each change can alter both the quantity and quality of alerts entering the SOC. That means the detection rules that worked on day one should not automatically be assumed to remain appropriate several years later.

In practice, tuning is part of the SOC’s everyday operation. In the examples discussed by our SOC team, a couple of thousand alerts might fire during a week before tuning and automation reduce them to hundreds reaching the SOC, with only tens ultimately becoming tickets requiring action. Crucially, those tuning decisions cannot simply be copied from one organisation to another.

A business whose employees only work in the UK has a very different risk profile from one whose people routinely travel internationally. What constitutes unusual login activity for the first organisation could be perfectly legitimate for the second. SOC tuning therefore needs to reflect the organisation’s specific environment, risk profile, and risk appetite.

How can automation reduce SOC alert fatigue?

Not every event needs a human analyst to investigate it immediately. Suppose an administrator creates or deletes a cloud resource. Rather than automatically sending the event to an analyst, an automated process could perform additional checks.

Did the user successfully pass conditional access? Did they use the appropriate privileged identity management process to elevate their permissions? Does the surrounding activity suggest legitimate administration?

If those checks indicate normal behaviour, the event might be recorded in a workbook for later review rather than joining an analyst’s immediate investigation queue. Safety logic could then escalate the activity if its frequency suddenly spikes. This approach can remove repetitive investigative work while maintaining visibility.

However, automation should not simply mean ignoring lower-priority alerts.  Sophisticated attackers actively attempt to remain quiet. They may test techniques against the security products they expect their target to use and deliberately adjust their behaviour until activity triggers a lower-priority alert rather than an obvious critical incident.

A P3 alert is not necessarily harmless simply because it is a P3. Analyst knowledge remains critical for understanding why a detection fired and whether apparently innocuous behaviour could represent something more serious. The objective should therefore be to automate repeatable checks and remove known noise, rather than blindly automate the entire triage process.

How will generative AI change SOC tuning?

Generative and agentic AI could fundamentally change the economics of SOC alert management. Traditionally, SOC tuning has focused on reducing a large volume of raw alerts into a smaller collection of high-fidelity events that human analysts can realistically investigate.

AI introduces another possibility: what if you did not need to tune out as much noise in the first place? Rather than asking an LLM to analyse millions of raw logs, a SOC could use existing detections as triggers. An AI system could then perform additional investigation around each alert, following established playbooks and checking related information before deciding whether it warrants human attention.

In that model, an apparently suspicious cloud resource creation could trigger an investigation. The AI could check authentication, conditional access, privilege elevation, and other contextual information. If everything suggests legitimate activity, it could close or record the alert without requiring an analyst.

If the evidence instead indicates malicious behaviour, it can escalate the incident for human investigation – or, where an organisation’s risk appetite permits it, potentially trigger an automated response.

This potentially turns one of the traditional assumptions of SOC tuning on its head. Instead of noise always being undesirable, additional alerts can provide useful signals for AI-led investigation, allowing humans to concentrate on the activity that genuinely warrants their expertise.

Can AI completely automate SOC triage?

Not yet – and implementing AI effectively requires getting the fundamentals right first. You cannot simply connect a generative AI platform to your security alerts and ask it to investigate everything. The underlying automation, playbooks, and processes need to exist first. If analysts always perform the same checks when investigating a particular incident, those steps can potentially be codified into an automated workflow that an AI system can execute.

There is also an economic consideration. Thoroughly investigating every event can require an AI system to perform large numbers of checks, consuming tokens and increasing cost. Organisations therefore need to determine how much machine-led investigation is economically justified before an alert reaches a human.

Most importantly, human oversight remains necessary. Automation and AI can increasingly remove common, repetitive alarms from analysts’ queues, but triage remains an important security function. The objective should be human in the loop, with technology handling repetitive investigative work while experienced analysts retain responsibility for the decisions requiring context, judgement, and security expertise.

Are AI-enabled attacks making alert fatigue worse?

Potentially – although identifying an individual alert as the direct result of AI is not straightforward. A SOC does not receive an alert labelled “AI attack”. Instead, analysts see the resulting activity.

Threat actors can use AI to accelerate vulnerability identification and exploitation, for example. Techniques that previously required manual work or relatively rigid scripts can increasingly be executed and adapted at machine speed. That can result in more activity against edge devices and other points of interaction, which in turn generates more security alerts.

AI can also explore attack paths that a human might simply never consider. The result is a threat environment in which attackers can test far more possibilities far more quickly. For SOCs already struggling with alert volumes, the implication is significant: the answer cannot simply be to employ enough analysts to manually investigate everything – the operating model itself has to evolve.

What separates a mature SOC from a struggling SOC?

There is no single technology or metric that makes a SOC mature. Effective SOC operations combine experienced analysts, mature processes, appropriate coverage, strong governance, automation, and the ability to tailor security operations to the organisation being protected.

Perhaps most importantly, organisations need to move away from viewing the SOC as a security control they simply purchase and forget about. The strongest model is a partnership.

Security changes. The organisation changes. Its infrastructure changes. Threats change. The SOC therefore needs an ongoing relationship with the organisation so detections, configurations, automation, and response processes can evolve alongside them.

That requires customisation without sacrificing scalability. It also requires mature governance to ensure that efficiencies introduced through tuning and automation do not inadvertently create security weaknesses.

Agentic AI will accelerate this evolution, but it will not remove the need for solid foundations. Automation, established processes, governance, and experienced humans remain essential building blocks.

Five steps to reduce SOC alert fatigue

If your analysts are struggling with alert volumes, the solution is not simply to switch off noisy detections. Instead:

1. Understand where the noise comes from. Identify which detections, systems and behaviours are generating disproportionate numbers of alerts.
2. Fix problems upstream where possible. Improve configuration and preventative controls so avoidable activity never needs SOC investigation.
3. Tune according to risk, not convenience. Adjust thresholds and detection logic, but understand the detection gaps every change could create.
4. Automate repeatable investigation. Turn the checks analysts repeatedly perform into playbooks and automated workflows that can reduce unnecessary human effort.
5. Keep humans in the loop. Use automation and AI to give analysts better information and fewer repetitive tasks – not to remove expert judgement from security operations altogether.

SOC tuning is about improving signal, not simply reducing volume

Alert fatigue is ultimately a symptom of a wider challenge. SOCs need broader visibility and stronger detection capabilities at exactly the same time as attackers are becoming faster and more sophisticated. Simply generating fewer alerts is not the answer.

Effective SOC tuning means understanding what your detections are telling you, removing unnecessary noise without blindly creating detection gaps, addressing configuration problems upstream, and using automation to make better use of analyst time.

Generative and agentic AI could take that model significantly further. If SOCs can build the right automation foundations, AI can increasingly perform the repetitive investigative work between an alert firing and an analyst deciding what to do about it.

The SOC of the future may therefore process far more signals while asking humans to investigate far fewer of them. And that could be the key to conquering alert fatigue without compromising your ability to detect the threats that matter most.

Is alert fatigue stopping your security team from focusing on genuine threats? Speak to our cyber security experts to explore how SOC tuning, automation, and the right operating model can help you improve detection and response without overwhelming your analysts.