---
title: "Handling GDPR erasure requests across the store, helpdesk and email tools"
description: "A GDPR erasure request is a customer asking an online store to delete their personal data. We stop marketing to that person within the hour, map every system that holds a copy, delete only by exact keys, and install a deletion ledger before deleting anything, because nightly syncs rebuild what you erase. Some records, such as invoices, must be kept by law, so the reply never says 'we deleted everything'. This is our working method, not legal advice."
date: 2026-10-11
lang: en
canonical: https://goingstellar.ro/methods/gdpr-erasure-requests-store-helpdesk-email/
author: Going Stellar
publisher: GOING STELLAR S.R.L.
topic: E-commerce / Privacy
license: CC BY 4.0
alternate_ro: https://goingstellar.ro/ro/metode/cereri-gdpr-de-stergere-magazin-helpdesk-email/
---

# Handling GDPR erasure requests across the store, helpdesk and email tools

*A GDPR erasure request is a customer asking an online store to delete their personal data. We stop marketing to that person within the hour, map every system that holds a copy, delete only by exact keys, and install a deletion ledger before deleting anything, because nightly syncs rebuild what you erase. Some records, such as invoices, must be kept by law, so the reply never says "we deleted everything". This is our working method, not legal advice.*

> E-commerce · Privacy · 2026-10-11 · https://goingstellar.ro/methods/gdpr-erasure-requests-store-helpdesk-email/

## Key points

- Stopping marketing is the first step of a GDPR erasure request, because Article 21(3) requires direct marketing to stop and does not get the one-month response period of Article 12(3).
- Suppress the person in both the email platform and the store's marketing consent, or a later sync can subscribe them again.
- Write the deletion into a ledger that re-applies after every sync before deleting anything, because downstream copies are rebuilt from the source.
- Delete only by exact keys written down before the first query, never by name, because a common surname matches many different people.
- Never tell the customer "we deleted everything": absence cannot be proven, and invoices must be kept by law.

## What to do when a customer asks you to delete their data

A GDPR erasure request is a customer exercising the right to erasure under Article 17 of the GDPR: asking a business to delete the personal data it holds about them. The order that works for an online store is: stop all marketing to that person first, within the hour; confirm identity without collecting more data; map every system that holds a copy; register the deletion in a ledger that re-applies it after each sync; delete by exact keys only; keep what the law requires; and tell the customer precisely what was deleted, what was kept and until when.

This article describes how we handle erasure requests for online stores, written after a real case in which every trap below was actually hit. It is not legal advice. The legal references are the ones our own playbook records for Romanian stores, and the playbook itself warns against citing retention periods from memory: check the law in force.

## Step 1: stop marketing before anything else

Stopping marketing is the first action, before triage or inventory. Article 21(3) of the GDPR requires processing for direct marketing to stop when the person objects, and it does not benefit from the one-month response period of Article 12(3).

In our real case the customer received a promotional email 2 hours 37 minutes after asking for erasure, and opened it. Nobody had been careless. There was simply no connection between the helpdesk ticket and the email platform. Suppress the person at both ends: in the email platform, and in the store's marketing consent, because the email platform's consent record had been created by the store's customer webhook and a re-sync could subscribe the person again.

Check every tool that sends messages on its own schedule. Our review app had no API for suppressing a person; we tried nine plausible endpoint names and all returned 404, so it had to be blocked by hand in its dashboard. Review requests typically go out 15 to 30 days after delivery, so a review request could otherwise arrive just after the written confirmation that messages had stopped.

## Step 2: confirm identity without collecting more data

When the erasure request comes from the same email address as the order, and the name or phone number matches, that is a reasonable identity check under Article 12(6). Asking for a copy of an identity document collects more data than the request needs, which conflicts with the data-minimisation principle in Article 5(1)(c), and it delays the answer.

The response deadline is one month from receipt under Article 12(3). Record the exact time the request arrived; the marketing incident above is measured from it.

