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.
Editorial analysis by NHI Mgmt Group, based on content published by DataBahn: “Data Pipeline Management and Security Data Fabrics”.
By the numbers:
- ~70% of the data being sent to SIEMs is not security-relevant.
- DataBahn says it delivers a 35%+ reduction in SIEM costs by reducing log sizes in 2-4 weeks.
Key questions
Q: What breaks when security data pipelines are treated as simple plumbing?
A: The control model breaks because routing, enrichment, and retention decisions get made too late.
Q: Why do SIEM-centric pipelines create hidden governance risk?
A: Because the organisation pays for ingestion volume even when much of the data has little security value.
Q: What are the signs that telemetry enrichment is failing in practice?
A: Enrichment is likely failing when data cannot be separated by the attributes teams expect, when troubleshooting still requires manual searching, or when logs and metrics remain hard to classify.
Practitioner guidance
- Define pipeline ownership as a governed control Assign accountable owners for collectors, connectors, transformations, and routing rules so machine access to telemetry flows is tracked like any other privileged dependency.
- Classify telemetry by security value before SIEM ingestion Create routing policies that distinguish high-value security events from routine data so full-fidelity SIEM storage is reserved for detections that justify the cost.
- Reduce brittle integration paths for new sources Standardise onboarding patterns for custom apps and unstructured sources so adding telemetry does not require repeated manual engineering work or long-lived exceptions.
Bottom line: Security data pipeline design is a governance issue because it determines where cost, loss, and visibility risks are absorbed.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:59 pm
Security data pipeline governance is now an identity problem as much as a data engineering problem. Every collector, connector, and routing service depends on machine credentials that need ownership, scope, and offboarding. That makes telemetry infrastructure part of IAM and PAM, not a separate engineering concern. Practitioners should treat pipeline access as governed machine identity.
A question worth separating out:
Q: How should security teams govern machine identities in industrial environments?
A: Security teams should govern machine identities the same way they govern privileged access: assign an owner, define a specific purpose, limit scope, and review it continuously. In practice, that means tracking service accounts, certificates, APIs, and connectors as non-human identities with their own lifecycle, not as background infrastructure. A machine identity should never have broader access than its workflow requires.
👉 Read our full editorial: Security data pipelines expose the governance gap in SIEM-centric SOCs