DPDP data retention and erasure: Rule 8 and the 2 minimum floors

There is no DPDP retention period. The phrase "retention period" appears 0 times in the Digital Personal Data Protection Act, 2023 and 0 times in the Digital Personal Data Protection Rules, 2025. So do "retention policy", "retention schedule" and "data retention". So do "storage limitation", "anonymise", "pseudonymise", "deletion" and "purge".

Almost every retention guide written for this framework opens by asking how long you may keep data. The framework never answers that question, because it is not the question the text asks. It asks what the data is still for, and then it does 3 other things: it deems the purpose spent after a fixed period for 3 named classes of company, it requires a warning before that erasure, and, in 2 separate sub rules, it requires you to keep data you might otherwise have deleted.

That last part is the one most guidance misses entirely. Read carelessly, Rule 8 looks like a deletion mandate. Half of it is a retention mandate.

DPDP retention for a Data Fiduciary: 1 duty to erase, 2 duties to keep. Neither the DPDP Act 2023 nor the DPDP Rules 2025 uses the words retention period, retention policy or retention schedule. The 1 duty to erase is section 8(7), the purpose test, which requires erasure on withdrawal of consent or as soon as it is reasonable to assume the specified purpose is no longer being served, whichever is earlier, with no period at all and a carve out for retention necessary to comply with any law, binding every Data Fiduciary and reaching the Data Processor too. The deemed timer that fires it is Rule 8(1), 3 years of inactivity, which deems the purpose spent so that section 8(7) bites without a judgement call, and it binds only the 3 classes in the Third Schedule, an ecommerce entity at 2 crore registered users in India, an online gaming intermediary at 50 lakh and a social media intermediary at 2 crore, running from the latest of her last approach and the commencement of the Rules, with account access and a stored virtual token excepted so this is not account deletion. The duties to keep are 2 separate 1 year floors: Rule 6(1)(e), the security floor, keep logs and personal data for 1 year to enable detection of unauthorised access, its investigation, remediation and continued processing after a compromise, yielding where another law requires otherwise and already present in the draft Rules of 3 January 2025; and Rule 8(3), the Seventh Schedule floor, keep personal data, associated traffic data and other logs of the processing for a minimum of 1 year from the date of processing for the Seventh Schedule purposes, being State use for sovereignty and integrity of India or security of the State, State use under law, and assessment for notifying a Significant Data Fiduciary, yielding only where further retention is required, with its own Illustration running the year even if she deletes her account, and new at notification rather than in the draft. Section 8 and Rules 6 and 8 are all in the group commencing 18 months after publication, computed as 13 May 2027, interpretation until officially confirmed. A third duty to keep, at least 7 years, binds a Consent Manager and not a Data Fiduciary: First Schedule Part B item 4(c).

The vocabulary that is not in the framework

Each count below was taken across 6 documents: the MeitY Gazette print of the Act, the India Code consolidated print, the Bill as passed by both Houses, the English section of the Rules, the bilingual extraction of the Rules so that nothing hides in the Hindi pages, and the corrigenda.

A 7th occurrence of "logs" in the Rules is the verb, in Rule 8(2), where she "logs into her user account", so the noun stands at 6.

One near miss belongs here too, because a bare word count would mislead. "Archive" as a word appears 0 times in both instruments, but "archiving" appears once in the Act, in section 17(2)(b) on Gazette page 12, and twice in the Rules, in the heading and the body of Rule 16. Both are the same thing, the research, archiving or statistical purposes exemption, and it is an exemption from the Act rather than a permission to retain, conditioned on standards set elsewhere. Do not reach for it as a retention answer.

The words the framework does use are built on "erase": the Act prints "erasure" 6 times and "erase" 3 times, and the English section of the Rules prints "erasure" twice, "erased" twice and "erase" once. "Retain" itself appears twice in the Act, and both are inside the Illustrations to section 8(7). A retention policy is a perfectly sensible thing to write. It is not a statutory requirement here, and nothing in the text prescribes its contents.

What the Act actually sets: a purpose test, not a period

