DPDP data retention and erasure: Rule 8 and the 2 minimum floors
By Abhijeet Singh · Primary sources verified by dpdprules.orgPublished · Last reviewed · Updated 29 min read
Jump to sourcesHow long can you keep personal data under the DPDP Act?
The short answer
No single general DPDP retention period exists. As at 25 October 2026, the erasure and minimum retention duties below are not in force; their common commencement is computed as 13 May 2027 and potentially as late as 15 May 2027, interpretation until officially confirmed. The exact English phrases retention period, retention policy, retention schedule and data retention appear 0 times in either instrument. Where section 8(7) applies, it requires erasure on withdrawal of consent or when the specified purpose is reasonably assumed to have ended, whichever is earlier, unless another law requires retention. Rule 8(1) deems that purpose no longer served after 3 years from the latest of the Data Principal's last approach, exercise of rights, or the Rules' commencement. It applies only to the Third Schedule's 3 threshold classes and corresponding purposes. Rule 8(2) requires notice at least 48 hours before completion of the erasure period under Rule 8. Rule 6(1)(e) requires specified security logs and personal data to be kept for 1 year. On this site's interpretation, Rule 8(3) generally requires Data Fiduciaries to keep personal data, associated traffic data and processing logs for at least 1 year for Seventh Schedule purposes. A registered Consent Manager separately keeps its Part B record for at least 7 years. Rule 4 and its First Schedule duties commence on a separate computed date of 13 November 2026 and potentially 15 November 2026, also interpretation until officially confirmed.
The DPDP framework has no single general retention period. The exact English 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".
The framework does not supply 1 answer for all data. 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 Data Fiduciary, it requires a warning before that erasure, and, in 2 separate sub rules, it requires you to keep identified material that you might otherwise have erased.
That last part is the one most guidance misses entirely. Rule 8 contains both erasure mechanics and a separate retention mandate.
Use the retention and erasure planner to work through the dates for your own inputs.
The vocabulary that is not in the framework
Each count below is a case insensitive exact English phrase count over the registered MeitY Gazette extraction for the Act and the registered English Rules extraction. The supporting source notes report the complete positive and zero counts. They make no claim about equivalent Hindi wording.
| Term you will see in retention guidance | Times it appears in the Act | Times it appears in the Rules |
|---|---|---|
| retention period | 0 | 0 |
| retention policy | 0 | 0 |
| retention schedule | 0 | 0 |
| data retention | 0 | 0 |
| storage limitation | 0 | 0 |
| anonymise, anonymisation | 0 | 0 |
| pseudonymise, pseudonymisation | 0 | 0 |
| deletion | 0 | 0 |
| purge | 0 | 0 |
| traffic data | 0 | 2 |
| logs, the noun | 0 | 6 |
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:
Section 8(7) says 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". It also requires the Data Fiduciary to cause its processor to erase personal data that the fiduciary made available to it. The opening saving clause preserves retention necessary for compliance with another law in force.
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 requires contractual and operational enforcement and belongs in your processing agreement. And the carve out inside section 8(7) is compliance with law, which is narrower than "we have a business reason" and sits alongside the separate section 17 exemptions described below.
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 a common objection to the scheme. The 10 years is not a DPDP number. It comes from the banking law the illustration assumes, and section 8(7) defers to that required retention. A sectoral retention question therefore needs the exact other law and the processing it covers, not a period borrowed from this illustration.
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."
This site reads Rule 8(1) as implementing the section 8(7) duty by fixing a point at which the specified purpose is deemed spent, rather than creating an independent erasure policy. Rule 8(1) itself says the Data Fiduciary "shall erase". Section 40(2)(g), the enabling clause for its time period, is drawn in deeming terms.
Being outside a Third Schedule class does not by itself disapply section 8(7). Where the Act applies and no section 17 exemption operates, the reasonable assumption test remains without a Third Schedule deemed date.
That position is subject to every applicable section 17 exemption. Section 17(1) disapplies most of Chapter II, including section 8(7), and Chapter III, including section 12, for 6 listed processing situations. Section 17(2) disapplies the Act for processing by a notified State instrumentality on listed public interest grounds and for qualifying research, archiving or statistical processing. Section 17(3) lets the Central Government notify Data Fiduciaries or classes, including startups, to whom section 8(7) and other named provisions do not apply; its reference to section 8(3) means the Act sub section, not Rule 8(3). Section 17(4) disapplies sections 8(7) and 12(3) for State processing. Section 17(5) permits a separate time limited notified exemption within its first 5 years.
The 24 October 2026 MeitY document library capture contains 1,605 records and 19 DPDP titled records, but no title discloses a section 17(3) notification. That is bounded search evidence only: the library is not the Gazette of India, so it cannot prove that no instrument exists. Section 17 is itself in the 18 month commencement group. The section 17 exemptions are set out in full separately.
| Sub rule | What it does | Who it binds | Parent in the Act |
|---|---|---|---|
| Rule 8(1) | Deems the specified purpose spent after the Third Schedule period of inactivity, so the section 8(7) erasure duty bites | Only the 3 classes in the Third Schedule, and only for the purposes that Schedule lists | Section 8(8), through section 40(2)(g) |
| Rule 8(2) | Requires a warning at least 48 hours before that erasure completes | On our reading the same classes, because the warning is tied to erasure "under this rule"; sub rule (3) also ends in erasure under the same rule, so a wider reading is open | No express sub section; the warning is not in the Act |
| Rule 8(3) | Requires a minimum of 1 year of retention of personal data, traffic data and processing logs for the Seventh Schedule purposes | The text says "a Data Fiduciary"; this site's general reach reading relies on the Illustration and remains interpretation | No corresponding sub section in the Act |
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.
| Class | Threshold | Period | Purposes excluded from the timer |
|---|---|---|---|
| Ecommerce entity | Not less than 2 crore registered users in India | 3 years | Enabling access to her user account; enabling access to a stored virtual token usable to get money, goods or services |
| Online gaming intermediary | Not less than 50 lakh registered users in India | 3 years | The same 2 |
| Social media intermediary | Not less than 2 crore registered users in India | 3 years | The same 2 |
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.
For the checkout, fulfilment, vendor and marketing flows around this timer, see the DPDP Act for ecommerce businesses.
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 an account deletion rule. Every row excludes the purposes of enabling access to her user account and a stored virtual token she can spend. That means Rule 8(1) does not deem those 2 purposes spent through its timer. It does not promise that an account, wallet or any particular data will always be retained; section 8(7), another law and the actual purpose still need to be tested.
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. The 3 year period runs from the latest of her last approach for the specified purpose, her exercise of rights in relation to that processing, or the Rules' commencement. A dormant account last used in 2019 therefore does not reach this deemed date in 2022; commencement supplies a later starting point.
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 produces 13 November 2028. Taking the stage that switches Rule 8 on produces 13 May 2030. The eGazette embedded date and the unresolved question whether commencement follows expiry of the stated period could move those dates as late as 15 November 2028 and 15 May 2030. Every date in this paragraph is our interpretation until officially confirmed.
The first timer driven Rule 8(1) erasure therefore cannot arise before late 2028 on these readings. Section 8(7) may require earlier erasure after it commences, because its withdrawal and purpose tests do not wait for the Third Schedule deemed date. The engineering matters now even though the deemed timer comes later.
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. A re engagement campaign you send is outside those words because you initiated it. An unrelated inbound contact is not automatically a reset either. Rule 8(2) separately says a login, contact initiated for the specified purpose, or exercise of rights can prevent the scheduled erasure. As a build recommendation, store those event types separately and have counsel map which inbound events serve each purpose; do not let a generic activity flag decide the legal clock.
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 each erasure date, so a per person next action date is the more reliable design. A monthly batch can still comply if every affected person receives the warning at least 48 hours before her own deadline. The notice must state what will happen and the events that prevent it, because the sub rule specifies both. And "user account" is defined in Rule 2(1)(c) to include profiles, pages, handles, email address, mobile number and similar presences, so it is wider than a login page.
The text states no maximum lead time. A warning 30 days out meets the timing words because it is at least 48 hours before completion, but it must still convey the erasure and prevention information Rule 8(2) requires.
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.
Open the retention map at full size.
| Rule 6(1)(e) | Rule 8(3) | |
|---|---|---|
| What must be kept | Such logs and personal data as enable the listed security purposes | Personal data, associated traffic data and other logs of the processing |
| Minimum period | 1 year | 1 year from the date of the processing |
| Why | Detecting unauthorised access, investigating it, remediating to prevent recurrence, and continued processing after a compromise | The purposes specified in the Seventh Schedule |
| Reach into vendors | Rule 6(1) covers processing by the fiduciary or on its behalf by a Data Processor | Same reach, and the Illustration puts the duty to ensure it on the fiduciary |
| Saving clause | "unless compliance with any law for the time being in force requires otherwise" | "unless further retention is required for compliance with any other law for the time being in force or notified by the Government" |
| Where it sits | Clause (e) of the minimum list of reasonable security safeguards | A standalone sub rule opening "Without prejudice to sub-rules (1) and (2)" |
The saving clauses are drafted differently. Rule 6(1)(e) yields where another law "requires otherwise", which on this site's reading can include a shorter legal hold. Rule 8(3) yields only where "further retention is required", which this site reads as a longer legal hold. Those conclusions are interpretations of the 2 phrasings, not statements either provision makes, and they have 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, so the security clause start date is not settled on the face of the text. Possible operational markers include the processing that produced the log and the date the log was created or last written to. As a practical recommendation rather than a legal requirement, run the security year from the latest defensible marker and document why.
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".
This site infers that the year makes the retained material available for those State and MeitY purposes. Neither instrument states that rationale. The inference comes from the Seventh Schedule purposes and its corrected cross reference to Rule 23(1), which empowers the Central Government to call for information through the corresponding authorised person. It also explains why the 2 floors cannot be treated as duplicates: Rule 6(1)(e) reaches only such logs and personal data as enable its listed security purposes, while Rule 8(3) names personal data, associated traffic data and other processing logs.
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 strongly cuts against that narrow reading: 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. This site therefore reads Rule 8(3) as having general Data Fiduciary reach and the Schedule as stating why the retained material must remain available. That remains interpretation because the sub rule does not expressly resolve the tension.
The third duty to keep, which attaches in the Consent Manager capacity
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. It binds a registered Consent Manager in that capacity. The same entity might also be a Data Fiduciary, but that is not what triggers this duty. 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". Item 3 defines the record as consents given, denied or withdrawn, the notices preceding or accompanying consent requests, and sharing 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 general DPDP period when it is a defined records duty. It arrives first: the First Schedule serves Rule 4, and Rule 1(3) puts Rule 4 in the 1 year group, computed as 13 November 2026 and potentially as late as 15 November 2026. Both dates remain interpretation until officially confirmed. And it regulates a registered Consent Manager's record, not personal data at large.
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, thresholds, 2 exceptions and 3 year period. One definition in its Note changed: the draft defined a social media intermediary as an intermediary under the Information Technology Act, 2000 that primarily or solely enables online interaction between 2 or more users, while the notified Note imports the definition in Rule 2(1)(w) 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. The only wholly new substantive retention duty discussed in this article is notified Rule 8(3), which requires the named personal data, traffic data and processing logs to be kept for Seventh Schedule purposes.
That is a fact about 2 published documents. Whether it matters legally is a separate question this site does not answer. The Rules invoke sections 40(1) and 40(2). Section 40(2)(g) names the deemed period under section 8(8), none of its 25 specific matters names a minimum retention floor, and clause (z) is residual. Section 40(1) also supplies a general rule making power, and section 40(2) expressly operates without prejudice to that generality. The absence of a dedicated clause therefore does not by itself resolve validity in either direction.
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. This site's reconciliation is that, once Rule 8(3) commences, it will be law for the time being in force and will fit the section 8(7) carve out for legally necessary retention. On that reading the year will not be an exception to the erasure duty; it will be an instance of the duty's own carve out, which also fits Rule 8(3)'s opening words, "Without prejudice to sub-rules (1) and (2)". Neither text states that reconciliation, and the older illustration is not annotated to show how the later Rule affects it.
Once Rule 8(3) commences, the operational consequence on that interpretation will be that its material cannot be erased during the minimum year merely because the person requests erasure or closes the account. Case 1 says the year runs "even if X deletes her account". After the year, Rule 8(3) says the Data Fiduciary shall cause the personal data and logs it covers to be erased unless further retention is required by another law in force or notified by the Government.
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.
| Section 8(7), no request needed | Section 12(3), on her request | |
|---|---|---|
| What starts it | Withdrawal of consent, or the purpose ceasing, whichever is earlier | Her request, made in the prescribed manner |
| Defence: another law requires retention | Yes | Yes |
| Defence: the specified purpose still needs the data | No, the purpose ceasing is itself the trigger | Yes, expressly |
| Who it runs against | The Data Fiduciary, and through it the Data Processor | Under section 12(1) the right covers personal data processed on consent she previously gave, including consent as referred to in section 7(a); Rule 14(2) is what directs the request to the Data Fiduciary to whom she previously gave consent |
The middle row is the one that decides real tickets. A live service relationship is not itself a defence. Section 12(3) asks whether retaining the specific personal data remains necessary for the specified purpose or for compliance with law. Section 8(7), once applicable and subject to section 17, can require erasure without a request when consent is withdrawn or the purpose is reasonably assumed to have ended. Section 40(2)(n) provides for prescribing the request manner, and Rule 14(2) directs it to the Data Fiduciary to whom she previously gave consent.
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.
The Schedule does not expressly name section 8(7), Rule 8(1), Rule 8(2), Rule 8(3) or Rule 6(1)(e). This site reads a significant section 8(7) or Rule 8 breach as falling within residual entry 7, which may extend to Rs 50 crore. That is an interpretation rather than a mapping the Schedule states.
Rule 6(1)(e) is part of the minimum reasonable security safeguards in Rule 6, while section 8(5) is the Act's security safeguards obligation. A Rule 6(1)(e) failure can therefore plausibly be read into entry 1, which may extend to Rs 250 crore. Entry 7 is a competing residual reading. The Schedule does not resolve that choice. None of the ceilings is an automatic charge: section 33(1) first requires a completed inquiry, a finding that the breach is significant and an opportunity to be heard. Section 33(2) then gives the Board 7 considerations for the amount. Section 33 is itself in the 18 month commencement group. The process is explained in how the Board decides a penalty.
Myths, and where each number really lives
| Circulating claim | What the text says | Where the number really comes from |
|---|---|---|
| "DPDP sets a 3 year retention limit" | The 3 years binds 3 named classes above stated user thresholds, for the purposes the Third Schedule lists, and it is a deeming period for inactivity rather than a cap on holding data | Third Schedule, Gazette pages 35 and 36 |
| "You must delete personal data within 1 year" | Rule 8(3) is a minimum, not a maximum. It requires the material it covers to be kept for at least 1 year, then erased unless further retention is required by another law in force or notified by the Government | Rule 8(3), Gazette page 27 |
| "DPDP requires a documented data retention policy" | "Retention policy" and "retention schedule" appear 0 times in both instruments. Nothing prescribes such a document or its contents | Nowhere in the framework |
| "There is 1 log retention duty, the 1 year in Rule 8" | There are 2 on a Data Fiduciary, with different subject matter, different reasons and differently drafted saving clauses, and a third of at least 7 years on a Consent Manager's consent records | Rule 6(1)(e), page 26, Rule 8(3), page 27, and First Schedule Part B item 4(c), page 33 |
| "DPDP sets a 7 year retention rule" | The 7 years is a registered Consent Manager's duty, in that capacity, to keep its defined record of consents, notices and sharing. It is not a general period for all personal data | First Schedule Part B item 4(c), page 33 |
| "The 3 years runs from the user's last login" | It runs from the latest of her last approach for the specified purpose, exercise of rights in relation to that processing, or commencement. Section 8(11) describes approach as contact she initiated for that purpose | Third Schedule, page 35, with section 8(11), page 8 |
| "The 48 hour notice is a grace period after erasure" | It is a warning at least 48 hours before erasure completes, and acting on it prevents the erasure | Rule 8(2), page 27 |
| "Retention breaches carry the Rs 250 crore penalty" | The Schedule does not name these rule clauses. This site reads a significant section 8(7) or Rule 8 breach into residual entry 7 at up to Rs 50 crore. Rule 6(1)(e) can plausibly be tied to entry 1 through section 8(5), while entry 7 is a competing reading. Section 33(1) prerequisites and section 33(2) factors still apply | Sections 33(1) and 33(2), with the Schedule, Gazette pages 16, 17 and 21 |
| "Anonymised data is outside the erasure duty" | Neither instrument uses the words anonymise or pseudonymise at all, so there is no named exemption and no standard to meet. The question is one of scope instead: section 2(t) defines personal data as any data about an individual who is identifiable by or in relation to such data, so whether your output still identifies anyone is a question of fact rather than a safe harbour | Nowhere in the framework, with section 2(t), Gazette page 3 |
When this starts to apply
As at 25 October 2026, none of these erasure or minimum retention duties is in force. Section 8, section 12 and section 33 are in the Act's 18 month group. Rule 1(4), as corrected, puts Rules 6, 8, 14 and 23 in the Rules' 18 month group. The printed Gazette dates produce 13 May 2027; the eGazette embedded date and a reading that commencement follows expiry of the stated period produce a latest reading of 15 May 2027. Both dates are interpretation until officially confirmed. The full commencement picture and why 2 publication dates circulate are covered separately.
A Business Standard report of 22 January 2026, citing an unnamed source, said the Government was likely to propose that the minimum retention requirement become operational within 90 days after amended Rules were notified. The report said MeitY did not respond by publication time. That is secondary reporting about a likely proposal, not an official instrument. The October 2026 Removal of Difficulties Order changed only section 9(1) and section 10(2)(c)(ii). The 24 October MeitY library capture disclosed no title for an amendment accelerating Rule 8(3), but that bounded library check is not a certified Gazette negative. The evidence is tracked in the January 2026 proposal article.
As at 25 October 2026, these provisions do not yet require erasure or minimum retention. As a practical recommendation, use the remaining time to build the per person warning pipeline and the 1 year floors before the relevant provisions commence.
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, once the provision commences you will need the deemed timer, warning and a per person next action date. If no, section 8(7) can still apply in its judgement based form, subject to section 17.
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 material will be inside a 1 year floor, and under which provision? Such logs and personal data as enable Rule 6(1)(e)'s listed security purposes are one answer. Personal data, associated traffic data and processing logs under Rule 8(3), on this site's general reach interpretation, are a different answer.
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.
Rule 8, official text with sources →Third Schedule, official text →The rights, including erasure on request →DPDP for ecommerce →