Rule 8 - Time period for specified purpose to be deemed as no longer being served

Rule 8 creates a specialised framework for determining when certain processing purposes are deemed to have ended, when affected personal data must be erased, and when specified data and processing logs must nevertheless be retained for at least one year.

The Rule must be read carefully because it contains three distinct legal mechanisms:

1. Inactivity-based deemed completion of purpose for specified large digital platforms under Rule 8(1) and the Third Schedule.

2. Advance warning before erasure under Rule 8(2).

3. A separate minimum one-year retention requirement under Rule 8(3), followed by erasure unless longer retention is legally required.

These mechanisms interact with each other, but they are not interchangeable. Rule 8 does not create a universal three-year retention period, nor does it create a universal requirement that all personal data must be deleted after one year. Its effect depends on the class of Data Fiduciary, the purpose of processing, the Data Principal’s activity, the date of each processing event, and any other law requiring further retention.

Commencement position: Rule 8 is scheduled to come into force eighteen months after publication of the final Rules, corresponding to13 May 2027 on the presently notified timeline. Sections 8(7) and 8(8), with which Rule 8 must principally be read, are also scheduled to commence as part of the eighteen-month phase.

1. Relationship between Rule 8 and Section 8 of the DPDPA

Rule 8 principally operationalises Sections 8(7) and 8(8).

Section 8(7) establishes the general erasure rule. Where processing is based on consent, the Data Fiduciary must erase personal data when:

• the Data Principal withdraws consent; or

• it is reasonable to assume that the specified purpose is no longer being served, whichever occurs earlier, unless retention is necessary for compliance with law.

The Data Fiduciary must also cause its Data Processor to erase personal data made available for processing.

Section 8(8) then explains when the specified purpose may be treated as no longer being served. It allows rules to prescribe a period where the Data Principal:

• has not approached the Data Fiduciary for performance of the specified purpose; and

• has not exercised her rights in relation to the processing.

Rule 8(1), read with the Third Schedule, prescribes that period for specified classes of large digital platforms. Rule 8(2) adds the requirement of a warning at least forty-eight hours before erasure.

Rule 8(3) performs a different function. It requires a minimum one-year retention of specified personal data, associated traffic data and processing logs for the prescribed purposes, notwithstanding the inactivity-based erasure mechanism.

The legal structure may therefore be expressed as follows:

• Section 8(7) creates the general duty to erase.

• Section 8(8) authorises a prescribed inactivity period for determining when a purpose is deemed no longer served.

• Rule 8(1) applies that deeming mechanism to classes and purposes listed in the Third Schedule.

• Rule 8(2) requires advance warning before erasure under that mechanism.

• Rule 8(3) creates a separate minimum one-year retention requirement for specified records and purposes.

• Other applicable laws may require longer retention and prevail over the ordinary erasure trigger for the period of that requirement.

This distinction is essential. Rule 8(1) determines when certain purposes are legally deemed to have ended. Rule 8(3) requires selected evidence and processing records to remain available for a minimum period even though the immediate commercial purpose may already have been completed.

1.1 The general erasure principle

The DPDPA does not permit personal data to be retained indefinitely merely because it may become useful later. Processing must remain connected to a lawful purpose, and continued retention must have an identifiable legal justification.

Under the general structure, a Data Fiduciary should ask:

1. What was the specified purpose?

2. Is that purpose still being served?

3. Has consent been withdrawn?

4. Does Rule 8 prescribe a deeming period?

5. Does Rule 8(3) require selected data or logs to be retained for one year?

6. Does another law require longer retention?

7. Is retention required for establishment, exercise or defence of a legal claim?

8. Which copies are held by Data Processors?

9. When the applicable justification ends, can the information be erased from every relevant environment?

Rule 8 does not replace this broader inquiry. It adds specific timing rules to it.

2. Rule 8(1): Deemed completion of purpose through inactivity

3. Limited application to classes in the Third Schedule

Rule 8(1) does not apply to every Data Fiduciary.

It applies only where:

• the Data Fiduciary belongs to a class identified in the Third Schedule;

• the personal data is being processed for a corresponding purpose identified in that Schedule;

• the applicable period has run;

• the Data Principal has not approached the Data Fiduciary for performance of that purpose;

• the Data Principal has not exercised her rights concerning the processing; and

• no law requires the personal data to be retained.

The Third Schedule presently covers:

• an e-commerce entity having at least two crore registered users in India;

• an online gaming intermediary having at least fifty lakh registered users in India; and

• a social media intermediary having at least two crore registered users in India.

The prescribed period is three years, calculated from the latest of the relevant date of user activity or the commencement of the Rules as specified by the Schedule.

Smaller platforms do not become subject to the Third Schedule merely because they conduct similar activities. They remain governed by the general erasure obligation under Section 8(7), together with Rule 8(3) and other applicable retention laws.

Therefore, a smaller e-commerce company cannot assume that it may retain all inactive customer information for three years simply because the Third Schedule gives certain large e-commerce entities a three-year period.

4. The three-year period is not a general retention entitlement

