Notifications
Clear all
Topic starter
02/08/2026 12:23 pm
TL;DR: Legacy SIEMs struggle with rising telemetry volumes, long retention needs, and the need to keep data both searchable and secure, according to DataBahn. The governance shift is no longer about collecting more logs, but about controlling access, cost, and response speed across the data pipeline.
NHIMG editorial — based on content published by DataBahn: Why are Legacy SIEMs a problem? The Case for a Security Data Lake
By the numbers:
- Filtering and enriching telemetry before it reaches the SIEM has reduced data volumes by 50 to 70 percent in production deployments, cutting SIEM licensing costs by more than half without sacrificing the underlying log.
- One medical device manufacturer running OT-heavy manufacturing sites cut Splunk costs by over 50 percent within seven days of deploying edge-level filtering and enrichment, without dedicating engineering bandwidth to the rollout.
Questions worth separating out
Q: How should security teams secure a security data lake without slowing investigations?
A: Use separate roles for ingestion, search, and administration, and make read access broad enough for investigations but narrow enough to prevent tampering.
Q: Why do legacy SIEMs struggle when telemetry volume keeps rising?
A: Because storage, search, and correlation costs rise faster than the quality of the signal.
Q: What breaks when security data is centralised without strong access controls?
A: Analysts may lose trust in the evidence if logs can be edited, deleted, or exported too freely.
Practitioner guidance
- Separate read, write, and admin privileges for security data Limit who can modify schemas, retention rules, and export paths.
- Move enrichment ahead of retention decisions Enrich telemetry with asset identity, source reputation, and threat context before deciding whether it belongs in the SIEM or lower-cost storage.
- Define retention tiers by investigation and compliance need Classify logs into hot, warm, and cold storage based on incident response, forensic, and regulatory use cases.
What's in the full article
DataBahn's full article covers the operational detail this post intentionally leaves for the source:
- The architecture behind stream enrichment, including how context is attached before ingestion.
- The practical reasoning behind routing low-value telemetry to cheaper storage tiers.
- The vendor's explanation of how security data lakes support AI-ready SOC workflows.
- The compliance and retention discussion for organisations that must keep logs for multiple years.
👉 Read DataBahn's analysis of legacy SIEM limits and security data lakes →
Security data lakes and SIEM cost pressure: what teams should do?
Explore further
02/08/2026 1:23 pm
Security data governance is becoming an identity problem as much as a storage problem. When telemetry becomes a shared enterprise asset, the question is no longer whether logs exist but who can read, move, or alter them. That makes access segregation, audit trails, and operational privilege boundaries part of the security-data architecture itself. Practitioners should treat the data lake as a controlled evidence system, not a passive archive.
A question worth separating out:
Q: What should organisations prioritise first: SIEM tuning or data-lake governance?
A: Governance first, because tuning a costly pipeline does not fix weak access, poor retention design, or untrusted evidence. Once roles, retention tiers, and auditability are defined, SIEM tuning becomes more effective because the pipeline is working with cleaner and more intentional data flows.
👉 Read our full editorial: Security data lakes are replacing legacy SIEM bottlenecks
