Who should own routing and retention policy when telemetry spans security and IT?

Why This Matters for Security Teams

Routing and retention policy is not just a logging preference. It determines whether telemetry can support incident response, forensics, regulatory evidence, and service reliability without creating unnecessary storage, privacy, or access risk. When security and IT both rely on the same data, unclear ownership often leads to duplicate pipelines, inconsistent retention windows, and gaps between what is collected and what is actually usable. The governance question matters as much as the technical one.

Security teams typically need higher-fidelity records for detection and investigation, while IT teams often optimise for troubleshooting and platform health. Those goals can coexist, but only if one authority sets the policy and the contributing teams agree on what must be preserved, where it may travel, and who can access it. That is consistent with the NIST Cybersecurity Framework 2.0 emphasis on coordinated governance and protection of information assets. In practice, many security teams encounter retention failures only after an investigation or audit has already needed the data, rather than through intentional policy design.

How It Works in Practice

In a mature operating model, central policy ownership sits with the enterprise, usually through security governance, risk, and compliance, with IT and platform engineering providing implementation input. The policy should define what telemetry is in scope, which fields are sensitive, how long each class of data is retained, and which destinations are approved for routing. It should also specify whether data is enriched before or after routing, because enrichment can increase sensitivity if it adds user, device, or identity context.

A practical policy usually distinguishes between operational, security, and legal retention needs. For example, short-lived performance logs may support IT troubleshooting, while authentication, privilege, and endpoint activity may require longer retention for threat hunting and investigation. Where privacy obligations apply, the default should be data minimisation, with tighter access controls and explicit justification for extended retention. Guidance from the CISA logging best practices is useful here because it stresses collection quality, integrity, and usability rather than simple volume.

• Define one policy owner, one approval path, and one exception process.
• Classify telemetry by business purpose, not by tool or source system alone.
• Route security-relevant events to detection and response platforms, but restrict broad access.
• Apply retention schedules by data class, jurisdiction, and investigation need.
• Document chain of custody and integrity controls for records that may become evidence.

Where identity data is embedded in logs, ownership should include clear rules for masking, enrichment, and access because telemetry can become a shadow identity store if left unmanaged. For broader governance alignment, organisations can also map policy decisions to the ISO/IEC 27001 information security management model and the NIST SP 800-92 log management guidance. These controls tend to break down when each platform team sets its own retention rules because the enterprise then loses a defensible, auditable view of what data exists and who can retrieve it.

Common Variations and Edge Cases

Tighter retention and routing control often increases operational overhead, requiring organisations to balance investigation readiness against storage cost, privacy exposure, and administrative complexity. That tradeoff becomes sharper in regulated industries, multi-tenant environments, and global deployments with conflicting data residency rules. Current guidance suggests central ownership should remain non-negotiable, while implementation can be federated if local teams operate within an approved policy envelope.

One common edge case is platform ownership split across a security operations centre, an IT operations group, and a cloud engineering team. In that model, each group may control a pipeline segment, but none should unilaterally change the retention clock or redirect sensitive telemetry to a new destination. Another edge case is vendor-managed observability, where default retention settings are convenient but may not match legal hold, audit, or incident response requirements. The safer approach is to treat vendor defaults as starting points, not policy.

For environments using identity-heavy telemetry such as authentication events, privileged session logs, or service account activity, the policy should also define whether the data supports NHI governance or only operational troubleshooting. That distinction matters because records tied to service identities or agentic workflows may need longer retention and stricter routing than ordinary application logs. Best practice is evolving here, but the principle remains stable: the enterprise owns the policy, and tool owners own the implementation within it.

Related resources from NHI Mgmt Group

• Who should own decisions about telemetry tiering and retention?
• Who should own authorization governance when policy spans IT, security, and compliance?
• Who should own identity detection coverage in a mature security programme?
• Who should own risk decisions when security fixes affect service stability?