## Step 3: map every place the customer's data lives

A customer's personal data in a small e-commerce business is spread over far more systems than the store. Our map for one customer covered: the store platform (customer record, orders, several copies of each address, IP address and fraud-risk scores); the email platform (profile, events, predictive scores); the helpdesk (profile, conversations, internal notes, and an order-status link carrying a secret key); the data warehouse (orders with a full raw JSON copy of each order, plus per-customer aggregates such as refusal scores); the shipping database; the order management system; profitability databases with about 28 backup tables inside the live database; local mirror databases; call recordings from the phone system; error-monitoring breadcrumbs that held order payloads; and spreadsheets and shared storage.

Three categories are easy to miss: raw JSON columns that hold a full copy of the order, archive tables inside a live database that no redaction procedure touches, and call recordings. Blind indexes, which are hashes of phone numbers or emails used for lookups, are personal data too: they let anyone test a guess, so they must be cleared.

## Step 4: install the deletion ledger before deleting

A deletion in a downstream copy is overwritten by the next sync unless the sync knows about it. In our setup the store feeds the warehouse, which feeds derived caches rebuilt several times a day, and the courier sync refills shipping data over a 90-day window. Without a ledger, a deletion was undone within 24 hours.

So the order is: write the request into a deletion ledger first, then delete. Small jobs re-apply the ledger every hour in each database, matching only exact keys from the ledger, never names. The jobs print nothing when there is nothing to re-apply, so any line in their log means a real resurrection, and the jobs double as monitoring. We accept them only after three consecutive silent runs.

The store platform itself refused to redact orders from the last 6 months, so the source stays live for months. We still filed the platform's official erasure request, which starts the clock. The proof of erasure is not the delete statement; it is the check the next day that the rows did not come back.

## Step 5: keep what the law requires, and say so

An erasure request does not override legal retention duties, and the reply should say which records stay and why. For Romanian stores our playbook records: invoices kept 5 years under Law 82/1991 Article 25 as amended by Law 36/2023 (the older period was 10 years, and language models still quote it); a copy of each invoice held by the tax authority's national e-invoicing system, where the store has no right to delete; the delivery record as a supporting document; the contractual core for 3 years; the legal conformity guarantee for 2 years from delivery; and the 14-day withdrawal period.

The withdrawal period deserves a sentence in the reply. If the request arrives inside those 14 days, a complete erasure leaves the store unable to process a return for the same person, which is against the customer's own interest. The marketing exclusion entry is also kept, isolated, because it is what stops future sends. Check every retention period against the law in force; this list is not legal advice.

## The traps we hit, and how we catch them now

**Namesakes.** For a common surname, one search returned 16 different people in one database and 11 in another. Deleting by name destroys someone else's data and turns one resolved request into two breaches. We write the list of allowed keys before the first query and never leave it; never a `LIKE '%name%'`.

**A zero without a positive control.** An empty result can come from a wrong filter, an encrypted column, missing access or a scope that does not cover the case. A shared folder of 18 files had no orders at all, so its zero came from coverage, not absence. A spreadsheet of 75,000 orders did not contain the customer because it stopped 6 months earlier. The first check of one server reported no tables because the database command-line tool was not installed; reading the file another way found the data in 3 tables. First prove that the method finds some other person.

**Encrypted columns.** Fields encrypted with a random IV never match a `WHERE` clause, and they fail silently as zero rows. Fetch the rows by order identifier and filter after decryption.

**No delete operation.** Our order management system's API had no delete operation in any of its 151 paths, and its only address write would have pushed changes to the store and every connected app. We cleaned its database directly instead.

## Where we were wrong, and what the reply must not say

Our first reply draft was invalidated by three facts we had not seen from the code: the request had never reached marketing, two sync loops would rebuild the deleted rows, and complete erasure was legally impossible. We learned the method from that case.

