Who is accountable when routing policy or telemetry retention fails?

Why This Matters for Security Teams

When routing policy or telemetry retention fails, the problem is rarely just a misconfigured rule. It is usually a breakdown in accountability across the control plane, where engineering, security, and compliance each assume someone else owns the outcome. That matters because routing affects where data flows, what gets masked, and who can see it, while retention determines what evidence exists after an incident or audit. Those are governance decisions as much as technical ones, and they should be treated that way in the operating model.

Under the NIST Cybersecurity Framework 2.0, ownership, oversight, and evidence management are part of the security programme, not side tasks delegated to infrastructure teams. If retention is too short, teams may lose forensic value. If it is too long or too broad, they may increase privacy and regulatory exposure. If routing policy is inconsistent, the organisation can create blind spots, duplicate records, or data leakage across environments. In practice, many security teams encounter this only after an investigation cannot be reconstructed or an audit asks for evidence that no longer exists.

How It Works in Practice

Accountability should follow the service that controls policy execution, not the team that merely deploys the pipeline. In practical terms, the control plane owner is responsible for defining routing rules, approving exceptions, validating telemetry destinations, and proving that retention settings match policy. Security leadership sets the minimum standard, platform teams implement and operate it, and compliance or risk functions verify that evidence is retained long enough and protected appropriately.

That model works best when the organisation separates design approval from day-to-day administration. A strong operating pattern usually includes:

• Named control owner for routing, masking, and retention decisions.
• Change control for any policy that alters data flow or retention windows.
• Logging of policy changes, approvals, and exception expiry dates.
• Periodic review of telemetry destinations, access paths, and deletion jobs.
• Evidence capture mapped to audit and incident response needs.

The control mapping aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where organisations need traceability for configuration management, audit logging, and retention enforcement. If routing policy sends telemetry to multiple tools, the owner also needs to confirm that masking is applied consistently before any downstream storage or enrichment. Otherwise, one unprotected copy can defeat the purpose of the control. These controls tend to break down in highly federated environments because local teams can alter pipeline behaviour faster than governance reviews can catch the change.

Common Variations and Edge Cases

Tighter routing and retention controls often increase operational overhead, requiring organisations to balance forensic completeness against storage, privacy, and delivery latency. The right answer also varies depending on whether the telemetry contains personal data, security events, or regulated business records, and current guidance suggests those categories should not always share the same retention policy.

There is no universal standard for this yet, but a few edge cases are common. In shared-service environments, a central platform team may run the control plane while business units own the data classification that drives retention. In regulated sectors, legal hold requirements can override normal deletion schedules, which means retention must be suspendable without breaking the wider policy. In incident response, temporary retention extensions are often justified, but they should be time-bound and approved through a documented exception path. Where telemetry supports identity or access investigations, NHI and privileged access records should be protected with the same discipline as other high-value security logs. The key test is simple: if no one can name the accountable owner and prove the last policy review, the control is effectively unmanaged.

Related resources from NHI Mgmt Group

• Who should own routing and retention policy when telemetry spans security and IT?
• Who is accountable when cost-cutting removes detection telemetry?
• Who should own decisions about telemetry tiering and retention?
• Who is accountable when telemetry leaks credentials into downstream tools?