DPDP data retention and erasure: build the lifecycle

Two independent triggers, whichever comes first

Section 8(7) requires a Data Fiduciary to erase personal data - and to cause its processors to erase it - on the earlier of two events: the Data Principal withdrawing her consent, or the point at which it is reasonable to assume the specified purpose is no longer being served.

The phrase whichever is earlier does real work. Organisations tend to build only the first trigger, because withdrawal is an event that arrives with a request attached. The second trigger arrives silently: nobody asks for anything, and the obligation matures anyway.

The whole duty is prefaced by unless retention is necessary for compliance with any law for the time being in force. That carve-out is genuine and it is narrower than it is usually treated as being - it is discussed further below.

Purpose no longer served is defined, not left to judgement

Section 8(8) supplies a test rather than leaving reasonableness at large. The purpose is deemed no longer served if the Data Principal does not approach the Data Fiduciary for the performance of the specified purpose, and does not exercise any of her rights in relation to the processing, for such period as may be prescribed.

Note the conjunction. Both limbs must be satisfied. Someone who never logs in but files an access request has exercised a right, and the clock does not run. The deeming provision is an inactivity test on both fronts.

Section 8(11) clarifies the first limb further: a Data Principal is considered not to have approached the Data Fiduciary during any period in which she has not initiated contact for the performance of the specified purpose. Passive receipt of your marketing email is not her approaching you.

The Third Schedule: three years, three classes

Rule 8(1) and the Third Schedule prescribe the period section 8(8) anticipated - but only for named classes. Those Data Fiduciaries must erase three years after the Data Principal last approached them or last exercised a right, or three years after the Rules commenced, whichever is latest, unless retention is required by law.

The named classes come with user-count thresholds, and the thresholds are high. E-commerce entities and social media intermediaries are in scope at two crore or more registered users in India; online gaming intermediaries at fifty lakh or more.

Read that carefully, because it is the most commonly misreported part of the Rules. There is no general three-year retention limit under the DPDP framework. There is a three-year rule for three classes of very large platform.

• E-commerce entity: two crore or more registered users in India.
• Online gaming intermediary: fifty lakh or more registered users in India.
• Social media intermediary: two crore or more registered users in India.

If you are not in the Third Schedule, what applies?

For everyone else, section 8(7) still binds - the duty to erase on withdrawal or when the purpose is no longer served has not gone away. What is absent is a prescribed period that fixes the second trigger with a number.

That is a harder position than having a deadline, not an easier one. You must form and document your own reasonable view of when each purpose stops being served, purpose by purpose, and be able to defend it. A retention schedule that says indefinite is not a view; it is the absence of one.

The defensible approach is to set a period per purpose, tie it to the nature of that purpose, write down the reasoning, and review it. A three-year default borrowed from the Third Schedule may be reasonable for a consumer account and plainly unreasonable for a one-off enquiry form.

The legal-retention carve-out is narrower than it looks

Retention necessary for compliance with any law for the time being in force is a real and important exception. Tax records, statutory registers, sector-specific record-keeping under RBI, SEBI or IRDAI directions, and litigation holds all sit within it.

Two limits are routinely overlooked. First, it is compliance with a law, not commercial convenience - we might need it for analytics, or it is useful for training a model, is not a legal requirement. Second, it justifies retaining the specific data the law requires for the period the law requires, not the whole record indefinitely.

In practice this means the carve-out usually shrinks the dataset rather than exempting it. An invoice may need to survive for the statutory period; the browsing history that led to it does not. Mapping which fields are held under legal compulsion, and which merely travel with them, is the work most retention projects skip.

Erasure has to reach your processors

Section 8(7)(b) is explicit: the Data Fiduciary must cause its Data Processor to erase personal data that was made available to it. Erasing your own copy while a vendor keeps theirs does not discharge the duty, and section 8(1) makes you responsible for processing carried out on your behalf regardless of any contract to the contrary.

This requires two things most organisations lack: a current list of which processors received which data under which purpose, and a contractual and technical route to instruct deletion and get confirmation.

Ask vendors the awkward question early - what is your deletion SLA, does it cover backups, and what confirmation do you provide. The answers vary enormously, and discovering a vendor cannot delete on request is much cheaper before you have five years of data with them.

