Data deletion
Data deletion for DPDP requests
A deletion request only counts if the data is actually gone from the systems that hold it. This page is the operational view: intake, verification, fulfilment, and evidence.
What a deletion request involves
The same loop every time, in order:
- Recognise the request wherever it arrives—email, form, support ticket.
- Verify it is really the person, before you touch anything.
- Find every place the subject's data lives.
- Delete it for real, across every system, in the right order.
- Record what ran and what happened.
Why manual deletion breaks
It works once, in one table, for one person. Then it stops scaling:
- Requests sit in inboxes and tickets, unacknowledged and untracked.
- Each deletion is one-off SQL with no review and no rollback.
- Foreign keys and shared tables mean deleting a row can break the app.
- There is no trail, so 'what happened?' has no answer later.
- The engineer who knew where data lived moves on.
The timeline you are actually on
DPDP enforcement is expected from around May 2027, with penalties up to ₹250 crore per violation. The pressure is not the law text—it is operating deletion correctly at volume before a request you cannot answer shows up. Start with the workflow, not the deadline.
How Erasure fits
Erasure's Rights product turns the loop into tracked work items:
- OTP-verified public intake so you don't open cases for emails nobody controls.
- Cases with a status and an activity trail, not email threads.
- Data Maps scope what gets deleted vs skipped before anything runs.
- Durable jobs run deletion across connected systems, with retries.
- Honest outcomes—completed, failed, or partial—plus exportable evidence.
Read more
Deleting a User's Data from MySQL: Dependency Order and Transactions
MySQL has its own traps when you delete one user's data—no deferrable foreign keys, the FOREIGN_KEY_CHECKS footgun, and InnoDB locking. Here is the safe order.
How to Delete a User's Data from PostgreSQL Without Breaking the Database
Deleting one user's data from Postgres means finding every table that references them, handling foreign keys in the right order, and running a safe parameterized DELETE. Here is the working method.
Webhook Retries and Idempotency for Deletion Workflows
When a deletion job depends on webhooks, retries are guaranteed and duplicates are certain. An idempotency key and a signature check are what keep the system safe.
Soft Delete vs Hard Delete for Privacy Requests
A soft-deleted row is still data. For privacy deletion requests, the flag that hides it is not the same as the deletion a regulator can see. Here is when each makes sense.
The Real Cost of Manual DSAR Processing (and What Automation Changes)
Manually processing a data subject request averages over $1,400 in staff time per Gartner estimates. Here is the cost model, and what automation changes for Indian startups.
How to Handle Data Deletion Requests: An Operational Guide for Startups
A practical workflow for handling data deletion requests in an Indian startup: intake, verification, fulfilment across systems, timelines, and evidence. No compliance team required.
Docs
What this does not solve
Rights handles DELETE first; ACCESS and CORRECT request types are planned, not shipped. Deletion runs against the systems you connect—today that is Postgres, MySQL, HTTP, and Webhook. Erasure does not guarantee compliance or file regulatory notifications.
Invite-only beta
Try it on your own stack
Erasure is invite-only in beta. Request an invite and we will walk you through the parts that matter for your product.