The Third Schedule does not grant large platforms a blanket right to preserve all personal data for three years.

Its function is to determine when the specified purpose is deemed no longer served in the circumstances covered. If the actual purpose has ended earlier and another erasure trigger applies, the Data Fiduciary cannot necessarily rely on the outer three-year period to retain unnecessary information.

Example

For example, if an online marketplace collects a temporary identity document solely to verify a particular high-value transaction, completion of that verification may bring the purpose to an end. The fact that the customer may remain generally active on the platform does not automatically justify retaining that document for three years.

The Data Fiduciary must continue applying purpose limitation record by record and operation by operation. “Customer relationship” is not sufficient as a universal purpose covering every item of personal data.

4.1 Meaning of “approaches the Data Fiduciary”

Rule 8 focuses on whether the Data Principal approaches the Data Fiduciary for performance of the specified purpose.

This requires a meaningful connection between the interaction and the purpose for which the personal data is being retained.

Relevant interactions may include:

• logging into the account;

• making a purchase;

• using the service;

• starting or continuing a game;

• posting or communicating through a social-media account;

• redeeming a qualifying virtual token;

• requesting customer assistance connected with the service;

• or otherwise initiating contact for performance of the relevant purpose.

The safest interpretation is not that every technical communication restarts every retention period for every processing purpose.

4.2 Illustration: Marketing email opened

A customer has not used an e-commerce account for three years but opens a promotional email sent by the platform.

Opening the email should not automatically be treated as approaching the platform for performance of every original purpose. The customer did not necessarily initiate the contact. Nor did she necessarily request performance of the account’s commercial purpose.

Treating passive tracking of an email-open pixel as active user engagement would risk converting marketing surveillance into a mechanism for indefinite retention.

4.3 Illustration: Customer-support query

The customer contacts the platform solely to request deletion of her account.

That contact is an exercise of rights or an erasure-related request. It should not be treated as renewed commercial engagement that authorises the platform to restart a three-year retention period for all personal data.

Indeed, Rule 8 treats the exercise of rights as a reason not to apply automatic erasure at that moment because the Data Fiduciary must first process and respond to the rights request. It does not convert an erasure request into renewed demand for the underlying service.

4.4 Illustration: Genuine service interaction

The customer logs into an inactive marketplace account, updates the delivery address and places a new order.

This is a genuine approach for performance of the service. Relevant purposes connected with account access, order fulfilment, payment and delivery are once again active.

However, the new activity does not automatically revive an unrelated earlier purpose, such as consent for a marketing campaign that was separately withdrawn.

4.5 Exercise of Data Principal rights

Rule 8(1) also refers to the Data Principal exercising her rights in relation to the processing.

This is necessary because automatic deletion while a rights request remains under consideration could:

• prevent the Data Fiduciary from responding;

• destroy evidence needed to explain processing;

• frustrate correction;

• conceal an earlier disclosure;

• or make grievance resolution impossible.

Example

For example, if a Data Principal requests access to information about processing shortly before expiry of the three-year period, the Data Fiduciary should not automatically erase the relevant records before fulfilling the request.

Similarly, if the individual challenges the accuracy of her information, the Data Fiduciary may need to preserve the disputed record, correction history and supporting evidence until the request and related grievance are resolved.

But the existence of a rights request does not permit indefinite preservation of all information. Once the request has been completed and any legitimate dispute or legal hold has ended, the erasure analysis must resume.

4.6 The Third Schedule and excluded purposes

5. User-account access

The Third Schedule excludes processing necessary to enable the Data Principal to access her user account from the ordinary three-year deemed-completion mechanism.

This exclusion recognises that an inactive user may still expect access to an account containing:

• purchased digital content;

• account settings;

• transaction history;

• stored benefits;

• communications;

• or another continuing digital presence.

The exclusion does not mean that every item of information associated with the account may be retained forever.

The Data Fiduciary must separate:

• data necessary to maintain access to the account; and

• data retained for unrelated purposes.

5.1 Illustration: Inactive social-media account

A user has not posted, messaged or logged in for three years.

The platform may need to retain limited account credentials and information necessary to preserve account access. That does not automatically justify continued retention of:

• expired advertising profiles;

• obsolete inferred interests;

• abandoned contact-upload data;

• old location histories;

• unnecessary device identifiers;

• or data held for completed experiments.

The account-access exception should be interpreted according to necessity. It is not a blanket exception for the entire user profile and every historical data set associated with it.

6. Virtual tokens

The Third Schedule also excludes processing required to enable access to a virtual token issued by or on behalf of the Data Fiduciary, stored on its platform and usable to obtain money, goods or services.

The expression may cover qualifying:

• stored-value balances;

• loyalty credits;

• platform credits;

• gift tokens;

• gaming balances;

• reward points;

• or other digitally maintained instruments capable of being used to obtain value.

The purpose of the exclusion is to prevent automatic erasure from depriving an inactive user of an existing digital entitlement.

6.1 Illustration: E-commerce credit

