Data Retention Policy for DPDP: Delete on Schedule, Defend on Demand

Who this is for: compliance, privacy and engineering teams that decide how long data is kept and make sure it is actually deleted.

Most organisations know how to collect data. Very few know how to get rid of it. Old databases, forgotten exports, backups and vendor copies accumulate until nobody can say what is held or why. Under the DPDP Act, data kept without a purpose is a compliance failure in itself, and every unnecessary record adds to breach exposure.

What the law requires

Section 8(7): a Data Fiduciary must erase personal data, and cause its processors to erase it, once the Data Principal withdraws consent or it is reasonable to assume the specified purpose is no longer being served, unless retention is necessary for compliance with any law.

Rule 8 and the Third Schedule add three specifics:

1. A one-year floor. Personal data, associated traffic data and processing logs must be retained for at least one year from processing, for purposes such as preventing, detecting and investigating breaches, unless a law requires otherwise. This matches the log retention in Rule 6.
2. A three-year inactivity limit for large platforms:

The period runs from the user's last approach or exercise of rights, or from the commencement of the Rules, whichever is later. Processing needed only to give the user access to their account or to virtual tokens is excluded.

1. 48 hours' notice. Where the three-year rule applies, the user must be told at least 48 hours before erasure that their data will be erased unless they log in or contact the fiduciary.

The anatomy of a retention policy

Each processing activity in your ROPA should carry five retention attributes:

Two rules make the policy workable:

• Keep the record, not the file. Where a law requires one document, keep that document, not the whole customer profile around it.
• Separate logs from content. Security logs have their own minimum; they are not a reason to keep customer content.

Legal holds

When data is relevant to an actual or reasonably expected dispute, investigation or regulatory request, suspend deletion under a documented legal hold with an owner, a scope and a review date. When the hold ends, deletion resumes.

Making deletion real

• Automate. Scheduled jobs per system, driven by the policy.
• Include processors. Send deletion instructions to vendors and collect confirmation.
• Handle backups. Use rotation so deleted data expires from backups within a known period.
• Anonymise properly. Aggregated, de-identified data can be kept; pseudonymised data cannot be treated as anonymous.
• Evidence it. Keep deletion logs (without the deleted content) so you can prove the policy runs.

For HR-specific periods under the Labour Codes, see HR records retention in India.

Common mistakes

• "Indefinitely" or "as long as necessary" with no period or trigger.
• One period for everything.
• Policies that no system enforces.
• Forgetting the 48-hour notice for platforms within the Third Schedule.
• Deleting logs too early in the name of minimisation.

How ConsentifyAI helps

ConsentifyAI stores period, trigger, legal basis and erasure method for every processing activity, manages legal holds, sends Third Schedule pre-erasure notices where they apply, and generates deletion tasks across systems and vendors with evidence of completion.