DPDP Act25 May 2026 9 min read

DPDP Act Storage Limitation: Data Retention Policy Guide

How to build a DPDP-compliant data retention policy — retention schedules, deletion workflows, and the storage limitation obligation under Section 8(7).

Key Takeaways

Section 8(7) requires Data Fiduciaries to erase personal data once the purpose for which it was collected is no longer being served.
A written data retention schedule specifying maximum retention periods for each data category is the first practical step toward compliance.
Automated deletion workflows are essential — manual processes fail at scale and cannot be audited reliably.
Legal hold provisions must be layered on top of retention schedules to prevent deletion of data subject to litigation or regulatory investigation.
Retention limits apply to backups, archives, and analytics data warehouses, not just primary production databases.

In this guide

Storage Limitation Under the DPDP Act
Section 8(7): The Erasure Obligation
Building a Data Retention Schedule
Reconciling Retention With Legal Obligations
Implementing Automated Deletion
Storage Limitation for Backups and Archives
Legal Hold Procedures
Monitoring and Auditing Retention Compliance

Storage Limitation Under the DPDP Act

Storage limitation is the principle that personal data should not be retained for longer than is necessary for the purpose for which it was collected. It is the temporal dimension of data minimisation: just as you should only collect what you need, you should only keep it for as long as you need it. Once the purpose has been fulfilled and no other legal basis exists to retain the data, it must be erased.

The DPDP Act 2023 makes storage limitation a statutory obligation. This is a significant departure from historical practice in Indian companies, where data was routinely retained indefinitely — either because deletion was not prioritised, or because data was seen as an asset whose future value was unknown. Under the Act, that approach carries legal risk.

Storage limitation is relevant across your entire data estate: production databases, data warehouses, analytical stores, log systems, email archives, file storage (S3 buckets, Google Drive), backups, and any third-party SaaS tools where personal data is stored. A comprehensive storage limitation programme must address all of these, not just your primary application database.

Section 8(7): The Erasure Obligation

Section 8(7) of the DPDP Act provides that a Data Fiduciary shall, unless retention is required or authorised by law, erase the personal data as soon as it is reasonable to assume that the specified purpose is no longer being served. The Act links this specifically to situations where the Data Principal has not approached the Fiduciary for goods or services — effectively meaning that inactive accounts and lapsed customer relationships trigger an erasure obligation.

The Act does not specify fixed retention periods — it takes a purpose-based approach. The DPDP Rules are expected to provide further guidance, potentially specifying retention periods for certain categories of data. Until the Rules are finalised, companies must determine appropriate periods based on the purpose served, legal requirements, and business necessity.

Importantly, Section 8(7) applies automatically — you do not need to wait for a Data Principal to exercise their right to erasure under Section 12. The Fiduciary has a proactive obligation to delete data once the purpose is exhausted. This is different from how many companies currently operate (deleting only on request) and requires a systemic shift.

Building a Data Retention Schedule

A data retention schedule is a document that specifies, for each category of personal data held by your organisation, the retention period and the legal basis for that period. It is the foundation of your storage limitation compliance programme. Without it, you cannot implement consistent deletion, cannot answer Data Principal rights requests accurately, and cannot demonstrate compliance to the Data Protection Board.

For Indian SaaS companies, a practical retention schedule typically covers: active customer account data (retained for subscription duration + 90 days post-termination for billing dispute resolution); payment and transaction records (7 years as required by Indian tax and accounting law); support and helpdesk tickets (12 months post-resolution, or longer if the issue is part of ongoing litigation); marketing and analytics data (12-24 months from collection); employee HR records (per applicable labour law, typically 3-5 years post-employment); audit logs (3 years minimum to support potential Board investigations).

Retention periods should be informed by legal requirements from multiple sources: GST law (6-year record retention), Companies Act (various periods), SEBI regulations if applicable, RBI regulations if applicable, and industry-specific requirements. Where a legal obligation requires retention beyond what privacy principles would dictate, the legal obligation governs — but you should retain only what the law requires and delete everything else.

Reconciling Retention With Legal Obligations

Indian law imposes various record-keeping obligations that can conflict with data minimisation and storage limitation. The Companies Act 2013, Income Tax Act, GST Act, and sector-specific regulations (RBI for fintechs, SEBI for securities firms) each specify minimum retention periods for financial and operational records. These legal obligations override the storage limitation principle — the DPDP Act itself acknowledges that retention may continue where "required or authorised by law."

The key is to retain only what the specific law requires, not everything. If GST law requires you to keep invoices for 6 years, you should retain the invoice data (invoice number, transaction amount, GST components, counterparty details) for 6 years — but you do not need to retain the customer's browsing history, profile photo, or any other personal data collected during their relationship with you that is not required for GST compliance.

Create a matrix that maps each data category to any specific legal retention obligation. For data with no legal retention obligation, apply your purpose-based retention period. For data covered by a legal obligation, retain for the legal minimum and delete immediately thereafter. This matrix should be reviewed by legal counsel annually and updated when regulations change.

Implementing Automated Deletion

