Should organisations centralise all telemetry or route it by use case?

Why this is not really a centralize-versus-decentralize choice

The better question is whether telemetry is governed as one shared capability or fragmented into many duplicated pipelines. Centralising the policy for collection, retention, access and quality gives the organisation consistency, but routing data by use case preserves operational relevance. That combination avoids the false trade-off between a single lake and isolated point solutions.

Shared collection works best when the same raw events can support multiple consumers without each team creating its own copy, schema, or retention rule. If you centralise everything into one destination but then force every workload to read from it the same way, you usually create latency, cost, and ownership problems rather than better observability.

The practical rule is to centralise governance, not necessarily every delivery path. Different use cases, security monitoring, infrastructure troubleshooting, compliance review, and incident response, often need different transformations, priorities, and retention periods, even when they start from the same source telemetry.

How shared collection with intelligent distribution works

In a well-designed model, instrumentation lands in a common collection layer and is then routed to the right consumers based on purpose, sensitivity, and latency needs. That lets teams consume the same underlying data without maintaining separate ingestion stacks or competing definitions of the truth.

This model is especially useful when the same telemetry supports both real-time operations and slower investigative work. For example, a security team may need high-fidelity event streams for detection, while an infrastructure team may need aggregated metrics for capacity planning. A governed distribution layer can serve both without forcing either one into a one-size-fits-all pipeline.

Central governance should also define who can see what, which fields may be masked, and when raw versus transformed data is appropriate. That matters because telemetry often includes environment details, user identifiers, tokens, IP addresses, or other sensitive operational context that should not be broadly exposed just because the data is useful.

What to watch for when routing telemetry by use case

Routing by use case can fail when it becomes an excuse for uncontrolled duplication. The useful pattern is a single source of collection with explicit distribution rules, not many teams exporting the same telemetry into separate tools with inconsistent retention, access control, and naming conventions.

It also fails when the organisation treats every consumer as equal. Some workflows need low-latency delivery, some need long retention, and some need only sampled or summarised data. If those differences are not designed up front, the platform becomes harder to operate and the data becomes less trustworthy.

Clear ownership is another requirement. Shared telemetry only works when there is one accountable function for standards, schema changes, access policy, and data quality, even if multiple teams consume the output. Without that, routing decisions drift and nobody can explain why different tools show different answers.

Risk and Threat Considerations

Telemetry concentration creates a high-value target, but fragmentation creates its own exposure. If teams copy the same events into separate systems, each copy becomes another place where sensitive data can leak, retention can drift, or attackers can hide inconsistent traces.

Failure mechanism: Poorly governed distribution produces parallel pipelines, inconsistent masking, and uncontrolled access paths. That weakens both detection quality and data minimisation, and it can leave security teams blind to which copy is authoritative.

Impact: Organisations can end up with duplicated cost, weaker incident reconstruction, and avoidable exposure of sensitive operational data. In a compromise, fragmented telemetry can slow investigation because no single team can reliably correlate events across all copies.

Practitioner Guidance

What to prioritise: Set a central policy for collection, classification, retention, masking, and access, then allow use-case-specific routing on top of that policy. The policy layer should be stable; the delivery layer can vary by consumer need.

What to verify: Confirm that every telemetry route has an owner, a documented purpose, and a retention rule. If two teams need the same feed, check whether they can consume from one governed source rather than building parallel exports.

Common mistake: Treating centralisation as a storage decision instead of a governance decision. A single platform does not automatically solve duplication, and distributed tooling does not automatically create chaos if the rules are consistent.

Practitioner takeaway: The right model is shared collection with controlled distribution, because it preserves consistency for governance while still letting each use case receive the form of telemetry it actually needs.

Related resources from NHI Mgmt Group

• How should organisations centralise AI use case and model inventories?
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How can organisations reduce secret leakage in ServiceNow at scale?
• How do organisations reduce false positives in secret detection pipelines?