Section 8(7) is the parent duty, and it is a condition rather than a clock:

"A Data Fiduciary shall, unless retention is necessary for compliance with any law for the time being in force,— ( a ) 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 ( b ) cause its Data Processor to erase any personal data that was made available by the Data Fiduciary for processing to such Data Processor."

3 things in that sentence decide most real cases. The trigger is the earlier of withdrawal and the purpose ceasing, so a live specified purpose does not save data once consent goes. The duty runs down your supply chain, because you must cause your Data Processor to erase too, which is a contractual and operational problem rather than a legal one and belongs in your processing agreement. And the single carve out is compliance with law, which is narrower than "we have a business reason".

The Act then works the test through 2 illustrations printed in the section itself, which is the closest the framework comes to naming a duration:

"( I ) X, an individual, registers herself on an online marketplace operated by Y, an e-commerce service provider. X gives her consent to Y for the processing of her personal data for selling her used car. The online marketplace helps conclude the sale. Y shall no longer retain her personal data. ( II ) X, an individual, decides to close her savings account with Y, a bank. Y is required by law applicable to banks to maintain the record of the identity of its clients for a period of ten years beyond closing of accounts. Since retention is necessary for compliance with law, Y shall retain X’s personal data for the said period."

Illustration II is worth pausing on, because it is the answer to the most common objection to the whole scheme. The 10 years is not a DPDP number. It comes from the banking law the illustration assumes, and the Act simply steps out of the way. That is the shape of every sectoral retention question under this framework: the other law sets the period, and section 8(7) defers to it.

Rule 8 is a deeming rule, and its heading says so

Rule 8 is almost always described as the retention rule. Its official heading is "Time period for specified purpose to be deemed as no longer being served".

That heading is not decoration. Section 8(8) creates a deeming power:

"The purpose referred to in clause ( a ) of sub-section ( 7 ) shall be deemed to no longer be served, if the Data Principal does not– – ( a ) approach the Data Fiduciary for the performance of the specified purpose; and ( b ) exercise any of her rights in relation to such processing, for such time period as may be prescribed, and different time periods may be prescribed for different classes of Data Fiduciaries and for different purposes."

So Rule 8(1) does not create a new duty to erase. It fixes the point at which the section 8(7) duty is triggered without anyone having to form a judgement about whether the purpose is spent. Section 40(2)(g), the enabling clause the Act provides for this, is drawn in exactly those terms.

The practical consequence is the opposite of how the rule is usually read. If you are not in a Third Schedule class, you do not escape the erasure duty. You keep the harder version of it, the reasonable assumption test in section 8(7), with no deemed date to hide behind.

2 express carve outs sit outside that, and both are on Gazette page 12 of the Act. Section 17(4) provides that section 8(7) and section 12(3) shall not apply in respect of processing by the State or any instrumentality of the State, and that section 12(2) shall not apply either where the processing is for a purpose that does not include making a decision that affects the Data Principal. Section 17(3) lets the Central Government notify Data Fiduciaries or classes of them, "including startups", as fiduciaries to whom section 8(7) shall not apply, along with section 5 and sections 8(3), 10 and 11. No notification under section 17(3) is recorded in this site's source registry as at 26 August 2026, and section 17 is itself in the 18 month commencement group. On our reading nothing notified under it can bite before that group commences. That is an inference from the commencement notification and not something section 17 says. The section 17 exemptions are set out in full separately.

A drafting point, recorded because this site records such things rather than smoothing them over. As printed, Rule 8(1) reads "shall erase such personal data, unless its retention is necessary for compliance with any law for the time being in force, or, for the corresponding time period specified in the Third Schedule, if the Data Principal neither approaches". The comma after "or" leaves that conjunction with nothing obvious to join, and the corrigenda correct pages 24, 29, 32, 34 and 38 only, so page 27 stands as printed. The draft of 3 January 2025 carried the same sentence without the "or", reading "compliance with any law for the time being in force, if, for the corresponding time period specified in the said Schedule, the Data Principal neither approaches". Reading the 2 prints together, our view is that the period is the period of inactivity and the law compliance carve out is a separate exception, which is also the only reading that makes sub rule (2) work. That is our reading, not something either text says.

