What DPDPA erasure means for your warehouse, your backups and your models

DPDPA requires a Data Fiduciary to erase personal data when the data principal withdraws consent or the purpose is served, unless retention is required by law. One sentence in the Act; a substantial engineering programme in practice.

The reason is that almost no organisation holds personal data in one place. It holds a production record, two or three analytics copies, a search index, a cache, a message queue, several years of backups, a set of extracts a finance team maintains, and whatever a dozen processors have. Deleting the production row addresses the first of those.

Start by finding the copies#

Before designing anything, establish where the data actually is. The count is consistently higher than the team expects, and the discoveries cluster in five places.

Analytics and warehouse copies. Personal data lands here by pipeline, not by decision, so nobody remembers authorising it. It is frequently identified rather than pseudonymised, because whoever built the pipeline needed a join key.

Search indices and caches. Elasticsearch, Redis, CDN caches. These hold denormalised copies that outlive the source record and are rarely wired into deletion logic.

Message queues and event logs. An event stream retaining thirty days of payloads contains personal data for thirty days after production deletion.

Non-production environments. Test and staging databases refreshed from production, usually unmasked, sometimes years old.

Extracts. The spreadsheet a team maintains, the report emailed monthly, the file on a shared drive. Ungoverned by definition and the hardest to enumerate.

The warehouse is where programmes fail#

Production deletion is a solved problem — a cascade, a soft-delete flag with a purge job, a documented runbook. The warehouse is where it comes apart, for three structural reasons.

Copies are append-only by design. Analytics architectures favour immutable fact tables. Deleting a row from a partitioned columnar store is expensive and sometimes not supported without rewriting the partition.

Derived tables multiply the problem. The raw record is joined into aggregates, cohorts and features. Deleting the source leaves the derivatives.

The join key is often the personal data. Where an email address or phone number is the identifier, it is present in every derived table by construction.

The pattern that works is to separate the identifier from the attributes at ingestion. A pseudonymous key in the warehouse, with the mapping to the real identifier held in a single, small, tightly governed lookup service. Erasure then becomes a deletion in the lookup service — after which the warehouse rows are no longer personal data, because they can no longer be attributed to an identifiable individual without information held separately and now destroyed.

That is a meaningful architectural change and not a quick fix. But it converts an intractable problem into a tractable one, and it is the design we recommend for any warehouse being rebuilt.

Backups: the position that holds#

The question every team asks: do we have to delete from backups?

No competent regulator expects you to restore a six-month-old snapshot to remove one row. What is expected is a documented and enforced position, and the one that holds has four parts:

1. A defined backup retention period, short enough to be defensible. Thirty to ninety days for operational backups is normal; a seven-year backup set containing personal data is not.
2. Backups are not used for anything except restoration. No analytics against backups, no restoring a snapshot to answer a question. Enforced by access control, not policy.
3. Restoration re-applies pending deletions. This is the critical mechanism. Maintain a deletion ledger of erased identifiers; any restore triggers replay of that ledger before the restored system returns to service.
4. The position is written down and referenced in your privacy notice's retention section.

Point three is what makes the rest credible. Without it, a restore silently resurrects data you told someone you had erased — and that is a breach of the undertaking, not merely a technical gap.

Processors#

Erasure obligations flow to anyone processing on your behalf. Two things are needed and most contracts have neither.

A deletion instruction mechanism — an API call, a documented process, something better than an email to an account manager. If deletion depends on a human at the processor remembering, it will not happen consistently.

Confirmation you can reconcile. A processor asserting deletion in an annual attestation is not evidence. A machine-readable confirmation, or at minimum a dated per-request record, is.

Vendors resist the second more than the first, which tells you which one matters. A processor who cannot confirm deletion in a form you can verify is a processor whose deletion you cannot evidence to a regulator.

Models: the genuinely unsettled part#

If a model was trained on a corpus that included data since erased, is the model itself personal data? Must it be retrained?

The honest answer is that this is not settled, in India or anywhere. What we can say is what a defensible position looks like, and that silence is not it.

A defensible position has four elements:

• Retraining occurs on a defined cadence — quarterly, or on a data-volume trigger — with erased records excluded from each new training set.
• The model is not used to make consequential decisions about an individual who has withdrawn. This is enforceable at inference time and is the strongest practical protection.
• Memorisation risk is assessed for models where verbatim reproduction of training data is plausible, with mitigation where it is.
• The reasoning is documented, including the acknowledgement that immediate retraining on every withdrawal is not technically viable and why the chosen cadence is proportionate.

A regulator encountering that analysis sees an organisation that considered the question. One encountering nothing sees an organisation that did not.

When retention is required by law#

The obligation carries an exception: erase unless retention is required for compliance with any law. That exception is real, frequently misapplied in both directions, and worth getting precise about.

Over-claimed. Teams cite "we need it for audit" or "finance requires seven years" without identifying the provision. A generalised sense that records should be kept is not a legal retention requirement, and an examiner will ask which law.

Under-claimed. Equally common. Organisations delete data they were obliged to keep, because the privacy programme moved faster than the conversation with Legal and Finance. Sectoral record-keeping under company law, tax provisions, medical record rules and RBI or SEBI requirements all impose retention that overrides the erasure duty.

The resolution is a retention register mapping each data category to the specific provision requiring its retention, the period, and the trigger that starts the clock. Where no provision exists, the default is erasure on withdrawal or purpose completion.

The useful distinction, and the one that unlocked a deadlock at a hospital group we worked with, is between the record required by law and the data derived from it. A clinical record retained under a medical record rule is outside the erasure right for that period. The marketing profile, engagement history and analytics features built from that record are not. Separating the two converted an apparently irresolvable conflict into a tractable data segregation project.

Write the register, have Legal sign each entry, and review it annually. It is the artefact that lets you erase confidently rather than defensively — and it is what you produce when someone asks why a specific record still exists.

Sequencing the work#

That final step is the one that matters. Everything above is design; the seeded-identity test is the only thing that tells you whether the design works. Run it before someone else does.

Our Privacy Engineering & Data Protection practice builds these programmes, and the DPDPA framework page sets out the full obligation set including the storage limitation and erasure duties.