Notifications
Clear all
Topic starter
02/08/2026 11:50 am
TL;DR: SIEM ingest costs, data loss risk, and proprietary schemas make security data pipelines a governance problem as much as an engineering one, according to DataBahn, with up to 70% of ingested data being non-security-relevant and some integrations taking 4 to 8 weeks. The architectural shift is less about moving logs faster and more about deciding where enrichment, routing, and resilience should sit in the security stack.
NHIMG editorial — based on content published by DataBahn: Why are legacy SIEMs a problem? Data pipeline management and security data fabrics
By the numbers:
- ~70% of the data being sent to SIEMs is not security-relevant.
Questions worth separating out
Q: How should security teams reduce SIEM costs without creating blind spots?
A: Security teams should move from ingest-everything thinking to governed data routing.
Q: Why do security data pipelines create operational risk in SOC environments?
A: They create risk when ingestion, transformation, and delivery are tightly coupled.
Q: What breaks when logs are not standardised before they reach downstream tools?
A: Correlation breaks first, followed by enrichment quality and auditability.
Practitioner guidance
- Define telemetry criticality tiers Classify logs, identity events, and workload signals into high-value, investigative, and archive tiers before ingestion so the SIEM only receives data that justifies its cost.
- Implement fallback delivery paths Add a secondary ingestion channel for high-priority data so a single blocked pipeline does not create a blind spot.
- Standardise event schemas upstream Normalize fields before forwarding telemetry to downstream tools so security events retain the identity, asset, and context data needed for correlation.
What's in the full article
DataBahn's full article covers the operational detail this post intentionally leaves for the source:
- Concrete examples of how security data fabric architecture separates ingestion from SIEM dependency.
- The vendor's breakdown of 400+ connectors and 900+ volume reduction rules for different data sources.
- Implementation detail on loss-less ingestion via mesh architecture and secondary channel routing.
- Operational claims about reducing SIEM log size in 2 to 4 weeks that are useful for deployment planning.
👉 Read DataBahn's analysis of security data pipeline management and SIEM cost pressure →
Security data pipelines and SIEMs: what governance gap are teams missing?
Explore further
02/08/2026 12:59 pm
Security data sprawl is becoming an identity governance problem. When machine identities, service accounts, and application telemetry are all routed through the same data stack, the question is no longer just how to ingest logs. It is how to govern the evidence trail that identity, privilege, and workload activity depend on. Practitioners should treat pipeline design as part of control design, not as a back-end implementation detail.
A question worth separating out:
Q: Who is accountable when security data loss occurs in a blocked pipeline?
A: Accountability sits with the team that owns the telemetry architecture, not just the SOC that consumes it. If a pipeline drops events because there is no fallback path, then evidence preservation failed at design time. Governance should treat ingestion resilience as a security control, not a maintenance issue.
👉 Read our full editorial: Security data pipelines expose the governance gap in SIEM-centric SOCs
