Data Retention Under DPDP: How Long Can You Keep Personal Data?

You know you need to delete personal data at some point. The DPDP Act says so. But "at some point" is not a retention policy, and the Act's actual requirements are more specific, and more layered, than most summaries suggest.

I have built data retention frameworks at three companies, and the pattern is always the same. The legal team knows the Act says "erase when the purpose is no longer served." The engineering team asks: "What does that mean in months?" Nobody has a clear answer, and the data stays forever by default. That default is now a compliance violation carrying penalties of up to ₹50 crore.

This guide translates Section 8(7) of the DPDP Act 2023, the relevant DPDP Rules 2025 provisions, and the sectoral laws that override both into a practical retention framework you can implement this quarter.

Key Takeaways

• Section 8(7) of the DPDP Act 2023 requires Data Fiduciaries to erase personal data when the processing purpose is fulfilled or when consent is withdrawn, whichever comes first, unless retention is required by another law.
• The DPDP Rules 2025 mandate a minimum 1-year retention for access logs and processing records for all Data Fiduciaries. Large platforms (e-commerce, social media, gaming) face a 3-year inactivity erasure trigger with a mandatory 48-hour pre-erasure notice.
• Consent Managers must retain audit trails of all consent events for a minimum of 7 years.
• Sectoral laws (RBI, Income Tax, Companies Act, GST) often require longer retention than the DPDP Act's "erase when done" principle. Your retention schedule must reconcile both.
• The penalty for retaining personal data beyond its lawful retention period is up to ₹50 crore per violation under the DPDP Act's penalty schedule.

What Does Section 8(7) Actually Require?

Section 8(7) of the DPDP Act 2023 establishes a single principle: a Data Fiduciary must erase personal data when the purpose for which it was collected is no longer being served, or when the Data Principal withdraws consent, whichever occurs earlier.

There is one exception. If retention is necessary for compliance with any law currently in force, the data may be retained for the period that law requires.

Here is what that looks like in practice:

Trigger	What Happens	Timeline
Purpose fulfilled	Data must be erased	As soon as the stated purpose is no longer active
Consent withdrawn	Data must be erased	Upon receipt of valid withdrawal request
Both triggers, different dates	Earlier trigger applies	Whichever event occurs first
Sectoral law requires retention	Exception applies	Retain for the period required by that specific law

The challenge is clear. "Purpose no longer being served" is not a calendar date. It is a judgment call that depends on what you told the Data Principal during collection, what processing activities you are actually performing, and whether the original purpose has genuinely concluded. This is why you need a documented retention schedule, not just a policy statement.

For a detailed analysis of the processing purposes that trigger these retention obligations, see our guide to legitimate uses under DPDP.

What Specific Retention Periods Does the DPDP Rules 2025 Set?

The DPDP Rules 2025 convert Section 8(7)'s principle into concrete timelines for specific scenarios. As of April 2026, these are the defined periods:

1-Year Minimum: Access Logs and Processing Records

All Data Fiduciaries and Data Processors must retain personal data access logs, traffic data, and processing records for a minimum of one year from the date of processing. This applies regardless of whether the personal data itself is deleted earlier.

These logs must capture:

• Access events (who accessed what data, when)
• Modification events (what was changed, by whom)
• Consent withdrawal records
• Deletion triggers and actions taken
• Security incidents involving personal data

The one-year period is a minimum. If your organisation is designated as a Significant Data Fiduciary, or if you operate a large platform under the Third Schedule, the log retention period extends to three years.

3-Year Inactivity Rule: Large Platforms

The DPDP Rules 2025, through the Third Schedule, impose a specific retention limit on certain categories of Data Fiduciaries:

• Large e-commerce companies
• Social media intermediaries with over 20 million registered users in India
• Online gaming platforms with over 5 million registered users in India

For these entities, if a Data Principal has been inactive for three consecutive years, the platform must erase their personal data. The three-year period starts from the later of two dates: the Data Principal's last purposeful interaction with the platform, or the date the DPDP Rules 2025 came into effect.

Before erasure, the platform must send a 48-hour pre-erasure notice. If the Data Principal responds or reactivates their account within those 48 hours, the data is retained. If there is no response, the data must be erased.

7-Year Minimum: Consent Manager Records

Entities registered as Consent Managers under the DPDP Act must retain audit trails of all consent events for a minimum of seven years. This includes the record of what consent was given, when, by whom, and any subsequent modifications or withdrawals.

Summary: DPDP-Mandated Retention Periods

