DPDP Act26 May 2026 8 min read

DPDP Act Right to Erasure: Handling Deletion Requests

How to handle DPDP Act right to erasure requests under Section 11 — intake process, verification, technical deletion, and what you can refuse.

Key Takeaways

Section 11(b) gives Data Principals the right to request erasure of personal data that is no longer necessary for the purpose it was collected for.
The erasure right is not absolute — retention required by law or needed to establish legal claims overrides an erasure request.
You must have a documented process for receiving, verifying, and fulfilling erasure requests before enforcement begins.
Erasure must cascade to backups, archives, and all Data Processors who hold the data on your behalf.
Refusing a valid erasure request can attract penalties of up to ₹10,000 per instance under the DPDP Act.

In this guide

The Right to Erasure Under the DPDP Act
What Section 11 Covers
When You Can Refuse an Erasure Request
Building an Erasure Request Intake Process
Technical Deletion: What "Erased" Really Means
Cascading Erasure to Data Processors
Handling Disputes and Board Escalations

The Right to Erasure Under the DPDP Act

The right to erasure — sometimes called the "right to be forgotten" — gives Data Principals the ability to request that a Data Fiduciary delete personal data that is no longer serving a valid purpose. Under the DPDP Act 2023, this right is codified in Section 11(b) and constitutes one of the core rights of Data Principals alongside the right to access, the right to correction, and the right to grievance redressal.

For Indian SaaS companies, the erasure right creates operational requirements that go beyond simply deleting a database record. It requires: a mechanism for Data Principals to submit erasure requests, a process to verify the requester's identity, an assessment of whether any legal basis for continued retention exists, technical capability to delete data across all systems and processors, and a process to confirm deletion to the requester.

Companies that have not previously offered data deletion capabilities will need to build them. Account deletion flows that simply deactivate an account without actually deleting underlying personal data do not satisfy the erasure right — the data must be genuinely deleted from all systems within the timeframe specified by the Rules.

What Section 11 Covers

Section 11 of the DPDP Act specifies that a Data Principal shall have the right to correction, completion, updating, and erasure of personal data in accordance with applicable law and the Rules. Section 11(b) specifically addresses erasure — the Data Principal can request deletion of personal data that is no longer necessary for the purpose for which it was collected, or where the Data Principal has withdrawn consent and there is no other lawful basis for processing.

The right to erasure under the DPDP Act is somewhat narrower than the equivalent right under GDPR Article 17, which includes additional grounds (objection to processing, unlawful processing, etc.). The DPDP Act ties erasure primarily to the cessation of purpose and withdrawal of consent. However, in practice these grounds cover most legitimate erasure requests — if a user wants their account deleted, the primary purpose (providing the service) is effectively withdrawn by the request itself.

The Rules will specify the form, manner, and timeframe for erasure requests. Based on comparable legislation, expect the Rules to require: a response (either confirming deletion or explaining grounds for refusal) within 30 days; deletion or anonymisation of personal data as soon as reasonably practicable after a valid request is confirmed; and a record of the request and the action taken.

When You Can Refuse an Erasure Request

The right to erasure is not absolute. You may decline an erasure request — in whole or for specific data categories — where retention is required by law. This includes financial records required under GST or Income Tax law, employment records required under labour law, medical records required under health regulations, and data subject to a legal hold in connection with litigation or a Board investigation. Document the specific legal basis for any refusal.

You may also retain data that is necessary to establish, exercise, or defend a legal claim. If a customer has raised a dispute about a transaction or is in the process of litigation with your company, you need not delete transaction records that are relevant evidence. Once the dispute or claim is resolved, however, the basis for retention under this ground ceases and the data should be deleted.

You cannot refuse an erasure request on the grounds that the data might be useful for analytics, that deleting it would be technically difficult, or that the user previously consented to collection. Consent is the basis for collection, but withdrawal of consent (expressed through an erasure request where no other basis exists) is the basis for deletion. "We collected it lawfully" is not a reason to refuse deletion of data that is no longer serving its original purpose.

Building an Erasure Request Intake Process

Establish a clear and accessible mechanism for submitting erasure requests. At a minimum, provide a designated email address (e.g., privacy@yourcompany.com) and an in-product "Delete My Account" or "Request Data Deletion" option. The DPDP Act requires a Consent Manager mechanism (for consumer applications) and a grievance redressal officer — erasure requests should flow through these channels.

Upon receipt, send an acknowledgement to the requester within 5 business days. Verify the requester's identity before processing — you should not delete data based on an unverified request that could be submitted by someone impersonating the Data Principal. Identity verification can be via the same authentication mechanism used in your product (e.g., confirm via a link sent to the registered email or phone number), or for higher-risk contexts, via submission of identity documentation.

