DPDP Data Retention Rules: How Long Can Indian Businesses Keep Customer Data Before May 2027?

Ask an Indian business how long it may keep customer data under the new privacy law, and the most common answer you will hear in 2026 is "three years." That answer is wrong for almost every business that gives it. The three-year figure comes from a specific mechanism in the Third Schedule to the DPDP Rules, 2025, and it applies to a defined set of very large digital platforms. For everyone else, the Digital Personal Data Protection Act, 2023 supplies no number at all. It supplies a question: when is the specified purpose for which you collected the data no longer being served?

That question is harder than any number, because it cannot be answered in a policy document. It has to be answered inside CRM databases, email platforms, customer-support systems, accounting records, analytics stacks, backups and the systems of every processor that touches the data. Under the commencement schedule in Rule 1 of the DPDP Rules, 2025, published in the Gazette on 13 November 2025, the substantive obligations, including the retention and erasure machinery in Rule 8, commence on 13 May 2027. From the date of this article, that is 230 days away. For the overall regime, the pillar reference is Data Privacy Compliance in India: The DPDP Act Framework. This article addresses the layer that pillar deliberately leaves open: how a business actually constructs a lawful retention period.

"Keep It for Three Years" Is Not India's DPDP Retention Rule

The misconception is worth dismantling precisely, because the real framework has three distinct layers and the three-year rule is only one of them.

Layer one is the general erasure obligation. Section 8(7) of the Act requires a Data Fiduciary, unless retention is necessary for compliance with any law in force, to erase personal data upon the Data Principal withdrawing her consent, or as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier, and to cause its Data Processor to erase data made available to it. The Act's own illustration is an online marketplace that helped a user sell a used car: once the sale concludes, the marketplace shall no longer retain her personal data. No three-year grace. No waiting period. Purpose ends; erasure follows.

Layer two is the deeming mechanism. Rule 8(1), read with the Third Schedule, tells three classes of very large platforms when they may treat the purpose as no longer served: after three years of user inactivity. This is a rule for defining purpose-end at scale, not a retention entitlement.

Layer three is the floor. Rule 8(3) requires every Data Fiduciary, regardless of size or class, to retain personal data, associated traffic data and processing logs for a minimum of one year from the date of processing, for the purposes specified in the Seventh Schedule, before causing their erasure. "Delete everything immediately" is therefore just as unlawful as "keep everything forever."

The practical consequence: a small SaaS company, a D2C brand, a clinic, a recruitment platform, none of them receives a three-year licence. They operate under layer one and layer three simultaneously, and the layer that usually bites first is the purpose test.

The Real Starting Point: When Is the Purpose No Longer Being Served?

A defensible retention schedule begins with purpose, not with an arbitrary number of months. Section 8(7)'s trigger is reasonableness: when is it reasonable to assume the specified purpose is no longer being served? Worked across the data categories most businesses actually hold, the answers diverge sharply:

Two disciplines emerge from the table. First, each category needs its own purpose-end trigger, because the Act assesses retention purpose by purpose, not database by database. Second, purpose creep is the operative risk: data collected for fulfilment drifts into marketing, analytics and "future opportunities" without a fresh lawful basis, and each silent drift extends a retention clock the business never consciously set. The collection-surface side of this problem, what the notice said the data would be used for, is where the retention answer is partly written in advance, and we have examined those notice failures in What Indian Websites Get Wrong About DPDP.

The Special Three-Year Rule for Large Digital Platforms

For the platforms that do fall within the Third Schedule, the mechanism deserves exact reading, because it is frequently misdescribed even in professional commentary.

Who Is Covered

How the Mechanism Works

Under Rule 8(1), a covered platform must erase the personal data it processes for the purposes listed in the Schedule if, for the specified period, the Data Principal neither approaches the platform for the performance of the specified purpose nor exercises her rights in relation to the processing. The period is three years from the date on which the Data Principal last approached the platform or exercised her rights, or from the commencement of the DPDP Rules, 2025, whichever is latest. Because the Rules were published on 13 November 2025 and the substantive provisions commence on 13 May 2027, the first wave of commencement-anchored erasure deadlines falls in November 2028 for users who have been continuously inactive since before the Rules were published.

Two features of the Schedule are routinely missed:

• Two purposes are carved out of the erasure duty: data processed to enable the Data Principal to access her user account, and data relating to a virtual token issued by or on behalf of the platform, stored on its facility and usable for money, goods or services. A platform need not auto-erase the very credentials and wallet balances that let an inactive user return.
• The deeming mechanism does not override law-based retention: Rule 8(1) expressly preserves retention necessary for compliance with any law in force.

The 48-Hour Pre-Erasure Notification

Rule 8(2) adds an operational duty with a hard edge. At least forty-eight hours before the erasure period completes, the platform must inform the Data Principal that her data will be erased on completion of the period, unless she logs into her user account, otherwise initiates contact for the specified purpose, or exercises her rights. This is an outbound, timestamped notification system, not a clause in a privacy policy: the erasure pipeline must pause for the notice window and reset if the user re-engages. For the engineering implication, the deletion job cannot be a simple scheduled purge; it must be a two-phase workflow, notify, wait, then erase, with both phases logged.

DPDP Does Not Override Your Other Legal Retention Obligations

