For two decades, the SIEM was the Security Operations Center (SOC). One platform ingested the data, parsed it, stored it, normalized it, enriched it, ran the detections and supported the investigations. If you had a SIEM, you had a SOC.
That model is coming apart. Gal Shafir, Co-Founder and CEO of Fig Security, spent years on the SIEM side at Google SecOps. Today he sees most large security teams already taking it apart.
“The SIEM-centric era is ending,” says Shafir. “Teams are splitting the stack into pieces that each do one thing well. Pipelines handle ingestion and filtering. One SIEM brings free ingest and great content for certain logs, another runs the custom, high-stakes detections. A data lake or object storage sits beside them for retention and hunting, with federated detection engines running across all of it. The SIEM is still there, as one first-class component. It’s just not the whole SOC anymore.”
The stack is getting cheaper, better, and much harder to engineer
The upside is real. Each component does its job more efficiently, data lands where it is cheapest to keep, and teams stop paying premium prices to process everything in one place.
Shafir compares it to what happened to application infrastructure.
“Apps went from client-server to Kubernetes and microservices. Everything got more scalable, more efficient and cheaper. It also got far more fragmented, and that created a whole new discipline to run it. DevOps engineers made it work because they got the tools: CI/CD, infrastructure as code, observability. SecOps is going through the same unbundling right now, without those tools.”
Every new component adds configurations, schemas and dependencies that change on their own schedule. A single detection now depends on a source, a pipeline, a parser, a schema, a field mapping and a rule, often owned by different teams in different products. Each product describes only its own corner. None of them shows the whole flow.
AI raises the stakes. Agents are arriving across the stack: analyst agents on the SIEM, hunting agents on the data lake, red team agents probing telemetry and pipelines. They all run on that same fragmented data foundation. The 2026 SANS SOC Report found that 79% of SOCs use AI or machine learning tools, but only 36% have built them into a defined SOC workflow.
“AI never doubts its input,” Shafir says. “You can have the best agents in the world, and they’ll tell you everything is fine, because the alert they should be investigating never fired. A field got renamed upstream, the rule is looking for something that doesn’t exist in the data anymore, and nobody knows.”
Organizations are hiring engineers, not more analysts
The people are changing as fast as the stack. AI is taking on more of the triage and investigation work that used to define the SOC. Organizations are not turning analysts into engineers to fill the gap. They are moving away from staffing analyst work that AI can now do, and hiring engineers to produce more detection and response from an infrastructure that keeps getting more complex.
Most teams are early in that shift. SOC-CMM’s SOC Maturity Report 2026, a benchmark of roughly 200 SOCs, found that “most SOCs still operate with more analysts than engineers.” The same report expects that to change: “With SOCs moving towards a higher level of automation, with and without AI, engineering will play a more important role in future SOCs.”
“Everyone we talk to is hiring engineers right now,” says Shafir. “Pipeline engineers, detection engineers, SIEM engineers. They all run one flow that has to produce detection and response, and that flow gets harder to engineer every quarter.”
Four kinds of change, all speeding up
Shafir points to four pressures that make the engineering job bigger every year:
- Threats evolve faster. Attackers use AI too, so the window between a new technique and a detection that catches it keeps shrinking.
- Tuning costs more. When AI processes every alert, a noisy or broken rule is no longer just analyst fatigue. “Processing garbage always costs you analyst time,” Shafir says. “Now it costs you AI spend too.”
- The business changes faster. Teams across the company are shipping internal applications, many of them vibe coded, and every one of them needs to be monitored.
- The data changes faster. Vendors update log formats, new sources come online, and pipelines get reshaped for cost. Each change can quietly break detections downstream while the SOC still thinks it is covered, resulting in Drift.
“Teams are stuck between two bad options,” Shafir says. “Move slowly so nothing breaks, or move fast and risk gaps nobody finds until an incident. Neither one keeps up with the rate of change.”
SecOps as Code is the only way to scale
Shafir’s answer is to run security operations the way DevOps runs cloud infrastructure.
Detection as Code (DaC) was the right first step, he says, but it only covers the last link in the chain.
“Putting your rules in GitHub protects the link that rarely breaks on its own. Drift happens upstream. SecOps as Code means every layer, from sources and pipelines to parsers and detections, is defined, versioned, tested, shipped and rolled back as one system. Terraform didn’t version one server. It versioned the environment.”
SecOps adds a twist software teams don’t face.
“In software, you own the inputs,” Shafir says. “In SecOps, the input is logs owned by someone else, and it can change without telling you. So testing has to mean proving a rule still fires on the data as it looks today.”
The result is a different kind of team.
“The SOC is turning into a software team,” says Shafir. “SecOps engineers were asked to adopt the DevOps mindset without ever getting the DevOps tools. That’s the gap we have to close.”
None of it works without control over the whole stack
None of this is possible without full control and visibility over every part of the stack. That is the layer Fig is building.
Fig connects to any SecOps infrastructure through a read-only API and maps every data, detection and response flow, from each source through pipelines and parsers to the rules and workflows that depend on it, across every SIEM, pipeline and data lake. The mapping is deterministic, with no AI involved, so the map is ground truth. Engineers build on top of it. They design changes with the full context of their own environment, test every change before production through CI/CD with version control and rollback, and keep verifying that what shipped yesterday still works today. The same map gives AI the accurate picture of the environment it needs to be trusted.
“We don’t care whose logo is on the box,” Shafir says. “Build it or buy it, swap it next year, it doesn’t matter. Engineers should have one place to control the entire stack. Their job is to engineer security outcomes, not to manually change configurations in a dozen tools from a dozen vendors. That’s what we mean by being the operating system for SecOps.”
What the SOC of 2030 will look like
The SOC of 2030 won’t have fewer components. It will have more: more pipelines, more storage tiers, more detection engines, and agents built or bought for nearly every layer. What won’t change, Shafir says, is that a human engineer runs the whole stack.
The job itself will move up a level. Teams will set goals for coverage, cost and response, and systems will propose the changes to get there, such as data rerouted to cheaper storage or new detections built on data the team already collects, each one already tested. Engineers review and approve, and every change, from a person or an agent, goes through the same checks.
“Engineers should be doing security, not the bits and bytes of making the infrastructure work,” says Shafir. “The SOCs that win in 2030 won’t be the ones with the most tools or the most agents. They’ll be the ones that run their stack like software, and can change it as fast as the business and the threats do.”
Source: SOC-CMM®, SOC Maturity Report 2026 (May 2026), licensed under CC BY-SA 4.0.