Who should own decisions about telemetry tiering and retention?

Security operations, identity, and platform teams should own it together because telemetry routing affects detections, audit evidence, and budget. If these decisions sit only with infrastructure or procurement, the organisation will optimise for storage cost instead of security outcomes and accountability.

Why This Matters for Security Teams

telemetry tiering and retention are not just storage decisions. They determine whether analysts can reconstruct an incident, whether identity events can be correlated across systems, and whether the organisation can prove control operation during audit or litigation. Current guidance suggests treating log retention as a security governance issue, not an infrastructure preference, because telemetry quality directly affects detection coverage, response speed, and evidentiary value. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful baseline for logging, audit, and retention expectations.

Teams often get this wrong by allowing cost-centred ownership to override investigative requirements. That leads to short retention windows, inconsistent log formats, and missing context when an attacker pivots through privileged accounts, API keys, or service identities. For NHI-heavy environments, the risk is higher because machine identities and automation often generate the signals that explain how access was used, not just who clicked a button. In practice, many security teams encounter telemetry gaps only after an incident has already closed the forensic window, rather than through intentional retention design.

How It Works in Practice

Effective ownership usually sits in a shared governance model. Security operations defines what events must be retained for detections, threat hunting, and incident response. Identity teams define which authentication, authorisation, and privileged activity records matter. Platform teams then implement routing, storage classes, and access controls so the policy is enforceable across endpoints, cloud services, IAM tools, and SIEM pipelines.

A practical tiering model separates telemetry by value and time sensitivity. High-value records such as privileged access, authentication failures, token issuance, admin actions, and changes to identity policy are kept longer and made harder to tamper with. Lower-value operational noise can be retained for shorter periods or summarised sooner. This approach aligns with the logging discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects organisations to preserve auditability and support monitoring objectives.

• Define retention by use case first: detection, investigation, compliance, and performance troubleshooting.
• Map each log source to an owner, a minimum retention period, and an evidentiary tier.
• Protect higher-tier logs with stronger access control, immutability, and integrity checks.
• Review whether the SIEM, data lake, or archive is the right system of record for each category.

Where identity is involved, retention should capture not only human login events but also service account activity, secrets use, and agent actions that can change state or call tools. That matters in zero trust and NHI governance because the security question is often not whether an identity exists, but whether its behaviour can be reconstructed after the fact. These controls tend to break down when telemetry is fragmented across cloud, SaaS, and on-premises systems because field names, timestamps, and ownership boundaries prevent reliable correlation.

Common Variations and Edge Cases

Tighter retention and higher-fidelity logging often increases storage, parsing, and access-review overhead, requiring organisations to balance investigative depth against cost and privacy constraints. That tradeoff becomes sharper when telemetry includes personal data, employee activity records, or highly sensitive system context.

There is no universal standard for exact retention periods across all event types. Some organisations keep privileged and authentication records for months or longer, while lower-risk operational logs are reduced much sooner. The right answer depends on threat model, regulatory obligations, and incident response maturity. If the business is subject to data protection rules, monitoring policy should also reflect data minimisation and lawful processing principles, not just security preference. In EU-regulated environments, NIS2 may influence operational logging expectations, while GDPR shapes how long identifiable event data should be held and who can access it.

Agentic AI and automation add a further edge case. When an AI agent uses tools or acts through delegated credentials, telemetry must be able to prove what identity was used, what permission was exercised, and whether the action was authorised. Best practice is evolving here, so organisations should document assumptions explicitly instead of treating agent activity as equivalent to a normal service job. For broader control mapping, NIST Cybersecurity Framework helps anchor governance and detection outcomes, while MITRE ATT&CK remains useful for defining which behaviours telemetry must capture to support hunting and response.

Related resources from NHI Mgmt Group

• Who should own AI triage decisions when a case is ambiguous or high risk?
• Who should own risk decisions when security fixes affect service stability?
• Who should own AI eval failures when they affect compliance or access decisions?
• What should security teams do about secrets hidden in SharePoint?