Product · 8 min read · Jun 2026

DPDP Data Retention & Erasure

W2 BI2.png # DPDP Data Retention & Erasure

Designing Clean Data Lifecycles For Your SaaS Product

Published by Vishwaas.ai | DPDP Series

1. Why Data Retention Under DPDP Deserves A Fresh Look

Most products are great at collecting data and terrible at letting go of it. Old tables, forgotten backups, stale logs - they quietly pile up in the background. Under India's Digital Personal Data Protection Act, 2023 (DPDP Act) and the DPDP Rules 2025, that 'keep everything forever' mindset becomes a compliance and trust risk.

Section 8 of the DPDP Act introduces the storage limitation principle - personal data must not be retained for longer than is necessary for the specified purpose of processing. The Rules add concrete timelines, erasure triggers and minimum log-retention requirements, especially through Rule 6 and Rule 8 and the Third and Seventh Schedules.

For SaaS teams, this turns data retention from an IT housekeeping topic into a core design question: 'What data do we keep, for how long, and how do we prove it?'

2. The Golden Rule: Purpose-First Retention And Erasure

DPDP's backbone is simple:

When the purpose of processing is fulfilled, personal data should be erased.

When the Data Principal withdraws consent, personal data should be erased.

The only exception is where retention is required by another law (for example, tax, KYC or sector regulations).

Practitioner summaries often describe this as: 'Purpose complete → delete; consent withdrawn → delete; legal mandate → keep.'

This means every data category in your stack - relational databases, object storage, AI training sets, logs, caches and backups - should be tied to a clear business purpose and a retention rule that follows this logic.

3. Rule 6 And Rule 8: Turning Principles Into Operations

While the Act sets the principle, Rule 6 and Rule 8 of the DPDP Rules add operational teeth:

Rule 6 - General Retention Obligations

Erase personal data that is no longer necessary for the specified purpose.
Instruct Data Processors to do the same.
Maintain records of erasure (what was deleted, when and why).
Track rejections of erasure requests, along with reasons.

Rule 8 - Time Period For Purpose To Be Deemed No Longer Served

Clarifies when a purpose is 'no longer being served' through Schedule-based time windows.
Adds mandatory 48-hour pre-erasure notice in certain contexts.
Requires a minimum one-year retention of logs and associated traffic data under the Seventh Schedule.

Together, these rules create a structured lifecycle: collect, use for a clearly stated purpose, notify, erase, and retain logs for a defined minimum period.

4. Third Schedule: 3-Year Inactivity Rule For Large Online Platforms

A lot of confusion in DPDP conversations comes from the Third Schedule, which applies only to certain large online platforms at defined user thresholds - such as big e-commerce marketplaces, social media intermediaries and online gaming platforms.

For these platforms, the Rules require that:

If a user has been inactive for three years (no login, no rights exercised, no meaningful contact), the Data Fiduciary must erase their personal data, unless retention is required by law or to allow access to accounts or virtual tokens.
At least 48 hours before erasure, the user must receive a clear notice explaining that their data will be deleted unless they log in or otherwise reinitiate contact.

This rule is narrow - it does not apply to sectors like BFSI, healthcare, government services or HR unless they fall under the specific categories defined in the Schedule. But it sets an important design pattern for everyone: inactivity should eventually translate into data deletion, not indefinite storage.

5. Seventh Schedule: One-Year Mandatory Retention For Sovereign Functions

The Seventh Schedule deals mostly with public and sovereign functions - law enforcement, taxation, courts, welfare delivery, licensing and regulatory activities.

Where this Schedule applies, Data Fiduciaries must:

Retain personal data, associated traffic data and processing logs for at least one year from the date of processing.
Only erase the data and logs after that period, unless another law requires a longer retention time.

This schedule is quite limited for private-sector SaaS products, but it matters if your platform supports government workflows or statutory registers. It also underscores a key idea: retention can be mandatory for some purposes, even if users ask for deletion, as long as it is grounded in law.

6. Log Retention: Why You Can Delete Data But Keep Logs

DPDP makes an important distinction between personal data and logs. Logs include things like access logs, consent logs, rights-handling logs, breach logs and system activity logs.

Under the Rules:

Data Fiduciaries must retain processing logs for at least one year from the date of processing, even if the underlying personal data has been erased.
Certain large online platforms may have three-year log retention expectations, tied to their risk profile and user scale.

Think of logs as the audit trail that lets you prove what you did, when and why - to regulators, auditors and sometimes to courts. DPDP wants you to delete unnecessary personal data, but it also wants you to be able to demonstrate responsible behaviour.

7. Children, Persons With Disabilities, And Complaints: Special Retention Scenarios

Retention rules get tighter around vulnerable groups and dispute scenarios.

Children and PWDs

Personal data of children must be erased when it is no longer necessary for the specified purpose, with tracking, profiling and behavioural advertising broadly prohibited.

For certain persons with disabilities, guardian verification is critical, and data must be erased when the guardian relationship ends unless another lawful basis continues.

Complaints, grievances and legal obligations

If a complaint, investigation or legal dispute is ongoing, organisations may retain relevant data until the matter is closed, with clear justification noted in their retention register.

This means retention policies should not be purely time-based; they must also be event-aware, pausing deletion where erasure would undermine due process or statutory obligations.

8. Backups, AI Data And The Real-World Complexity

Real stacks are messy: you have production databases, analytics warehouses, backup tapes, AI training sets and observability pipelines. DPDP guidance and expert commentary acknowledge this complexity:

Erasure expectations focus first on live systems - backups may be allowed to roll off via normal rotation rather than immediate hard deletion, as long as they are immutable and access-controlled.
AI-specific data without sector mandates should follow the same purpose-based principle: delete evaluation or training data once the run is done, and ensure model weights cannot be reversed to recover raw personal data.
Every copy of personal data - production, cache, data lake, AI store - must be mapped in your retention schedule so nothing quietly escapes the lifecycle.

For product managers, this is where close collaboration with data engineering and infrastructure teams becomes essential.

9. Building A DPDP-Aligned Retention Matrix For Your Product

Practitioner guides increasingly recommend a DPDP retention matrix - a single table that maps all major data categories to their purposes, legal basis and erasure trigger.

A typical matrix for a SaaS product might include columns like:

Data category (user profiles, billing records, session logs, support tickets, AI feedback).
Purpose (account management, billing, security monitoring, product improvement).
Legal basis (consent, legitimate use, statutory mandate).
Retention rule (e.g., 'until account closure + 3 years', '3 years of inactivity', '1 year of logs').
Overrides (e.g., tax law, RBI circulars, sector norms).
Erasure trigger (purpose completion, consent withdrawal, inactivity period, dispute closure).

Once you have this matrix, you can implement scheduled deletion jobs, build dashboards for DPDP audit readiness, and answer regulator or customer questions with clarity instead of guesswork.

10. Turning Retention And Erasure Into A Trust Feature

Done well, retention and erasure are not just compliance chores - they are visible markers of respect for user data.

Under DPDP, telling a user 'we delete your data when it's no longer needed, and we can show you how' is far more powerful than listing a dozen vague purposes in a policy.

For Vishwaas.ai and other DPDP-focused platforms, this opens an opportunity:

Provide configurable retention policies that align DPDP rules with sector regulations.
Orchestrate erasure workflows across multiple systems and processors.
Maintain evidence-grade logs to show that deletion actually happened and that overrides were legally justified.

In a world where 'data is the new oil' has started to feel dated, DPDP pushes Indian organisations toward a better slogan: data is a responsibility. Clean, well-documented data lifecycles - with thoughtful retention and timely erasure - are how that responsibility shows up in your product.