Accountability should sit with the privacy program, but execution is shared across application, identity, legal, and vendor management teams. The privacy owner defines the rule, engineering implements the workflow, and records or legal teams define retention exceptions. Vendor managers must ensure service providers can honor deletion requests, otherwise the organization cannot complete the process end to end.
Who actually owns account deletion end to end?
The accountable owner should be the privacy program, because account deletion is ultimately a rights and policy question, not just a technical ticket. Privacy defines when deletion is required, what exceptions apply, and what proof is needed. Identity, application, legal, and vendor teams execute their parts, but one function must own the outcome and remove ambiguity when systems disagree.
That ownership is especially important when deletion spans records, active sessions, backups, and third-party platforms. A request is not complete until the organisation can show the account is removed or rendered inaccessible everywhere the policy covers, including suppliers that hold replicated data or authentication material. For background on the identity and lifecycle side of that problem, see Ultimate Guide to NHIs.
Why the accountability model has to cross privacy, identity, legal, and vendors
Deletion fails when teams treat it as a single-system task. Privacy sets the rule, engineering implements the workflow, identity teams revoke access and close authentication paths, legal defines retention holds, and vendor managers make sure processors and service providers can actually delete what they store. If any one of those owners is missing, the organisation can end up with a policy that looks complete but does not work in practice.
This is also where the distinction between “deleted” and “no longer usable” matters. Some systems must purge data; others may retain records for legal or audit reasons while still removing active access and linking identifiers. That means the accountability model has to cover both control design and exception handling, not just the final wipe action.
For practitioners, the most useful framing is that privacy is accountable for the decision and the standard, while other teams are responsible for execution against that standard. That prevents privacy from becoming a passive reviewer and prevents engineering from making ad hoc deletion choices without the policy context. If your deletion workflow depends on non-human credentials or service integrations, the broader lifecycle and governance issues are captured well in The 2025 State of NHIs and Secrets in Cybersecurity.
What good accountability looks like in practice
Good accountability is visible in ownership boundaries and evidence, not in a vague “privacy owns it” statement. The privacy owner should define the deletion standard, escalation path, retention exception process, and completion criteria. Identity and application teams should be able to demonstrate the technical steps that disable access, remove tokens or linked credentials, and trigger downstream removal. Vendor management should be able to show contractual and operational deletion commitments from processors.
What to verify: confirm that each system in scope has a documented deletion path, that every exception is tied to a legal or regulatory basis, and that external vendors have a tested method for honoring requests within the required timeframe. The important question is not whether a delete button exists, but whether the organisation can complete deletion across all replicas, exports, logs, and outsourced services.
What good looks like: there is one accountable owner for the overall result, clear executors for each system boundary, and a measurable completion record that proves the request was handled across the full data and identity chain. For the access-governance and offboarding mechanics that often sit underneath this process, Ultimate Guide to NHIs, What are Non-Human Identities is the most direct internal reference.
Practitioner takeaway: Treat account deletion as an owned privacy outcome with shared execution, not as a one-team cleanup task, because accountability only works when one function can prove the entire chain finished, including vendors and retained exceptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-02 — Roles, Responsibilities, and Authorities | Defines who owns privacy deletion outcomes across teams. |
| PR.AA-01 — Identity Management and Access Control | Deletion must remove or disable access paths tied to the account. | |
| GV.PO-01 — Policy Establishment | Deletion needs a defined privacy policy and exception basis. | |
| Recommendation — Assign a single accountable owner and document cross-functional responsibilities for deletion completion. Revoke account access and disable authentication paths as part of deletion. Set a deletion policy that defines scope, retention exceptions, and completion criteria. | ||
| CIS Controls v8 | 6.1 — Establish an Access Granting Process | Deletion depends on controlled removal of access and entitlements. |
| 6.3 — Disable Dormant Accounts | Accounts that are no longer needed should be disabled or removed promptly. | |
| Recommendation — Use a formal process to remove access and validate that entitlements are withdrawn. Disable accounts promptly when deletion or retention rules require access removal. | ||
| NIST SP 800-63 | 5.2 — Identity Proofing and Enrollment | Deletion requests depend on trustworthy identity lifecycle records. |
| 7.2 — Lifecycle Management | Covers account lifecycle events including suspension, termination, and reactivation. | |
| Recommendation — Verify identity records before acting on high-risk deletion requests. Manage account lifecycle events so deletion steps are consistently executed and recorded. | ||
Related resources from NHI Mgmt Group
- Who is accountable for making CPRA Do Not Sell or Share rights work across privacy, marketing, and vendor operations?
- How should privacy teams implement account deletion requests across mobile apps and connected systems?
- Who is accountable for protecting PII across privacy and identity programmes?
- Who is accountable when identity activity cannot be traced across systems?
