DPDP data retention and erasure: what to keep, and when to delete it

Section 8(7) says a Data Fiduciary must erase personal data when the Data Principal withdraws consent or when the specified purpose is no longer being served, unless retaining the data is necessary to comply with another law. The Act also requires the Data Fiduciary to cause its Data Processors to erase data when it is no longer needed for the purpose, subject to applicable law.

That means “keep everything indefinitely” is difficult to defend, but “delete everything immediately” can also be wrong. Tax, employment, healthcare, financial-sector and other rules may require records to be retained for a particular period. Identify those obligations for each record type before setting an erasure date.

For practical purposes, a retention schedule should state what data is covered, why it is held, what event starts the clock, the period or review point, any legal hold, who approves exceptions, and how deletion is confirmed across processors and backups.

See sections 6(5), 8(7) and 12(3) of the Act.

A spreadsheet is often enough to begin. The hard part is making the entries concrete enough for teams to act on and specific enough to distinguish a genuine legal hold from an old habit.

1. Name the record and purpose. Separate records that serve different purposes, even if they live in the same system.
2. Choose a clear trigger. Examples include account closure, completion of a transaction, the end of a recruitment campaign, or the last contact for a specified purpose.
3. Record the source of the period. Note the business need, Act or Rule provision, sector regulation, contract, or other legal requirement supporting the period.
4. Set the action at expiry. Decide whether the record is erased, anonymised where appropriate, archived under a legal requirement, or flagged for a documented review.
5. Assign an owner and system path. Identify who reviews exceptions and which platforms, vendors, exports and backups need to be covered.
6. Keep evidence of the outcome. Record the deletion request, completion date, systems covered, failures and follow-up actions.

Review the schedule when a purpose changes, a product is retired, a vendor is replaced, or a new legal retention requirement appears. A written schedule is useful only if teams can connect it to actual systems and processes.

Customer information is usually copied across a CRM, billing tool, support inbox, analytics service, messaging platform and one or more processors. A deletion workflow should say which system is authoritative, how connected systems are notified, and how a failed deletion is escalated.

• Keep an inventory of systems and processors that receive each data category.
• Define how production data, exports and recoverable backups are handled when a deletion is due.
• Use a documented legal-hold process so that required records are isolated from routine use and not kept without review.
• Test a sample deletion end to end and retain evidence of completion or an exception.

The Rules’ one-year log requirement applies to the specified purposes and includes processing undertaken on the Data Fiduciary’s behalf by a processor. Include processor retention and erasure instructions in contracts and operational checks where that rule applies.