Data Retention and Erasure Under the DPDP Rules: The Three-Year Clock and How to Automate It

Short answer: Under the DPDP Act, personal data must be erased once the purpose it was collected for is no longer being served, unless retention is required by law. The DPDP Rules add a specific clock for named classes of data fiduciary — e-commerce entities, online gaming intermediaries, and social media intermediaries above prescribed user thresholds — requiring erasure after three years of Data Principal inactivity, with at least 48 hours' notice before deletion.

Indian Companies Do Not Delete Data

Storage is cheap, and every product team's instinct is that data might be useful later. The result, in almost every Indian company we assess, is a data estate where nothing has ever been deleted: eight-year-old abandoned carts, KYC documents from customers who churned in 2019, support tickets from a product that no longer exists, and a data warehouse that replicates all of it.

The DPDP Act inverts that default. Erasure is not a user favour granted on request; it is an ongoing obligation triggered by the purpose ending. The two independent triggers:

• Purpose exhaustion — the purpose for which the data was collected is no longer being served, and retention is not necessary for legal compliance.
• Consent withdrawal — the Data Principal withdraws consent, at which point processing must cease and data must be erased unless a law requires retention.

Key insight: "we might need it for analytics" is not a legal retention requirement. Neither is "the CEO wants historical trends." A retention justification needs a statute behind it, or the data goes.

The Three-Year Inactivity Clock

The Rules go further for specified classes, attaching a bright-line timer rather than a judgement call.

Class of Data Fiduciary	Retention trigger	Action required
E-commerce entities (above the prescribed registered-user threshold)	Three years since the Data Principal last approached for the purpose, or since Rules commencement, whichever is later	Erase personal data and associated logs and traces
Online gaming intermediaries (above threshold)	Same	Same
Social media intermediaries (above threshold)	Same	Same

Two details matter operationally.

First, the clock runs from the Data Principal's last approach for the specified purpose — not from account creation, not from the last marketing email you sent them. Opening your app to check an old order restarts it. A dormant account that nobody has touched in three years does not.

Second, the obligation reaches traces and logs, not just the primary record. Deleting a row in the users table while the same identifiers persist in application logs, analytics events, the data warehouse, the CRM, backups, and a vendor's system is not erasure. This is where implementations fail.

The 48-Hour Notice

Before erasing, the Data Fiduciary must give the Data Principal at least 48 hours' notice, so they can log in and prevent deletion if they still want the account. The notice must reach them through the contact channel they provided.

This is a genuine product requirement, not just a compliance one. It needs a scheduled job that identifies candidates, a delivery mechanism that works, a way for the user to act on it, and a record that the notice was sent — which becomes your evidence that the erasure was lawful.

Retention Justifications That Actually Hold

Retention beyond purpose exhaustion needs a legal basis. In India the common ones are:

Data class	Typical retention basis	Indicative period
Financial and tax records	Income Tax Act, Companies Act	6–8 years
KYC records	PMLA and regulator directions	5 years after relationship ends (verify current sectoral rules)
Employment records	Labour codes, PF and ESI rules	Varies by record class
Payment transaction data	RBI directions	Per RBI requirement
Litigation hold	Ongoing or reasonably anticipated proceedings	Duration of the matter
Marketing contact history	None	Purpose-based only
Product analytics on identified users	None	Purpose-based only, or de-identify

Verify the exact period against the current text of the applicable law and your sectoral regulator's directions — these change, and a retention schedule citing a superseded circular is a finding waiting to happen.

Building the Machinery

Manual erasure does not survive audit. Six components make it automatic.

1. A retention schedule, per data class

Not per system — per class of data. Each row: what the data is, which purpose it serves, the retention basis (statute or purpose), the period, and the deletion method. Anything without a statutory citation defaults to purpose-based expiry.

2. A last-activity timestamp you trust

The three-year clock is worthless if you cannot say when a user last approached you for the purpose. This usually means defining "approach" precisely per product and writing it to a single authoritative field, rather than inferring it from six different event streams that disagree.

3. A deletion map

Every location an identifier lives: primary database, replicas, warehouse, search index, cache, object storage, application logs, analytics platform, CRM, email tool, support desk, payment processor, backups. Erasure means all of them. Write this map before you write the deletion job — most teams discover four systems they had forgotten while making it.

4. The notice job

Scheduled, idempotent, and logged: identify candidates, send the 48-hour notice, record delivery, wait, re-check activity, then delete. Re-checking activity after the notice window matters — a user who logs in during those 48 hours must not be deleted.

5. Backup handling

Backups are the honest awkwardness in every erasure programme. Selectively deleting from an immutable backup is usually impossible. The workable position is a documented backup retention cycle short enough that deleted data ages out within a defined window, plus a suppression list ensuring restored records are re-deleted immediately. Document the approach; do not pretend backups are already handled.

6. An erasure log

