Erasure Requests vs Legal Retention Obligations: How to Reconcile Them
Section 12 does not require erasure when retention is necessary for a specified purpose or legal compliance. The hard part is proving that necessity request by request.
The exception is real, but it is not a blanket excuse
Section 12 gives Data Principals the right to erasure of their personal data, but it also carves out an exception: erasure is not required where retention is necessary for the specified purpose for which the data was collected, or to comply with any other law currently in force. That exception exists precisely because plenty of legitimate retention obligations - tax records, dispute-limitation periods, sector-specific recordkeeping - sit alongside the Act, and it would be unworkable to force deletion that breaks those obligations.
The risk is treating the exception as a default answer rather than something you can actually justify for the specific data in question. A blanket policy of denying every erasure request on vague retention grounds will not hold up if it is challenged, because the exception is tied to necessity for a specific purpose, not a general preference to keep data longer.
Mapping retention obligations before the request arrives
The organizations that handle this well have already mapped, category by category, which personal data has a legal or contractual retention requirement attached, how long that requirement runs, and which law or contract term drives it. When an erasure request comes in, the response becomes a matter of checking that map rather than convening an ad hoc legal review under time pressure.
Without that map, the default reaction tends to be overly cautious - refusing erasure because nobody is confident it is safe to delete - which risks looking like resistance to a legitimate right rather than a genuine legal constraint.
Communicating a partial or delayed erasure
Often the honest answer is neither a full erasure nor a full refusal - some fields can be deleted immediately while others must be retained until a specific date tied to a legal obligation. Explain that split clearly to the Data Principal: what is being erased now, what is being retained, for how long, and under what legal basis.
Where full erasure is not yet possible, consider whether the retained data can be restricted from further active use - kept only for the compliance purpose and walled off from marketing, analytics, or other processing - so the Data Principal's underlying concern about ongoing use is addressed even while the retention obligation persists.
Documenting the necessity determination
Whatever decision you reach, write down the specific law, contract clause, or business purpose that justifies retention, tied to the specific data elements in question. A generic reference to unspecified compliance requirements will not survive scrutiny from a grievance officer, an internal auditor, or the Board.
This documentation also protects the organization on the other side of the ledger - if you did erase data that should have been retained, having a documented, deliberate assessment shows the decision was reasoned rather than careless.
Where to go next
The Retention Planner is built to help map data categories against the retention periods that apply to them, which is the foundation you need before you can answer an erasure request with confidence rather than guesswork.