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

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 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:

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.

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.

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 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:

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 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

1. Inventory first. List data categories, systems and processors. Without this, a schedule is guesswork.
2. Collect legal sources. Ask counsel for the statutory periods that apply to your records, and write them into the schedule.
3. Set the floor. Configure log stores and processors for the one-year minimum under Rules 6 and 8(3).
4. Automate erasure. Build deletion jobs per system, the processor fan-out and the backup ledger.
5. If you are a Third Schedule platform, build the inactivity tracker and 48-hour notice.
6. 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, because it depends on it. If you want engineers to build the schedule and the deletion jobs with your team, see our services.

This guide explains the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 as notified on 13 November 2025. It is general information, not legal advice. Check the official text, and your counsel, before relying on it.