DPDP and the right to erasure: what 'right to be forgotten' actually means in India
India's DPDP Act gives individuals the right to erasure. Here is what it actually requires, what it does not require, and how to build an erasure workflow that is both compliant and operational.
What does the DPDP Act say about the right to erasure?
The DPDP Act's erasure right is embedded in the consent withdrawal mechanism: when a data principal withdraws consent, the Data Fiduciary must cease processing and erase the personal data 'as soon as reasonably practicable'. This is not a standalone 'right to erasure' in the GDPR sense — it is tied to consent withdrawal. Processing on other lawful bases (statutory obligations, contract performance) is unaffected by consent withdrawal. But in practice, most consumer-facing processing is based on consent, so withdrawal effectively functions as an erasure right for most everyday data.
What personal data can you keep after consent is withdrawn under DPDP?
There are legitimate grounds to retain data even after consent is withdrawn: data you are legally required to retain (tax records, financial transaction records, statutory regulatory filings); data needed to fulfil a contract the individual has entered into (if they are still a customer); data needed for legal proceedings, investigations, or enforcement; and data relating to a pending grievance or rights request from the same individual. In each case, the data must be retained only for the specific lawful purpose and deleted as soon as that purpose is exhausted.
How do you erase personal data stored across multiple systems under DPDP?
The hardest part of erasure is not the legal question — it is the engineering challenge. Personal data for a single customer may exist in: your CRM; your email marketing platform; your customer support tool; your analytics database; your data warehouse; your backup systems; your partner's or vendor's systems; and possibly your AI training datasets. A consent withdrawal that erases data from your primary database but leaves it in 12 other systems is not a compliant erasure. Map your data flows before you build your erasure workflow.
How do you build a DPDP-compliant data erasure workflow?
A compliant erasure workflow: (1) receives the withdrawal or erasure request; (2) identifies all systems containing the individual's data using a subject identifier (email, phone, user ID); (3) applies legal hold checks — is any of this data subject to a statutory or legal hold that overrides erasure?; (4) executes deletion in all eligible systems; (5) instructs downstream processors (vendors) to delete; (6) confirms deletion to the individual with a response letter; and (7) records the erasure in your breach/rights register. Automate as much of this as possible — manual erasure across 12 systems is error-prone and does not scale.
Must you delete personal data from backup systems when consent is withdrawn?
Backup systems present a particular challenge. When you delete from your live database, the data may persist in backups for weeks or months depending on your backup retention policy. Most privacy regulators accept that data in encrypted backups that are never accessed or restored — and that will be overwritten on a normal schedule — does not need to be actively extracted and deleted from the backup tapes. However, if a backup is ever restored, the restored data should be subject to immediate erasure if the individual's consent was withdrawn before the restoration.
How do you inform someone after erasing their data under DPDP?
When you complete an erasure, inform the individual of what you deleted and, where you retained data under a lawful basis, explain what you retained and why. This transparency builds trust and satisfies the Act's principle of informedness. If erasure is not possible for some data (e.g., data in archived legal records), explain that too. The communication should be clear, plain-language, and specific to their request — not a generic auto-response.
Frequently asked questions
Can a customer demand we delete their purchase history?
Purchase history retained for statutory tax purposes — GST records, income tax records — can be retained for the statutory period regardless of a deletion request. However, purchase history retained in your marketing database beyond the statutory period, or copies in your analytics warehouse with no statutory obligation, must be deleted on request. Be precise about which copies of which data are retained under which justification.
We use purchase data in our AI model. Can we retrain the model every time someone requests deletion?
Model retraining on every deletion request is not operationally feasible for most companies. The practical approach is: (a) use anonymised data for model training wherever possible, so individual deletion requests do not affect the model; (b) when identifiable data must be used, document a model retraining schedule (e.g., quarterly) and commit to not making the specific model available for inference on the requesting individual's data until the next retrain; (c) research machine unlearning techniques for cases where faster removal is required. Document your approach and be transparent with data principals about your model retraining schedule.
What is the timeline for responding to an erasure request?
The DPDP Act requires erasure 'as soon as reasonably practicable' after consent withdrawal. The specific timeline will be set in the Rules, but the working assumption for a rights response SLA is 30 days, with complex cases extendable by a further 30 days with notification. Build your erasure workflow to target 30 days from receipt of request as the standard SLA.
Build your data erasure workflow
Niti Bharat's DSAR Request Tracker and Data Principal Rights Portal tools help you manage erasure, access, and correction requests — with an audit trail for every completed request.
Get the DSAR Request Tracker