Data Type	Applies To	Minimum Retention	Maximum Retention	Source
Access logs and traffic data	All Data Fiduciaries	1 year	No explicit maximum (purpose-based)	DPDP Rules 2025, Rule 8
Access logs (large platforms)	SDFs and Third Schedule entities	3 years	No explicit maximum	DPDP Rules 2025, Schedule VI
User personal data (large platforms)	Third Schedule platforms	None specified	3 years from last interaction	DPDP Rules 2025, Third Schedule
Consent audit trails (Consent Managers)	Registered Consent Managers	7 years	No explicit maximum	DPDP Rules 2025, Rule 10
General personal data	All Data Fiduciaries	None specified	Until purpose fulfilled or consent withdrawn	DPDP Act 2023, Section 8(7)

How Do Sectoral Laws Override DPDP Retention Rules?

This is where data retention gets genuinely complicated for Indian businesses. Section 8(7) of the DPDP Act includes a carve-out: data may be retained if "necessary for compliance with any law for the time being in force." In practice, this means your retention schedule must account for every other Indian law that prescribes data keeping periods.

Here are the ones that affect the most businesses:

Sectoral Law	Data Type	Required Retention Period
Income Tax Act, 1961	Books of account, financial records	6 years from end of relevant assessment year (8 years for transfer pricing)
GST Law	Returns, invoices, challans, e-way bills	72 months (6 years) from filing date of annual return
Companies Act, 2013	Books of account, vouchers	8 years preceding current financial year
Companies Act, 2013	Registers of members	Permanent retention
RBI KYC Directions	KYC records (identity, address proof)	5 years after business relationship ends
RBI AML Guidelines	Transaction records	10 years beyond account closure
CERT-In Directions (2022)	System logs, event logs	180 days (rolling)
IT (Intermediary Guidelines) Rules	User information for tracing	180 days after account cancellation
SEBI Regulations	Client records, trading data	5-10 years depending on record type
IRDAI Regulations	Policyholder records	Policy tenure + 8 years

The practical consequence: you cannot simply erase a customer's data the moment they close their account. If that customer made purchases, you have GST obligations (6 years). If you collected KYC data, you have RBI obligations (5-10 years depending on the data type). If they were an employee, you have Income Tax and PF/ESI record obligations.

Your retention schedule must reflect the longest legally mandated period across all applicable laws for each data category. Deleting data prematurely to comply with DPDP when another statute requires its retention creates a different compliance problem.

How to Build a DPDP-Compliant Data Retention Schedule

This is the operational core. A retention schedule maps every category of personal data your organisation holds to a defined retention period, a legal justification, and a deletion mechanism. Without one, you are retaining data by default, or deleting it arbitrarily, and both are problems.

Step 1: Start With Your Data Inventory

If you have already completed a DPDP data audit, you have a personal data inventory. If not, start there. You need to know what personal data you hold before you can decide how long to keep it.

Pull your inventory and organise it by data category. Each category will have its own retention logic.

Step 2: Determine the Purpose for Each Data Category

For every data category, document the specific processing purpose. This is the anchor for your retention period, because Section 8(7) ties erasure to purpose fulfilment.

Be precise. "Marketing" is not a purpose. "Sending monthly product updates via email to customers who opted in" is a purpose. The more specific the purpose, the more defensible the retention period.

Step 3: Identify All Applicable Legal Retention Requirements

For each data category, check whether any sectoral law mandates a retention period. Use the table above as a starting reference, but verify against your specific regulatory obligations.

If a sectoral law applies, that period becomes your minimum. The DPDP Act's "erase when done" principle yields to the sectoral mandate.

Step 4: Set a Defined Retention Period

For each data category, set a retention period using this logic:

1. If no sectoral law applies, set the retention period based on the processing purpose. Add a reasonable buffer for dispute resolution or audit (typically 6-12 months beyond purpose fulfilment).
2. If a sectoral law applies, set the retention period to the statutory minimum required by that law.
3. Never set "indefinite" as a retention period. Every record needs a defined endpoint.

Step 5: Document the Schedule

Here is the template I use. Adapt it to your organisation's data categories:

