Retention & Erasure
Define how long you keep data, automate when it goes, and prove it actually went.
The problem
Section 8(7) of the DPDP Act is one sentence long and creates one of the hardest operational challenges in compliance: "The Data Fiduciary shall erase personal data... where the Data Principal withdraws consent or where the specified purpose is no longer being served, whichever is earlier."
That sentence means: you must know the purpose for every piece of personal data you hold, you must know when that purpose has been served, you must delete the data when the purpose is served or consent is withdrawn (whichever comes first), you must delete it from every system including backups and third-party processors, you must do it within 7 days for erasure requests with no ongoing lawful basis, and you must be able to prove you did it.
Most companies fail at the first step. They do not have a defined retention schedule - a document that says "customer transaction records: 7 years (Companies Act requirement), marketing consent records: 3 years after withdrawal, support ticket data: 18 months after resolution." Without this, data accumulates indefinitely and every system becomes a compliance liability.
The second failure point is backup deletion. Your primary database may delete a user's data within 24 hours. But if your backup system retains a snapshot containing that data for 90 days, you are non-compliant for 89 of those days. Most companies do not map their backup architecture against their retention schedules.
The third failure point is processor follow-through. When you delete customer data from your systems, does your CRM vendor also delete it? Does your email marketing tool purge it from their servers? Does your analytics platform remove it from their data warehouse? Under DPDP, you need proof that processors have completed deletion - not just your own systems.
What ComplyDP does
Retention schedule builder
Define retention periods for every data category, mapped to purpose and legal basis. The platform comes pre-loaded with common Indian statutory retention requirements (Companies Act, GST, labour laws, PF Act) so you do not need to research retention obligations from scratch.
Automated deletion triggers
When a retention period expires or consent is withdrawn, the platform flags the data for deletion. Automated triggers can initiate deletion workflows across connected systems or generate task lists for manual deletion where automation is not available.
Processor deletion tracking
When you send a deletion request to a vendor, track whether they confirmed deletion, when, and with what evidence. Maintain a chain of deletion proof across your entire processor ecosystem.
Backup-aware retention
Map your backup architecture (daily snapshots, weekly full backups, disaster recovery copies) against your retention schedules. The platform identifies where backup retention exceeds data retention periods and flags the compliance gap.
Erasure certificates
Generate audit-ready erasure certificates for every deletion event: what data was deleted, from which systems, when, by whom, and with what processor confirmations. This is your evidence when the DPBI asks 'can you prove you deleted it?'
How it works
- 1
Define your retention schedule
For each data category in your inventory, set a retention period and the reason for it (statutory requirement, business need, consent-dependent). The platform suggests defaults based on Indian law.
- 2
Map systems and backups
Identify every system where each data category is stored - including backups, caches, and processor systems. This is the deletion scope for each data category.
- 3
Activate triggers
Set automated flags for when retention periods expire or consent is withdrawn. The platform generates deletion tasks with deadlines and assigns them to system owners.
- 4
Execute and certify
Delete across all systems, collect processor confirmations, and generate an erasure certificate. Store the certificate as your audit evidence.
What the Act requires
| Section | Requirement |
|---|---|
| Section 8(7) | Erase personal data when purpose is served or consent is withdrawn, whichever is earlier |
| Section 12 | Data Principal can request erasure - must be completed within prescribed timeline (7 days) |
| Section 6(4) | When consent is withdrawn, processing must stop and data must be deleted |
| Rule 8 (for certain entities) | Large platforms must erase data after specified inactivity periods (e.g., 3 years) with 48-hour prior notice to user |
Frequently asked questions
When must we delete personal data?▼
When the purpose for which it was collected is no longer being served, OR when the Data Principal withdraws consent - whichever comes first. Unless a separate legal obligation requires retention (Companies Act, tax laws, etc.), in which case you retain only for the statutory period and then delete.
Do backups need deletion too?▼
Yes. If a backup contains personal data that should have been deleted, that backup is non-compliant. Practically, most companies cannot delete individual records from backups. The compliant approach is to ensure backup rotation periods align with retention schedules, and to flag data as 'marked for deletion' so it is not restored from backup after deletion from primary systems.
Do DPDP Rules set specific retention periods for some businesses?▼
Yes. Large-scale e-commerce platforms (20M+ users), online gaming platforms (5M+ users), and social media platforms (20M+ users) must erase personal data after 3 years of user inactivity, with a 48-hour notice sent before deletion. All organisations must retain data processing logs for at least 1 year.
Can we keep data forever for 'analytics'?▼
No. 'Analytics' is not an indefinite retention justification. If you need data for analytics, define a specific retention period, disclose it in your privacy notice, and delete when it expires. Consider anonymisation - truly anonymised data (irreversible, verified) falls outside DPDP's scope.
Find out where you stand
10-minute diagnostic. 43 controls. No demo call required.