Hydrolix is a real-time data platform company that helps organizations manage and analyze massive volumes of streaming data. Its technology combines high-speed ingestion, long-term data retention and fast querying to support use cases including observability, cybersecurity, log analytics and AI-driven applications while helping reduce the cost of storing large-scale data.
For years, the SIEM has served as the nerve center of security operations. But rising telemetry volumes, costly retention and AI-assisted investigations are prompting managed security service providers to reconsider how security data is stored, searched and analyzed.
Digital IT News spoke with Matteo Rebeschini, Field CISO at Hydrolix, about the changing SIEM architecture and what it could mean for MSSP operations, customer outcomes and profitability.
What has changed in the security landscape to make the traditional SIEM model less workable for MSSPs?
The SIEM was built for a world where humans ran every step of an investigation. There was some automation, like detection rules and alerting, but the platform was fundamentally designed around a person writing queries and reading results. The speed of the analyst was the speed of the system, so a few seconds or minutes of query latency was never a problem.
Two things have broken that assumption. The first is data volume. Enterprise telemetry is growing 20 to 30 percent a year, and in some environments closer to 50. Most organizations running a SIEM today are paying more than they planned because volumes outran the original scoping. And it’s not that SIEMs can’t technically scale; most can scale horizontally to a certain level. It’s that scaling becomes prohibitively expensive and operationally complex, so teams hit an economic ceiling long before a technical one.
The second, and bigger catalyst, is agentic security operations. Teams are starting to adopt LLMs as part of automated investigations, taking what SOAR started with static playbooks to the next level. But agents expose limitations that human analysts tolerated: long-running queries against large datasets, and delays of hours or even days to rehydrate archived data before it can be searched at all.
Meanwhile, the adversary side has already made this shift. An industry threat report published by CrowdStrike earlier this year found AI-enabled attack operations up 89% year over year, with average breakout time- meaning the gap between initial access and lateral movement- down to 29 minutes, and the fastest observed case at just 27 seconds. When attacks complete in minutes, a data architecture built around human query patterns is structurally behind before the investigation even starts.
MSSPs feel all of this first. Their business model depends on onboarding customers quickly and scaling economically, so they lean on automation more than most enterprises and build custom tooling to make things work. That makes them highly motivated to reduce total cost of ownership, both to protect margins and to price competitively.
Unlike heavily regulated enterprises that change their stacks slowly, MSSPs can adopt new architectures fast without disrupting the customer experience. So when the economics or the speed of the SIEM stop making sense, MSSPs are the first to act on it.
How do current SIEM economics influence which telemetry MSSPs ingest, retain or discard—and what security risks can those decisions create?
For MSSPs, like any large enterprise, there are always hard decisions that have to be made when the cost is a constraint for a SIEM. You deploy a SIEM, the vendor does an estimation of the capacity and licensing you need, and how much it will cost, and very quickly you see you are ingesting more than you expected.
This happens with MSSPs too. When they scope an agreement with a customer, they do an estimation of the volume of data that will be ingested, and then as they are deploying, they see the volume of data coming in is higher than what was expected. So the MSSP is left with three options, and none of them are good.
They can go back to the customer and ask for more money, which strains the relationship and makes them look like they scoped the deal wrong. They can absorb the cost themselves, which erodes the margin the business runs on. Or they can reduce visibility, deciding which log sources matter most from an ingestion and retention point of view.
Most end up choosing the third option because it’s the only one that doesn’t show up on an invoice. But the cost is still there, just hidden. You can’t reliably know in advance which telemetry will matter from a risk or detection standpoint.
A log source that seems low-value today becomes critical the day a new vulnerability or attack technique emerges that touches it. That is the risk MSSPs and large enterprises take on every time they decide not to observe certain logs. It’s like having a physical security camera system.
You can’t afford to cover the entire structure you are monitoring, so you choose to not install cameras in areas where you think there’s less risk. But that’s a risk too because you lose visibility and you can only protect what you can observe.
Are MSSPs preparing to replace the SIEM, or reposition it within a more modular security architecture?
Today, reposition. But the door to replacement is open wider than it’s ever been. Most MSSPs already use only part of a SIEM because of their specific requirements around multitenancy, automation, and fast customer onboarding. They build solutions for their customers rather than reselling a SIEM as a service.
That usually means their own collection agents under their own brand, detection logic they develop and maintain outside the SIEM so it can be deployed consistently across every tenant, custom SOAR workflows tailored to each customer’s environment and response procedures, and scripts and automation pipelines that let them onboard a new customer in days instead of weeks.
Even before agentic AI, many were using the SIEM mostly as a data layer and building detection, automation, and investigation capabilities around it. So MSSPs have always been open to options outside the SIEM when it adds capability or reduces cost.
What’s changed is that agentic security operations are accelerating the question. As automation takes over the human-centric role the SIEM was designed for, MSSPs are asking why they should pay full price for a platform when they use a small part of what it offers.
For most, the near-term answer isn’t ripping the SIEM out. It’s keeping the SIEM for detection and the workflows analysts know, and adding a purpose-built data layer underneath it for the cases where SIEM economics break down: when data volumes get too large or retention gets too expensive.
But here’s what makes this moment different. Once an MSSP has detection logic it owns, automation it built, and a data layer handling storage and search, the SIEM’s remaining role keeps shrinking.
Each new agentic capability takes over another function that used to justify the license. MSSPs won’t replace the SIEM as a strategic decision; they’ll wake up one renewal cycle and realize there’s not much left to renew.
What is a security data layer, and which capabilities distinguish it from a conventional security data lake?
Data lakes solved the storage-cost problem: put everything in cheap object storage and stop paying SIEM ingest rates for every byte. But the industry learned quickly that cheap storage alone isn’t a solution. There’s a reason the term “data swamp” entered the vocabulary.
Lakes became dumping grounds where telemetry went in ungoverned and undocumented, and where data effectively went to die because nobody could find it or use it. And for an MSSP holding customer telemetry, an ungoverned swamp isn’t just useless; it’s a compliance liability.
Even a well-governed lake doesn’t solve the harder problem, which is access. Most lakes apply structure at query time, so getting answers means scanning large volumes of raw data. And most tier data by age to control costs: recent data might be reasonably fast to search, but older data gets moved to colder storage tiers where it’s either slow to scan or, in true archive tiers, has to be restored before it can be queried at all.
Analysts learn to avoid that data because reaching it takes too long, which defeats the point of retaining it. You can store massive amounts of telemetry in a lake, but storage without fast access is an archive, not an operational resource.
The security data layer is designed around access, specifically for the requirements of agentic security operations. Data still lives in low-cost object storage, but in a single tier: everything is equally queryable whether it’s an hour old or five years old, with no rehydration step and no waiting.
High compression is what makes that economically viable, because you’re retaining years of full-fidelity telemetry at a fraction of the raw footprint. The distinction matters most for agents. A human analyst can tolerate a tiered system with occasional delays. An agent running an investigation makes hundreds of queries, and every one of them needs to come back at machine speed.
Beyond reducing storage costs, how could a redesigned SIEM stack affect investigation speed, customer service and MSSP profitability?
If an MSSP is paying full SIEM rates but only using a fraction of the platform, moving high-volume telemetry to a data layer can meaningfully improve margins. Data is less costly to store in a data layer than paying for a full SIEM, especially when there’s high compression, and that data can be stored for years. That opens capabilities that weren’t previously economical, like offering customers years of searchable retention instead of the typical 90 days.
When it comes to security analytics and incident response, all activities are faster if you use a security data layer that doesn’t tier data. Agentic security operations use the data layer as a way to detect and respond faster. Adversaries always have first-mover advantage, and now they’re using AI to move even faster.
This has become an AI-versus-AI contest. Adversaries are using LLMs to automate reconnaissance, generate exploits, and run full attack chains. The only viable counter is agentic defense operating at the same speed — and agentic defense is only as fast as its slowest component. In most security stacks today, that slowest component is data access
What demands will AI-assisted and agentic investigations place on security-data access, quality and query performance?
Humans may have tolerance for slower responses and queries. A few seconds or minutes may not be perceived as slow when doing investigations manually but things change a lot when you have LLMs that operate faster than the speed of humans. When agents drive investigations, every slow query compounds: the agent stalls, retries, re-queries, and burns more compute and time on each reasoning loop.
Fast data access directly reduces both the cost and the latency of every agentic investigation. If your security operations run at the speed of AI, your data layer has to run at that speed too. Traditional SIEMs were engineered around human query patterns, where a few seconds of latency was fine when a person was reading the results. It isn’t fine when an agent is making hundreds of queries per investigation. The defining question for security architecture now isn’t features; it’s whether every component in the stack can operate at machine speed.
Related News:
