Who is accountable for routing and retention decisions in a security pipeline?

Why This Matters for Security Teams

Routing and retention decisions shape whether security telemetry becomes usable evidence or expensive noise. The accountable owner must define what is kept, where it is sent, how long it is retained, and who can override defaults. Without that ownership, teams often end up with duplicated logs, blind spots, inconsistent retention periods, and uncontrolled cost growth. The most useful control language is in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where audit logging, configuration management, and retention governance intersect.

This is not just a SOC hygiene issue. Routing determines whether events reach the SIEM, a data lake, or a case management workflow in time to support detection and response. Retention determines whether investigations can reconstruct attacker movement, prove control operation, and support legal or regulatory review. If those choices are left to source owners by default, the result is usually fragmented policy and inconsistent enforcement across cloud, endpoint, identity, and application layers. In practice, many security teams encounter retention gaps only after an incident or compliance review has already exposed them, rather than through intentional governance.

How It Works in Practice

In mature environments, accountability sits with the function that owns security telemetry architecture, typically security engineering or security operations with formal input from data platform and compliance teams. That owner defines the routing standard, retention tiers, exception process, and review cadence. Source system teams can provide requirements, but they should not be the final decision-makers unless the data is strictly local and never used for central detection.

The practical model is usually policy-driven and tiered:

• High-value detection data, such as authentication events, privilege changes, and endpoint alerts, is routed to the SIEM or detection pipeline first.
• Lower-value or bulk data may be normalized, sampled, or sent to cheaper storage if it is not needed for real-time alerting.
• Retention periods are assigned by use case, not by convenience, with longer retention for investigation, legal hold, and regulated records.
• Overrides are documented, time-bound, and approved by the accountable owner rather than left as informal team preference.

This is also where identity and privileged access issues matter. If logs are needed to prove who performed an action, then identity events, PAM activity, and administrative sessions must be routed in a way that preserves correlation. A routing policy that drops or truncates those records undermines later response. Current guidance suggests aligning the pipeline with control families such as logging, monitoring, and retention under NIST, while using operational rules that distinguish detection data from archive data. For attack-pattern thinking, MITRE ATT&CK is useful because it helps teams prioritize which telemetry must be preserved to investigate credential abuse, persistence, and lateral movement.

Where organisations are operating in cloud-native or multi-tenant environments, the same accountability model should extend to cloud logs, SaaS audit trails, and identity providers. Best practice is evolving for AI-assisted security pipelines as well, because some teams now route agent activity, tool calls, and retrieval traces into security storage. Those records can be highly sensitive and may require tighter retention and access controls than standard operational logs. These controls tend to break down when ingestion ownership is split across many platform teams because no single group is empowered to enforce retention expiry or reject low-value logging exceptions.

Common Variations and Edge Cases

Tighter retention often increases storage cost and privacy burden, requiring organisations to balance investigative depth against minimisation and legal exposure. That tradeoff becomes more visible when logs include personal data, customer identifiers, or high-volume application telemetry that is only occasionally useful.

One common variation is regulatory retention. Some sectors need longer evidence windows, while others can justify shorter periods if detection coverage is strong and legal counsel agrees. Another edge case is shared responsibility in platform engineering: source teams may own the application, but security still owns the policy for central security telemetry. There is no universal standard for exactly how many days each log type must be retained, so the defensible approach is to document the business purpose, risk rationale, and review date for each class of data.

Special care is needed when retention intersects with identity, non-human identity, or agentic AI. If an autonomous agent can create, delete, or move security data, then those actions should be treated as privileged and logged accordingly. Where the environment is highly distributed, routing decisions also need periodic validation to ensure that schema changes, cloud service updates, or pipeline failures have not silently broken ingestion. For operational resilience, teams should pair governance with testing, because a policy without verification is easy to approve and easy to lose.

For broader control mapping, the retention and routing owner should also look at the evidence expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls and the detection logic priorities described in MITRE ATT&CK. The hard part is not deciding that logs matter, but deciding which team is accountable when platform convenience, investigation needs, and retention limits point in different directions.

Related resources from NHI Mgmt Group

• Who is accountable when a security pipeline drops critical telemetry?
• Who is accountable for recovery decisions when security and IT priorities conflict?
• Who is accountable for security decisions in embedded build pipelines?
• How should security teams handle identity decisions when business context changes quickly?