A customer returned a product and received ₹2,000 in platform credit. She did not otherwise use the account for three years.

Automatically deleting all information necessary to identify and redeem that credit could deprive her of value. The platform may retain the limited information needed to preserve access to the token.

However, the existence of the credit does not justify preserving unrelated behavioural profiles, advertising segments or detailed browsing histories.

6.2 Illustration: Expired promotional points

A platform issued promotional points that lawfully expired after six months under transparent programme terms.

The virtual-token exception does not necessarily require indefinite retention after the entitlement has lawfully ceased. The Data Fiduciary should distinguish between an active redeemable token and an expired or extinguished promotional benefit.

6.3 Calculation of the Third Schedule period

7. Starting point

The Third Schedule provides a three-year period measured from the latest of:

• the date on which the Data Principal last approached the Data Fiduciary for performance of the specified purpose;

• the date on which she last exercised her rights in relation to the processing; or

• commencement of the DPDP Rules, 2025.

The “whichever is latest” formulation prevents historical inactivity preceding commencement from causing immediate erasure as soon as Rule 8 becomes operational. It gives covered Data Fiduciaries a prospective reference point for existing accounts.

7.1 Illustration: Account inactive before commencement

A user last used a covered e-commerce account in January 2024. Rule 8 becomes operational in May 2027.

The platform should not simply calculate three years from January 2024 and declare the period already expired before the Rule commenced. The commencement date operates as the later reference point under the Third Schedule.

7.2 Illustration: Activity after commencement

A user accesses the account and makes a purchase in December 2027.

For the purposes connected with that purchase and account interaction, the relevant inactivity calculation would be linked to the later engagement rather than the commencement date.

8. Purpose-specific clocks

Where one account supports several services, different purposes may end at different times.

Suppose a marketplace account is used for:

• product purchases;

• a loyalty programme;

• digital-book access;

• product reviews;

• marketing;

• and a stored-value wallet.

The Data Principal may stop purchasing goods but continue accessing digital books. She may withdraw marketing consent while retaining the wallet balance.

The Data Fiduciary should not necessarily apply one account-wide “last active” date to every processing operation. A purpose-based retention architecture should distinguish:

• performance of each service;

• consent status;

• continuing account access;

• virtual token access;

• legal retention;

• and rights activity.

A single undifferentiated retention clock may keep unnecessary data too long or erase continuing entitlements too early.

9. Rule 8(2): Forty-eight-hour warning before erasure

Rule 8(2) requires a covered Data Fiduciary to inform the Data Principal at least forty-eight hours before completion of the applicable erasure period.

The communication must explain that the personal data will be erased unless the Data Principal:

• logs into her user account;

• otherwise initiates contact for performance of the specified purpose; or

• exercises her rights in relation to the processing.

10. Purpose of the warning

The warning performs several functions.

It prevents unexpected deletion of an inactive account or service history. It gives the Data Principal a final opportunity to preserve an ongoing relationship. It also enables her to exercise rights before relevant personal data is erased.

This is particularly important where deletion may affect:

• access to historical purchases;

• a dormant social-media profile;

• stored content;

• account recovery;

• game progress;

• unsettled customer-service matters;

• or information needed for a rights request.

The warning is not a request for fresh consent. Logging in or contacting the platform should not automatically be treated as consent to unrelated processing.

11. At least forty-eight hours

The phrase “at least” means forty-eight hours is the minimum advance period. A Data Fiduciary may give earlier warning.

For large platforms, a single notice exactly forty-eight hours before deletion may create practical problems where:

• the email is filtered as spam;

• the registered number is inactive;

• the user is travelling;

• the individual needs time to export data;

• or the account contains valuable digital content.

A longer operational notice period may therefore be appropriate, but any earlier warning should still explain the actual deadline accurately.

12. Method and quality of communication

Rule 8(2) does not reproduce the exact communication language used in Rule 7, but the warning should be clear enough to allow meaningful action.

It should identify:

• the account or service concerned;

• the expiry date;

• the consequence of no action;

• the personal data or broad account information affected;

• the method for logging in;

• other contact methods;

• the rights mechanism;

• and any data-export facility.

A message stating only “Your inactive account is subject to our retention policy” would not communicate that erasure will occur unless the user acts.

13. A warning must not become manipulative re-engagement

The warning should not use deceptive design to revive commercial engagement.

Example

For example, the platform should not:

• present only a prominent “Keep everything” button while hiding erasure;

• combine account preservation with renewed marketing consent;

• require a purchase to prevent deletion;

• treat opening the warning email as renewed engagement;

• silently reactivate advertising profiles;

• or reset unrelated consent preferences.

The Data Principal should be able to understand what action preserves which part of the account or processing.

13.1 Effect of user action after the warning

14. Logging into the account

If the Data Principal logs in, the automatic erasure contemplated by Rule 8(2) is not carried out at the end of that period.

However, the effect should be understood carefully. A login may establish continuing interest in account access, but it does not necessarily revive every processing purpose.

Illustration

A user logs into a social-media account only to download old photographs and disable marketing preferences.

