Data deletion requests: there is no one button

A customer writes in and asks you to delete everything you hold on her. The instinct is to look for a button. There is no button. What there is, in a normal Indian D2C stack, is the same person sitting in eight or nine systems under slightly different keys, and two or three of those systems are not yours.

Where the customer actually lives

Write the list before you need it. In most brands it looks like this. The storefront holds the account, the saved addresses and a payment token. The order management system holds every order line and usually a second copy of the address. The 3PL and the courier hold a real name, a working phone number and a full address, because a parcel cannot move without them. The WhatsApp or SMS provider holds the number and the message history. The reviews tool holds a display name and often an email. The support desk holds the entire conversation, including whatever the customer pasted into it. The accounting system holds the invoice. And somebody on the growth team has a CSV on a laptop from a campaign eighteen months ago.

That last one is the one that ruins the exercise, because nobody remembers it exists. Local exports are the same problem as unrevoked logins, and the fix is the same discipline you should already be running when someone leaves the team. The inventory of connected systems people build during an OMS cutover is usually the closest thing a brand already has to a data map. Start from that and add the tools nobody classes as systems.

What you can delete and what you have to keep

The Act gives a person the right to ask for erasure, and says the fiduciary shall erase unless retention is necessary for the specified purpose or for compliance with any law in force. That is section 12(3) of the Digital Personal Data Protection Act, 2023, read from the Act text published on meity.gov.in. The Act itself illustrates the exception with a bank that has to keep client identity records for years after an account closes.

Your accounting and tax records sit in that exception. Do not guess the number of years. Get it from the person who signs your returns, write it into the retention table once, and stop relitigating it per request.

There is a second keep-it rule that surprises engineers. Rule 8(3) of the Digital Personal Data Protection Rules, 2025, notified as G.S.R. 846(E) on 13 November 2025, requires a fiduciary to retain personal data, associated traffic data and processing logs for a minimum of one year from the date of processing, then erase, unless another law requires longer. The illustration printed in the Rules is an e-commerce example: the platform keeps the order confirmation, payment and delivery events for at least a year from the transaction even if the customer deletes her account. So the honest answer to a deletion request is rarely that everything is gone. It is that the account and the marketing profile are gone, and the transaction record stays for the period the law sets.

The clock, and who starts it

Rule 14(1) of the Rules requires you to publish the means by which a person makes a rights request and the particulars you need to identify her. Rule 9 requires you to publish the business contact of a Data Protection Officer if one applies, or of a person who can answer questions about processing, and to repeat that contact in every response to a rights request. Both are website work, done once.

On timing, be careful with the numbers you have read elsewhere. Rule 14(3) sets an outer bound of ninety days on the grievance redressal system. The Rules do not set a separate published deadline for a plain deletion request, so the exact figure you commit to depends on how the Rules as notified are read, and ninety days is a ceiling on grievances rather than a service level to aim at. Most of these requests can be closed inside a working week. Say so on your page and then hold to it.

Whoever answers your support queue will receive the request, because that is the inbox printed on the invoice. That person needs a script, not a lawyer. The same routing thinking you use for support across channels applies here: one owner, one queue, one template.

Log it or it did not happen

One row per request. Ticket reference, date received, how you confirmed identity, every system touched, what was erased, what was retained and the reason, date closed, who signed it off. Keep it boring and keep it in one sheet. Rule 6 of the Rules already expects logs and monitoring that let you detect and investigate unauthorised access, and expects those logs held for a year. A deletion log is cheap insurance in the same drawer.

Remember the downstream leg. The Act requires a fiduciary to cause its processor to erase personal data it made available for processing. That means a written instruction to the 3PL and the messaging provider, and a reply you keep. Your messaging vendor holds numbers you sent it for order and refund notifications, and it will not clean up on its own.

Do the three artefacts now

Build the system map. Decide the retention rule for each system in advance, in one table, approved once. Write the exception list, which is the short set of things you will not delete and the reason for each. Three documents, one afternoon, and the first request stops being an emergency.

One more reason to do it early. The bulk of the operating rules, including the ones on notice, security, erasure periods and rights requests, come into force eighteen months after the date the Rules are published in the Official Gazette. That is preparation time, and it is the only kind you get.

This is operational guidance and not legal advice. Your counsel signs the retention table.