# DPDP data retention: how long to keep it and when to erase

Source: https://dpdp.d2c.in/guides/dpdp-data-retention/ · Updated 2026-11-13 · DPDP Ready by Mirav Labs

**Short answer:** Section 8(7) of the DPDP Act requires you to erase personal data once consent is withdrawn or the purpose is no longer served, unless another law requires you to keep it. Rule 8(3) sets a one-year minimum for personal data, traffic data and logs. Large e-commerce, gaming and social media platforms must erase after three years of inactivity, with at least 48 hours' notice. These apply from 13 May 2027.

## Key takeaways

- Erase when consent is withdrawn or the purpose is served, and make your processors erase too (section 8(7)).
- Every fiduciary keeps personal data, traffic data and processing logs for at least one year from processing (Rule 8(3)).
- Third Schedule platforms erase after 3 years without contact, with a notice at least 48 hours before (Rule 8).
- Retention required by another law, such as tax or financial record-keeping, overrides erasure for that data only.
- Write a retention schedule with a period, legal source, erasure method and owner for every data category.

Many organisations keep personal data indefinitely by default. Storage is cheap, nobody owns deletion, and old data feels useful. The DPDP Act changes the default: from 13 May 2027, keeping personal data after its purpose is over is a breach in itself, and so is deleting some of it too early.

That second point is new. The final Rules added a one-year minimum retention for every fiduciary, so your retention policy now has a floor and a ceiling. This guide explains both, and gives you a schedule template you can fill in this quarter.

## What does the DPDP Act say about data retention?

Section 8(7) is the core rule. Unless retention is necessary to comply with a law, a Data Fiduciary must erase personal data, and make its Data Processors erase it, as soon as it is reasonable to assume the specified purpose is no longer being served, or when the Data Principal withdraws consent, whichever is earlier. Section 8(8) adds that a purpose is deemed no longer served if the person does not approach you or exercise their rights for a prescribed period. That period is prescribed for some classes in the Third Schedule.

