DPDP Rule 8: What You Must Delete and When
If you’ve ever wondered why you still get “We miss you!” emails from an app you abandoned five years ago, here’s the secret: most organisations never delete anything, even when the purpose is long over. Rule 8 is designed precisely to fix this.
Rule 8 is one of the most operationally heavy parts of the DPDP regime. It decides how long personal data can be stored, when it must be deleted, what happens to logs, and how companies must prove it.
Rule 8 Explained

Purpose-Based Retention Only
Rule 8 says: only keep data for as long as you genuinely need it. No more storing 10-year-old onboarding details “just in case”.
Example:
If a fintech only needs your PAN for account verification, it cannot keep it forever. Once the verification purpose is done—and no other law requires retention—the data must go.
Mandatory Deletion When Purpose Ends
When the purpose is done, deletion is not optional. It’s mandatory. And “deletion” isn’t the pretty UI version (“Delete Account”) — it must happen across databases, analytics systems, logs (where relevant), archives, and with every processor.
Example:
If a customer closes their account with an online learning platform, the platform cannot keep the profile, phone number, and old course activity forever. Rule 8 requires erasure unless another law mandates retention.
Inactivity-Based Deletion
This is the interesting, very India-specific part. If a Data Principal doesn’t interact with a service for a certain period (defined in the Third Schedule), the organisation must initiate erasure.
Example:
If a user hasn’t logged into a shopping app in years, Rule 8 essentially asks: “Does the user still want this account? If not, delete it.”
This prevents companies from accumulating “zombie accounts” — accounts that exist but the user has mentally moved on.
48-Hour Pre-Erasure Notice
Before deleting data due to inactivity, the organisation must send a notice at least 48 hours in advance. This gives the user a final chance to say, “Hey, I’m still here — please keep my account.”
Example:
You get an email: “Your account will be deleted in 48 hours unless you log in.”
Clean, transparent, and fair.
To comply with the law, the notice must include five essential elements:
One-Year Minimum Retention of Logs
This is where cybersecurity meets privacy. Rule 8 requires Data Fiduciaries to keep processing logs, access logs, and related technical records for at least one year, even after the purpose is completed.
Why?
- To investigate breaches
- To perform forensics
- To support DPB inquiries
Think this: If a breach occurs tomorrow, do you have enough logs to prove what happened?
Deletion Must Reach Every System
Deletion must propagate everywhere — and this is the hardest part technically.
Erasure must reach primary databases, cloud object stores, event streams, analytics pipelines, DR sites, archived backups (as far as technically possible), and all downstream processors.
This is where most organisations struggle.
Deleting from the UI is easy. Deleting from five SaaS tools + two backups + a warehouse + archived logs? That’s the real test.
Special Cases Under the Third Schedule
The Third Schedule applies to High-Volume Data Fiduciaries (HVDFs). These include large social media platforms, e-commerce marketplaces, gig apps, fintech services, gaming platforms and OTT providers.
HVDFs follow stricter retention and erasure requirements than regular Data Fiduciaries. This includes:
Fiduciaries. This includes:
- Shorter inactivity periods before erasure must begin.
- Category-specific retention timelines for fraud, AML, chargebacks, grievances and regulatory audits.
- Enhanced log-retention expectations, often longer than the standard one-year period.
- Stronger deletion evidence, ensuring erasure covers primary systems, DR environments and all processors.
Why Rule 8 Exists: The Policy Logic
1. To Stop Indefinite Data Hoarding
Most companies keep everything forever. This rule forces them to clean up.
Example:
If your 2014 fitness app still has your age, height, and running data, that’s exactly the problem Rule 8 is fixing.
2. To Reduce Breach Impact
Less stored data = smaller breach blast radius.
If a breach hits a system storing 10 years of unused data? Disaster.
If it hits a system storing only what’s necessary? Damage is contained.
3. To Improve Security & Forensics
The one-year log rule ensures investigations don’t hit a dead end. When a breach, unauthorised access, or system anomaly occurs, logs become the only reliable record of who accessed what, when, and how.
4. To Build Accountability Into Architecture
Privacy is no longer a policy problem — it’s an engineering requirement.
Rule 8 forces organisations to redesign how they store, track, delete, and log data.
Why Compliance Matters
Rule 8 is one of the most heavily enforceable areas of the DPDP regime because improper retention and failed deletion directly affect breach impact and user rights.