Data Category	Purpose	Retention Period	Legal Basis	Sectoral Override	Deletion Method	Review Date
Customer account data	Service delivery	Duration of account + 12 months	Consent (Section 6)	None	Automated deletion	Quarterly
Purchase transaction records	Order fulfilment, returns	Duration of relationship + 6 years	Legal compliance (Section 7(e))	GST Law (72 months)	Automated archival, then deletion	Annual
Employee payroll data	Salary processing, tax compliance	Employment + 8 years	Employment (Section 7(b))	Income Tax Act (6-8 years)	Scheduled deletion	Annual
KYC records (fintech)	Identity verification	Relationship + 5 years	Legal compliance (Section 7(e))	RBI KYC Directions	Manual review + deletion	Annual
Marketing email list	Promotional communications	Until consent withdrawn + 30 days	Consent (Section 6)	None	Automated upon withdrawal	Monthly
Support ticket data	Issue resolution	2 years post-resolution	Consent or legitimate use	None	Automated deletion	Quarterly
Website analytics data	Traffic analysis, UX improvement	14-26 months	Consent (Section 6)	None	Platform auto-deletion	Quarterly
Job applicant data	Recruitment	12 months after hiring decision	Consent (Section 6)	None	Automated deletion	Monthly
CCTV footage (digitised)	Security monitoring	60-90 days	Legitimate use (Section 7(d))	None	Automated overwrite	Monthly
Access logs	Security, audit compliance	1 year minimum	DPDP Rules 2025	CERT-In (180 days rolling)	Automated rotation	Quarterly

Step 6: Implement Deletion Mechanisms

A retention schedule without enforcement is paperwork. You need actual deletion mechanisms.

Automated deletion is the gold standard. Configure your systems to flag or delete records when retention periods expire. Most modern databases, CRMs, and cloud storage platforms support time-based lifecycle rules. Set them.

Scheduled manual reviews work for lower-volume data categories where automated deletion is impractical. Assign a quarterly review cadence with a named owner.

Cascading deletion is the part most teams miss. When you delete data from your primary system, does it also get deleted from backups, analytics exports, development environments, email archives, and processor systems? Your deletion process must cascade to every location where the data exists. Under Section 8(7), the obligation extends to ensuring your Data Processors also erase the data.

For guidance on how this fits into your broader compliance infrastructure, see the DPDP compliance checklist, specifically Steps 12 and 15.

What Happens When a Data Principal Withdraws Consent?

Consent withdrawal triggers an independent erasure obligation under Section 8(7), separate from the purpose-based trigger. When a Data Principal withdraws consent, you must erase their personal data regardless of whether the original purpose has been fulfilled.

The process should work as follows:

1. Receive the withdrawal request through your DSR intake channel.
2. Verify the identity of the Data Principal making the request.
3. Check for sectoral law overrides. If any portion of the data must be retained under another law (tax records, KYC data), document the specific legal basis and retain only that portion.
4. Erase all data not subject to a legal retention override. This includes data in primary systems, backups, processor systems, and any derived datasets.
5. Notify the Data Principal of what was erased and what was retained (with the legal basis for retention).
6. Log the entire action with timestamps, data categories affected, and the identity of the person who executed the deletion.

The key mistake I see: treating consent withdrawal as a request to "stop processing" when it legally requires erasure. Archiving data and stopping active use is not deletion. The Act says "erase," and that means the data should no longer exist in any retrievable form.

There is a practical tension here. If your backup retention cycle is 30 days, data deleted from production will still exist in backups for up to 30 days. Document this lag in your privacy notice and ensure the backup copy is purged in the next cycle. Regulators understand that instantaneous deletion from every system is technically impractical; what they will not accept is an indefinite backup retention that effectively nullifies the deletion.

What About the 48-Hour Pre-Erasure Notice?

The DPDP Rules 2025 require Data Fiduciaries to notify Data Principals at least 48 hours before erasing their personal data when the retention period expires. This applies in two specific contexts:

1. Large platforms under the Third Schedule, where the 3-year inactivity trigger activates. Before deleting an inactive user's data, the platform must send a notice and wait 48 hours.
2. Purpose-based erasure for any Data Fiduciary, where the retention period you defined in your retention schedule has expired. Before executing the deletion, notify the Data Principal.

The notice should include:

• A clear statement that personal data will be erased
• The specific data categories to be erased
• The reason for erasure (purpose fulfilled, inactivity period reached)
• How the Data Principal can respond if they wish to retain their account or data
• A 48-hour window to respond before erasure is executed

If the Data Principal responds within 48 hours with a request to retain the data, you must pause the erasure and document the interaction. If there is no response, proceed with deletion and log the action.

Common Mistakes in DPDP Data Retention

Having reviewed data retention practices at multiple organisations, these are the patterns that consistently create compliance risk:

