Right to Erasure Under DPDP: How Deletion Requests Actually Work

The right to erasure under Section 12 of India's DPDP Act is the operational heart of the law. A data principal can request deletion of their personal data, and the fiduciary must act. The interesting part, and the part most companies are unprepared for, is what "acting" means when the data lives in six systems and nobody has a map.

This post walks through a deletion request end to end: how it arrives, how it gets verified, what fulfilment actually involves, and what evidence looks like. It is not legal advice; it is the workflow, in the form a product team can build against.

Where requests come from

A deletion request can arrive through any channel:

• An in-app flow the product provides
• Email to support or privacy@
• A form on the website
• (Future) a consent manager channel under the DPDP ecosystem

The first design decision is not which channel to build first; it is how to recognise a request in any channel. An email that says "delete my account and everything about me" is a legal event. If it lands in a shared inbox and gets replied to next week by someone who forwards it to engineering, you have already lost the timeline.

Verification: knowing it is really the person

Before acting on a request, the fiduciary should verify the requester is who they claim to be. The DPDP context makes this non-optional in practice: you do not want to delete one user's data because someone else impersonated them.

Verification methods scale with sensitivity:

• Email OTP for account-linked requests
• More factors for sensitive data (health, financial)
• Operator-initiated verification for requests that arrive through odd channels

Erasure's Rights product uses an OTP intake path: the subject proves control of their email, then the request enters the system as verified. The verification step is recorded, because the evidence trail starts here.

Fulfilment: the part nobody is ready for

Fulfilment is where deletion requests die in most companies. A verified request needs to be executed across every system holding the person's data:

1. The primary application database
2. Supporting databases and replicas
3. Caches and search indexes
4. Third-party SaaS tools that were handed the data
5. Logs and backups, per your retention policy

The honest truth is that most companies cannot do this today because they do not know where the data lives. This is the data inventory problem, and it is why a deletion workflow and a data map are two halves of one system.

For systems you control, fulfilment means real deletion: rows removed or anonymized per policy, not soft-deleted and forgotten. Erasure runs durable jobs against connected systems, Postgres, MySQL, HTTP APIs, and webhooks, with outcomes recorded honestly: completed, failed, or partial. A failed deletion is recorded as failed, which is uncomfortable and correct.

The timeline

The DPDP Act does not hand you unlimited time. The Rules frame breach notification at 72 hours, and rights requests carry their own operational expectation of timeliness. The practical design goal is a request workflow with visible status and a clock: received, verified, in progress, completed.

Status tracking matters for two reasons. It keeps the team honest about SLAs, and it produces the audit trail the evidence requirement needs.

Evidence: what you can show afterward

When the request is done, the question becomes "can you show what you did?" Evidence for a deletion request includes:

• The request itself and how it arrived
• The verification proof
• The list of systems acted upon
• The outcome per system, with timestamps
• The job records and activity trail

Erasure packages this into exportable evidence: a structured record of the case, the actions, and the outcomes. The point is not paperwork for its own sake; it is that a regulator, a customer, or a court asking "what happened here" gets a coherent answer instead of a shrug.

What breaks in practice

The failure modes are depressingly consistent across companies:

• Requests arrive in unstructured channels and get lost
• Verification is skipped, so deletion becomes a data-security risk
• The team does not know all the systems holding the data
• Deletion is soft, so the data survives in backups and indexes
• No record exists of what was done

Every one of these is fixable with machinery, which is the entire reason Erasure exists. The platform turns the workflow into a repeatable system: intake, OTP verification, data maps, durable jobs, activity, and evidence.

The workflow in one picture

A deletion request under DPDP, done properly:

Subject requests deletion
        ↓
Identity verified (OTP or equivalent)
        ↓
Case created with status and timeline
        ↓
Systems identified via data maps
        ↓
Durable jobs run against each system
        ↓
Outcomes recorded honestly (completed/failed/partial)
        ↓
Evidence package exportable

The data mapping post covers the inventory half of this, and the compliance checklist places deletion in the full DPDP work list.

The bottom line

The right to erasure is not a form; it is a workflow with verification, multi-system execution, honest outcomes, and evidence. Companies that treat it as a support ticket will be overwhelmed by the first dozen requests. Companies that build the machinery will find it is the same work every time, which is the point of infrastructure.

Erasure is in invite-only beta; request access or read the deletion docs to see how the workflow is structured.