Financial Penalties Are Significant
Rule 8 failures (retention, deletion, logs) fall under penalties up to ₹50 crore, while broader security failures connected to retention (like improper backups or access logs) fall under ₹250 crore.
Penalties apply per instance, meaning repeated failures multiply liability.
DPB Powers
The Data Protection Board can initiate inquiries, request logs, demand evidence of deletion, summon processors, and issue binding corrective orders.
In severe or repeated non-compliance, the Board can recommend blocking a service’s access in India.
Investigation Triggers
A breach involving old or unnecessary data is the fastest way to attract scrutiny. If you retain data beyond purpose, the DPBI will ask why.
If you lack logs, the DPBI will ask how you will prove anything. If your processors cannot delete data promptly, you remain liable.
Operational Consequences
Non-compliance leads to ballooning storage costs, unmanaged replicas, impossible deletion requests, and constant firefighting during audits.
The reputational damage from deleting accounts without proper notices — or retaining data for years without reason — can be as harmful as financial penalties.
Compliance with Rule 8 is not optional hygiene; it is the foundation for secure, accountable, and transparent data governance.
How To Comply with Rule 8: A Practical Blueprint
This is where organisations must focus their energy.
1. Build a Retention & Erasure Framework
- Define retention periods for each personal data category.
- Map DPDP obligations to sectoral laws (RBI, SEBI, IRDAI, Income Tax, Companies Act).
- Document purpose → retention → deletion triggers.
- Implement Records of Processing that reflect Rule 8.
2. Deploy the Right Technical Architecture
- Set up a central retention engine.
- Automate deletion across systems
- Integrate deletion with login/activity tracking.
- Build 48-hour notice pipelines (SMS/email/app).
- Establish log storage with one-year minimum retention.
- Review backup architectures to avoid reintroducing deleted data.
3. Update Contracts & Vendor Controls
- DPAs must include retention limits.
- Vendors must provide deletion proofs.
- Processors must support log retention and DPB cooperation.
- Perform vendor privacy posture assessments.
4. Create Operational SOPs
- End-of-purpose deletion workflows.
- Inactivity-clock monitoring.
- 48-hour notice process.
- Audit logs for every deletion event.
- Evidence preservation for DPBI inspections.
Grey Areas — And Their Answers
Some Rule 8 questions don’t have explicit answers in the Act or Rules, but organisations still need direction.
Here are the three most important grey areas and how to approach them.
1. What counts as “interaction” for inactivity-based deletion?
The most reasonable interpretation is any meaningful action that shows the user is still using the service — such as logging in, making a transaction, updating a profile, using a feature, or interacting through an app.
Passive events like receiving an email or seeing a push notification should not reset the inactivity clock, because they don’t demonstrate active use.
2. How should organisations handle deletion in backups?
Backups are not intended for routine access, so immediate deletion inside immutable backup sets is not required.
However, backups must be encrypted, access-restricted, lifecycle-managed, and overwritten as part of the rotation schedule.
More importantly, if a restoration occurs, organisations must ensure that deleted personal data does not silently reappear.
This means running “post-restore deletion jobs” and maintaining strict logs of restoration events.
3. What if sectoral laws require longer retention than DPDP?
Sectoral laws prevail.
If RBI or SEBI requires seven to ten years of record retention, the organisation must follow that requirement, even if the DPDP’s purpose-based retention period would ordinarily be shorter.
The solution is to mark such datasets as “legal hold” under the retention matrix and clearly communicate the dual requirements in privacy notices and internal documentation.
Conclusion
Rule 8 forces every organisation to answer the questions they’ve avoided for years: Do we need this data? Why are we keeping it? Can we prove when we deleted it?
It is a rule that pushes companies away from convenience and toward accountability — and the ones that adapt early will face fewer risks and far greater trust.
Key Takeaways
- Rule 8 Explained: Retention must be tied to purpose, inactivity triggers deletion, logs must be stored for one year, and deletion must reach all systems.
- Why It Exists: To prevent hoarding, reduce breach damage, strengthen forensics, and enforce disciplined data architecture.
- Who It Affects: Fiduciaries, processors, and principals — everyone in the data ecosystem.
- Why Compliance Matters: High penalties, DPB scrutiny, sectoral overlap, and major security implications.
- How to Comply: Align governance, build automated retention engines, maintain logs, enforce vendor controls, and operationalise SOPs.
- Grey Areas: Interaction definitions, backup deletion strategy, and reconciling DPDP with sectoral rules.
