KaryaFlow
Back to blog

Who the DPDP retention rule binds

Kirtesh Sharma9 min read

Practical guidance for planning, not legal advice. Confirm your own obligations with counsel and against the Gazette text.

There is a retention rule in the DPDP Rules that gets quoted a lot: delete personal data three years after the person last interacted with you. It appears in most compliance checklists without qualification, and it has convinced a lot of small companies they have a countdown running.

Read the Third Schedule and it narrows sharply.

Who the three-year rule actually binds

The Schedule names three classes of Data Fiduciary and sets a threshold for each:

  • E-commerce entities with “not less than two crore registered users in India”
  • Social media intermediaries with “not less than two crore registered users in India”
  • Online gaming intermediaries with “not less than fifty lakh registered users in India”

Two crore is twenty million registered users. If you run a 60-person company with forty thousand customers, you are not within three orders of magnitude of this rule. It was written for the largest consumer platforms in the country, and it is a backstop for them rather than a general obligation.

For those that are in scope, the clock is “three years from the date on which the Data Principal last approached the Data Fiduciary for the performance of the specified purpose or exercise of her rights, or the commencement of the Digital Personal Data Protection Rules, 2025, whichever is latest”, with carve-outs so a person can still reach their account and any virtual tokens holding value.

The obligation that does apply to you

Here is the part the checklists bury. You do not get a retention policy because the Third Schedule tells you to. You get one because of purpose limitation, which applies to every Data Fiduciary from the start.

You may hold personal data for the purpose the person consented to. When that purpose is finished, the basis for holding it is finished too. And if they withdraw consent, you act on it.

Notice that this is a stricter standard than the one you were worried about, not a looser one. A three-year backstop lets a giant keep a dormant record for three years. Purpose limitation asks a much harder question much sooner: why do you still have this? For most small companies the honest answer for a lot of their data is “no reason, we just never deleted anything”.

A workflow that survives being asked about

Four steps, in this order. The order matters — most teams start at step three and end up automating something they never defined.

  1. Map data to purpose. For each category of personal data, write the purpose it was collected for and the event that ends that purpose. Contract ends. Account closed. Enquiry not converted after N months. If you cannot name the ending event, that is the finding, and it is common.
  2. Decide the retention rule per purpose, including any legal or tax reason you must keep something longer — those override, and they are a legitimate answer. What is not legitimate is applying them to everything because it is easier.
  3. Make deletion complete. This is where it usually fails. Deleting from the CRM while the record survives in the email tool, the analytics warehouse, the support inbox and last night's backup is not deletion. Enumerate every destination the data reaches, including exports someone set up two years ago.
  4. Keep evidence. An erasure you cannot demonstrate is one you may as well not have performed. Log what was deleted, when, on whose request, and from which systems — then test the whole path on a real record and time it.

Why a fragmented stack fails step three

Every tool you add is another destination that has to honour a deletion and another place a copy can outlive its purpose. The failure is rarely that a team refused to delete something. It is that nobody knew the seventh copy existed.

One data model collapses step three into a single operation and makes step four fall out of the audit log for free. It does not make you compliant — steps one and two are policy work that no software decides for you. It removes the part that quietly goes wrong.

What we ship today is on our security and compliance page, and the deletion and retention questions are in the eight to ask every vendor — including us.

Where this comes from

Thresholds and the retention period are quoted from the Third Schedule of the DPDP Rules, 2025, checked 8 August 2026. Some secondary summaries add a notice requirement before erasure; we could not find it in the Schedule text itself, so we have not stated it here — check the full Rules if that detail matters to you.

Purpose limitation and erasure obligations sit in the Act and the wider Rules rather than in this Schedule. As always: confirm against the Gazette text and your counsel, not against a vendor's blog.