What was deleted, when, under which rule, and that notice was served. This is the artefact that proves compliance. Keep the log — it contains no personal data if built correctly, only identifiers-of-record and timestamps.

What a Retention Schedule Row Looks Like

Abstract advice about "building a retention schedule" is why most companies never build one. Here is the concrete artefact — six columns, one row per data class:

Data class	Purpose	Basis for retention	Period	Trigger	Deletion method
Abandoned cart contents	Recovery marketing	Purpose only	90 days	Cart creation	Hard delete, cascade to warehouse
Order and invoice records	Transaction record	Income Tax Act, Companies Act	8 years	Financial year end	Hard delete after period
Support ticket transcripts	Service delivery	Purpose only	24 months	Ticket closure	Redact PII, retain aggregate
Marketing contact history	Campaign delivery	Purpose only	Until withdrawal + 30 days	Consent withdrawal	Hard delete, add to suppression list
Dormant account (e-commerce)	Account provision	Rules three-year clock	3 years inactivity	Last approach for purpose	48h notice, then delete data, logs, traces
Application logs with user IDs	Debugging	Purpose only	30 days	Log write	Automatic log rotation

Two disciplines make this document real rather than decorative. Every row with "purpose only" in the basis column needs a defensible answer to "why that number" — and if you cannot give one, the number is too long. And every row needs a named system owner, because a schedule nobody owns is a schedule nobody enforces.

Withdrawal Should Trigger Erasure Automatically

The most common structural defect we see: consent withdrawal and data erasure are separate systems that do not talk to each other. The user clicks "withdraw consent," a flag flips in the consent platform, and the underlying data sits untouched in six systems while marketing continues to see them in a segment built last quarter.

The Act treats these as one event. On withdrawal, processing must cease and the data must be erased unless a law requires retention. Wiring that means:

• the consent platform emits an event on withdrawal rather than only updating its own state,
• downstream systems subscribe to it — CRM, email platform, ad-audience sync, warehouse,
• the erasure job runs against the same deletion map used for scheduled retention,
• data covered by a legal retention basis is quarantined rather than deleted, flagged as processing-restricted, and the user is told which categories were kept and why,
• the whole sequence is logged as evidence that withdrawal was honoured.

Key insight: if withdrawal only changes a boolean, you have built a preference toggle, not a compliance control. The test is simple — withdraw consent on a test account, wait a day, and check whether that person still appears in your email platform's audience.

Erasure Requests From Data Principals

Separately from scheduled retention, individuals can request erasure directly. The same deletion map serves both paths, which is why building it once is worth the effort. Requests arrive through your rights channel and run on your published SLA — see our guide to running Data Principal rights requests at volume. Withdrawal of consent should trigger the same machinery automatically rather than waiting for a separate erasure request.

Frequently Asked Questions

How long can a company retain personal data under India's DPDP Act?

Only as long as the purpose for which it was collected continues to be served, unless a law requires longer retention. There is no general permitted period. For specified classes — e-commerce entities, online gaming intermediaries, and social media intermediaries above prescribed user thresholds — the Rules impose erasure after three years of Data Principal inactivity.

What is the three-year rule in the DPDP Rules 2025?

Specified classes of Data Fiduciary must erase personal data, and associated logs and traces, three years after the Data Principal last approached them for the specified purpose or from commencement of the Rules, whichever is later. At least 48 hours' notice must be given to the Data Principal before erasure.

Does the DPDP Act require deleting data from backups?

The obligation is to erase personal data; the Act does not carve out backups. Since selective deletion from immutable backups is generally impractical, the accepted approach is a documented backup retention cycle short enough that deleted data ages out within a defined window, combined with a suppression list so restored records are immediately re-deleted.

What happens when a user withdraws consent?

Processing must cease and the personal data must be erased, unless retention is required by law. Withdrawal should trigger the same erasure machinery as scheduled retention rather than sitting in a separate manual queue, and the withdrawal itself must be recorded as evidence.

Can we keep data for analytics after the purpose ends?

Not in identifiable form. Analytics is not a legal retention requirement. If historical analysis matters, de-identify the data so it no longer relates to an identifiable individual — at which point the Act no longer applies — and be rigorous about it, since stripping direct identifiers alone is usually insufficient.

What penalty applies for failing to erase data?

There is no dedicated erasure entry in the penalty schedule, which means it falls into the residual category for breach of any other provision — up to ₹50 crore. Retaining data you should have deleted also increases exposure under the security-safeguards head, which carries up to ₹250 crore, because data you no longer need is data you can still lose.

Where Consently Fits

Retention only works if it is wired to consent state. Consently records per-purpose consent immutably, propagates withdrawal as an erasure trigger rather than a flag someone has to notice, tracks retention clocks per purpose, and keeps an audit trail of what was erased and when — the evidence an auditor or the Board will ask for. Talk to us about automating your retention obligations.