The login may demonstrate continued interest in account access and content retrieval. It does not necessarily justify restarting a three-year period for behavioural advertising, contact-list analysis or location profiling.

15. Initiating contact

The Data Principal may avoid automatic erasure by otherwise contacting the Data Fiduciary for performance of the specified purpose.

The contact should relate to the relevant service. An unrelated complaint, regulatory communication or accidental interaction should not automatically renew every purpose.

16. Exercising rights

If the Data Principal exercises a right, the Data Fiduciary must preserve the information necessary to address it.

Example

For example, she may request:

• access to processing information;

• correction of inaccurate personal data;

• erasure;

• grievance redressal;

• or information needed to understand past sharing.

The rights request should be processed on its own terms. It should not be characterised as unconditional commercial re-engagement.

17. Rule 8(3): Minimum one-year retention

Rule 8(3) begins with the words “without prejudice to sub-rules (1) and (2)”. This means the one-year requirement operates independently of, and alongside, the inactivity-based erasure framework.

The sub-rule requires a Data Fiduciary to retain:

• such personal data;

• associated traffic data; and

• other logs of processing, for a minimum of one year from the date of the relevant processing, for the prescribed purposes.

After that period, the Data Fiduciary must cause the data and logs to be erased unless:

• another law requires further retention; or

• further retention has been notified by the Government.

18. Rule 8(3) applies beyond the Third Schedule classes

Unlike Rule 8(1), the text of Rule 8(3) is not expressly limited to large e-commerce, gaming and social-media entities.

It refers generally to a Data Fiduciary and to processing undertaken:

• by the Data Fiduciary; or

• on its behalf by a Data Processor.

Accordingly, the one-year requirement potentially has wider application than the three-year inactivity rule, subject to the qualifying language regarding the specified data and prescribed purposes.

The two mechanisms should therefore not be merged:

• the three-year inactivity rule applies to specified large platforms and corresponding purposes;

• the one-year processing-record rule is framed more generally.

19. Minimum period, not automatic maximum

The expression “minimum period of one year” means the specified information cannot ordinarily be erased before the one-year period where Rule 8(3) applies.

But one year is not always the final deletion date. Longer retention may be necessary for:

• tax records;

• accounting records;

• anti-money-laundering duties;

• financial-sector regulation;

• employment legislation;

• regulatory investigations;

• legal claims;

• court orders;

• statutory audits;

• or another notified requirement.

At the same time, the minimum period does not permit indefinite retention after the applicable purpose and legal justification have ended. After the one-year period, the Rule directs the Data Fiduciary to cause erasure unless further retention is legally required.

20. Event-based retention

Rule 8(3) states that the one-year period runs from the date of such processing.

This suggests an event-based or processing-based record lifecycle rather than one universal account-level clock.

20.1 Illustration: Recurring transactions

A customer places orders on:

• 1 June 2027;

• 15 August 2027; and

• 4 January 2028.

Each transaction involves its own processing events and corresponding records. The one-year period for one transaction should not automatically be calculated from the date of another.

In practice, organisations may apply record-group or batch-retention rules, provided no required record is erased before its applicable minimum period and unnecessary retention is not extended indefinitely.

20.2 Illustration: Continuing service

A cloud service continuously processes customer data through storage, retrieval, synchronisation and backup.

Treating every automated background operation as restarting a one-year period for the entire historical dataset could make erasure impossible. The Data Fiduciary must interpret and implement the requirement at a defensible level of processing and record granularity, linked to the prescribed purposes and actual logs.

This is an area in which further governmental or Board clarification may be important.

20.3 Meaning of “such personal data”

Rule 8(3) does not say “all personal data” in the abstract. It refers to “such personal data, associated traffic data and other logs of the processing” for the specified purposes.

The phrase should be read contextually. It indicates that the retention obligation attaches to personal data and records relevant to the prescribed purposes, not necessarily every data field ever held by the Data Fiduciary.

20.4 Illustration: Completed e-book purchase

The Rule’s illustration states that an e-book platform must retain order details, personal data and logs concerning order confirmation, payment and delivery events for at least one year, even if the user deletes her account.

The relevant records may include:

• transaction identifier;

• purchaser identity;

• product purchased;

• date and time;

• payment confirmation;

• delivery event;

• device or access information relevant to the transaction;

• and processing logs.

It does not necessarily justify retaining unrelated marketing profiles, abandoned browsing histories or unnecessary contact-list data.

20.5 Associated traffic data

“Associated traffic data” should be understood as metadata generated in connection with communication, access, routing or use of the relevant processing system.

Depending on the context, it may include:

• source and destination identifiers;

• IP addresses;

• timestamp information;

• device identifiers;

• session identifiers;

• routing information;

• login events;

• transmission records;

• API transaction metadata;

• and system-access information.

Traffic data can itself be personal data where it relates to an identifiable individual. It may reveal:

• location;

• communication patterns;

• service usage;

• behavioural habits;

• devices;

• relationships;

• and activity timelines.

