They should prioritise centralisation when distributed services make it difficult to answer basic investigation questions or when volume and cardinality are making storage and analysis cost-prohibitive. Centralised, structured evidence is more valuable than additional raw telemetry that cannot be queried or correlated effectively.
When centralisation beats more collection
Prioritise centralised telemetry when the real problem is not lack of raw signals, but inability to answer basic investigative questions quickly and consistently. If events are scattered across teams, tools, or regions, correlation becomes slow, blind spots multiply, and responders spend more time stitching together evidence than understanding what happened.
Centralisation also wins when scale changes the economics of analysis. Very high event volume, noisy cardinality, and duplicated storage can turn “collect everything” into an expensive way to collect little that is actually usable. The better test is whether the data can be queried, joined, and retained in a form that supports incident work.
What “better telemetry” means in practice
Centralised telemetry is not just a bigger logging bucket. It means choosing a smaller, more structured set of evidence that supports cross-system questions such as who did what, from where, in what sequence, and with what outcome. That usually requires common fields, consistent timestamps, and enough context to correlate across services without rebuilding the story from scratch.
The practical trade-off is depth versus usability. More local data can help a single team diagnose one component, but it often adds fragmentation when the question spans multiple services or control planes. Structured central evidence is usually more valuable than additional raw events that cannot be searched, normalised, or linked to other sources.
In mature environments, centralisation also improves retention discipline. You can keep high-value evidence longer, drop low-value noise sooner, and reserve expensive storage for data that is actually useful for detection, forensics, and auditability. That is often a better outcome than expanding collection indiscriminately.
How to decide whether to centralise first
Use centralisation first when the current telemetry model fails one of three tests: you cannot answer the investigation question, you cannot correlate events across domains, or you cannot sustain the storage and analysis cost. If any of those are true, the next improvement is usually better shape and placement of data, not more data.
By contrast, if a specific gap is caused by missing coverage from a genuinely important source, then expanding collection may still be justified. The key is to distinguish absence of evidence from evidence that is present but operationally unusable. Those are different problems and they need different fixes.
A sensible rule is to centralise the evidence needed for shared security questions first, then selectively add new sources only where they close a known investigative gap. That avoids building a telemetry estate that is broad on paper but weak in analysis.
Risk and Threat Considerations
Distributed telemetry creates two forms of risk: operational blindness and decision delay. When logs are fragmented across systems or teams, suspicious activity can blend into normal local noise, and incidents take longer to detect, scope, and contain. The same fragmentation also makes retention gaps and inconsistent data quality more likely.
Failure mechanism: telemetry remains trapped in isolated tools, schemas, or ownership silos, so responders cannot reliably join events into a single investigative timeline and storage growth outpaces analytical value.
Impact: the organisation misses weak signals, spends more on collection than on usable evidence, and increases the chance that an attacker or fault will remain misunderstood long enough to widen its blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — The network is monitored to detect potential cybersecurity events | Centralised telemetry directly supports unified monitoring and detection across distributed services. |
| GV.OV-01 — Cybersecurity risk and performance are monitored and results are used to inform risk management decisions | Telemetry centralisation is a governance decision about observability value versus collection cost. | |
| Recommendation — Consolidate telemetry into a monitorable pipeline that improves event detection and correlation. Use central telemetry metrics to steer collection priorities and retire low-value sources. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Logging controls depend on logs being usable, searchable, and centrally reviewable for investigation. |
| Recommendation — Centralise logs so investigations can query and correlate them efficiently. | ||
Practitioner Guidance
What to prioritise: start with the evidence that answers shared security questions, not the source that is easiest to collect. If multiple teams need to correlate the same behaviour, centralise that stream before you expand niche local retention.
What to measure: track mean time to answer a standard investigative question, query success across domains, and the ratio of stored telemetry to telemetry actually used in investigations. If the ratio is poor, you likely have a collection problem disguised as a visibility problem.
Decision rule: if a new source adds volume without improving correlation, reconstruction, or retention value, reject it or downsample it; if it closes a documented investigative gap, add it in structured form and route it into the central analysis path.
Practitioner takeaway: centralise when analysis, not collection, is the bottleneck. The goal is evidence that is consistently usable, not a larger pile of data that still cannot answer the question.
Related resources from NHI Mgmt Group
- When should organisations prioritise analytics investment over collecting even more data?
- When should organisations prioritise self-service data infrastructure over a centralised data team model?
- Should organisations prioritise data awareness over manual tagging?
- When should organisations prioritise DSPM over another data security project?