> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to handle data deletion requests properly
- URL: https://blog.jestor.com/handle-data-deletion-requests/
- Published: 2026-09-16T18:54:47.000Z
- Updated: 2026-09-16T18:54:47.000Z
- Author: Bruno Bannach

Handling **data deletion requests** requires a process, because deletion is irreversible and partial deletion is often the correct outcome. In **Jestor**, the request is a tracked record with verification, a decision about what must be retained, and evidence of what was done.

## Why ad hoc deletion is risky in both directions

Deleting everything on request can breach a retention obligation, since some records must be kept for a defined period regardless of preference.

Deleting nothing, or losing the request, creates a different problem. Both outcomes come from treating deletion as a task rather than a process.

What a structured process provides:

- Verification that the requester is who they claim
- A decision about what must be retained and why
- Evidence of what was deleted and when
- A response within the required timeframe
- Consistency across requests

## What to decide per request

| Question                  | Why it matters                                        |
| ------------------------- | ----------------------------------------------------- |
| Is the requester verified | Deleting on an unverified request is its own breach   |
| What data exists          | It is usually spread across processes                 |
| What must be retained     | Legal and contractual obligations override preference |
| What can be deleted       | The actual scope of the action                        |
| What was done             | Evidence of compliance                                |
| Response deadline         | Usually defined by regulation                         |

## Step by step to handle one

1. **Log the request** with its date, which starts the response clock.
2. **Verify the requester** before acting on anything.
3. **Locate the data**, across every process that holds it.
4. **Identify retention obligations**, and document them.
5. **Delete what can be deleted**, and anonymize where retention applies.
6. **Record what was done** as evidence.
7. **Respond to the requester**, explaining what was retained and why.

## Why explaining retention improves the response

A requester told only that their data was deleted, and who later sees their name on an invoice, will assume bad faith. Explaining that certain records are retained under a legal obligation, with the period stated, converts a potential complaint into an acceptable answer.

## Why choose Jestor

In **Jestor**, requests run as a tracked process with **SLA** for the response deadline, permissions restrict who can perform deletions, the history records what was done and by whom, and deletions of structural items require an emailed confirmation code, which is a deliberate barrier against irreversible mistakes.

## Frequently Asked Questions

### Should everything be deleted on request?

No. Some records carry retention obligations that override preference. See [jestor.com](https://www.jestor.com/?ref=blog.jestor.com).

### What should be verified first?

The identity of the requester, before any action is taken.

### What should the response say?

What was deleted, what was retained and the reason for the retention.

## Video Tutorial: Step by Step

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by **AI**. Discover Jestor at [jestor.com](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.