Accordingly, traffic data retained under Rule 8(3) remains subject to security, access control and purpose restrictions. Its classification as a log or metadata record does not make it non-personal.

20.6 Other processing logs

“Other logs of the processing” may cover records showing:

• collection;

• validation;

• access;

• modification;

• sharing;

• transmission;

• delivery;

• deletion;

• consent status;

• system actions;

• Processor activity;

• and other processing events.

The logging requirement should not be interpreted as authority to record the full content of every activity where metadata would be sufficient.

20.7 Illustration: Email service

A system may need to record that a transactional email was generated, addressed, sent and delivered. It may not always be necessary to retain an additional full copy of the message within the log itself.

20.8 Illustration: Customer-support call

A Data Fiduciary may need to retain a record showing that support processing occurred, who handled it and what action was taken. Rule 8(3) does not automatically require full audio recording of every call if the call was not otherwise recorded or if a less intrusive record satisfies the prescribed purpose.

Data minimisation remains relevant even within mandatory retention.

20.9 The apparent Seventh Schedule cross-reference issue

Rule 8(3), as reproduced in the final text, refers to purposes specified in the Seventh Schedule. However, the published Seventh Schedule is associated with Rule 22 and concerns purposes and authorised persons for governmental information requests, including specified State interests. It does not appear on its face to operate as a straightforward schedule of ordinary retention purposes under Rule 8(3).

This creates an apparent textual or cross-referencing difficulty.

It should not be resolved casually by assuming that “Seventh Schedule” means “Third Schedule.” The Third Schedule expressly concerns Rule 8(1), not Rule 8(3), and its content addresses classes of large platforms, purposes and three-year periods, not the separate one-year minimum-retention mechanism.

The legally cautious position is:

1. the final Gazette text is controlling;

2. the reference should be read exactly as notified unless corrected or authoritatively interpreted;

3. the Seventh Schedule’s actual content must be considered;

4. a private commentary should not rewrite the Rule;

5. any corrigendum, amendment, notification or Board clarification should be monitored; and

6. Data Fiduciaries should document the interpretation adopted pending official clarification.

The Rule’s own illustrations indicate that the intended one-year retention mechanism applies to ordinary processing records such as order, payment and delivery events and to records held by a cloud Data Processor. That apparent intention sits uneasily with the subject matter of the published Seventh Schedule, making official clarification particularly important.

20.10 Analysis of the statutory illustrations

21. E-book transaction

The first illustration concerns a Data Principal purchasing an e-book.

Once the e-book is delivered, the immediate specified purpose of processing for purchase and delivery may be completed. Nevertheless, the platform must retain relevant order details, personal data and processing logs for at least one year from the transaction.

The illustration establishes several principles.

21.1 Completion of the commercial purpose does not always require immediate erasure

Delivery may complete the principal transaction, but Rule 8(3) imposes a minimum period for the relevant records.

21.2 Account deletion and record erasure are not identical

A Data Principal may delete the visible account, but the Data Fiduciary may still be legally required to preserve selected backend records.

However, the retained records should be:

• removed from ordinary customer-facing use;

• restricted from marketing and profiling;

• limited to required fields;

• protected through access controls;

• and erased when the legal period ends.

21.3 The platform need not necessarily retain everything

The illustration refers to order details and logs involving order confirmation, payment and delivery. It should not be understood as authority to retain unrelated information merely because an e-book was purchased.

21.4 Continuing access to the e-book creates an additional nuance

If purchase of the e-book gives the Data Principal continuing access through the platform, delivery may not be the only ongoing purpose. The platform may need selected data to authenticate entitlement and provide future access.

That continuing-access purpose should be distinguished from the separate one-year evidentiary or processing-record retention requirement.

22. Cloud Data Processor

The second illustration concerns a company using a cloud provider to host customer records.

It confirms that the Data Fiduciary must ensure that the Processor also retains the relevant data and associated logs for the required period before erasure, unless another law requires longer retention.

This does not transfer the legal decision about retention to the cloud provider.

The Data Fiduciary must determine:

• which records must be retained;

• the applicable period;

• the legal basis;

• whether longer retention applies;

• what access restrictions are required;

• and when erasure must occur.

The cloud provider implements those instructions as Data Processor.

22.1 Contractual implications

The processing contract should address:

• retention periods;

• start and end points;

• log availability;

• preservation during migration or termination;

• deletion from active systems;

• treatment of backups;

• legal holds;

• subprocessor retention;

• deletion confirmation;

• and assistance with regulatory inquiries.

22.2 Example: Contract termination after six months

A Data Fiduciary terminates the cloud service six months after a processing event.

If Rule 8(3) requires the relevant records for one year, termination cannot result in premature deletion. The parties may need a secure export, limited archival arrangement or controlled retention mechanism covering the remaining period.

At the same time, the provider should not keep the full hosted environment indefinitely merely because selected logs require preservation.

22.3 Interaction between the three-year and one-year periods

23. They regulate different questions

The three-year period under Rule 8(1) asks:

