Who should be responsible for data retention policy governance when legal, security, and storage teams are all involved?

Who should own data retention policy governance?

Data retention governance should sit with one accountable owner, not with a loose committee. That owner should be able to arbitrate legal retention obligations, security requirements, and operational deletion practices, then hold each team to a shared policy and exception process. In practice, the right model is central accountability with distributed execution.

Why shared involvement still needs one decision-maker

Legal and compliance are usually the source of retention obligations, but they do not operate the storage platforms that execute deletion. Security cares about confidentiality, integrity, legal hold handling, and evidence preservation. Storage and operations understand systems, backup cycles, replication, and deletion latency. Those inputs are all necessary, but they are not the same as ownership.

When governance is split across teams without a named owner, the policy becomes a negotiation rather than a control. That is where retention periods get interpreted differently, exceptions accumulate, and nobody can confidently say whether a dataset is being kept because it must be, or because no one has enforced deletion.

What the governance model has to cover

The accountable owner needs authority over the full retention lifecycle: define the policy, approve exceptions, confirm legal hold handling, and ensure deletion is operationally achievable in every system where the data lives. That includes primary stores, replicas, archives, exports, logs, and backup media. Without that end-to-end scope, the policy may look compliant on paper while remaining incomplete in practice.

This is also where Identity Data Privacy and Consent Guide becomes useful, because retention decisions are tightly linked to lawful handling, minimisation, and data subject rights. The governance owner does not replace legal judgment, but must make sure those obligations are translated into enforceable controls.

The same accountability pattern applies when automated systems, service accounts, or platform processes are used to archive or delete records. If a technical control is part of retention enforcement, the owner must verify that the control is monitored, testable, and not dependent on undocumented manual action.

How to assign the role in a practical organisation

The best owner is usually a business or information governance function with enough authority to coordinate legal, security, privacy, and infrastructure, rather than one of those teams alone. Legal defines what must be kept, security defines what must be protected, and operations defines how deletion and retention are executed. The owner translates those inputs into one policy, one exception path, and one accountability chain.

If no single function can accept that responsibility, the next best option is a named governance lead with formal authority to resolve conflicts and escalate unresolved retention disputes. The critical test is simple: if a regulator, auditor, or incident responder asks who approved the retention decision, there should be one answer, not three.

For the technical side of deletion and storage control, NIST SP 800-88 Media Sanitization is the most direct reference in the supplied sources because it frames disposal, clearing, purging, and destruction as controlled actions rather than informal cleanup. That is useful when governance has to be translated into operational evidence.

Risk and Threat Considerations

Retention governance fails when the policy owner is unclear, because teams default to their local incentives: legal over-retains to reduce uncertainty, operations delays deletion to avoid breakage, and security may preserve data longer than necessary for investigation convenience. The result is excessive retention, weak exception control, and broader exposure if sensitive data is retained after its business purpose has ended.

Failure mechanism: The policy is written collaboratively, but no single owner is empowered to reconcile conflicts, approve exceptions, or verify that deletion actually occurs across primary systems, archives, backups, and downstream copies.

Impact: Organisations can end up with inconsistent retention, avoidable data exposure, incomplete deletion evidence, and an inability to demonstrate compliance when challenged.

Practitioner Guidance

What to prioritise: Assign one accountable governance owner first, then make legal, security, privacy, and storage teams contributors to that owner’s decision process. If the ownership model is ambiguous, every later retention control will be harder to prove and easier to bypass.

What to verify: Confirm that the owner can name the policy source, the exception approver, the deletion evidence expected from operations, and the escalation path for legal holds. If any of those are missing, the governance model is not yet operational.

Practitioner takeaway: Shared input is healthy, but shared ownership is usually a failure mode. Retention governance works only when one accountable role can turn legal intent into enforceable, auditable deletion behaviour.

Related resources from NHI Mgmt Group

• How should security teams use IAST and RASP in NHI governance?
• How should security teams structure data collection and retention in a privacy policy for a SaaS service?
• How should security teams use data minimisation to reduce storage waste without weakening governance?
• How should security and governance teams operationalize sensitive data controls when classification, policy, and remediation live in different tools?