What Is Right to be Forgotten?

The right to erasure obliges an organisation to delete an individual's personal data on request, in defined circumstances. It is conceptually simple and operationally one of the hardest privacy rights to satisfy, because deletion in a modern architecture is not a single action.

It is also not absolute. The right applies where there is no overriding basis for retention, and legal obligations, the establishment or defence of legal claims, and certain public interest grounds can all justify keeping data.

Why deletion is architecturally hard

Personal data does not sit in one table. It is in the production database, the read replicas, the data warehouse, the analytics platform, the search index, the caches, the log files, the email archive, the support ticketing system, the marketing platform and every backup taken since the record was created.

Deleting from production while leaving twelve downstream copies is the normal outcome for an organisation that has not designed for this, and it is not compliance — it is the appearance of it.

The backup problem, and the accepted answer

Backups are the genuinely awkward case. Selectively removing one individual's records from immutable backup sets is usually impossible, and destroying entire backup sets to honour one request is disproportionate and creates a different risk.

The generally accepted approach is to put backups beyond use: document that the data remains in backups, ensure those backups are not restored into live systems without re-applying the erasure, and let it expire with the normal retention cycle. That position needs to be documented in advance rather than improvised.

Designing for erasure before you need it

Organisations that handle this well share a few properties. They know where personal data flows, because they maintained a map rather than reconstructing one per request. They have a deletion path that reaches downstream systems rather than only the primary store. And they can produce evidence of what was deleted and when, because a request you cannot demonstrate you honoured is one you may have to defend.

Third parties are the remaining gap. Where data was shared with processors or partners, the obligation frequently extends to informing them — which requires knowing who received what.

When you can refuse, and how to do it properly

The right is qualified, and refusing where a valid ground applies is legitimate. Retention required by law, data needed for the establishment or defence of legal claims, and certain public interest or research grounds all support keeping information.

What matters is the handling. A refusal should be explained, reference the specific basis relied on, and inform the individual of their right to complain to the regulator. Silent refusal, or a response that simply declines without reasoning, converts a defensible position into a complaint.

Partial erasure is frequently the right outcome — removing what is not needed while retaining the specific fields a legal obligation requires, rather than treating the request as all or nothing.

Where to start

Trace one customer record through your systems and list everywhere it appears. That single exercise produces both the deletion procedure and an accurate picture of your data sprawl.

See PIPEDA compliance and PIPEDA versus GDPR. GuardsArm supports GDPR compliance.