Deletion requests when your CRM is a sheet

Please delete all the data you hold about me. It arrives without warning, usually with no reference number, sometimes from an address that does not match anything you can find.

The panic is unnecessary. For a business whose leads live in a spreadsheet, this is a short task. The reason it feels alarming is that most people have never done it once, so there is no routine to fall back on.

Building the routine takes about an hour and makes every future request a ten-minute job.

It is also worth knowing that the volume is low. Most small businesses receive a handful of these in a year, often prompted by a person tidying up their own exposure rather than by any dissatisfaction with you. Treating the first one as an opportunity to build the process, rather than as an incident, is the difference between an hour spent once and an hour spent every time.

This is a working explanation for people who run websites, not legal advice. If your processing is unusual or high-risk, take proper advice.

You should not delete records on the strength of an unverified email, and you should not demand a passport either. The standard is reasonable measures proportionate to the request.

For contact form data, replying to the address held on the record is usually sufficient and elegant: it confirms control of the address without collecting anything new. If the request arrives from a different address claiming to be the same person, ask for something that ties the two together, such as the date and subject of the original enquiry.

Be careful not to turn verification into an obstacle course. An excessive identity process is itself a compliance problem, and it reads as obstruction to the person on the other end.

This is the step that takes the time, and it is the reason to do the mapping exercise before you ever receive a request.

Search the spreadsheet for the address and the name separately, because people submit under variations. Search your inbox, because notification emails are copies. Search any CRM, help desk or mailing platform. Check whether the person appears in an export that still exists.

The uncomfortable discovery for many businesses is how many places one enquiry ended up. That count is the real output of a first deletion request, and it usually leads to reducing the number of copies long before the next one arrives.

Erasure is not absolute. Data needed for a legal obligation, for establishing or defending legal claims, or for a contract still in force can generally be retained, and so can a minimal suppression record.

That last one matters practically. If you delete every trace of someone who asked not to be contacted, nothing stops them being re-added when they appear in a future import. Keeping a minimal record of the request itself, enough to honour it, is normally the right call.

Where you keep something, be able to say why. One sentence per category is enough: invoices retained for tax purposes, suppression entry retained to honour the objection.

What you cannot do is keep the record because it might be commercially useful later. That is precisely the interest erasure is designed to override, and citing it in a response is the fastest way to turn a routine request into a complaint.

The mechanics are dull, which is the goal. Filter for the person, confirm the rows are theirs, delete them, and note the action.

Two cautions. First, deleting a row in a shared sheet is immediately visible to anyone with access and recoverable from version history, so if the request concerns something sensitive, be aware that history retains it for a period. Second, if anything downstream references specific cells, deleting rows can break it, which is a good reason for downstream tools to reference the sheet rather than fixed positions.

A common refinement is to blank the identifying columns rather than delete the row, keeping the date and the source so monthly counts stay accurate. That satisfies erasure as long as the remaining data cannot identify the person.

Every notification email is a copy, and they are scattered across whoever was on the distribution. Searching your own mailbox is easy; being sure about a colleague's is not.

The practical approach is to search the shared mailbox thoroughly, ask individuals to search theirs, and reduce the problem structurally afterwards. A pipeline where the notification is a pointer rather than the record leaves far less to clean up, because the email says a submission arrived rather than reproducing all of it.

This is one of the quieter arguments for keeping notifications brief.

Backups will contain the data and cannot usually be edited. The accepted approach is to delete from live systems, record that the data remains in backups, and ensure it is not restored into live use.

Do not claim more than you have done. Telling someone every trace has been erased when a backup will hold it for another ninety days is a worse answer than explaining the position plainly.

If your backup retention is indefinite, that is worth fixing for its own sake, and it is the same conversation as retention on live data.

The deadline is generally one month from receipt, extendable in limited circumstances for complex requests. Most contact form requests are not complex.

The response should confirm what was done, name anything retained and why, and state that the person can complain to a supervisory authority if unhappy. Three short paragraphs.

Keep a log of requests received and actions taken. It is the evidence that your process exists, and after the third entry it also becomes the training material for whoever handles the next one.

1. Verify the requester proportionately, ideally by replying to the address on file.
2. Search every location on your data map, not just the spreadsheet.
3. Delete or anonymise, keeping only what you can justify.
4. Record what you kept and why.
5. Reply within a month, plainly.
6. Log the request.

Written down once, this stops being a compliance event and becomes a task.

Every difficulty in a deletion request traces back to the same cause: the same enquiry existing in several places. The legal test is easy; the archaeology is not.

Which makes the strongest preparation an architectural one. When submissions land in one spreadsheet with notifications acting as alerts rather than copies, the answer to what do you hold about me is one search, and you can give it with confidence.

That confidence is worth more than the time it saves. The tone of a response to a data request is read closely by the person who sent it, and a prompt, specific reply defuses situations that a vague one escalates. Being able to say precisely what you held, what you deleted and what remains, on the day you receive the request, is the whole difference.

How long do I have to respond?

Can I refuse a deletion request?

Do I have to delete the notification emails too?

What about backups I cannot edit?

Is blanking the identifying columns enough?

Can I keep a record that they asked to be deleted?

What if I cannot find them?

Do I need a formal process document for this?