Three things follow:

 
- **Retention is tied to purpose,** so you need to know the purpose of every data set. That comes from your [notice](https://dpdp.d2c.in/guides/dpdp-privacy-notice/) and consent records.
 
- **Withdrawal triggers erasure,** not just a stop to processing. Section 6(6) also requires you to stop processing within a reasonable time.
 
- **Processors are in scope.** Erasure is not complete until your cloud, CRM, analytics and support vendors have erased too.

Section 17(3) allows the government to exempt notified fiduciaries, including startups, from section 8(7). No such exemption has been notified, so plan as though it applies to you. Retention is not one of the breaches with its own line in the penalty Schedule, so it falls under “any other provision”, up to ₹50 crore.

## When is a purpose “no longer served”?

For most businesses, the end of a purpose is an event you can name: a contract ends, an account is closed, a job applicant is not hired, a lead goes cold, a support ticket is resolved. Your retention schedule should name the event, not just a period.

For three classes of large platforms, the Rules fix the inactivity period for you, which is the next section.

## The Third Schedule: three years for large platforms

Rule 8(1) and the Third Schedule apply to:

 
- e-commerce entities with 2 crore or more registered users in India,
 
- online gaming intermediaries with 50 lakh or more registered users in India, and
 
- social media intermediaries with 2 crore or more registered users in India.

If a user neither approaches the platform for the specified purpose nor exercises their rights for three years, the platform must erase their personal data, unless a law requires retention. The three years run from the latest of the user's last approach, their last exercise of rights, or the commencement of the Rules. The rule does not apply to data needed for the user to access their account, or to virtual tokens held on the platform that can be used for money, goods or services, such as wallet balances.

### The 48-hour notice

Rule 8(2) requires the platform to tell the user at least 48 hours before the period ends that their data will be erased unless they log in, make contact, or exercise their rights. In practice, build this as a scheduled job:

 **Track activity**Last contact per user

 **Find due users**Daily inactivity scan

 **Notify**At least 48 hours before

 **Wait**Login resets the clock

 **Erase**Systems and processors

**Now:** 
Even if you are below these thresholds, the same job design works for your own inactivity periods.

## What is the one-year minimum retention under Rule 8(3)?

Rule 8(3) applies to every fiduciary, whatever its size. For any processing done by you or by a processor on your behalf, you must keep the personal data, associated traffic data and other processing logs for **at least one year from the date of processing**, for the purposes in the Seventh Schedule. Those purposes are uses by the State or its instrumentalities for sovereignty, integrity and security, for functions under law and for disclosures required by law, and the government's assessment of whether to notify a fiduciary as significant. After the year, you must erase, unless another law requires further retention.

Rule 6(1)(e) separately requires logs and personal data to be kept for one year for detecting, investigating and remediating unauthorised access, and for continuity, unless law says otherwise. See our [security safeguards guide](https://dpdp.d2c.in/guides/dpdp-security-safeguards/).

The Rules' own illustration is an online purchase: once delivery is complete, the purpose is served, but the order details and logs of the processing (order, payment, delivery events) are kept for at least a year, even if the customer deletes the account. A second illustration makes the same point for a cloud provider acting as a processor.

Floor and ceilingRule 8(3) is a floor, not a licence. Data kept for this one year should be held for the Seventh Schedule and security purposes only: moved out of live systems where you can, access-restricted, and not used for marketing or analytics.

## How does DPDP retention interact with other laws?

Section 8(7) gives way to any law that requires you to keep data. Common sources are tax and financial record-keeping laws, company law, labour and employment laws, sector regulators (banking, insurance, securities, telecom, health), and directions on incident logs. These often require years of retention for invoices, accounts, KYC and employment records.

The DPDP Act does not override these laws, but it does shape how you keep the data:

 
- Keep only the records the other law actually requires, not the whole customer profile around them.
 
- Use them only for that legal purpose.
 
- Record the legal source in your schedule, so you can answer an erasure request with a specific reason. The [rights guide](https://dpdp.d2c.in/guides/dpdp-data-principal-rights/) covers how to respond.
 
- Ask your counsel to confirm each statutory period. Do not rely on a figure copied from an old policy.

## How to build a DPDP retention schedule

A retention schedule is a table, owned by someone, that your systems actually enforce. Start with your data inventory and give every category one row. Here is a template with sample rows:

| Data category | Purpose | Legal basis | Retention period | Legal source | Erasure method | Owner |
|---|---|---|---|---|---|---|
| Marketing leads | Sales follow-up | Consent | Until withdrawal, or a set period after last engagement | s.8(7); your policy | Hard delete in CRM; suppression entry only | Head of marketing |
| Customer account profile | Providing the service | Consent or s.7(a) | Account life, then the Rule 8(3) minimum | s.8(7); Rule 8(3) | Delete job across app DB, search index, cache | Product owner |
| Invoices and payment records | Statutory record-keeping | Legal obligation | Period set by tax law | Tax law (confirm with counsel) | Archive, restricted access, delete at end | Finance controller |
| Application and access logs | Security, investigation | Rule 6, Rule 8(3) | At least 1 year from processing | Rule 6(1)(e); Rule 8(3) | Rolling expiry in log store | Security lead |
| Job applicants (not hired) | Recruitment | Consent | Short fixed period after decision | s.8(7); your policy | Delete in ATS and mailboxes | HR lead |
| Support tickets | Resolving queries | s.7(a) | Fixed period after closure | s.8(7); your policy | Redact personal fields, keep stats | Support lead |

Two rules make the schedule useful. Every period has a trigger event (“12 months after account closure”, not “12 months”). And every row has an erasure method that a named system implements, so it is enforced by code rather than by memory.

## How do you erase across backups and processors?

### Backups

Restoring a backup can bring erased data back to life. Practical controls:

 
- Keep backup retention short and documented, so erased data ages out on a known date.
 
- Keep a minimal erasure ledger (an internal ID and date, no personal fields) and replay it after any restore.
 
- Where the architecture allows, encrypt per customer or per tenant and destroy the key at erasure.

### Processors

Section 8(7) makes you responsible for your processors' erasure, and section 8(1) makes you responsible for their processing generally. Your contracts should require erasure on instruction and at contract end, written confirmation, the same treatment of their sub-processors, and the Rule 8(3) one-year log retention on your behalf. Keep a register of which processor holds which data category, so an erasure request goes to every one of them. Our [fiduciary and processor guide](https://dpdp.d2c.in/guides/data-fiduciary-vs-data-processor/) has contract clauses.

### Data warehouses and analytics

Copies in warehouses, BI extracts and spreadsheets are where retention usually fails. Either bring them under the same schedule or aggregate them so they no longer identify anyone. Data that cannot identify an individual is outside “personal data” under section 2(t); pseudonymised data with a key you still hold is not.

## What to do next

 
- **Inventory first.** List data categories, systems and processors. Without this, a schedule is guesswork.
 
- **Collect legal sources.** Ask counsel for the statutory periods that apply to your records, and write them into the schedule.
 
- **Set the floor.** Configure log stores and processors for the one-year minimum under Rules 6 and 8(3).
 
- **Automate erasure.** Build deletion jobs per system, the processor fan-out and the backup ledger.
 
- **If you are a Third Schedule platform,** build the inactivity tracker and 48-hour notice.
 
- **Test and evidence it.** Run a sample erasure end to end and keep the logs.

Retention usually comes after the inventory in a [DPDP roadmap](https://dpdp.d2c.in/guides/dpdp-implementation-roadmap/), because it depends on it. If you want engineers to build the schedule and the deletion jobs with your team, see [our services](https://dpdp.d2c.in/#services).

## Frequently asked questions

### What is the data retention period under the DPDP Act?

The Act does not set one period for all data. You keep data while the purpose is served and erase it afterwards, unless a law requires longer. Rule 8(3) adds a minimum of one year from processing for personal data, traffic data and logs, and the Third Schedule sets a three-year inactivity limit for large e-commerce, gaming and social media platforms.

### How long should we keep logs under DPDP?

At least one year. Rule 6 requires logs and personal data to be kept for one year for detecting, investigating and remediating unauthorised access, and Rule 8(3) requires every fiduciary to keep personal data, traffic data and processing logs, including its processors', for at least one year from processing. Erase after that unless another law requires more.

### Can a customer ask us to delete data we must keep under tax law?

They can ask, and you must erase what you no longer need. Section 8(7) does not require erasure where retention is necessary to comply with a law. Keep only the records that law requires, restrict access to them, use them only for that purpose, and tell the customer what you kept and why.

### Who does the Third Schedule apply to?

E-commerce entities and social media intermediaries with 2 crore or more registered users in India, and online gaming intermediaries with 50 lakh or more. They must erase personal data after three years without contact or exercise of rights, counted from the latest of the last contact or the commencement of the Rules.

### Do we have to delete personal data from backups?

The Act does not carve out backups, so your erasure approach has to cover them. The usual pattern is to let backups expire on a short, documented cycle, keep a record of erased records so they are not restored, and use per-customer encryption keys where you can, so destroying a key makes the data unreadable.

### Is anonymised data subject to DPDP retention limits?

The Act applies to personal data, meaning data about an individual who is identifiable by or in relation to it (section 2(t)). Data that genuinely cannot identify anyone is outside that definition. Test your anonymisation honestly: pseudonymised data with a key you still hold is personal data.