For years, the SIEM has been the center of gravity in the security operations center. It was where the logs went, where detections fired, and where analysts sat to piece together what happened. If you were standing up a SOC, the SIEM was the first thing you bought and the last thing you would think to question.
Now the question is being asked out loud. In the past year, three out of five customers 7AI talked to said the same thing: they want to stop putting everything into the SIEM. The tool still works. What changed is the world around it. Data outgrew budgets; security telemetry was scattered across cloud platforms, SaaS applications, identity providers, and data lakes; and the founding promise that centralizing everything would make the team faster began to clash with what analysts experienced.
Three things stopped adding up: the cost of centralizing every log, the assumption that data should live in one place, and a detection model that asks teams to choose between noise and blind spots.
What the SIEM was built to do
To understand why teams are reconsidering the SIEM, it helps to remember what made it critical in the first place. The SIEM solved a real problem, and it solved it well enough to run the SOC for decades.
In the early days of security operations, the challenge was fragmentation. Every system produced its own logs in its own format, sitting in its own silo. A firewall knew what it saw, the domain controller knew what it saw, and no one could connect the two. The SIEM's insight was to pull all of that into one place: collect the logs centrally, normalize them into a common shape, and give analysts a single pane of glass to search across everything at once.
That unlocked work the SOC could not do before. Detection could run rules against data from across the environment, so a pattern that spanned systems could actually be caught. Investigations had somewhere to go, a central store an analyst could query to reconstruct what happened. And compliance had a home, with retention and reporting that auditors could point to.
For an on-premise world, the logic was sound. Systems lived in a data center you controlled, data volumes were large but manageable, and centralizing everything was the most reliable way to see across it. The SIEM became the center of the SOC because, at the time, centralizing was the best answer.
Why the model is straining now
The environment the SIEM was built for stopped existing. The conditions that once made centralizing the obvious choice have quietly inverted, and each one puts pressure on a different part of the model.
The economics flipped
When data lived in a data center, ingesting it into the SIEM was manageable. Then telemetry exploded. Cloud, identity, endpoint, SaaS, and network sources now generate volumes that would have been unthinkable a decade ago, and SIEM pricing scales with exactly that: how much you ingest and how long you keep it. Teams found themselves making security decisions on budget grounds, dropping log sources or shortening retention to control spend.
Centralization stopped matching where data lives
The single-store premise assumed you could, and should, pull everything into one place. Today the data already lives in capable systems that aren't going anywhere. Duplicating all of it into a separate SIEM means paying to store it twice and keep two copies in sync, some of which may never be queried.
That pressure is why security data lakes (SDLs) have gained popularity. Teams adopt them for the storage economics: keep everything for longer, at a fraction of SIEM rates. But they come with trade-offs. The lake holds the data and leaves detection to another system, speaks a different query language than the one your team already knows, and returns results slowly enough that analysts feel it. Storage costs drop. Detection and query speed stay tied to the SIEM, and the work of connecting the two lands on analysts.
Detection became a trade-off
The SIEM was very good at allowing detection engineers to find suspicious patterns. But teams were left with bad choices. Either wide-ranging alerts that are inaccurate and prone to false positives, drowning the team, or extremely narrow alerts that are akin to signatures, missing even small variants of the original pattern. Both choices are bad. The former causes analyst burnout, and the latter makes you blind.
Whichever way a team tunes it, the output is signal that a person still has to resolve, and the volume has outpaced the humans doing it.
The SIEM still does what it was built to do. The assumptions underneath it — cheap centralization, one place for data, and detection accurate enough that a human could keep up with the output — are what stopped holding. That is what teams are responding to when they start to rethink it.
What moving data to a lake actually costs
For most teams, the first move is practical: route the high-volume sources — network flows, DNS, cloud audit logs, raw endpoint telemetry — into an SDL and keep the rest in the SIEM. The invoice responds immediately. Storage runs at a fraction of SIEM rates, and retention stretches from months to years.
The analysis stays behind. The data is still there and still queryable, and the detection content covering it lives in the SIEM, written in the SIEM's language against the SIEM's schema. Bringing that coverage to the lake means rewriting the rules for a different query engine, revalidating them, and maintaining two detection estates in parallel. Many teams reach that step, weigh the engineering, and leave the lake as archive.
So the migration hardens into a visibility decision. Every source a team moves for budget reasons becomes a source detection engineers stop writing against, and every source they keep for coverage reasons is one they pay SIEM rates to hold. Analysts feel it during investigations: the well-covered data sits in one system, the deep history sits in another with a different query language and slower response, and connecting the two is manual work done under time pressure.
What "rethinking" actually looks like
Rethinking the SIEM starts with the one assumption underneath it: that data has to come to the analysis. Most teams now hold their telemetry in at least two places, the SIEM and a security data lake, and the split has been managed by hand. Analysts are pivoting between tools and stitching the picture together themselves. The shift underway puts the analysis on top of both.
The shift shows up in three ways, and they line up with the pressures the team feels.
- From centralize-then-analyze to query where the data lives: The old model says move everything into one store, then run detection and investigation. A federated approach breaks the link between where the data sits and where analysis happens. Detection and investigation run against the data in place, in your SIEM, in your security data lake, in your cloud platforms, so the lake becomes a detection surface on equal footing with the SIEM. Each source keeps its own format and query language; results come back normalized to a common shape, so one question gets answered across all of them at once. You keep the lake's storage economics and gain detection on top of them.
- From more alerts to answers: A traditional SIEM is very good at producing signal and leaves the interpretation to people. The new model puts the investigation itself in scope: agents pull the context, follow the leads across tools, and hand an analyst completed casework to approve, adjust, or escalate. Humans stay on the loop and own the decisions that matter. The volume stops landing on a person first.
- From tool-bound to tool-agnostic: Analysis welded to one central store can only answer questions about what you already centralized. Analysis that travels reaches across the tools you already run and acts on what it finds. The SIEM becomes one of several places your data can live.
Where 7AI fits
If the shift is toward querying data where it lives, the natural question is what that looks like in practice. It's the idea behind 7AI's Federated SIEM.
Federated SIEM connects to your data where it already sits, across your existing SIEM, your security data lake, and your cloud platforms, and puts agents to work on top of it. Detection is abstracted from storage, so the same detection logic runs across all of those sources at once. Investigations happen across them too, and your team stays on the loop: agents carry the volume, people direct the work and make the calls that matter. Over the past year, those agents have completed more than 9 million investigations and returned over a million analyst hours to customer teams.
Moving a source to cheaper storage becomes a pure cost decision, with coverage holding steady wherever the data lands.
The part that matters most is that you set the terms. Keep as much in your SIEM as you want, move as little as you want, and change your mind later without having to redo everything.
See how our Federated SIEM works and how it compares to traditional deployments.
