The right to erasure -sometimes called the right to be forgotten -is one of the most operationally demanding rights in any data protection framework. Under India's DPDP Act, you must be able to honour it reliably, within prescribed timelines, and with documented proof. Treat it as a support ticket and you will fail an audit; treat it as a workflow and you will pass.
This is Step 6 territory of the wider DPDP programme -see our 90-day roadmap for the full sequence. For how erasure relates to consent withdrawal, see our consent mechanism guide -withdrawal often triggers an erasure obligation downstream.
1. When Does the Right to Erasure Apply?
A data principal can request erasure of their personal data in several situations:
- Purpose fulfilled -the reason you collected the data has been served. A delivery is complete; the address you held to complete it is no longer needed.
- Consent withdrawn -and there is no other legal basis for continued processing. Marketing consent withdrawn means the marketing profile is no longer lawful to hold.
- Data no longer necessary -the data has aged past the point where it serves the original purpose.
- Unlawful processing -the data was processed without a valid basis from the start.
If you must retain data for tax, audit, employment, or sectoral regulatory purposes, you may decline erasure for that specific data -but you must document the legal basis for retention and delete everything else. The data principal is entitled to a clear written explanation of what is being retained and why.
2. The Seven-Step Workflow
Receive and acknowledge
Set up a clear, accessible channel for erasure requests -a dedicated email (privacy@yourcompany.com), a form inside your app, or a "Delete My Data" button in account settings. Acknowledge receipt immediately with a reference number and expected resolution timeline. This sets expectations and begins your audit trail.
Verify identity
Before processing any deletion, confirm the requester is the data principal (or their authorised representative). A simple identity check -matching the request to a registered email or account, or a verification token sent to the registered address -is sufficient. Do not create unnecessary friction. Do not delete data based on an unverified request.
Locate all instances of the data
This is where the data inventory you built earlier pays off. You need to find the data across:
- Primary databases (application, customer, transactional)
- Backup and archive systems
- Third-party processors and vendors you have shared data with
- Analytics and logging systems
- Marketing and CRM platforms
- Support ticketing systems
- Data warehouse and BI systems
Document every system searched, even where no data was found. The completeness of the search is part of your defensibility.
Assess retention obligations
Before deleting, check whether you have a legal obligation to retain the data. See the retention table in the next section. Where retention applies, communicate this to the data principal, specify what data will be retained and why, and delete everything else.
Execute the deletion
Deletion must be thorough. Two acceptable approaches:
- Hard delete -data is permanently removed from all systems.
- Anonymisation -data is stripped of all identifying attributes so it can no longer be linked to the individual. Must be irreversible.
Soft deletes (marking a record as deleted but keeping the data in the database) are not sufficient compliance. If you use soft deletes operationally for recovery, ensure you have a scheduled purge process that permanently removes data after a defined period.
Notify third parties
If you have shared the data principal's data with third parties -processors, partners, analytics vendors, marketing platforms -you must notify them of the erasure request and instruct them to delete as well. Document this in your response log. Your Data Processing Agreement with each vendor should explicitly cover the cascade obligation; if it does not, you have a gap to close.
Confirm and document
Send the data principal a written confirmation that their data has been deleted, specifying what was deleted, from which systems, and what (if anything) was retained and why. Maintain an internal record of:
- Request received date and identity verification completed
- Systems searched and deletion actions taken
- Third parties notified
- Confirmation sent to data principal
- Any retention exception applied, with legal basis cited
3. Retention Obligations That Override Deletion
Several Indian regulations require data retention for fixed periods regardless of erasure requests. The most common are:
| Data Category | Retention Period | Source |
|---|---|---|
| GST records | 8 years from end of relevant financial year | CGST Act |
| Income tax / audit records | 6-8 years | Income Tax Act, Companies Act |
| Employment records | Varies by state -typically 3-7 years | State labour laws |
| Financial transaction records | 5-10 years | PMLA, RBI rules, SEBI regulations |
| KYC records | 5-10 years after relationship ends | PMLA, RBI/SEBI/IRDAI rules |
| Active legal hold | Until matter is resolved | Court orders, litigation |
The principle: retention applies only to the specific data categories required by the regulation, not your entire customer record. If GST law requires you to retain invoices for 8 years, you keep the invoice -not the marketing preferences, not the device identifiers, not the support chat history.
4. Common Pitfalls to Avoid
- Failing to delete from backup systems -backups need to be rotated out within the documented retention window
- Not notifying third-party processors -they continue to hold the data after you have deleted it
- Over-retaining data beyond the stated legal basis -keeping a customer record for 10 years because "GST law" when only the invoice needed retention
- No acknowledgement or response within the expected timeline -silence reads as non-compliance
- Deleting data that is subject to a legal hold or active regulatory requirement
- Treating soft delete as sufficient -without a purge schedule, the data still exists
- Pseudonymisation labelled as anonymisation -if a re-identification key exists anywhere, it is not anonymisation
5. Building Deletion Into Your Architecture
The best time to design erasure capability is when you build the system, not when the first request arrives. Architectural patterns that make deletion straightforward:
- Data subject ID as a primary linking field. Every record that references a data principal carries a stable identifier. Targeted deletion becomes a single ID-based query across systems.
- Avoid duplicating personal data across tables without a reason. Each duplicate is another place to delete from and another place to forget.
- Backup retention policies in writing. If backups roll over every 35 days, that becomes the latest-possible delete date for backups. Document it.
- Sub-processor capability check before onboarding. Verify each new vendor can honour an erasure cascade before you sign the DPA. Vendors who cannot delete are vendors who will fail you on a future request.
- Erasure runbook. A documented internal procedure that lists every system, the deletion API or process for each, the responsible owner, and the verification step.
- Quarterly purge of soft-deleted records. A scheduled job that permanently removes anything marked deleted older than the retention window.
The right to erasure is a test of how well you actually know your own data. If you cannot find it, you cannot delete it. Invest in data mapping -it will serve you well beyond just erasure requests.
Need a reliable erasure workflow?
SecComply designs and operationalises DPDP rights workflows -including the erasure runbook, vendor cascade procedures, and audit-ready logging that turns a legal obligation into a routine operation.
Book a rights workflow review →FAQ
The DPDP Act does not yet prescribe a fixed timeline through rules. As a defensible default, acknowledge within 24-72 hours and complete the deletion within 30 days. Many global frameworks (GDPR) require completion within one month; aligning to that benchmark keeps you safe while specific Indian rules are finalised.
You can refuse only where you have an overriding legal obligation to retain -GST records, employment records under labour law, financial records under sectoral regulation, or active legal hold. You must document the refusal with the specific legal basis and communicate this to the data principal. You cannot refuse simply because deletion is inconvenient or commercially undesirable.
Yes, but the timing can be different from primary system deletion. Backups are typically rotated out on a schedule (30-90 days is common). The accepted practice is to delete from primary systems immediately, and confirm that backups containing the data will be rotated out within the documented backup retention period. Document the backup rotation policy as part of the erasure response.
No -not on its own. Soft delete (marking a record as deleted but keeping the data in the database) does not satisfy the erasure obligation. If you use soft deletes operationally for recovery, you must run a scheduled purge process that permanently removes soft-deleted records after a defined period. The end state is data that genuinely cannot be retrieved or reconstructed.
Anonymisation is an accepted alternative to deletion provided the anonymisation is irreversible -the data can no longer be linked to the individual, even by combining it with other information you hold. Pseudonymisation (where a re-identification key exists somewhere) is not anonymisation and does not satisfy the obligation.