Notifications
Clear all
Topic starter
18/08/2026 2:29 pm
TL;DR: Security data pipelines are becoming the control point for routing, shaping, and enriching telemetry before it reaches SIEM and analytics platforms, but the trade-off between flexibility and operational complexity still constrains teams, according to TENZIR. For identity and security programmes, the practical issue is not tooling preference, but whether the pipeline can be governed, versioned, and adapted without creating specialist bottlenecks.
NHIMG editorial — based on content published by TENZIR: security data pipelines, low-code control, and open-core flexibility
Questions worth separating out
Q: How should security teams govern multi-tenant telemetry without duplicating pipelines?
A: Security teams should separate tenant execution from central policy oversight.
Q: When does telemetry sampling create more risk than it reduces?
A: Sampling creates more risk whenever the stream carries incident evidence, high-value errors, or security-relevant state changes.
Q: What do organisations get wrong about low-code security data tools?
A: They often assume low-code means low governance overhead.
Practitioner guidance
- Version-control pipeline logic Store parsers, routing rules, and enrichment logic in Git so changes are reviewable, testable, and rollback-ready rather than trapped in a GUI.
- Define telemetry preservation rules Identify identity, access, and high-signal security events that must never be reduced or dropped, then codify those preservation rules before cost optimisation begins.
- Audit specialist dependency points Map which pipeline components require deep product expertise and reduce single-owner bottlenecks through documentation, peer review, and operational runbooks.
What's in the full article
TENZIR's full article covers the operational detail this post intentionally leaves for the source:
- The TQL operator examples that show how routing, enrichment, and shaping are chained in practice
- The product comparison scenarios that contrast parser handling, cost reduction, and platform lock-in
- The open-core architecture argument, including how the underlying engine supports extension and transparency
- The community library workflow for reusable parsers, pipelines, and context packages
👉 Read TENZIR's analysis of low-code security data pipelines and open-core control →
Security data pipeline flexibility: what practitioners should re-evaluate?
Explore further
18/08/2026 3:17 pm
Security data pipelines have become governance infrastructure, not plumbing. Once routing and enrichment decide which identity and security events survive into downstream platforms, the pipeline itself becomes part of control assurance. That matters for IAM, NHI, and investigations because missing telemetry is a governance failure, not just an ingestion issue. Practitioners should therefore treat pipeline design as a formal control surface.
A question worth separating out:
Q: What is the difference between pipeline flexibility and pipeline governability?
A: Flexibility is the ability to build many kinds of data flows. Governability is the ability to understand, review, test, and safely change those flows over time. A platform can be highly flexible but still hard to govern if its logic lives in opaque menus or specialist scripts that only a few people can maintain.
👉 Read our full editorial: Security data pipelines need flexibility without operational lock-in