Who the 3 year timer actually binds

The Third Schedule has 3 entries. Not 3 categories of data, and not 3 sizes of company: 3 named classes.

4 things follow, and each of them is routinely stated the wrong way round elsewhere.

The 3 years is not a general limit. "Three years" appears 3 times in the English section of the Rules and all 3 are these rows. It appears once in the Act, in section 43(2) on Gazette page 19, where it is the sunset on the Government's power to make removal of difficulties orders and has nothing to do with anybody's data.

The thresholds are on registered users, not revenue, not headcount and not data volume. The Note to the Schedule defines each class, and it borrows as it goes: it defines ecommerce entity itself, as a person who owns, operates or manages a digital facility or platform for ecommerce, taking ecommerce and marketplace ecommerce entity from the Consumer Protection Act, 2019 and expressly excluding a seller who merely offers goods on a marketplace, and it defines social media intermediary wholly by reference to clause (w) of sub rule (1) of rule 2 of the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021. Whether you are inside a borrowed definition is a legal question about that other instrument, and it is worth answering precisely rather than by eye.

These thresholds have nothing to do with Significant Data Fiduciary status. They look like size tests and they sit near each other in the same instrument, which is why they get conflated, but nothing in the Third Schedule confers or indicates SDF status and the SDF factors are set elsewhere and differently.

This is not account deletion. Every row excepts the data needed to let her reach her user account and any stored virtual token she can spend. A platform running this timer correctly erases the behavioural and transactional record while keeping the account reachable and the wallet intact.

The clock starts later than everyone assumes

The period column does not read "3 years after her last visit". It reads:

"Three years from the date on which the Data Principal last approached the Data Fiduciary for the performance of the specified purpose or exercise of her rights, or the commencement of the Digital Personal Data Protection Rules, 2025, whichever is latest."

"Whichever is latest" is a floor, and it is load bearing. A dormant account last used in 2019 does not become erasable 3 years after 2019. The clock restarts at commencement for the entire dormant back catalogue at once.

Which commencement is not settled on the face of the text, because the Rules do not commence on 1 date. Rule 1(2) brings Rules 1, 2 and 17 to 21 into force on publication, Rule 1(3) brings Rule 4 in after 1 year, and Rule 1(4) brings the rest, including Rules 6 and 8 and by extension the Schedules they serve, in after 18 months. Taking the first stage, the printed publication date of 13 November 2025, the earliest erasure falls due on 13 November 2028. Taking the stage that actually switches Rule 8 on, derived as 13 May 2027, it falls on 13 May 2030. Both are our computations from a printed date and both are interpretation until officially confirmed.

Either way the answer to "when does the first Rule 8(1) erasure fall due" is no earlier than late 2028, which is well past the point at which most compliance programmes assume this rule has already bitten. The engineering matters now. The first deletions do not.

What counts as approaching you

Section 8(11) settles the input the timer runs on, and it is the sub section least likely to be in a vendor checklist:

"For the purposes of this section, it is hereby clarified that a Data Principal shall be considered as not having approached the Data Fiduciary for the performance of the specified purpose, in any period during which she has not initiated contact with the Data Fiduciary for such performance, in person or by way of communication in electronic or physical form."

The test is that she initiated contact, for the performance of the specified purpose. On our reading that has 2 consequences worth designing for. A re engagement campaign you send does not reset anything, because you initiated it. And a contact that is not for the performance of the specified purpose, such as a support ticket about a refund on a closed order, sits awkwardly against the words even though most systems will record it as activity. Rule 8(2) is drafted more generously than section 8(11), since it lets her stop the erasure by logging in or "otherwise initiat[ing] contact", so the safest build treats any inbound contact as a reset and treats outbound contact as nothing.

The 48 hour warning is a build, not a policy