When should the specified purpose of an inactive account be deemed no longer served for the covered large platform?

The one-year period under Rule 8(3) asks:

For how long must the relevant personal data, traffic data and processing logs be retained for the prescribed purpose after a processing event?

The three-year period is based on inactivity and applies to specified platform classes. The one-year period is based on processing events and is framed as a minimum retention rule.

24. The periods may overlap

Suppose a covered e-commerce platform has an active customer who places an order today.

The order records may be subject to:

• the continuing service purpose;

• one-year minimum retention under Rule 8(3), where applicable;

• a longer tax or accounting retention period;

• and the Third Schedule’s inactivity-based framework if the customer later becomes inactive.

The platform should not simply select the longest period without identifying the purpose for each record.

Different records may have different outcomes:

• delivery instructions may become unnecessary shortly after delivery;

• transaction and tax records may require longer legal retention;

• account credentials may remain necessary while the account exists;

• marketing consent records may remain necessary to prove status;

• behavioural profiles may require earlier deletion if their purpose ends;

• fraud-prevention records may be governed by a separate legal analysis.

24.1 Interaction with withdrawal of consent

Section 8(7) provides that withdrawal of consent is an erasure trigger, subject to lawful retention.

Rule 8 does not permit a Data Fiduciary to disregard withdrawal and keep ordinary consent-based processing active for three years.

24.2 Illustration: Marketing withdrawal

A customer withdraws consent to personalised marketing after one year of using the e-commerce platform.

The company cannot continue behavioural profiling for the remaining two years on the ground that the Third Schedule period has not expired. Consent has been withdrawn for that purpose.

It may preserve limited records necessary to show:

• the previous consent;

• withdrawal date;

• suppression status;

• and compliance with the withdrawal.

Those records should not be used to continue the marketing itself.

24.3 Illustration: Account deletion

A user asks to delete her gaming account.

The platform should:

1. cease consent-based processing within a reasonable time;

2. determine which data must be erased;

3. identify records subject to Rule 8(3);

4. identify financial, fraud, taxation or legal requirements;

5. preserve only the necessary records under restricted access;

6. cause Processors to apply the same instructions; and

7. erase the retained records when the final legal basis ends.

The user-facing account may therefore disappear before every backend statutory record is erased.

24.4 Interaction with other laws

Rule 8 repeatedly preserves retention required by other law.

This recognises that the DPDPA’s erasure principle does not operate in isolation. Organisations may be required to retain different records under:

• taxation laws;

• company law;

• goods and services tax legislation;

• anti-money-laundering requirements;

• banking regulation;

• securities regulation;

• insurance regulation;

• employment and social-security laws;

• consumer law;

• telecommunications regulation;

• court orders;

• limitation requirements;

• and regulatory investigations.

25. Longer retention must be record-specific

A law requiring preservation of invoices does not automatically authorise retention of every customer-behaviour record.

Example

For example, a tax law may require preservation of:

• invoice number;

• purchaser identity where applicable;

• transaction value;

• tax information;

• date;

• and payment details.

It may not require retention of:

• advertising profiles;

• clickstream data;

• precise historical location;

• product-recommendation inferences;

• contact-list uploads;

• or unrelated customer-service recordings.

The Data Fiduciary should retain the legally required record, not the entire surrounding data environment.

26. Documenting the legal basis

A defensible retention schedule should identify:

• record category;

• processing purpose;

• Data Fiduciary;

• Processor location;

• applicable Rule 8 period;

• other law requiring retention;

• statutory provision;

• event triggering the period;

• expiry date;

• access restriction;

• deletion action;

• and exception or legal hold.

A statement such as “retained for legal purposes” is too vague if the organisation cannot identify the relevant law and record.

26.1 Processor responsibility

Rule 8 extends to processing undertaken on behalf of the Data Fiduciary by a Data Processor.

The Data Fiduciary must therefore cause Processors to:

• apply the correct retention period;

• preserve required processing logs;

• stop ordinary use where the purpose ends;

• segregate records retained solely for compliance;

• erase information when instructed;

• pass requirements to authorised subprocessors;

• address backup copies;

• and provide evidence of completion.

The Data Fiduciary remains accountable for deciding what should be retained and what should be erased.

27. Processor conflict with its own legal obligations

A Processor may be subject to an independent law requiring it to preserve particular records.

The contract should establish a procedure under which the Processor:

• identifies the legal requirement;

• informs the Data Fiduciary where legally permitted;

• limits retention to the required information;

• restricts further processing;

• preserves confidentiality;

• erases the data after the requirement ends;

• and provides evidence where appropriate.

A Processor should not rely on an undefined “legal obligation” to retain customer data indefinitely.

28. Exit and migration

Retention duties must survive termination where legally required.

A Data Fiduciary moving from one cloud provider to another should decide:

• what is migrated;

• what remains in statutory archive;

• how duplicate copies are avoided;

• how old backups expire;

• how subprocessor copies are handled;

• and how deletion is verified.

Without exit planning, migration can create multiple uncontrolled copies and conflicting retention periods.

