Gal Shafir on why the SOC of 2030 will run like a software team
The SOC of 2030 will look more like a software team
Security operations centers are moving away from one all-purpose SIEM. Gal Shafir, co-founder and CEO of Fig Security, says the SOC of 2030 will connect several specialized systems and manage them with the same discipline software teams use for cloud infrastructure.
That does not mean every 30-person company needs to build a miniature security engineering department. It does mean the old idea of buying one security platform and assuming it sees everything deserves a second look.
Why the single-SIEM model is breaking apart
For years, the SIEM sat at the center of the SOC. It collected logs, stored them, normalized the data, ran detections, and supported investigations. Shafir previously worked on the SIEM side at Google SecOps, so he has seen that model from inside the industry.
His argument is not that SIEMs are disappearing. It is that they are becoming one part of a larger system. One SIEM might offer attractive pricing for log ingestion. Another might handle custom, high-priority detections. A data lake or object storage system might keep older information for investigations. Detection engines could run across several of those locations.
That creates a practical problem. A security alert is only useful if the right data reaches the right rule. If a parser changes, a pipeline stops forwarding logs, or a storage policy moves data somewhere a detection cannot search, the system may fail quietly.
More tools do not automatically produce better protection. They can create more places for a small IT team to lose visibility.
What “security as code” means in plain English
Software teams do not make major changes by clicking through production systems and hoping for the best. They define changes, test them, track what happened, and keep a way back if something breaks. Shafir believes security operations should work the same way.
In this model, the team documents how data moves from its source through collection pipelines and parsers, into SIEMs or data lakes, and then into detection and response workflows. A planned change can be reviewed before deployment. The team can see which rules, alerts, and automated actions depend on it.
Fig connects to security operations infrastructure through a read-only API. It maps data, detection, and response flows across SIEMs, pipelines, and data lakes. That is less exciting than an AI agent that promises to investigate incidents by itself, but it addresses a more basic concern. Is the security machinery working at all?
That foundation matters. An automated response built on missing or misrouted data is still a bad response.
What this means for a small business
The article describes a future stack with ingestion pipelines, multiple SIEMs, data lakes or object storage, federated detection engines, and automated agents. For a large security team, that may become normal. For a small business, copying that design would be expensive and unnecessary.
We would not recommend buying several security platforms just to match a prediction about 2030. We would first make sure the basics are visible and tested. That means identifying which systems generate security logs, confirming that important logs actually arrive, checking how long they are retained, and testing whether alerts reach a person who can act.
We would also document the dependencies. If Microsoft 365 sign-in logs feed a detection rule, that relationship should not live only in one technician’s memory. If a firewall change affects remote access alerts, the team should know before the change goes live.
For many small and mid-sized businesses, “security as code” will start as disciplined documentation and change control. It does not require a full DevOps department or a new product purchase.
Our view of the 2030 prediction
Shafir is probably right about the direction. Security products already divide work among log platforms, endpoint tools, identity systems, cloud services, automation platforms, and specialized detection products. That fragmentation will not make the job simpler.
But the headline can sound more revolutionary than the business impact really is. A 30-person company does not need multiple SIEMs because a startup executive described the SOC of 2030. It needs reliable logging, sensible retention, monitored alerts, and someone accountable for fixing failures.
The useful lesson is control, not complexity. Before adding another security tool, ask what data it receives, what happens when that data stops, and how the team will prove the alerting still works after a routine IT change.
Ask IT911Now to review those data flows with you. We can help identify the gaps first, then decide whether any new security product earns a place in the budget.