Should organisations centralise telemetry policy or leave it to individual teams?

What central telemetry policy should control, and what local teams should still decide

Centralise the policy around the decisions that affect organisation-wide security and auditability: what must be retained, how long it must be kept, where it may be routed, who can access it, and which logs are mandatory for compliance or investigations. Local teams can still choose formats, verbosity, sampling, and service-specific fields, as long as they stay inside the approved policy envelope.

The practical test is whether a decision changes evidence quality, retention consistency, or the ability to reconstruct incidents across environments. If it does, it belongs in the central policy. If it mainly affects implementation detail or service tuning, teams can own it locally.

That split matters because telemetry is only useful when it is comparable across systems. Shared policy reduces blind spots, prevents duplicate logging standards from emerging, and makes it easier to prove that the organisation kept the right evidence for the right period.

Why decentralised telemetry rules create operational and compliance drift

Leaving the whole model to individual teams usually produces uneven retention, inconsistent routing, and different assumptions about what counts as an auditable event. Over time, that makes investigations slower because analysts have to learn each team’s logging habits before they can trust the data.

It also weakens governance. When teams set their own rules, one environment may retain the right records for thirty days while another keeps them for a year, or one service may forward security events to the SOC while another keeps them local. The result is not just inefficiency, but fragmented evidence and avoidable compliance exposure.

Central policy should therefore define the minimum viable security and compliance standard, then let teams exceed it if needed. That keeps the organisation from drifting into a collection of local logging cultures that cannot be compared or audited consistently.

How to balance shared governance with team autonomy

The cleanest operating model is policy at the centre, execution at the edge. Security, compliance, and platform owners define mandatory requirements, then engineering teams implement telemetry within those guardrails using their own service knowledge and release cadence.

Local autonomy is valuable when it improves signal quality. Teams often know which events are noisy, which fields help with troubleshooting, and which logs need higher fidelity during peak load. But that discretion should never extend to retaining less than required, bypassing central routing, or changing audit-relevant handling without approval.

For organisations that use common logging pipelines, this is where a central reference architecture helps. It gives teams a standard path for collection, enrichment, forwarding, and access control, while still allowing service-specific implementation choices. That pattern is consistent with broader security governance guidance in NIST Cybersecurity Framework 2.0 and logging control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls.

Risk and Threat Considerations

Telemetry policy becomes a security issue when inconsistent logging creates gaps in detection, evidence retention, or incident reconstruction. Attackers benefit when one team omits high-value events, shortens retention, or routes logs somewhere the SOC does not monitor, because those gaps reduce visibility and slow response.

Failure mechanism: Decentralised policy leads to uneven coverage, so important events are missing, inaccessible, or retained for different periods across environments. That breaks correlation, weakens alert triage, and can leave investigators unable to prove what happened.

Impact: The organisation may lose forensic value, miss lateral movement or privilege abuse, and fail to meet audit or regulatory expectations. At scale, the largest risk is not one bad log setting, but systemic inconsistency that makes the entire telemetry estate unreliable.

Practitioner Guidance

What to prioritise: Set mandatory standards first for retention, routing, access, and audit coverage, then permit teams to tune only the variables that do not change evidence quality. If a setting affects investigation, compliance, or cross-environment comparability, it is not a local preference.

What to verify: Check that each team can demonstrate where logs go, who can access them, how long they remain available, and whether security-critical events are consistently captured across production, staging, and third-party integrations. If the answer differs by environment, the policy is too loose.

Practitioner takeaway: Centralise the rules that make telemetry trustworthy, and decentralise only the choices that improve service-level signal without weakening auditability or incident response.

Related resources from NHI Mgmt Group

• Should organisations centralise certificate lifecycle management or leave it with application teams?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?