"At least forty-eight hours before completion of the time period for erasure of personal data under this rule, the Data Fiduciary shall inform the Data Principal that such personal data shall be erased upon completion of such period, unless she logs into her user account or otherwise initiates contact with the Data Fiduciary for the performance of the specified purpose or exercises her rights in relation to the processing of such personal data."

3 implementation facts sit in that sentence. The warning is defined by reference to the erasure date, so you cannot send it on a monthly batch schedule and satisfy the rule for everyone; it is per person, keyed to that person's own next action date. The notice must state what will happen and how to stop it, because the sub rule specifies both the fact of erasure and the acts that prevent it. And "user account" is defined in Rule 2(1)(c) to include profiles, pages, handles, email address and mobile number, so the channels that count as her account are wider than a login screen.

There is no maximum lead time. The rule sets a floor of 48 hours, so warning 30 days out satisfies the floor on the words of the sub rule and, on any sensible reading of the purpose, serves her better.

The 2 minimum floors that make you keep data

This is the part almost no page separates, and the 2 duties are genuinely different. Both are in the group commencing 18 months after publication, so they arrive together.

The saving clauses are drafted differently, and on our reading the difference is not cosmetic. Rule 6(1)(e) yields where another law "requires otherwise", which on its words is wide enough to accommodate a law requiring a shorter hold. Rule 8(3) yields only where "further retention is required", so we read it as not answered by a law requiring you to delete sooner. That is this site's reading of the 2 phrasings, not a statement either sub rule makes, and it has not been tested.

The 2 floors are also drafted asymmetrically on when the year starts. Rule 8(3) says "for a minimum period of one year from the date of such processing". Rule 6(1)(e) says "for a period of one year" and fixes no start point at all, so the date your obligation runs from under the security clause is not settled on the face of the text. The candidates are the date of the processing that produced the log, as Rule 8(3) says expressly, and the date the log was created or last written to. As a practical build recommendation and not a requirement of the text, run the security year from whichever of those falls later.

The Seventh Schedule is the other half of Rule 8(3), and it is the half nobody quotes. Its heading reads "[ See rule 23(1) and 8(3)]", and its 3 purposes are use by the State or its instrumentalities in the interest of sovereignty and integrity of India or security of the State, use by the State or its instrumentalities for performing a function or fulfilling an obligation under law, and carrying out assessment for notifying any Data Fiduciary or class of Data Fiduciaries as Significant Data Fiduciary. Its third column, headed "Authorised person", names for each purpose the person through whom the Rule 23(1) power to call for information is exercised, and it is not always an officer: for the second purpose the entry reads "Person authorised under applicable law".

On our reading the year therefore exists so that the State and MeitY can reach the record inside it. Neither instrument says that in terms; it is an inference from what the Seventh Schedule lists and from the cross reference to Rule 23(1), the power to call for information, printed at the head of the Schedule. That inference is not hidden and it is not a criticism of the rule. It is simply a different reason from the one a security team would assume, and it changes what you keep. A retention design that satisfies Rule 6(1)(e) by holding access logs will not satisfy Rule 8(3), which reaches the personal data and the traffic data as well.

A scope question deserves a straight answer. Read literally, "for the purposes as specified in the Seventh Schedule" could mean the duty applies only where the processing is itself for a Seventh Schedule purpose, which would confine it to State processing and SDF assessments. The Illustration printed under the sub rule rules that out: Case 1 is a consumer buying an e book and Case 2 is a company using a cloud host, neither of which is State processing, and neither platform is given a user threshold. On that basis our reading is that Rule 8(3) binds Data Fiduciaries generally and the Seventh Schedule states what the retained material must be available for. That is a reading of the sub rule against its own Illustration, not a statement the text makes.

The third duty to keep, which is not yours unless you are a Consent Manager

