MSPs are increasingly turning to Machine Learning-based monitoring to cut through the noise of traditional alert systems and improve detection of genuine threats. Ziad Nasr, General Manager, Acronis Middle East, tells us how organisations can harness Machine Learning (ML) to enhance Security Operations Centre (SOC) efficiency while ensuring analysts remain engaged and vigilant.
For years, managed service providers (MSPs) have battled with alert fatigue, that endless deluge of red flags from traditional monitoring systems that often turn out to be noise rather than meaningful threats. At best, it’s a distraction. At worst, it numbs response teams to real incidents, turning security operations centres (SOCs) into environments where everything blares and nothing gets prioritised.
Enter Machine Learning (ML)-based monitoring, and with it, the promise of clarity. Smarter systems, fewer false positives, quicker detection of anomalies. It’s a long-overdue evolution in how MSPs manage risk and uptime. But as MSPs embrace this new monitoring paradigm, it’s worth asking a harder question: what are we giving up in exchange for this new precision?
Because while ML is solving one problem, it may be quietly introducing another.
From too much noise to not enough sound
Traditional monitoring tools don’t discriminate. A spike in CPU usage, an unusually timed login or a failed update patch, even when harmless, can trigger an alert. Now multiply that across multiple clouds and thousands of endpoints, and it’s easy to see how a Monday morning can spiral into a fog of notifications, dashboards and fire drills. For many MSPs, that’s not a hypothetical, it’s just another start to the week.
ML-based monitoring promises something radically different. These systems learn over time, filtering out background noise, clustering related events, and flagging anomalies that actually warrant attention. The result is not just fewer alerts, but better ones, and a clearer picture of what’s going on beneath the surface.
But herein lies the catch: what happens when the alerts stop coming?
For SOC engineers, and especially junior staff, the constant stream of notifications wasn’t just a nuisance, it was much needed hands-on education. Each false positive was a chance to explore, to ask why something flagged, to get under the hood of the system. With fewer alerts, we may be losing a key training ground. And worse, teams may start to assume the system has it all under control. That’s when silence becomes dangerous.
Cured, but complacent?
Just as fatigue from too many alerts dulls focus, over-reliance on ML can do the same, but in subtler ways. Once teams begin to trust the system implicitly, there’s a danger of assuming it’s always right, or that it’s caught everything worth catching.
So, understand the impact, consider how subtle configuration drifts are typically uncovered. Often, these affect a handful of customer environments for weeks and don’t trigger alerts because these changes occur gradually, and behaviours technically fall within the learned baseline of ML systems. Such issues usually only come to light when support engineers notice an uptick in unusual helpdesk queries and decide to investigate manually.
Incidents like these are reminders that ML tools are remarkable, but they aren’t omniscient. They depend on training data, contextual parameters and decision thresholds — all of which can age or become misaligned with evolving systems. If no one is watching the watchers, important details can slip through the cracks.
ML monitoring is a game-changer, but it’s not set-and-forget
None of this is to say ML-based monitoring isn’t valuable. When used well, it transforms how MSPs scale operations. ML-based alerting goes beyond static thresholds, drawing from telemetry, logs and real-time behavioural data to deliver a richer, more accurate view. It frees up analysts to focus on genuine threats, supports faster root cause analysis and enables a more proactive security posture. For stretched SOC teams, it’s a welcome evolution.
But these systems aren’t ‘set-and-forget’. Models drift. Contexts shift. And clients’ needs evolve. If no one is validating the outputs, tuning the thresholds or questioning the results, the quality of protection can quietly degrade.
Regular audits of model performance are therefore essential, not just in terms of false positives, but false negatives too. Teams should be manually reviewing anomalies that the system didn’t flag, running routine spot-checks, and understanding the logic behind the decisions being made. Cross-training staff in how these models work will help them question and interpret outputs with a critical eye, rather than treating alerts (or the absence of them) as infallible truth.
Honing the human edge
So how can MSPs keep their teams engaged and sharp in an environment that feels increasingly automated?
The trick is to actively design opportunities for engineers to stay sharp, even in a world with fewer alerts. Start with something as simple as post-incident reviews. When the system catches something, don’t just thank the algorithm and move on. Walk through the detection journey. What signal tipped it off? What data did it correlate? Would a human have caught it, or missed it?
Tabletop exercises are another useful strategy. Simulate events that the system isn’t designed to detect — such as a partner API going rogue, or a rogue insider gradually escalating privileges. Challenge engineers to spot the signals the system might miss, such as a shift in ticket tone from a customer, or a repeated pattern of minor access anomalies across unrelated endpoints.
There’s also value in encouraging a broader view. Some threats don’t leave neat logs or signatures. Socio-technical factors such as a stressed insider, a business partner behaving oddly, a sudden shift in external communication might not trigger the system, but they matter. These are the kinds of patterns humans are particularly skilled at detecting.
These exercises don’t need to result in a major discovery. They’re about maintaining the mindset that not everything worth noticing will appear in an alert.
A smarter SOC is still a human one
Ultimately, ML-based monitoring should be seen for what it truly is: a force multiplier. It doesn’t replace your SOC analysts, it amplifies them. It gives them time back. It removes the drudgery. It lets them focus on high-impact work.
The smartest MSPs won’t be the ones who lean back and let the platform run the show. They’ll be the ones who lean in, using ML to elevate their teams, not sideline them. They’ll invest in both the tech and the talent. And they’ll build SOCs that are not only more efficient, but more resilient, more curious and better prepared for the threats the models haven’t seen yet.
Because at the end of the day, it’s not about reducing alerts, it’s about staying alert.
