The Digital Personal Data Protection Act 2023 grants a right to erasure, but it is conditional, narrower than GDPR's "right to be forgotten," and tied to specific legal triggers. GDPR Article 17 is broad: a data subject can demand deletion on grounds ranging from objection to processing, to withdrawal of consent, to simply deciding they no longer want their data held. Indian law does not replicate that breadth.

Section 12(3) of the DPDPA frames erasure differently. It is not a free-standing demand right. It sits within the Data Principal's right to correction and erasure, and its exercise is anchored to two conditions: withdrawal of consent, or cessation of the purpose for which the data was collected.

That distinction matters enormously. A GDPR erasure form ported into an Indian compliance workflow will accept requests that Section 12(3) does not support, and reject requests that Section 8(9) already mandates the fiduciary honour, even without the user asking.

What Section 12(3) Actually Grants Data Principals

The statutory text of Section 12(3) grants a Data Principal the right to erasure of personal data that is no longer necessary for the purpose for which it was collected, or where consent has been withdrawn.

Two entry points. Both require the fiduciary to act.

Section 6(4) is the first trigger. When a Data Principal withdraws consent, the data fiduciary must stop all processing tied to that consent. Withdrawal is not a request for the fiduciary to consider; it is a legal event that starts the erasure clock. The fiduciary has no discretion to continue processing because the data is "useful" or "already integrated into our systems."

Section 8(9) is the second, and it operates independently of the user doing anything at all. Once the purpose for which the data was collected is served or ceases to exist, the fiduciary is under a statutory obligation to erase that data. The user does not have to ask. The obligation is on the fiduciary to monitor purpose status and act.

A concrete example: an NBFC lending app collects income certificates, bank statements, and employment letters during loan appraisal. The loan application is rejected. The purpose of the credit assessment is complete. Under Section 8(9), the NBFC must erase those documents without waiting for the applicant to file a request. If the applicant does file under Section 12(3), the NBFC is already in breach if the data is still sitting in their document management system six months later.

This dual-track obligation: user-triggered and fiduciary-initiated, is the part most compliance frameworks miss.

The Four Scenarios Where Erasure Is Legitimate

Scenario 1: Consent Withdrawn (Section 6(4))

A user revokes marketing consent on a fintech app. Every downstream system that received data for marketing purposes, the CDP, the email marketing tool, the retargeting pixel data, and the third-party enrichment vendor must have that data deleted. The trigger is the withdrawal event, not a separate erasure request. The fiduciary's obligation begins at the moment of withdrawal.

Scenario 2: Purpose Fulfilled or Lapsed

A bank closes a savings account. KYC data collected at onboarding was collected for the purpose of maintaining that account. Once the account is closed and all statutory retention periods have elapsed, continued storage of that data has no valid purpose. A customer who closes their account and follows up 18 months later, demanding deletion of their KYC documents, is exercising a right that Section 12(3) supports, provided no legal retention mandate applies.

Scenario 3: Data Collected Without Valid Consent

Where data was collected without a valid consent notice under Section 5(1), no clear purpose statement, no language the user could understand, or consent bundled with terms of service, the collection itself is unlawful. Erasure in this scenario is immediate. There is no SLA grace period. The fiduciary cannot argue that they need 30 days to process the request. The data should not exist.

Scenario 4: Minor's Data Where Parental Consent Is Disputed (Section 9)

Section 9 requires verifiable parental consent before collecting a minor's personal data. A school edtech platform that enrolled a student with parental consent, and later faces a divorced parent contesting that consent, is in a difficult position. If the consent is successfully disputed or withdrawn by the guardian, the platform faces an erasure obligation on data tied to that consent. The minor's academic records may need to be separated from the personal data profile that the platform keeps for legal reasons; what must be deleted is a question of purpose mapping, not convenience.

When an Organization Can Lawfully Refuse

Refusal is legitimate in specific, documented circumstances. It is not a catch-all defence.

Legal retention obligations override user erasure requests: The RBI Master Direction on KYC (2016, updated through 2023) mandates that KYC records be maintained for five years after the business relationship ends. A bank customer demanding the deletion of their KYC documents cannot override this. The fiduciary must retain the data, but must also inform the user that their request is refused, state the legal basis, and record that exchange.

Active litigation or regulatory inquiry: SEBI-regulated entities such as brokers, AMCs, and portfolio managers must preserve trading records and client data for specified periods. If a SEBI enforcement action is underway involving a particular account, an erasure request from that account holder during that period is not actionable. Deleting the data at that point would itself be a compliance breach.

Section 17 exemptions: National security, law enforcement, and prevention of cognizable offences create a category where normal Data Principal rights do not apply. A telecom operator that has received a CERT-In advisory flagging an account for investigation cannot honour an erasure request from that account holder. The CERT-In direction takes precedence.

The Operational Reality: What Erasure Actually Requires

Here is where compliance frameworks meet infrastructure reality, and where most enterprises discover their exposure.

Personal data in a mid-size Indian enterprise does not live in one system. It lives in the CRM, the data warehouse, the backup snapshots, the email archive, the analytics database, the fraud detection model's training dataset, the third-party logistics partner's system, and the cold storage archive that hasn't been reviewed in three years.

Point-and-click deletion from the customer portal marks a record as deleted in the application layer. It does not touch the backup taken last Tuesday. It does not remove the row from the reporting warehouse that refreshes nightly. It does not notify the downstream analytics vendor.