This is the section where most retention projects go wrong. Section 8(7) opens with the words "unless retention is necessary for compliance with any law for the time being in force," and Rule 8 repeats the carve-out. India already has a dense lattice of record-retention statutes, and they survive the DPDP Act intact. The principal anchors, verified against the statutory framework, are:

The correct reading of the carve-out is narrow and record-specific. A six-year tax retention obligation justifies keeping the invoice, payment and ledger records the tax law names; it does not justify keeping the customer's browsing history, support chats and marketing profile alongside them. The disciplined exercise runs in four steps: apply the DPDP purpose test first; identify whether another law genuinely requires retention of the specific record; retain only what that obligation requires, for the period it requires; erase when that justification ends. A business that treats one statutory retention duty as a licence to keep the entire customer file has not complied with either regime.

The reverse error is equally real. Erasing records that a tax, corporate or financial-sector law requires you to keep, in the name of DPDP minimalism, converts a privacy-compliance project into a statutory default. The Act's second illustration makes exactly this point: a bank whose customer closes her savings account must still retain client-identity records for the period the law applicable to banks prescribes.

The Processor Problem: Deletion Must Travel Through Your Technology Stack

Section 8(7)(b) contains the obligation most retention policies ignore: the Data Fiduciary must cause its Data Processor to erase any personal data made available to it. Deleting a customer record from the CRM interface establishes nothing about the copies resting with the email platform, the analytics provider, the cloud host, the payment gateway, the customer-support tool or their respective sub-processors and archives.

The contractual side of this is already established practice: processor agreements need return-and-deletion obligations, deletion certificates on exit, and flow-down clauses binding sub-processors, which we have analysed in The Hidden Liability in Your Tech Stack: Why Your SaaS Vendors Expose You Under the DPDP Act. The retention layer adds a further requirement that those contracts rarely address today: the processor must be able to execute your retention schedule, not just its own. In practice that means your retention matrix must name, for each data category, every processor holding a copy; your contracts must give you an enforceable instruction right to erase on purpose-end; and your evidence file must collect the processor's deletion confirmation, because under Section 8(1) the Board will treat the processor's continuing retention as yours. Rule 8's own illustration is direct on the point: a company engaging a cloud provider to host customer records must ensure the provider also observes the one-year minimum retention of data and logs before erasure. The instruction pipeline runs in both directions, floors as well as ceilings.

Backups, Logs and the Difference Between Deletion and Disappearance

"Delete everything the moment the purpose ends" fails twice: once legally, once technically.

The legal floor. Rule 8(3) requires every Data Fiduciary to retain personal data, associated traffic data and processing logs for a minimum of one year from the date of processing, for the purposes specified in the Seventh Schedule, which relate to use by the State and its instrumentalities and to assessment for Significant Data Fiduciary notification. After that year, the fiduciary must cause the data and logs to be erased, unless another law or a government notification requires longer retention. The illustration supplied with the Rule is an e-book platform: even if the buyer deletes her account after delivery, the platform must retain the order details and processing logs, the order confirmation, payment and delivery events, for at least one year from the transaction.

The technical distinction. A defensible architecture separates four tiers and treats them differently:

The governance point is that deletion must be demonstrable. A retention policy that cannot produce evidence of what was erased, when, from which systems, and under whose authority, will not satisfy an inquiry by the Data Protection Board. The penalty tier relevant here is the residual one: breach of obligations such as the Section 8(7) erasure duty attracts penalties of up to Rs. 50 crore per contravention, while failures of the Rule 6 security safeguards that protect retained data can reach Rs. 250 crore. Indefinite retention is not neutral storage; it is unquantified exposure accumulating in your own systems.

Build the Retention Matrix Before May 2027

The implementation deliverable is a single governed artefact: a retention matrix in which every personal-data category carries its full compliance logic on one row. The columns that matter:

Three build rules make the matrix real rather than decorative. First, every row ends in an automated or scheduled action, because a retention period that depends on someone remembering it is not a control. Second, the Third Schedule classes are a separate build: platforms near the user thresholds need the inactivity clock, the account-access and virtual-token carve-outs and the 48-hour notification workflow engineered into the product, not bolted onto the policy. Third, the matrix is a living instrument: new features create new purposes, new vendors create new processor rows, and the matrix must be revisited on every product change, not annually.

The Bottom Line

Indian law does not hand businesses a retention number; it hands them a discipline. Section 8(7) erases on withdrawal of consent or the end of the specified purpose, whichever comes first. The Third Schedule's three-year mechanism is a purpose-deeming rule for a small class of very large platforms, with a 48-hour pre-erasure notification duty attached. Rule 8(3) sets a one-year floor for data and processing logs that applies to everyone. Other statutes then override all of it, record by record, for tax, corporate, financial and employment purposes. The businesses that will be compliant on 13 May 2027 are the ones that can answer, for every category of personal data they hold, four questions: why do we have it, when did that purpose end, which law requires us to keep it anyway, and can we prove the deletion travelled through every system and processor that touched it. A retention matrix that answers those questions is the whole task, and it can be built this quarter.

This article is published for general informational purposes and reflects the DPDP Act, 2023 and the DPDP Rules, 2025 as notified. It does not constitute legal advice on any specific set of facts.