Sweep the English section of the Rules for every affirmative duty to retain identified data for a stated period and it returns 3, not 2. The third is in the First Schedule, Part B, "Obligations of Consent Manager", item 4(c) on Gazette page 33, and it binds Consent Managers rather than Data Fiduciaries. A Consent Manager "shall maintain such record for at least seven years, or for such longer period as the Data Principal and Consent Manager may agree upon or as may be required by law". The record is the one item 3 of the same Part defines: consents given, denied or withdrawn by her, the notices preceding or accompanying requests for consent, and the sharing of her personal data with a transferee Data Fiduciary.

It belongs here for 3 reasons. It is the longest minimum period stated anywhere in the Rules, and 7 years is often quoted loosely as a DPDP retention rule when it is a records duty on 1 kind of regulated entity. It arrives first: the First Schedule serves Rule 4, and by extension rides on Rule 4's commencement, which Rule 1(3) sets at one year after publication, computed as 13 November 2026 and interpretation until officially confirmed, ahead of every other duty in this article. And it is a duty about consent records rather than about anybody's personal data at large, so if you are not registered as a Consent Manager it is not yours and it sets no period for your data.

The floor that was added after the consultation closed

The draft Rules published on 3 January 2025 for public comment contained a rule 8 with 2 substantive sub rules, the deemed timer and the 48 hour warning, and a third sub rule that was only a definition of "user account". There was no minimum retention floor in it at all. The definition moved to Rule 2(1)(c) in the notified Rules, and a wholly new Rule 8(3) took its number.

The draft Seventh Schedule confirms the sequence from the other end. In the draft it was headed with 1 cross reference, to the information calling rule. In the notified Rules it reads "[ See rule 23(1) and 8(3)]".

The rest of the Third Schedule is close to unchanged. The draft carried the same 3 classes, the same thresholds, the same 2 exceptions and the same 3 year period. One definition in its Note did move, and it is one this article leans on: the draft defined a social media intermediary as an intermediary under the Information Technology Act, 2000 who primarily or solely enables online interaction between two or more users, and the notified Note replaces that with the definition in clause (w) of sub rule (1) of rule 2 of the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021. Draft rule 6(1)(e) already carried the security year in identical words. So of everything in this article, the single provision that did not go out for consultation in this form is the one that requires you to keep personal data, traffic data and processing logs available for the Seventh Schedule purposes.

That is a fact about 2 published documents, and we state it as one. Whether it matters legally is a separate question that this site does not answer: the Rules recite that they are made under sub sections (1) and (2) of section 40, section 40(2) runs from clause (a) to clause (z), 25 specific matters and a residual clause (z), of which (g) is the one naming Rule 8's subject, none of the 25 names a minimum retention period, and clause (z) plus the general power in section 40(1) are what any argument about that would turn on. Rule 6, which nobody disputes, has no dedicated clause in section 40(2) either, so the absence is not a defect on its face.

Where the Act's illustration and the Rules' illustration pull apart

Put the 2 official illustrations side by side and they appear to disagree.

Illustration I to section 8(7): X sells her used car through the marketplace, the sale concludes, "Y shall no longer retain her personal data."

Illustration, Case 1, to Rule 8(3): X buys an e book, delivery completes, "the specified purpose of processing is served", and the platform "must retain the order details, personal data, and logs of the processing ... for at least one year from the date of the transaction, even if X deletes her account."

Same shape of transaction, same moment of completion, and one text says stop retaining while the other says retain for a year. The reconciliation is available on the words, and it is that section 8(7) carves out retention "necessary for compliance with any law for the time being in force", and Rule 8(3) is law for the time being in force. On that reading the year is not an exception to the erasure duty at all; it is an instance of the duty's own carve out, which is why Rule 8(3) opens "Without prejudice to sub-rules (1) and (2)". That reconciliation is ours. Neither text states it, and the older illustration is not annotated to show that the newer instrument has qualified it.

The operational consequence is blunt and is the sentence most retention designs will need to change: for the first year after processing, "delete my data" is not the answer, and neither is closing the account. Case 1 says the year runs "even if X deletes her account", which is the only occurrence of delete in any form in the English section of the Rules.

The erasure request is a different route with a different defence

Erasure on request is not Rule 8. It is section 12(3), it belongs to the rights chapter, and its defences are not the same ones.