Retaining everything "just in case." This is the most common default. Companies collect personal data, never define a retention period, and the data accumulates indefinitely. Under Section 8(7), indefinite retention without a defined purpose is non-compliant. Every data category needs a defined endpoint.

Confusing archival with deletion. Moving data to a cold storage tier or marking it as "archived" is not erasure. If the data is still retrievable, it has not been deleted under the Act. Proper erasure means the data is no longer accessible in any form.

Ignoring backups. Production databases get purged. Backups do not. If your backup retention policy is 90 days, every piece of deleted data still exists for 90 days after deletion. This does not make you non-compliant by itself, but you must document the backup lifecycle and ensure deleted data is purged from backups in the next cycle.

Not accounting for processor systems. When you delete data from your systems, your Data Processors may still hold copies. Section 8(7) places the erasure obligation on the Data Fiduciary, and that extends to ensuring processors delete the data as well. Your data processing agreements should specify deletion procedures and timelines.

Setting retention periods without legal review. An engineering team sets a 90-day retention for customer transaction data, not realising that GST law requires 6-year retention of invoice records. Or a legal team mandates 7-year retention of all customer data without considering that most data categories have no sectoral retention requirement and should be deleted much sooner. Both the legal and technical teams need to collaborate on the retention schedule.

No automated enforcement. A retention policy document in a shared drive is not a retention mechanism. Without automated deletion rules in your actual systems, data accumulates regardless of what your policy says. Someone leaves the company, the spreadsheet tracking manual deletions gets abandoned, and a year later you are sitting on data you should have deleted nine months ago.

Frequently Asked Questions

What is the default retention period under the DPDP Act?

The DPDP Act 2023 does not prescribe a single default retention period for all personal data. Section 8(7) establishes a principle: erase personal data when the purpose for which it was collected is no longer being served, or when the Data Principal withdraws consent, whichever is earlier. The specific retention period depends on the processing purpose and any applicable sectoral law. For access logs, the DPDP Rules 2025 set a minimum of 1 year. For large platform user data, the maximum is 3 years from last interaction. For all other data, you must define a purpose-based retention period and document it.

Can I keep customer data after they close their account?

It depends on what the data is and whether a sectoral law requires its retention. For example, purchase transaction records may need to be retained for 6 years under GST law, and KYC records for 5 years under RBI directions, even after the account is closed. However, data that serves no ongoing legal or statutory purpose, such as browsing history, marketing preferences, or support chat transcripts, must be erased once the account relationship ends (plus any reasonable processing buffer you have disclosed in your privacy notice). Document the legal basis for any post-account-closure retention in your retention schedule.

What is the penalty for retaining personal data too long under DPDP?

Retaining personal data beyond its lawful retention period is a breach of Section 8(7). Under the penalty schedule of the DPDP Act 2023, this falls under "breach of any other provision" carrying a maximum penalty of ₹50 crore per violation. If the retained data is subsequently compromised in a breach, the penalty exposure escalates to ₹250 crore for failure to implement reasonable security safeguards. The Data Protection Board has discretion over the actual penalty amount, considering factors such as the nature and duration of the violation and efforts by the Data Fiduciary to mitigate damage.

How do I handle data retention when multiple laws apply?

Apply the longest legally mandated period. If the DPDP Act says "erase when done" but the Income Tax Act requires 6 years of retention for financial records, retain the data for 6 years. Document the specific sectoral law and provision that justifies the extended retention. When the sectoral retention period expires and no other legal basis remains, erase the data. Your retention schedule should list the applicable law for every data category where a sectoral override exists.

Do I need to notify users before deleting their data?

As of April 2026, the DPDP Rules 2025 require a 48-hour pre-erasure notice to Data Principals before the completion of the data retention period. This is explicitly mandated for large platforms under the Third Schedule when the 3-year inactivity trigger activates. For other Data Fiduciaries, the notice requirement applies before executing purpose-based erasure. The notice must give the Data Principal an opportunity to respond before deletion proceeds.

Simplify Your DPDP Compliance

This article is for informational purposes and reflects the DPDP Act 2023 and DPDP Rules 2025 as understood at the time of writing. For guidance specific to your business, we recommend consulting a qualified data protection professional.

Building a retention schedule is one piece. Enforcing it across consent records, customer data, employee records, and third-party processors requires systems that track retention periods, trigger deletion workflows, and maintain audit-ready logs. ComplyZero handles this as part of a single self-serve platform: automated retention tracking, consent management, DSR workflows, and compliance records designed for Indian businesses.

Join the Waitlist →