Maintain a request register that tracks: requester identity, date received, date acknowledged, data categories covered, legal basis assessment (processing or refusing), date of deletion or refusal, and the reason for any refusal. This register is evidence of your compliance in the event of a Board complaint or audit.

Technical Deletion: What "Erased" Really Means

Erasure under the DPDP Act means more than marking a record as deleted in your application UI. It means permanent deletion of personal data from all production systems — primary databases, caches, search indices, and application logs — such that the data cannot be recovered through normal application means. Account deactivation (where the data is hidden but retained) does not satisfy the erasure obligation.

Implement a hard-delete process: when an erasure request is confirmed, set the record to be permanently deleted from the database. If your architecture uses soft deletes, you need an additional step to purge soft-deleted records on a schedule (or immediately for erasure requests). Cascade the deletion to all related tables: profile data, activity logs, preferences, billing information (subject to any legal retention obligation), and any personal data stored in separate services.

Search indices (Elasticsearch, Algolia) and caches (Redis, Memcached) often contain replicated personal data and must be explicitly cleared. Consider implementing an event-driven deletion architecture: when a hard-delete event fires in the primary database, publish an event to a queue that triggers deletion jobs in all secondary systems. This approach ensures completeness without requiring manual coordination across systems.

Cascading Erasure to Data Processors

Personal data processed by your vendors — analytics platforms, CRMs, email marketing tools, support systems, cloud storage — must also be deleted in response to a valid erasure request. Your Data Processing Agreements with vendors should include a provision requiring them to delete or return data within a specified period upon your instruction.

Create an erasure runbook that lists all vendor systems containing personal data and the steps to trigger deletion in each. For systems with API access, build automated deletion calls into your erasure workflow. For systems without API deletion support, document the manual steps required and assign responsibility. Ideally, vendor erasure is also triggered within the same response window as your primary system deletion.

Note that some vendors (particularly analytics and advertising platforms) may have their own data retention policies that make immediate deletion impractical. Address this in your DPA negotiation upfront: ensure vendors commit to deleting data within 30 days of your instruction, and that they provide written confirmation of deletion. If a vendor cannot commit to timely deletion, consider whether using that vendor is compatible with your DPDP obligations.

Handling Disputes and Board Escalations

A Data Principal who is unsatisfied with your response to an erasure request can escalate to your Grievance Officer (required under Section 12 of the Act) and ultimately to the Data Protection Board. The Board can investigate the complaint, direct you to comply, and impose penalties for non-compliance. Having a documented, timely process for handling the initial request reduces the risk of escalation to the Board.

If a Data Principal disagrees with your refusal of their erasure request (e.g., you claimed a legal retention basis they contest), handle the grievance internally first. Your Grievance Officer should review the original decision, consult with legal counsel if the basis is disputed, and respond to the Data Principal with a clear explanation. If the refusal is upheld, inform the Principal of their right to escalate to the Board.

Maintain records of every erasure request and every decision for at least 3 years. If a matter is escalated to the Board, you will need to produce evidence of: the request received, your identity verification, your legal basis assessment, your deletion actions (with timestamps and system coverage), and any communications with the requester. Organisations that cannot produce this evidence face a much harder compliance position before the Board.

Frequently Asked Questions

Does "delete my account" constitute an erasure request under the DPDP Act?

It should be treated as one. When a user clicks "delete account," they are effectively withdrawing from the relationship and requesting that their data not be retained. Build your account deletion flow to trigger the full erasure process — not just account deactivation. Retain only data you have a specific legal obligation to keep, and document the retention basis.

Can we anonymise data instead of deleting it in response to an erasure request?

Anonymisation can satisfy the erasure obligation if the anonymisation is genuine and irreversible — meaning re-identification is not reasonably possible even with additional data or effort. Pseudonymisation (where you retain a key that could re-identify) does not satisfy an erasure request. If you genuinely anonymise to an aggregate statistical record, the personal data is gone and the obligation is met.

How do we handle erasure requests for shared accounts (e.g., a company account with multiple users)?

Erasure requests from an individual user of a shared account should delete that individual's personal data — their profile, activity logs, and any data attributable to them — without deleting other users' data or the organisational account itself. Build your data model to allow individual-level deletion within a multi-user account structure.

What if we receive an erasure request but the account has an outstanding balance or dispute?

You may retain financial and transaction data necessary to resolve the outstanding balance or dispute. Inform the Data Principal of this basis for temporary retention and the expected timeline. Once the financial matter is resolved, delete the retained data promptly. Other data not needed for the financial resolution should be deleted without waiting for the financial matter to conclude.

How quickly must we complete an erasure after confirming a valid request?

The DPDP Rules will specify the timeframe. Based on draft Rules and comparable legislation, expect a requirement to complete deletion within 30 days of confirming the request. Primary system deletion should be immediate or near-immediate; secondary systems and processor deletions should follow within the same 30-day window. Document completion dates.