Manual data deletion processes are unreliable, unscalable, and inauditable. Automated deletion workflows — triggered by retention period expiry, account termination events, or consent withdrawal — are the only practical way to enforce storage limitation at scale. This requires engineering investment but is a compliance necessity under the DPDP Act.

Implement soft-delete first: when a user account is terminated or a retention period expires, mark records as scheduled for deletion and remove them from all application queries immediately. After a short grace period (30 days is typical, to allow for error recovery), run a hard-delete job that permanently purges the records from the database and cascades deletion to all related tables. Log the deletion events for audit purposes.

For data in secondary systems — data warehouses, analytics platforms, log aggregators — implement TTL (time-to-live) policies where the platform supports it, or scheduled deletion jobs. Tools like Apache Airflow or cloud-native scheduling services can run nightly or weekly deletion jobs against retention schedules. Ensure deletion from secondary systems is synchronised with primary database deletion to avoid data being recoverable from secondary sources after the primary record is deleted.

Storage Limitation for Backups and Archives

Backups present a specific challenge for storage limitation compliance. Database backups typically contain full snapshots of all data at a point in time, including records that have been subsequently deleted. If a backup is restored after a record has been deleted to comply with a retention period or an erasure request, the deleted data reappears — violating the storage limitation obligation.

Strategies to handle this include: (a) limiting backup retention periods so that no backup exists for longer than the shortest retention period of any data category it contains — impractical for most companies; (b) using application-level encryption with data-specific keys so that deleting the encryption key renders the data in backups permanently inaccessible (cryptographic erasure); (c) implementing incremental backup strategies that allow surgical deletion of specific records; (d) clearly documenting that backups are for disaster recovery purposes only and establishing controls preventing restoration of deleted records outside of a declared disaster recovery event.

Most Indian SaaS companies will find cryptographic erasure or backup retention limits to be the most practical approaches. Cryptographic erasure requires that the encryption key management be integrated with your deletion workflow — when a record is deleted, the associated key is deleted or rotated to a new version that the deleted record was not encrypted with.

Legal Hold Procedures

Automated deletion must be paused when data is subject to a legal hold — a formal preservation obligation triggered by litigation, a regulatory investigation, or a Board inquiry. Deleting data subject to a legal hold can constitute destruction of evidence and expose the company to serious legal consequences beyond DPDP penalties.

Establish a legal hold procedure that integrates with your retention management system. When in-house counsel or an external solicitor issues a legal hold notice, the IT team should be able to place a hold flag on all relevant data categories and custodians within 24 hours. Held data is excluded from automated deletion jobs until the hold is lifted.

Maintain a legal hold register that tracks: the case or matter reference, the date the hold was issued, the data categories and custodians covered, and the date the hold was lifted. Review outstanding holds quarterly to ensure holds are lifted promptly when the underlying matter is resolved — data should not remain on indefinite legal hold after the matter closes.

Monitoring and Auditing Retention Compliance

Storage limitation compliance should be monitored continuously, not just at policy creation. Implement dashboards that track: the volume of records by data category and age, the number of deletion jobs run and records deleted in the past period, any deletion failures or exceptions, and the status of backup retention.

Conduct a storage limitation audit annually that includes: reviewing the retention schedule against current processing activities, sampling records to verify they were deleted according to the schedule, reviewing deletion job logs for errors or missed runs, and confirming that backup retention policies are aligned with the schedule. Document the audit findings and any remediation items.

Connect your retention compliance monitoring to your DPDP compliance programme. AuditPath and similar platforms allow you to track retention policy controls and link evidence of deletion job execution to your compliance records. This creates the audit trail that the Data Protection Board may request during an inquiry.

Frequently Asked Questions

How long can we keep data for a churned SaaS customer under the DPDP Act?

There is no fixed period specified in the Act — it depends on the purpose. Typically: keep billing records for the legally required period (usually 6-7 years for Indian tax compliance), keep account data for a short period after termination to handle billing disputes (30-90 days is common), and delete all other personal data. Document the justification for whatever period you choose.

Does the storage limitation obligation apply to data we receive in inbound emails from customers?

Yes. Email containing personal data from customers is personal data under the DPDP Act. Email systems should be covered by your retention schedule — most companies retain business emails for 2-3 years. For customer support emails, align with your helpdesk ticket retention period. Configure email archiving systems to apply retention policies automatically.

Can we retain anonymised data indefinitely?

Yes. Truly anonymised data is not personal data under the DPDP Act, so storage limitation does not apply to it. If your analytics use case can be served with aggregate or anonymised data, anonymising rather than deleting may allow you to retain useful insights without holding personal data beyond its retention period.

We process data on behalf of our enterprise clients. Who is responsible for storage limitation?

Your enterprise clients are the Data Fiduciaries; you are the Data Processor. Storage limitation obligations under the Act fall primarily on the Data Fiduciary. However, your contracts with clients should specify retention periods and your obligation to delete data when instructed. You should implement technical controls to enforce those contractual commitments.

What evidence should we keep to prove we deleted data on time?

Maintain deletion logs that record: the data category, the retention period trigger event (e.g., account termination date), the deletion date, and the systems from which data was deleted. For bulk deletions, record the job run parameters and record counts. These logs should themselves have a defined retention period — typically 3-5 years to align with potential Board inquiry timelines.