TL;DR: Gartner’s 2026 Security and Risk Management Summit elevated security data lakes as a new category while removing standalone security data pipelines from the Hype Cycle, reflecting a shift from routing data as infrastructure to treating the data layer as the foundation for detections, according to Axoflow. The market is moving toward architectures where collection-time detection, normalization, and downstream analytics are separated deliberately, and that changes how SOC teams evaluate cost, portability, and control.
Editorial analysis by NHI Mgmt Group, based on content published by Axoflow: “The pipeline was never the destination”.
Key questions
Q: How should security teams separate detection logic from security data transport?
A: Treat transport, normalization, and detection as distinct functions.
Q: Why do security data lakes help SOC teams more than simply buying a bigger SIEM?
A: Because the core problem is usually storage economics, not detection ambition.
Q: What breaks when identity telemetry is not normalized before analytics?
A: Correlation becomes brittle, especially across service accounts, tokens, cloud workloads, and endpoint events.
Practitioner guidance
- Define the security data layer as a separate architecture domain Document where collection, normalization, detection, storage, and investigation each happen so teams stop treating the pipeline as a single undifferentiated system.
- Move high-value detections closer to collection time Run correlation and filtering before telemetry reaches premium SIEM storage, then forward only alerts and normalized events downstream.
- Preserve identity telemetry in schema-consistent form Standardize service account, token, workload, and access events early enough that rules can correlate them across cloud and endpoint sources.
Bottom line: Security data lakes shift the SOC conversation from ingest volume to the quality of the data layer that feeds detection.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Security data lakes are not a storage trend, they are a control-plane shift. Once detection logic moves closer to collection, the architecture stops being about log retention and starts being about how security decisions are produced. That changes the governance model for SOC data because the pipeline, the normalization layer, and the analytics layer now need separate accountability. Practitioners should evaluate whether their current stack can actually support that split.
A few things that frame the scale:
- 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
A question worth separating out:
Q: What does a security data lake change for SOC governance and accountability?
A: It forces teams to separate ownership of data movement, detection design, and storage economics. That matters because governance fails when one team is accountable for ingest cost, another for alerting, and nobody owns the quality of the data layer that makes detections work.
👉 Read our full editorial: Security data lakes are changing security operations architecture