Who is accountable for keeping DROP deletion closed over time?

Who actually owns DROP deletion over time?

Accountability should be shared, but ownership must be explicit. The control only holds when the workflow owner, data security reviewer, legal approver, and system implementer each know their part, and when one function is responsible for keeping the 45-day cycle moving, closing exceptions, and proving completion across environments.

Why shared accountability still needs a single control owner

DROP deletion is not a one-time ticket, it is a recurring control with approvals, verification, execution, and closure. Shared accountability works only when there is a named owner for end-to-end tracking, otherwise the process tends to stall at handoffs, especially when requests touch multiple datasets, systems, or business exceptions.

The practical question is not who helps with deletion, but who is answerable if a record remains undeleted after the cycle should have closed. In most operating models, that means privacy operations runs the queue, while one accountable owner ensures the queue is reviewed, escalated, and resolved on schedule.

What each function is responsible for in the deletion cycle

Privacy operations typically manages intake, status tracking, and request coordination. Data security validates discovery, confirms whether the data subject or record set is actually in scope, and checks that deletion evidence is trustworthy. Legal defines exemptions, retention holds, and stop conditions where deletion must pause or narrow.

System owners carry the execution burden because deletion happens in their platforms, databases, backups, and downstream services. That means they must understand where copies live, what can be deleted safely, and what evidence can prove the action occurred. If any of these responsibilities is vague, the process becomes a routing exercise rather than a control.

Why the recurring 45-day cycle needs active governance

The recurring cycle matters because deletion does not stay complete on its own. New records, rehydrated copies, delayed exports, and exception queues can reopen the exposure unless someone reviews ageing items and confirms that each cycle closes with evidence. A ISO/IEC 27001:2022 Information Security Management style ownership model is useful here because it forces assignment, review, and repeatability.

The control also benefits from a tracked workflow rather than informal follow-up. CIS Controls v8 is relevant because the discipline here is not only deletion, but ensuring the accountable team can monitor completion, validate action, and reduce the chance that stale data persists unnoticed.

Risk and Threat Considerations

When deletion ownership is diffuse, the main risk is not a dramatic failure, it is silent non-closure: requests age out, exceptions linger, and copies remain in systems that nobody believes still matter. That creates avoidable privacy exposure, retention drift, and a weak audit trail if someone later asks why the record was not removed on time.

Failure mechanism: Handoffs between privacy, legal, data security, and system owners break the chain of accountability, so no single party keeps the cycle moving, resolves exceptions, and proves that deletion actually happened.

Impact: The organisation can miss deletion deadlines, retain data longer than intended, and lose confidence in both compliance reporting and operational control over downstream copies.

Practitioner Guidance

What to verify: Confirm that one role is named as the end-to-end owner for the deletion queue, not just for approvals. That owner should be able to show current status, ageing exceptions, and evidence of completion for every request in the cycle.

Decision rule: If a request needs legal review or platform-specific execution, treat those as supporting approvals or actions, not as substitutes for ownership. If no one is accountable for closure, the control is not operating, even if individual steps are being performed.

Practitioner takeaway: Shared work is fine, shared accountability is not, because recurring deletion controls fail when no one is answerable for closure, exception handling, and proof across the full lifecycle.

Related resources from NHI Mgmt Group

• Who is accountable for keeping a CUI enclave compliant over time?
• Who should be accountable for keeping security questionnaire answers accurate over time?
• When do NHI access reviews create more value than a one-time cleanup?
• How do organisations reduce the dwell time of exposed credentials at scale?