DPDP data retention is governed by rule 8 of the Digital Personal Data Protection Rules, and rule 8 asks for two opposite things. It forces erasure three years after a Data Principal goes inactive, but only for three named classes of large consumer platforms. It separately forces every Data Fiduciary, with no size threshold at all, to retain personal data, associated traffic data and processing logs for a minimum of one year from the date of processing.
A retention policy written only around deletion will breach the one-year floor. A policy written only around record-keeping will breach the erasure ceiling, if the ceiling applies to you. Most teams build exactly one of the two and discover the other during an assessment.
Rule 8 sits in the eighteen-month commencement tranche, which lands in mid-May 2027. That is the date to plan against, and it is a single cliff rather than a phased ramp.
Rule 8 Pulls in Two Directions at Once
Rule 8 of the DPDP Rules pulls in two directions because its erasure duty and its retention duty have completely different populations. The erasure duty is narrow and conditional; the retention duty is universal.
So you cannot answer "how long do we keep personal data under DPDP" with one number. You need two answers per data category: the earliest date you may delete, and the latest date you may keep. For most companies the first is binding and the second never fires at all.
This is one of the harder rules in the set to implement, and the difficulty is not legal. Working out which clock applies takes an afternoon. Making erasure happen across primary stores, read replicas, backups, warehouses and derived analytics datasets is an engineering programme that runs for quarters.
The Three Third Schedule Classes and Their Thresholds
The three-year inactivity clock in rule 8 applies only to the three classes named in the DPDP Third Schedule, and each carries its own registered-user threshold — two crore for two of them, fifty lakh for the third:
| Class | Threshold |
|---|---|
| E-commerce entity | At least two crore registered users in India |
| Online gaming intermediary | At least fifty lakh registered users in India |
| Social media intermediary | At least two crore registered users in India |
Note that the gaming threshold is an order of magnitude lower than the other two. An online gaming intermediary crosses into scope at fifty lakh registered users in India, where e-commerce and social media entities do not until two crore.
Why Most Companies Are Not in Them
Most companies are not in any of the three classes, and saying so plainly is more useful than implying that the three-year clock is a universal DPDP obligation. A B2B SaaS vendor is not an e-commerce entity. A fintech lender, a hospital group, a logistics company, an insurer and a staffing platform are none of the three, and none of them hit the thresholds anyway.
If you are not in a Third Schedule class, the inactivity erasure duty in rule 8 does not reach you. Your retention obligations under DPDP are the one-year floor, whatever other Indian law imposes on your sector, and your own purpose-limitation discipline — which is still worth having, because retaining data you no longer need is a breach-blast-radius problem even when no rule forbids it.
Registered users is not monthly active users, and it is not accounts net of churn. If you are within sight of a threshold, decide now how you will count, and build the erasure pipeline before you cross it rather than after.
Not sure which DPDP retention clock applies to your data?
Share your work email and we'll map your data categories against rule 8's erasure duty and its one-year floor, and flag which of the two is actually binding for you.
How the Three Year Inactivity Clock Is Calculated
For a company inside a Third Schedule class, the three-year inactivity clock under DPDP runs from the latest of three events: the date the Data Principal last approached the Data Fiduciary, the date they last exercised a right, or the commencement of the Rules. Whichever of those is latest starts the three years.
Two details in that construction do real work. "Whichever is latest" means the clock cannot be backdated against data you already hold: existing dormant accounts do not become immediately erasable the day the rule bites, because commencement acts as a floor on the start date. And exercising a right resets the clock just as a login does, so your rights-request handling and your retention engine have to write to the same timestamp.
The duty is also displaced where retention is necessary under another law. If a sectoral regulator, a tax rule or a record-keeping statute requires you to hold the data longer, that requirement overrides the erasure obligation for the data it covers. It has to be documented per data category rather than asserted in general — the same discipline an ISO 27001 retention schedule already demands.
The Forty Eight Hour Pre Erasure Notice
Rule 8(2) adds an operational step most teams forget entirely: at least forty-eight hours before erasure, you must tell the Data Principal that it is coming, and tell them that logging in or exercising a right will stop it.
This is a product surface, not a policy paragraph. Something has to compute the pending-erasure population two days ahead, reach people who by definition have not logged in for three years, say plainly what will be deleted, and offer an action that cancels it. The notice job and the erasure job therefore have to share state: a login arriving thirty-six hours into the window must abort an erasure already scheduled.
Build the cancellation path first. A notice that goes out and an erasure that runs anyway is worse than no notice, because you have told the Data Principal they had a remedy and then removed it.
The One Year Floor That Applies to Everyone
The one-year floor applies to everyone, Third Schedule class or not. Rule 8(3) requires a Data Fiduciary to retain personal data, associated traffic data and processing logs for a minimum of one year from the date of processing.
Read the three categories carefully, because teams usually plan only for the first. Associated traffic data and processing logs are the ones most stacks rotate out by default — log retention is typically set by cost, not by law, and thirty or ninety days is a common default that is now well short of the requirement.
The floor runs from the date of processing, so it is per-record, not per-account. A record created eleven months ago is not eligible for deletion even if the account that produced it closed last week. That is a different data model from the one most deletion jobs assume.
Where the Floor Meets the Security Safeguards Log Rule
The floor in rule 8(3) and the log retention inside the security safeguards point the same way, and together they constrain any deletion-by-default architecture. Rule 6's seven minimum safeguards include retaining logs and personal data for one year unless another law requires otherwise — a retention floor placed deliberately inside the security rule, as an anti-tampering measure.
So the one-year minimum arrives twice, from two rules, with two rationales. Rule 8(3) frames it as a retention duty. The safeguards frame it as making sure evidence of unauthorised access survives long enough to investigate, alongside their demand for visibility on access through logs, monitoring and review. Our guide to DPDP security safeguards covers how the seven items fit together.
The combination matters because the safeguards duty is tied to the largest penalty band in the Act. Aggressive log rotation is no longer just a retention policy question; it undercuts the control the regulator treats most seriously.
Backups, Data Warehouses and Analytics Copies
Backups, data warehouses and analytics copies are where DPDP erasure requirements stop being a policy exercise. Erasing a row from a primary database is a single statement. Erasing the same person from every derived and replicated copy is a programme, and the notice window in rule 8(2) gives you no room to improvise it.
- Backups. Immutable snapshots exist so that nothing can be altered after the fact, and the safeguards rule names backups as a reasonable measure for continued processing. You cannot selectively delete from most of them. The workable pattern is a documented snapshot retention period, a suppression list reapplied on restore, and a restore runbook that does not resurrect erased records.
- Warehouses and lakes. Columnar and append-only stores make per-subject deletion expensive. Partitioning by subject or by ingestion date, plus scheduled compaction, turns erasure from a full-table rewrite into a bounded job.
- Derived datasets. Feature stores, training sets, BI extracts and cached segments each hold their own copy. Every one needs either a lineage link back to the subject or a rebuild-from-source schedule short enough that erasure propagates inside the one-year floor.
- Third-party processors. A Data Fiduciary may involve a Data Processor only under a valid contract, and that contract is where your erasure instruction has to live. Your deletion is not complete until theirs is.
None of this works without knowing where the copies are, which is why a current data inventory is the real prerequisite. The approach in our GDPR asset inventory guide transfers directly: you cannot erase from a system you have not recorded.
A Worked DPDP Retention Schedule
A worked retention schedule turns rule 8 into something an engineer can implement. Four columns do the job: the data category, which clock applies, what triggers it, and what the pre-erasure notice has to do.
| Data category | Applicable clock | Trigger | Pre-erasure notice |
|---|---|---|---|
| Account data (Third Schedule class) | Three-year inactivity erasure, subject to the one-year floor | Latest of last approach, last exercise of a right, or Rules commencement | Required 48 hours ahead; must say erasure is coming and that logging in or exercising a right prevents it |
| Account data (not a Third Schedule class) | One-year floor only | One year from date of processing | None required by rule 8 |
| Transaction and billing records | One-year floor, extended where another law mandates longer | One year from date of processing, or the end of the statutory period | None; erasure here follows your own purpose limitation |
| Associated traffic data | One-year floor | One year from date of processing of each record | None |
| Processing and access logs | One-year floor, reinforced by the safeguards log duty | One year from the date the entry is written | None |
| Backup snapshots | The snapshot retention period you define and document | Snapshot expiry | None; carry a suppression list so a restore does not resurrect erased records |
| Warehouse and derived datasets | Mirrors the clock on the source record | Propagated from the source erasure, or rebuilt from source | Covered by the source record's notice |
Two rules of reading this table. Where a clock and the floor conflict, the floor wins until it expires. And where another law requires retention, record which law, for which category, and for how long, in the schedule itself.
DPDP Data Retention Questions Teams Ask
These are the DPDP data retention questions teams ask most often once they realise rule 8 contains both an erasure duty and a retention floor.
Only if you are an e-commerce entity with at least two crore registered users in India, an online gaming intermediary with at least fifty lakh, or a social media intermediary with at least two crore. Those are the three Third Schedule classes. Most companies are in none of them, so the three-year erasure clock does not apply and the binding obligation is the one-year minimum in rule 8(3).
Not unconditionally. Rule 8(3) requires personal data, associated traffic data and processing logs to be retained for a minimum of one year from the date of processing, and the security safeguards separately require one year of log and personal data retention unless another law requires otherwise. Deletion-by-default architectures and short log rotation windows both need revisiting against that minimum.
Rule 8(2) requires that at least forty-eight hours before erasure you inform the Data Principal that their personal data is about to be erased, and that logging in to the user account or otherwise initiating contact to exercise a right will prevent the erasure. The notice has to be paired with a working cancellation path, so an action taken inside the window actually aborts the scheduled deletion.
Yes. The three-year erasure obligation does not apply where retention is necessary for compliance with any other law. Document it per data category rather than as a blanket exemption: name the law, the category it covers, and the period it requires. Otherwise you have an argument rather than a defence, and no way to tell the retention engine which records to skip.
Rule 8 is in the eighteen-month commencement tranche, which takes effect in mid-May 2027, eighteen months after the Rules were published in the Gazette on 14 November 2025. Nothing in that tranche phases in gradually. Given that erasure across replicas, backups and derived datasets is engineering work rather than a policy line, the schedule is less generous than it reads.
Turn rule 8 into a retention schedule you can defend
Book a demo and we'll show how Konfirmity holds your data categories, their retention clocks and the evidence that erasure actually ran, in one place.
Book a demo
Build the Floor Before the Deletion Job
Build the one-year floor before you build the deletion job, because the floor applies to you with certainty and the three-year clock probably does not. Audit log retention windows first — the most commonly misconfigured piece and the cheapest to fix — then confirm that your traffic data and processing logs survive a full year from the date of processing.
Then decide honestly whether you are in a Third Schedule class. If you are not, say so in writing and move on to purpose limitation, which is better practice than the rule requires and reduces your exposure anyway. If you are, or will be, start with the inventory of places a person's data lands, because the pre-erasure notice and the erasure job are both downstream of knowing what has to be deleted and where. The official text and subsequent notifications are published by the Ministry of Electronics and Information Technology at meity.gov.in.
Our SOC 2 data retention guide covers the same schedule-plus-evidence mechanics, and the full set of DPDP duties this rule sits alongside is laid out in our DPDP compliance checklist.
