Data Deletion Requests: Setting Up the Process While They Are Still Rare
A “delete my data” request arrives rarely. That is exactly why nobody prepares for it: with two such emails a year it seems easier to work it out on the spot. The problem surfaces the moment the email arrives, the response clock is already running, and nobody knows how many places that person’s data sits in.
A caveat: specific deadlines and obligations depend on your country and your status as a data controller. Check with a lawyer. What follows is the organisational part, worth doing in advance regardless of jurisdiction.
What a person can ask for
Deletion is only one option, and not the most common.
| Request | What it means | Difficulty |
|---|---|---|
| Access | Show me what data you hold about me | Medium: must be gathered from every system |
| Rectification | You have the wrong phone number | Low |
| Erasure | Remove everything | High: copies are scattered |
| Restriction | Keep it but stop using it | Medium |
| Portability | Give it to me in machine-readable form | Medium |
| Withdrawing consent | Stop sending me the newsletter | Low, if consents were separated |
The first row is underestimated. An access request takes more work than deletion: you must not simply remove but gather and present, in a comprehensible form.
Why the process is needed while requests are rare
Because it cannot be built in a day, and the main work is not technical.
Once a request arrives you have a limited window, and what has to be established is exactly what should have been known in advance: which systems hold personal data, who has access, whether it exists in backups, whether it was passed to contractors. The same inventory as a data storage map. Anyone who built that has already done half the work.
The hard part is finding every copy
One person’s data in a typical company sits in more than one place:
- The enquiry in the database.
- A duplicate in the mailbox that received the notification.
- A record in the CRM.
- Correspondence with a salesperson.
- A spreadsheet somebody exported for a report.
- Backups covering several months.
- The newsletter service.
- The support chat.
The last three are the most common reason “we deleted everything” turns out to be untrue. The exported spreadsheet especially: it takes on a life of its own and features in no process at all.
A six-step process
- Intake. One address or form, published in the privacy policy. Not “write to your account manager”: requests must land in one place rather than get lost in general email.
- Identity check. A sensible minimum: a reply from the same address or confirmation through the account. Demanding a scanned passport for a request to delete a phone number is excess that creates its own problem.
- Logging. Date, substance, response deadline. One spreadsheet is enough.
- Search across the system list. This is where the pre-built inventory works. Without it this step takes days.
- Execution and record. What was deleted, what was retained and on what basis.
- Reply to the person. In plain language, listing what was done.
What must not be deleted
An important part often forgotten: not all data is subject to deletion on request.
Documents you are legally required to retain, such as accounting, tax and contractual records, stay regardless of the request. The correct response here is not “we deleted everything” but an honest explanation: what was removed, what must be retained, for how long and on what basis.
This is where mistakes happen in both directions: either deleting what should have been kept, or refusing entirely instead of deleting the rest.
Backups are their own question
Deleting a record from a week-old backup is technically difficult, and sometimes impossible without restoring the whole set.
The practical approach generally accepted as reasonable: do not rewrite backups, but record that on any restore this data will be deleted again. Plus a limited retention period for the backups themselves, after which the question disappears by itself.
The key is not to stay silent about it. Explaining that data has been removed from live systems and will disappear from archives within a stated period is more honest and safer than claiming nothing remains.
How to prepare in one day
- List the systems holding personal data. The same list as for the storage map.
- Set up a dedicated address for these requests and publish it in the privacy policy.
- Name someone responsible. One person, not a department.
- Write a response template: received, we will process by this date.
- Create a four-column request log.
- Confirm with your accountant which documents cannot be deleted.
That is a few hours of work. When a request arrives you will spend half an hour on it instead of two days, and more importantly you will be able to answer with confidence rather than hoping nobody checks.
The paradox is that preparing for these requests pays off even if none arrive. That same system inventory is needed to understand where data is stored, to assess vendors, and for any conversation about security. One piece of work, three applications.