Backups, logs and the honest answer

Erasure runs into two systems that are designed to resist it. Backups exist precisely so that deleted things can come back, and logs are required by Rule 6 to be retained long enough to support breach investigation.

The workable position is not to pretend these are erased on the same schedule as live data. It is to document them: state that live systems erase on the trigger, that backups age out on a defined cycle after which the data is unrecoverable, and that restoration from backup re-applies pending erasures. Then actually implement that last part, because it is where the design usually breaks.

Logs need the same treatment in reverse. Where a log must retain personal data for investigation, hold it for a defined period tied to that purpose, minimise what is written, and erase on that schedule. Retention obligations pointing in opposite directions have to be reconciled explicitly, or the strictest system silently wins and the weakest silently loses.

Section 12 erasure on request is a different route

Alongside the automatic duty in section 8(7), section 12 gives the Data Principal a right to erasure on request. The two are easy to conflate and they behave differently: section 8(7) fires without anyone asking, while section 12 arrives as a request that must be handled through the published channel Rule 14 requires.

A section 12 request also yields to the same legal-retention carve-out, so the answer is sometimes a partial erasure with an explanation rather than a clean deletion. Saying so plainly, with the provision relied on, is a better answer than a silent partial action.

Build one erasure mechanism serving both routes. Organisations that build a rights-request workflow and a separate retention job usually find the two disagree, and the disagreement is discovered by a Data Principal.

Build a retention register with owners

The artefact that makes all of this tractable is a register: one row per purpose, recording what data is held for it, the trigger and period for erasure, the legal basis for any retention override, the systems and processors holding copies, and a named owner.

It is the same register the consent work and the breach work need, viewed from a third angle - which is why doing it once, properly, is far cheaper than doing three partial versions for three projects.

Owners matter more than the document. A retention rule with no named owner is not reviewed, and a rule that is not reviewed drifts from what the systems actually do within about two release cycles.

• Purpose, and the data held for it.
• Erasure trigger and period, with the reasoning if not prescribed.
• Any legal retention override, naming the law and the fields it covers.
• Systems and processors holding a copy, with a deletion route for each.
• Backup ageing cycle and the re-application rule after a restore.
• A named owner and a review date.

Anonymisation is an alternative to deletion, if it is real

The Act applies to personal data - data about an identifiable individual. Data that genuinely cannot be linked back to a person is outside that definition, so irreversibly anonymising a dataset is a legitimate alternative to erasing it, and often a more useful one where the analytical value is real.

The word carrying the weight is irreversibly. Removing a name while retaining a device identifier, an account number or a sufficiently distinctive combination of attributes is pseudonymisation, and pseudonymised data remains personal data because re-identification remains possible. Most of what organisations describe as anonymised is in fact pseudonymised.

The honest test is adversarial: could this dataset be re-identified using other data we hold, or data that is publicly available? If yes, the retention duty still applies to it. Where anonymisation is genuine, record the method and the reasoning, because the claim that data fell outside the Act is one you may later have to support.

Getting the first pass done without boiling the ocean

A complete retention register across a mature estate is a long project, and treating it as an all-or-nothing exercise is the most reliable way to arrive at May 2027 with nothing in place.

Sequence by risk instead. Start with the systems holding the most personal data about the most people, and with the purposes where the retention period is most obviously indefensible - the marketing list nobody has pruned since 2019, the support desk holding every attachment ever sent, the analytics warehouse with raw event data going back to launch.

A register covering the top ten systems, with owners and real periods, is worth far more than a complete inventory that exists as a spreadsheet nobody executes against. Coverage can be extended; a policy that was never implemented anywhere cannot be defended at all.

What to do before 13 May 2027

Section 8 commences with the main operational tranche on 13 May 2027. If you are in a Third Schedule class, the three-year clock also runs from the Rules commencing, which means the first erasures under it fall due on a date you can calculate now.

The long-lead item is finding the copies. Most organisations know their primary store and underestimate the analytics warehouse, the CRM, the support desk, the data lake and the vendor who has had a nightly export since 2021. Start there, because a retention rule you cannot execute everywhere is a policy rather than a control.