28.1 Backups, archives and deletion

29. Erasure beyond the active database

Erasure should ordinarily address:

• production databases;

• cloud replicas;

• files;

• shared folders;

• email;

• exports;

• test environments;

• analytics platforms;

• operational logs;

• Processor copies;

• subprocessor copies;

• caches;

• archives;

• and backups.

Deleting only the visible account does not necessarily amount to erasure.

30. Backups

Immediate deletion from every immutable backup may not always be technically possible. A defensible arrangement may:

• remove personal data from active processing;

• isolate backups;

• prevent restoration for ordinary use;

• reapply deletion instructions if restoration occurs;

• maintain a defined backup-overwrite cycle;

• and ensure final expiration.

The existence of a backup should not become a permanent exception to erasure.

31. Archived statutory records

Records retained solely because of Rule 8(3) or another law should ideally be placed in a restricted archive.

Such an archive should prevent:

• ordinary marketing use;

• routine employee access;

• product analytics;

• AI training;

• account personalisation;

• unrelated sharing;

• and alteration without authorisation.

Retention does not mean continued operational use. The more appropriate model is restricted preservation for the legal purpose.

31.1 Data Principal expectations and transparency

A Data Fiduciary should explain its retention approach clearly.

The privacy notice or retention communication should distinguish:

• active account information;

• information retained while a service is being provided;

• inactivity-based erasure;

• the forty-eight-hour warning;

• minimum processing-record retention;

• legal retention;

• Processor retention;

• and final erasure.

A blanket statement that information is retained “as long as necessary” may be legally accurate at a high level but may not provide meaningful understanding where the organisation has established and knowable retention periods.

32. Account deletion interface

Where a Data Principal deletes an account, the interface should not misleadingly promise that “all data is immediately and permanently erased” if selected records must legally remain.

A more accurate explanation would distinguish:

• information erased from active service systems;

• records retained under applicable law;

• purpose and duration of restricted retention;

• and eventual deletion.

Transparency does not require exposing sensitive system architecture. It requires an honest account of the practical effect.

32.1 Deemed completion is not the same as invalidation of all prior processing

When the purpose is deemed no longer served, previous lawful processing does not become retrospectively unlawful.

The effect is prospective:

• ordinary processing for the completed purpose should stop;

• personal data should be erased unless retention is legally required;

• Processor instructions should be issued;

• and remaining records should be restricted.

The Data Fiduciary may still preserve evidence necessary to show:

• what transaction occurred;

• what consent was given;

• what service was performed;

• when data was erased;

• and how legal obligations were discharged, provided retention of that evidence has a valid basis.

32.2 Inactivity does not equal withdrawal of consent

Rule 8’s inactivity mechanism and Section 6 withdrawal are legally different.

Withdrawal is an express act by the Data Principal. Inactivity is the absence of relevant service engagement or rights activity for the prescribed period.

The practical consequences may overlap because both can lead to cessation and erasure. But the legal triggers differ.

A platform should not describe inactivity-based deletion as “consent withdrawal by the user.” Nor should it treat a user’s inactivity as consent to new processing.

32.3 Re-engagement after erasure

If personal data has been erased after the inactivity period and the individual later returns, the Data Fiduciary may need to treat the person as a new or returning user without the deleted history.

It should not attempt to reconstruct erased profiles from:

• backups;

• old Processor copies;

• shadow databases;

• marketing tools;

• or security logs retained for another purpose, unless lawful restoration is necessary for the purpose for which those records were retained.

Re-engagement does not retroactively revive data that was lawfully erased.

32.4 Threshold and classification issues

33. Registered-user thresholds

The Third Schedule uses thresholds based on registered users in India:

• two crore for e-commerce entities;

• fifty lakh for online gaming intermediaries;

• two crore for social-media intermediaries.

A Data Fiduciary near a threshold should establish a consistent method for determining:

• what counts as a registered user;

• whether duplicate accounts are counted;

• whether deleted or suspended accounts remain included;

• whether bots or fraudulent users are excluded;

• how India-linked users are identified;

• and the date on which threshold status is assessed.

The Schedule’s definitions and imported statutory concepts should govern the classification. A company should not manipulate account classifications to place itself below the threshold.

34. Crossing the threshold

Where a platform grows beyond the threshold, it should determine:

• when it became subject to the Schedule;

• how existing user inactivity is treated;

• how the commencement floor applies;

• when warnings must begin;

• and whether historical data can be mapped to purpose-specific clocks.

The final Rules do not appear to set out a detailed transition mechanism for a platform crossing the threshold after commencement. This is another area where a cautious interpretation and well-documented implementation method are necessary.

35. Falling below the threshold

A large platform that later falls below the threshold should not assume that every existing retention obligation disappears immediately.

Its classification, pending erasure processes and continuing general duties under Section 8(7) require careful assessment. Falling outside Rule 8(1) would not create a right to retain data indefinitely.

35.1 Automated retention systems

Large platforms cannot implement Rule 8 reliably through manual review alone. They will ordinarily require automated retention and erasure systems.

