Data Retention and Erasure Under DPDPA

Data retention and erasure under the DPDPA represent one of the most operationally complex compliance challenges facing Indian organisations. Section 8(7) establishes the foundational principle: personal data must be erased when the Data Principal ceases to be a customer or withdraws consent, unless retention is required by another law. Section 12(3) grants Data Principals the right to request erasure of their personal data. However, the intersection of these erasure obligations with India's extensive sectoral retention requirements — RBI record-keeping, Companies Act document preservation, Income Tax Act assessment periods, SEBI transaction records — creates a compliance matrix that demands granular, data-element-level retention policies rather than blanket organisational approaches.

The DPDPA creates two distinct erasure triggers. Section 8(7) is a proactive obligation: the Data Fiduciary must erase personal data when the processing purpose is no longer being served and the Data Principal has ceased to be a customer or has withdrawn consent. This obligation does not require a Data Principal request — it is an automatic duty triggered by relationship cessation. Section 12(3) is a reactive right: the Data Principal may request erasure of personal data, and the Data Fiduciary must comply unless a legal retention obligation applies. The interaction between these provisions means that organisations face erasure obligations from two directions simultaneously. The Section 8(7) obligation requires proactive data lifecycle management — organisations must know when relationships end and when processing purposes cease. The Section 12(3) right requires responsive infrastructure — organisations must be able to locate, evaluate, and erase specific data elements upon request. Both obligations are subject to the same exception: retention required for compliance with any law for the time being in force.

India's regulatory landscape imposes retention obligations that directly intersect with DPDPA erasure requirements. The RBI Master Directions require banks and NBFCs to retain KYC records for five years after business relationship cessation. The Companies Act 2013 mandates preservation of books of account for eight financial years. The Income Tax Act 1961 requires maintenance of books for six years from the end of the relevant assessment year. SEBI regulations mandate transaction record retention for specified periods. The Information Technology (Reasonable Security Practices) Rules contemplate data retention for purposes of legal proceedings. The Telecom Regulatory Authority guidelines specify call detail record retention periods. Each of these sectoral requirements creates a lawful retention basis under Section 8(7)'s exception. However, the retention basis is data-element-specific, not blanket: a bank may retain KYC documents for five years, but this does not authorise retention of all personal data collected during the banking relationship. Organisations must conduct data-element-level mapping to identify which specific data elements are covered by which retention law, and erase everything else.

Implementing DPDPA-compliant retention requires a three-layer approach. First, a data inventory that maps every personal data element to its processing purpose, legal basis, and applicable retention law. Second, a retention schedule that specifies, for each data element, the retention period, the triggering event for retention commencement, and the applicable law authorising retention beyond the DPDPA erasure obligation. Third, technical erasure capability that can execute element-level deletion across all systems — production databases, analytics platforms, backup systems, disaster recovery environments, and processor systems under Section 8(2). Technical erasure presents particular challenges for backup systems: organisations typically cannot delete individual records from backup tapes or immutable storage. Compliant approaches include: (a) encryption-based erasure where the encryption key is destroyed; (b) backup retention policies that ensure complete rotation within a defined period; or (c) documented compensating controls where immediate erasure is technically infeasible. The CERT-In Directions 2022 requirement to retain log data for 180 days adds another layer: system logs containing personal data metadata must be included in the erasure framework.

Every erasure decision — whether proactive under Section 8(7) or responsive under Section 12(3) — must be documented with: the data elements erased, the systems from which erasure was executed, the date and method of erasure, any data elements retained with the specific legal basis for retention, and the expected retention end date for retained elements. This documentation serves multiple purposes: it demonstrates compliance to the Data Protection Board, provides evidence in response to Data Principal queries, and creates an audit trail for the independent data auditor required under Section 10(2) for Significant Data Fiduciaries. Where an erasure request under Section 12(3) is partially denied due to legal retention obligations, the Data Fiduciary must communicate to the Data Principal: which data has been erased, which data is being retained, the legal basis for retention, and the expected retention period. Failure to provide this communication may itself constitute a grievance under Section 13, escalating the matter to the Board. The most compliance-resilient organisations implement automated retention enforcement: systems that automatically flag data reaching retention expiry, initiate erasure workflows, and generate compliance documentation without manual intervention.