How to Handle Data Deletion Requests: An Operational Guide for Startups

A data deletion request arrives in your support inbox on a Tuesday. What happens next determines whether you are running privacy operations or playing whack-a-mole. This guide is the operational workflow we recommend to startups, the one that works without a dedicated compliance team.

The DPDP Act's right to erasure makes this a legal workflow, and the penalty regime gives it teeth. But the mechanics are pure operations: intake, verification, fulfilment, record. Here is each step, with the practical details that make it work.

Step 1: Recognise the request everywhere

Deletion requests do not arrive in a labelled envelope. They come through support email, in-app forms, social media DMs, and legal letters. The first failure mode is not recognising a request when you see one.

Set up a single intake point, even if it is just an alias, and train everyone that "delete my data," "remove my account and everything," and "erase me from your systems" are legal events, not feature requests.

Step 2: Verify before you act

Verify the requester controls the identity they are asking to delete. For account-based requests, an email OTP or a signed-in session is enough for most products. For sensitive data, health or financial, add a factor.

Verification is not bureaucracy; it is the difference between fulfilling a request and leaking one user's data to an impersonator. Record the verification step; it is part of the evidence trail.

Step 3: Create a case with a status

Every request becomes a tracked case: received, verified, in progress, completed. The status gives you three things at once: a timeline you can manage, visibility for the requester, and an audit trail for later.

A shared spreadsheet technically works at low volume. It breaks at the point where two requests arrive in a day and each touches five systems. The tooling decision is really a decision about when you stop trusting the spreadsheet.

Step 4: Find the data (this is where it gets real)

Fulfilment requires knowing where the person's data lives:

• Primary database tables
• Supporting services and their stores
• Caches, indexes, and queues
• Third-party tools that received the data
• Logs and backups, within your retention policy

If you cannot list these from memory, the request is going to involve archaeology. This is the data inventory problem, and it is the reason deletion and data mapping are one system, not two. A data map records which tables hold personal data and what the identifiers are, so a deletion request becomes a lookup instead of an investigation.

Step 5: Delete for real, everywhere

Execute the deletion across every system in the map. Real deletion means:

• Rows removed or anonymized per your policy
• Caches and indexes updated, not just the source of truth
• Third-party systems told to delete (or a documented basis for why you cannot)
• Backups handled per retention policy, not silently kept forever

Soft deletion is the classic trap: the row gets a flag, the data survives, and a future export or breach reveals it. If your policy says deleted means deleted, the implementation has to match.

Step 6: Record what happened

When the work is done, produce the record: the request, the verification, the systems acted on, the outcomes, the timestamps. This is the evidence. Under DPDP's evidence orientation, the record is the deliverable, and the deletion is the means to it.

Erasure records outcomes honestly: completed, failed, or partial. If a connector failed and the data survived, the case shows it. That honesty is uncomfortable and necessary; it is what makes the record defensible.

The workflow in practice

Request arrives (any channel)
        ↓
Single intake point
        ↓
Verification (OTP / session / extra factor)
        ↓
Case created with status + timeline
        ↓
Data map lookup: which systems hold this person's data
        ↓
Durable jobs run against each system
        ↓
Outcomes recorded: completed / failed / partial
        ↓
Evidence package exportable

What this costs

The honest cost breakdown for a startup:

• Manual processing at low volume: a few hours per request, assuming you know where the data lives
• Manual processing without a data map: days per request, plus the risk of missing a system
• Tooled processing: minutes per request, with a record every time

The Gartner figure gets cited a lot here: manually processing a data subject request averages over $1,400 in staff time. At Indian startup volumes, the absolute cost is lower, but the shape is the same: manual scales linearly and badly. Our DSAR cost post does the math.

When to build vs buy

Build the workflow yourself if you have one database, a handful of requests a year, and an engineer who enjoys writing bespoke SQL. Buy or use infrastructure when any of these is true: data in multiple systems, request volume beyond a trickle, or a regulator-adjacent sector where evidence quality matters.

Erasure is the infrastructure path: Rights for the case lifecycle with OTP verification, Data Maps for inventory, Systems for durable fulfilment across Postgres, MySQL, HTTP, and Webhook, and Evidence for the exportable record. It is invite-only in beta with pricing from ₹0.

The bottom line

Deletion requests are not support tickets; they are legal workflows with verification, multi-system execution, and evidence. The startup that builds the six-step loop now will process its hundredth request with the same machinery as its first. The startup that improvises will rediscover the workflow every time, under time pressure, with a regulator's clock running.

The right to erasure guide covers the legal side in depth, and the compliance checklist slots this workflow into the full DPDP picture.