The rules for the reply: never write "we deleted everything", because absence cannot be proven, only what was deleted. Do not claim recipients were notified unless they were. If an email went out after the request, say so; the platform's logs are as available to an investigator as they are to you. Separate what you verified from what someone told you. Tell the customer they can complain to the national data protection authority.

The audit itself creates copies: API response caches, transcripts, exports. Purge the raw dumps at the end, keep the working file as evidence of a correct process, and never put real customer data into documentation, which is how data leaks.

## Limits and checklist

Some things a store cannot close alone. Shared storage and spreadsheets can only be declared clean for the files actually enumerated, because an access token often sees only the files its own app created. Signed public links to invoices or labels can only be invalidated by the vendor that issued them; if the vendor cannot, document the limitation instead of hiding it.

**1.** Suppress marketing everywhere, at both ends, within the hour. **2.** Check identity from the order email; do not ask for ID. **3.** Map every system, including raw JSON, archive tables, recordings and blind indexes. **4.** Ledger first, delete second, exact keys only. **5.** Verify the next day that nothing came back. **6.** List what is kept, under which law, until when. **7.** Never write "we deleted everything".

## Questions and answers

### What should an online store do first when a customer asks to delete their data?

The first step is to stop all marketing to that person, within the hour, before any triage. Article 21(3) of the GDPR requires direct marketing to stop and does not get the one-month period that applies to the rest of the request. Suppress the person in the email platform and in the store's own marketing consent, and block any review-request or SMS tool that sends on its own schedule. This is not legal advice.

### Can a store delete all of a customer's data under GDPR?

A store usually cannot delete everything, because legal retention duties override the erasure request for some records. For Romanian stores our playbook records invoices kept 5 years under Law 82/1991 as amended by Law 36/2023, a copy in the national e-invoicing system that the store cannot delete, and the conformity guarantee for 2 years from delivery. The reply should list what is kept, why and until when. Check the law in force.

### Why does deleted customer data reappear after a GDPR deletion?

Deleted customer data reappears because downstream databases are rebuilt from the source by scheduled syncs. If the store still holds the order, the next sync into the warehouse or shipping database restores the deleted rows, in our case within 24 hours. Register the request in a deletion ledger first, run jobs that re-apply it after every sync, and confirm the next day that the rows did not come back.

### Do I need to ask for an ID card to verify a GDPR erasure request?

An ID card is usually unnecessary. When the request comes from the same email address as the order and the name or phone number matches, that is a reasonable identity check under Article 12(6). Asking for an identity document collects more data than the request needs, which conflicts with data minimisation in Article 5(1)(c), and it delays the answer. This is our practice, not legal advice.

### How do I avoid deleting the wrong person's data during a GDPR request?

Avoid deleting the wrong person by writing down the exact keys allowed for deletion, such as specific order numbers, the customer identifier, the email and the phone number, before the first query, and never matching by name. In our case one common surname matched 16 different people in one database and 11 in another. Also prove that each search can find someone else before trusting a zero result.

## How to cite

**Cite this as:** Going Stellar (2026). *Handling GDPR erasure requests across the store, helpdesk and email tools*. GOING STELLAR S.R.L.. https://goingstellar.ro/methods/gdpr-erasure-requests-store-helpdesk-email/

```bibtex
@misc{goingstellar2026gdpr,
  title  = {Handling GDPR erasure requests across the store, helpdesk and email tools},
  author = {{Going Stellar}},
  year   = {2026},
  url    = {https://goingstellar.ro/methods/gdpr-erasure-requests-store-helpdesk-email/},
  note   = {2026-10-11}
}
```

Licence. Free to quote with attribution.

## Also available

- This page as HTML: https://goingstellar.ro/methods/gdpr-erasure-requests-store-helpdesk-email/
- Same article in Romanian: https://goingstellar.ro/ro/metode/cereri-gdpr-de-stergere-magazin-helpdesk-email/