Who should own GDPR erasure requests when responsibility spans IT, legal, and operational teams?

When GDPR erasure requests span IT, legal, and operational teams, ownership should be assigned to the organisation as a governed process, not handed to a single function. The right model is a named business owner or privacy lead with clear decision rights, while IT, legal, records, and operations each own the parts they can actually execute and attest to.

That matters because erasure is both a compliance obligation and a cross-system change effort. The request can touch backups, logs, third-party processors, retention holds, and exception handling, so ownership has to cover coordination, evidence, and escalation, not just deletion.

What “ownership” means in a GDPR erasure workflow

Ownership here is mainly about accountability, not manual execution. IT can remove data from production systems, legal can interpret the request and any exemptions, and operational teams can confirm where personal data lives in business processes. The owner is the function that ensures the request is triaged, routed, tracked, and closed with evidence.

That distinction prevents the common failure mode where “IT owns deletion” becomes a narrow technical task and the organisation misses legal holds, third-party copies, or retention rules. For GDPR, the person or team accountable for the request must be able to answer whether erasure is lawful, complete, and documented.

A practical ownership model usually has one accountable lead plus several contributing owners. The accountable lead should control the case record, set deadlines, decide when the request needs escalation, and confirm whether the request is fully satisfied or partially refused under an applicable exception.

Why cross-functional ownership is the only workable model

Erasure requests are rarely contained inside one system or one department. A single request may require locating data across HR, CRM, support tooling, analytics, archives, and vendor platforms, then determining whether each copy must be deleted, retained, or masked under a lawful basis.

That is why legal and privacy review cannot be treated as a postscript to IT deletion, and why IT cannot be left to decide the legal outcome alone. The organisation needs a workflow that joins policy, records management, system knowledge, and third-party coordination into one controlled process.

This also helps with proof. If a regulator, customer, or internal auditor asks what happened, the organisation should be able to show who reviewed the request, what systems were searched, what was deleted, what was retained, and why any retention was permitted. For the underlying GDPR obligations, the EU General Data Protection Regulation (GDPR) remains the primary reference point for the rights and processing rules that drive this workflow. For identity and governance mapping, Identity Security Regulatory Map is useful for connecting GDPR obligations to access, audit, and governance controls, and Ultimate Guide to NHIs, Regulatory and Audit Perspectives helps when erasure touches automated systems, service accounts, or machine-managed data paths.

How to assign responsibilities without creating gaps

The cleanest approach is to define one owner for the case, one owner for legal determination, one owner for technical deletion, and one owner for business-data verification. Each owner should have a clear deliverable, because “shared responsibility” without named outputs usually leads to delay and incomplete evidence.

• Use legal or privacy to decide whether the request is valid, whether any exemption applies, and what must be retained.
• Use IT to search, delete, suppress, or anonymise data in systems under technical control.
• Use operational teams to identify process-specific repositories, manual records, and downstream business copies.
• Use the accountable owner to track third-party notifications, approvals, exceptions, and closure evidence.

The strongest operating model is the one that makes ownership visible at each step. If the request can stall because one team is waiting on another, then the ownership design is too vague and the process is too easy to drop between functions.

Risk and Threat Considerations

Erasure requests create exposure when responsibility is split but not reconciled. The most common risk is incomplete deletion, where one system is cleaned up while backups, replicas, exports, or vendor copies remain untouched, creating a false sense of compliance.

Failure mechanism: Unclear ownership leads to missed repositories, unreviewed exceptions, and weak evidence, so the organisation cannot prove that deletion was complete or lawfully denied where retention applied.

Impact: That can produce regulatory breach, customer complaint, audit failure, and continued retention of personal data that the organisation believed it had removed.

Practitioner Guidance

What to prioritise: Appoint one accountable owner for the erasure case and define the handoffs to legal, IT, records, and operations before handling the request volume. If the organisation cannot name who closes the case and signs off the evidence, the governance model is not ready.

What to verify: Confirm that the process covers discovery, deletion, exception approval, third-party notification, and closure evidence. The key test is whether a non-technical reviewer could reconstruct what was done and why from the case record alone.

Practitioner takeaway: GDPR erasure ownership works only when accountability sits above the individual tasks, because the real control is coordinated decision-making plus provable completion, not deletion activity in isolation.

Related resources from NHI Mgmt Group

• Who should own continuous security monitoring when responsibility spans development, security, and operations teams?
• Who should own information security policy decisions when responsibility spans security, vendors, and business teams?
• Who should own access certification decisions when responsibility spans business and IT teams?
• Who should own GDPR compliance when privacy, legal, and security teams all have a role?