An insurance company processing a health claim is a useful illustration of this complexity. That claim data exists in the core policy administration system, the TPA's system that adjudicated the claim, the fraud detection model's training data, the regulatory filing archive, and the encrypted cold storage backup. Each of those has a different deletion pathway. Some are owned by the fiduciary. Some are owned by third-party data processors. Each requires a separate execution step.

The DPDPA does not specify a numeric SLA for erasure in its final rules; those are yet to be notified. But Section 13 grievance timelines and MeitY's draft rules signal a 30-day expectation. At that scale, a manual process breaks. A compliance officer cannot track 200 concurrent erasure requests across 20 systems with a spreadsheet and email chains.

What a Compliant Erasure Workflow Looks Like

A defensible erasure workflow has six steps. Each is non-negotiable.

Step 1: Request receipt and identity verification: The Data Principal submits the erasure request. The fiduciary must verify identity before acting; a request from an unverified sender cannot trigger deletion of another person's data.

Step 2: Purpose and legal basis check: Before executing deletion, the fiduciary must determine whether a legal retention obligation applies. This check must happen before the erasure, not after.

Step 3: Downstream system mapping: Every system that holds data tied to this Data Principal and this purpose must be identified. This requires a live data map, not a document written during the last audit.

Step 4: Execution across all stores: Deletion executes across every mapped system,  primary, backup, archive, and downstream processors. Each execution must be confirmed, not assumed.

Step 5: Confirmation to the user: The Data Principal receives written confirmation that erasure was completed, specifying what was deleted and what was retained (and why, if a retention exception applies).

Step 6: Immutable audit log entry: Section 8(3) requires the fiduciary to demonstrate compliance. That demonstration requires a timestamped, tamper-proof log showing every step of the erasure workflow, the request, the verification, the legal basis check, the execution confirmation, and the user notification. Without that log, you cannot prove erasure happened. An auditor asking for proof of compliance on a disputed erasure request will accept nothing less.

The partial erasure scenario deserves explicit attention. A user has an active home loan but wants their marketing profile deleted. The loan-related data stays; there is a valid contractual and legal basis. The marketing segmentation data, the browsing behaviour data fed to the bank's CDP for cross-sell targeting, the email engagement history, that goes. The workflow must document exactly what was deleted, what was retained, and the legal basis for each decision.

Penalties and What Enforcement Will Look Like

Section 33 of the DPDPA sets the financial consequences clearly: failure to honour Data Principal rights attracts penalties of up to ₹250 crore per instance.

The Data Protection Board, once constituted, will have the authority to adjudicate complaints filed directly by Data Principals. A user who submits an erasure request, receives no response, and escalates to the Board creates a paper trail that the fiduciary must answer.

The precedent from GDPR enforcement on erasure failures is instructive. European banking regulators have imposed significant penalties on institutions that could not demonstrate complete erasure, cases where data persisted in backup systems or third-party processors after the primary deletion was confirmed. 

Frequently Asked Questions

Q: Does the DPDP Act's right to erasure apply to data collected before the Act came into force?

The Act does not contain explicit retroactive application provisions for erasure rights. However, once the Act is in force, fiduciaries will need to honour erasure requests for all data they hold, including data collected before commencement, where the processing continues. If you are actively processing pre-Act data based on consent collected under pre-Act standards, that consent needs re-examination. MeitY's final rules and the Board's guidance will clarify the retroactivity question, but preparing your data inventory now so you know what you hold and where, is the only defensible position.

Q: If a user withdraws consent but we have a legal obligation to retain the data (e.g., RBI KYC norms), do we still have to erase?

No, the legal retention obligation overrides the erasure request. RBI's Master Direction on KYC mandates retention for five years post-relationship. You must refuse the erasure request for KYC data, but you must do so in writing, stating the legal basis (the specific RBI directive), and informing the Data Principal of the grievance escalation path. Silence, or a generic "we cannot process this request," is not sufficient.

Q: What counts as valid identity verification before processing an erasure request? Can we use Aadhaar OTP?

Aadhaar-based authentication for private sector entities is governed by the Aadhaar Act and UIDAI regulations. Direct Aadhaar OTP verification is not available to most private sector fiduciaries. Acceptable identity verification for erasure requests includes verification against account credentials, registered mobile OTP, PAN-based verification where applicable, or video-based verification for high-risk requests. The verification method must be proportionate to the sensitivity of the data being deleted.

Q: Can a Data Principal demand erasure of data that has been anonymised?

No. Anonymised data, i.e., data processed so that the individual is no longer identifiable, falls outside the definition of personal data under the DPDPA. If the anonymisation is genuine and irreversible, the erasure right does not apply. The practical risk here is that most "anonymised" datasets are pseudonymised, not truly anonymised. If re-identification is technically feasible, the data is still personal data, and the erasure right applies.

Q: What happens if our third-party data processor (e.g., a cloud analytics vendor) cannot confirm deletion?

The fiduciary remains accountable. Section 8(2) requires fiduciaries to ensure their data processors act in accordance with the Act. A cloud vendor that cannot confirm deletion within the required timeline is a compliance gap that belongs to the fiduciary, not the vendor. Your processor agreements must include contractual erasure SLAs and technical confirmation mechanisms. If a vendor cannot provide deletion confirmation, the fiduciary must escalate that gap immediately — and document it as an unresolved exception in the audit log.

CoTrust by Digio maps every erasure request to its source systems, executes deletion across all connected stores, and generates the Section 8(3)-compliant audit log automatically.

This content is for informational purposes and does not constitute legal advice. Consult qualified legal professionals for advice specific to your circumstances.