Those systems should be capable of:

• classifying the processing purpose;

• identifying the applicable Data Fiduciary class;

• recording last meaningful user interaction;

• recording rights activity;

• distinguishing account-access and token exceptions;

• calculating processing-event retention;

• applying legal holds;

• sending advance warnings;

• recording delivery;

• suspending erasure where appropriate;

• issuing Processor instructions;

• handling failures;

• recording deletion;

• and supporting audit.

36. Accuracy of inactivity signals

The retention engine should not treat every automated event as user activity.

The following should not necessarily restart the clock:

• background application refresh;

• automatic token renewal;

• security scan;

• marketing email delivery;

• advertising pixel;

• system-generated recommendation;

• Processor backup;

• unsuccessful login by an attacker;

• or internal employee access.

The system should distinguish activity initiated by the Data Principal from system activity performed without her participation.

37. Erasure failures

Automated deletion can fail because of:

• unavailable systems;

• incorrect identifiers;

• Processor errors;

• duplicate records;

• legal-hold conflicts;

• schema changes;

• backup limitations;

• or incomplete data inventories.

The system should generate exceptions and escalation rather than silently marking the data deleted.

A deletion status should be supported by actual completion across affected systems and Processors.

37.1 Security implications

Retention and security are closely connected.

Keeping data longer increases:

• the volume available to an attacker;

• the number of systems containing copies;

• the likelihood of outdated permissions;

• the complexity of incident investigation;

• and the consequences of a breach.

Premature deletion can also create risks where necessary records are lost, legal obligations cannot be met or integrity cannot be restored.

Rule 8 therefore requires a controlled balance:

• do not erase before a mandatory period expires;

• do not keep data after the final lawful justification ends;

• restrict information retained solely for compliance;

• and protect retained records throughout the period.

The one-year retention rule does not reduce Rule 6 security obligations. Personal data and logs retained under Rule 8 remain subject to access control, monitoring, encryption or equivalent protection, Processor safeguards and secure deletion.

37.2 Enforcement consequences

A significant breach of Rule 8 may fall within the residual Schedule entry for violation of another provision of the Act or Rules, carrying a maximum penalty of up to ₹50 crore.

Relevant non-compliance may include:

• failure to erase after the prescribed period;

• erasure before the required one-year period;

• failure to issue the forty-eight-hour warning;

• maintaining inactive profiles beyond the permitted period without legal justification;

• treating passive tracking as account activity;

• failing to preserve required logs;

• failing to cause a Processor to retain or erase relevant records;

• continuing to use legally retained records for unrelated purposes;

• or maintaining indefinite Processor or backup copies.

The maximum amount is not automatic. The Board must conduct an inquiry, determine that a significant breach occurred, provide an opportunity of hearing and apply the factors in Section 33.

A failure may be more serious where:

• large numbers of Data Principals are affected;

• the retention is systematic;

• high-impact data is involved;

• the Data Fiduciary ignored repeated deletion failures;

• personal data was retained for commercial exploitation;

• Processor copies were uncontrolled;

• rights requests were frustrated;

• or the Data Fiduciary falsely represented that information had been deleted.

37.3 Overall interpretation

Rule 8 creates a layered retention and erasure framework rather than one simple deletion deadline.

Its correct interpretation rests on the following propositions:

1. The general duty to erase originates in Section 8(7).

2. The deemed-purpose mechanism under Rule 8(1) applies only to specified large e-commerce, gaming and social-media entities.

3. The three-year period is an inactivity-based deeming rule, not a universal licence to retain all personal data.

4. The period should be applied to the relevant purpose, not indiscriminately to the entire account.

5. Account-access and virtual-token processing are excluded only to the extent necessary to preserve those functions.

6. The forty-eight-hour intimation gives the Data Principal a final opportunity to preserve access or exercise rights.

7. Logging in should not automatically revive unrelated consent or processing purposes.

8. Rule 8(3) creates a separate minimum one-year retention requirement for specified personal data, traffic data and processing logs.

9. The one-year period runs from the relevant processing event, not necessarily from account creation, account deletion or the most recent unrelated activity.

10. One year is neither a universal minimum for every personal-data field nor a universal maximum requiring deletion regardless of other law.

11. Other statutory retention duties may require longer preservation.

12. Legally retained data should be restricted from unrelated operational or commercial use.

13. The Data Fiduciary must cause its Processors to apply the relevant retention and erasure instructions.

14. Account deletion does not always mean immediate erasure of every backend statutory record.

15. The apparent Rule 8(3) cross-reference to the Seventh Schedule requires careful monitoring for official clarification and should not be privately rewritten.

Key point

Rule 8 requires Data Fiduciaries to know why each record is held, what event starts its retention period, what activity keeps the purpose alive, what law requires longer retention, and what systems and Processors must erase it when that justification ends. Its central principle is not simply “delete after one year” or “delete after three years.” It is that every period of retention must be tied to a defined purpose, a prescribed minimum, a genuine continuing service or a specific legal obligation, after which erasure must follow.