How to Handle a DPDP Data Deletion Request Without a Compliance Team

What the law asks you to do

The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025, and the Data Protection Board of India already exists. The main obligations for businesses, including the rights that let people ask for their data to be erased, start 18 months after notification, which is around 13 May 2027. You do not have to be fully ready today, but you do need the process in place before that date, and a workflow built now is cheaper than one rushed in 2027.

The erasure duty itself sits in Section 12 of the Act. A person who gave consent can ask you to erase their personal data, and you must do so unless keeping it is necessary for the purpose it was collected for or a law requires you to keep it. In practice, the trigger is usually one of two things: the person withdraws consent, or the purpose has ended, such as a finished order or a closed account. Your job is to check which of the two exceptions applies before you delete anything.

Timing is where sources disagree, and you should know the disagreement before you write your internal rules. The Act sets no fixed period for access, correction, erasure or nomination requests. The Rules set a 90-day outer limit for grievances. One explainer reads that 90-day limit as applying only to grievances. Another guide says requests to complete an erasure should also be finished within 90 days, and says a seven-day acknowledgement is required. Neither reading is settled in the text we could check, so the safe course is to treat 90 days as the ceiling for any request and set a shorter target for yourself. As a working rule, we would acknowledge each request within a week and aim to finish within 30 days, then document any case that runs longer.

Two more operational points matter. First, the Rules require you to publish how a person can make a request and which identifiers you need to find their records, so the intake channel is part of the legal duty, not just a convenience. Second, the erasure duty reaches the vendors and processors who hold data for you. If your payroll bureau, email marketing tool or cloud CRM keeps a copy, they must act on your instruction as well.

Why this problem costs money

The biggest direct exposure is the penalty schedule. Failing to honour access, correction, erasure or grievance rights can attract a maximum penalty of up to 50 crore rupees under the Schedule to the Act. That is a ceiling, not a fixed fine. The Data Protection Board sets the actual amount by looking at factors such as how serious the failure was and how long it lasted, which is why a documented, consistent process matters more than a perfect one.

The more common cost is staff time, and it is worth putting a number on it. Before you buy anything, time your next few requests. My planning assumption is that a single request touches four to six systems, such as a CRM, a billing or accounts ledger, an email tool, a support inbox, a WhatsApp number and a vendor. Finding the records, checking the retention question, deleting, and writing the proof usually takes 45 minutes to two hours when it is done by hand. This is an estimate, not a survey figure. Test it against your own log. At 20 requests a month, that range becomes roughly 15 to 40 hours of a person's time every month, and that work often lands on the owner or the office manager.

The third cost is error. A deletion that misses a backup, a WhatsApp export or a vendor copy leaves the data in place while your records say it is gone. A deletion that removes a record you must keep, such as an invoice that GST rules require you to retain, creates a tax problem. Both errors are much more likely when requests sit in a shared inbox and nobody owns the decision.

The manual way and the automated way

The table below compares how the same request is handled in a manual setup and in a workflow that connects your intake channels, a register and your systems.

Step-by-step: setting up the workflow

Step 1: Publish one intake route and stop accepting requests anywhere else

Choose one web form, one email address and, if your customers use WhatsApp heavily, one WhatsApp Business number. Google Forms, Zoho Forms or the form tool in your CRM will all work for the web version. Put the link in your privacy notice and on your website footer, because the Rules expect the request route to be visible. Tell staff that a request sent to a personal phone or a sales rep's inbox still counts, and must be forwarded to the register within a working day.

WhatsApp deserves care. The WhatsApp Business Platform can send messages to a webhook when a customer writes, which lets a workflow tool create a case automatically. Outside the 24-hour customer service window, however, you can only send approved message templates, so plan your acknowledgement message as a template in advance.

Step 2: Open a case in a register the moment a request arrives

Use one register. A shared spreadsheet is enough for low volume. A ticket tool such as Zoho Desk or a CRM case object works better once requests are frequent. Each case needs a request ID, received date, channel, the type of request (access, correction, erasure, nomination or grievance), and the due dates. Keep the register lean. It should record what was asked and what was done, not copy the personal data itself. That keeps the log from becoming a second copy of the data you are trying to delete.

Step 3: Verify the requester before you touch any record