The middle row is the one that decides real tickets. An erasure request made while the service relationship is live is answered by the purpose, not by the request. The same request after the purpose is spent adds nothing, because section 8(7) already required erasure without her asking. Section 40(2)(n) provides for prescribing the manner of a section 12(3) request, and Rule 14(2) is where the notified Rules deal with making requests to exercise rights.

What getting retention wrong costs

The Schedule to the Act has 7 entries. Entries 1 to 6 name specific provisions: section 8(5) security safeguards at up to Rs 250 crore, section 8(6) breach intimation at up to Rs 200 crore, section 9 children at up to Rs 200 crore, section 10 Significant Data Fiduciary duties at up to Rs 150 crore, section 15 Data Principal duties at up to Rs 10,000, and breach of a voluntary undertaking accepted under section 32.

Section 8(7) is named in none of them. So a failure to erase, or a failure to run the Rule 8 timer and its warning, falls in entry 7, "Breach of any other provision of this Act or the rules made thereunder", at up to Rs 50 crore. The Rs 250 crore figure that retention marketing tends to attach to everything is entry 1, and entry 1 is security safeguards.

That produces an asymmetry worth naming. Rule 6(1)(e) is a clause of the minimum list of reasonable security safeguards, and section 8(5) is the security safeguards obligation, so on our reading a failure of the Rule 6(1)(e) year is arguable under entry 1 while a failure of the Rule 8(3) year sits in entry 7. The same 1 year of logs, potentially 2 very different ceilings, depending on which sub rule you missed. Mapping a rule breach to a Schedule entry is a reading and not something the Schedule states, and none of these ceilings is a tariff: section 33(2) requires the Board to weigh 7 matters in fixing any amount, which is set out in how the Board decides a penalty.

Myths, and where each number really lives

When this starts to apply

None of it is in force today. Section 8 sits in the group that commences 18 months after publication of the Act commencement notification, and Rule 1(4) puts Rules 3, 5 to 16, 22 and 23, which covers both Rule 6 and Rule 8, in the equivalent group for the Rules. Section 12 is in the same Act group. Computed from the publication date printed on the Gazettes, that is 13 May 2027, and the calculation is our interpretation until officially confirmed, because the notifications state a period rather than a date and do not say how the period is counted. The full commencement picture and the reason 2 different dates circulate are covered separately. Reporting since January 2026 also has MeitY proposing to bring the minimum retention requirement in Rule 8(3) into force within 90 days of an amendment rather than at 18 months. No such amendment has been located, so that limb has no date at all, and the record behind it is set out in the January 2026 proposal to cut the window to 12 months.

Nothing in the framework requires you to erase anything today, and nothing requires you to retain anything today either. What the dates do give you is a build window, and it is not generous for the 2 items that are engineering rather than drafting: the per person warning pipeline and the 1 year floors, which have to be in place before the processing they cover, not after.

What to do

Compute the dates rather than estimating them: the retention and erasure planner works out the 1 year floor and the latest warning time deterministically, and the compliance plan puts the resulting work into a plan for your organisation.

Then answer 4 questions in this order, because each one changes the next.

Are you in a Third Schedule class, on the borrowed definitions rather than by eye? If yes, you owe the deemed timer and the warning, and you need a per person next action date in your data model. If no, you still owe section 8(7), in its harder judgement based form.

What is each purpose, and how would you know it had ended? The purpose test cannot be operated at all without that, and it is where the privacy notice and the retention design meet: the purposes you told people about are the purposes you have to measure against.

Which of your data is inside a 1 year floor, and under which of the 2 sub rules? Security logs and personal data under Rule 6(1)(e) is one answer. Personal data, traffic data and processing logs under Rule 8(3) is a different and wider one.

Which other laws bind you, and for how long? That question is not one this site guesses at. Illustration II to section 8(7) is the Act telling you that the other law wins, and identifying the other law is work for your counsel with your data map in hand.

The official text is at Rule 8, Rule 6, the Third Schedule, the Seventh Schedule and section 8.