Accountability is shared, but the control must be owned end to end. Privacy operations handle the request workflow, data security validates discovery and verification, legal defines exemptions, and system owners execute deletion in their environments. The framework only works if those responsibilities are explicitly assigned and tracked across the recurring 45-day cycle.
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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access control | Deletion governance depends on controlled, assigned access to data and systems. |
| A.5.34 — Privacy and protection of PII | DROP deletion is a privacy workflow that must manage retention and erasure duties. | |
| Recommendation — Assign and enforce deletion ownership and approvals under a formal access control process. Track privacy deletion requests with explicit ownership, evidence, and exception handling. | ||
| CIS Controls v8 | CIS-5 — Account Management | Recurring deletion relies on accountable ownership and traceable responsibility across teams. |
| CIS-8 — Audit Log Management | Deletion needs evidence that requests were completed and exceptions were resolved. | |
| Recommendation — Define accountable owners for deletion queues and enforce completion tracking. Log deletion actions and keep evidence for closure and review. | ||
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?