Verification is the step most likely to go wrong. Send a one-time code to the mobile number or email address already on your file, and only proceed when the code is entered. If the request comes from a nominee or a representative, ask for proof of the nomination and of the nominee's identity. Avoid asking for national identity numbers in email. Where an identity document must be uploaded, optical character recognition tools such as Google Cloud Document AI or Tesseract can read the name and number to match against your file, but the image should be deleted after the check and the check should be logged. A language model can help classify the request and draft the acknowledgement, yet a person should approve every outgoing reply.

Step 4: Start the clock and tell the person what happens next

Send the acknowledgement in the same channel the request came in on. It should give the request ID, say what you are checking, and state the date by which you expect to finish. Set the internal target in the register. Once a case passes the halfway point without a decision, the workflow should alert the owner. If a case has to be extended, record the reason and tell the person in writing. Avoid quietly letting a case sit open.

Step 5: Route the case to each system owner

Keep a simple map of where personal data lives: CRM, billing and accounts, email marketing, support desk, WhatsApp exports, shared drives, HR files and each vendor. Assign an owner to each system. When a case opens, the workflow creates one task per system, with the identifiers needed to find the person's records. For a consent withdrawal, the same person's data may also sit in a marketing tool, an analytics platform or a third-party enrichment vendor, and each of those copies must be handled.

Step 6: Decide retention before anyone presses delete

This is where most small businesses get stuck, so give it a named approver. For accounts and billing, that is usually your accountant. Invoices, GST records and payment entries in Tally Prime, Zoho Books or a similar ledger often have to be kept for a set period under tax law. Your accountant may tell you to keep the transaction but erase or mask the contact details that are not needed for the tax record. UPI payment history follows the same logic. The case record should state which rule you relied on, in plain words, so that a future reviewer can follow it.

Step 7: Delete, confirm, and keep the proof

Each system owner deletes or masks the data and marks the task as done with a date and a note. Backups and archives need a plan too. Erasure across replicas, backups and derived datasets is engineering work, not a single click, so write down the rule you apply, such as overwriting backups on their normal cycle and blocking restores of erased records. Where a vendor holds data, send them the instruction in writing and file their confirmation. When every task is complete, send the closing message and set the case to closed.

Step 8: Keep an audit trail that a stranger could read

An audit trail is a time-stamped list of what was asked, who checked the identity, what decision was taken and why, which systems were touched, who approved each step and when the reply was sent. Store it apart from the personal data itself. Keep it for as long as your retention policy says, and review it once a quarter. The trail is what protects you if a person complains to the Board, which is why the rules on grievances matter here. A record that shows a clear process is far easier to defend than a memory.

What breaks and how to prevent it

Most failures in this workflow are predictable, and each one has a simple control.

• A copy survives in a backup, a WhatsApp export or a laptop. Prevent it by listing those locations in your system map and adding them to the task list for every case.
• The wrong person is verified. Prevent it by never confirming a deletion by phone alone and by checking the one-time code against the contact on file.
• A record that tax law requires you to keep is deleted. Prevent it by making retention a separate approval step with your accountant named.
• A consent withdrawal is handled in one tool but not in the others. Prevent it by treating every withdrawal as a case that creates tasks for each system.
• A deadline is missed because the request sat in a shared inbox. Prevent it by creating the case automatically and sending reminders to the owner.
• A language model drafts a reply that misstates the law or promises something you cannot do. Prevent it by requiring a person to approve every reply before it leaves.
• Vendors are never told. Prevent it by adding a deletion-support clause to every contract that touches personal data, and by filing each vendor's confirmation.

When not to automate

Automation is not worth building for every business. If you receive only a handful of requests a year, a printed checklist and a spreadsheet will serve you better than a connected workflow, and the time spent setting up the connections will exceed the time saved for years. If your personal data sits mostly in paper files or on staff phones, fix that first, because a workflow cannot reach data it cannot see. If a request comes with a legal notice, a dispute, or a request from an authority, stop the workflow and hand the case to a lawyer. Automation cannot decide what the law requires you to keep, and it cannot take responsibility for a legal judgement. It can only make sure the question gets asked, recorded and answered on time.

What it typically takes

The cost to you is mostly owner and staff time rather than money for tools, and the time depends on how many systems you have. For a small business with one CRM, one accounts ledger and one email tool, a first version is usually a matter of a few weeks of part-time work. That covers writing the intake route and privacy notice text, mapping systems, creating the register and running three test cases with dummy data. A larger business with many systems and vendors needs a longer mapping exercise, and the mapping is the part that takes the most effort. Start with the mapping now, while the duties are not yet enforceable, so that the process is already tested when May 2027 arrives.