Deleting data when a customer asks

A customer data deletion request means one thing in practice: find every copy of that person's data — database rows, backups, logs, caches, exports and third-party tools — erase or anonymise it within the legal deadline, keep only what retention rules genuinely require, and confirm the result in writing. The delete button is the easy part; the copies are the work.

Key Takeaways

Processing a deletion request means tracing one person's data through five places: the live database, backups, application and server logs, caches and search indexes, and third-party processors. GDPR gives you one month; other laws differ. Verify the requester through the account itself, document every step, and keep only what a retention rule genuinely requires.

• The visible profile is a fraction of the data — backups, logs, caches, exports and third-party tools hold fragments you must handle too.
• Verify through the account itself: a logged-in session or a signed link to the address on file, never data read back to a stranger.
• Inventory before you delete; the gaps in the inventory are where requests fail.
• Some data stays: invoices and accounting records usually survive, redacted rather than erased.
• Give backups a written strategy — expire on rotation, restore-and-scrub, or crypto-shred.
• Document every step: who asked, what you checked, what you removed, what you kept, when you confirmed.

What is a customer data deletion request?

A customer data deletion request is a formal, often legally backed ask to erase a named person's personal data and confirm the result. GDPR calls it the right to erasure; Nepal's Individual Privacy Act 2075 and California's CCPA grant similar rights. Copies count as much as the visible profile.

Personal data means more than names and emails: phone numbers, addresses, IP addresses, support transcripts and device identifiers usually qualify. Requests arrive by email, ticket or app form, and they do not have to cite any law to be valid. We are engineers, not lawyers — get the legal boundaries confirmed by someone qualified. The engineering job is the same everywhere: locate, erase or anonymise, prove it.

Why is deleting one customer so hard in production?

Deleting a customer is hard because the profile you can see is a fraction of what exists. Nightly database dumps, NGINX access logs, Redis caches, analytics events, mailing-list records and exported spreadsheets all retain fragments, and the request is only done when each one is handled.

The primary delete has traps of its own. In Postgres or MySQL, a row referenced by orders, tickets and audit tables cannot simply vanish; ON DELETE CASCADE will happily take two years of legitimate order history with it. Read PostgreSQL's DELETE documentation before trusting a cascade in production, and rehearse on a staging copy first. On WordPress, core has shipped personal-data export and erasure tools under Tools in the admin since 4.9.6 — WordPress documents the erasure flow and plugin hooks in its plugin privacy handbook, so start there before writing anything custom.

When can you refuse a deletion request?

You can refuse, or partially refuse, when a specific obligation requires the data to stay: tax and accounting law, an active contract, an unresolved legal claim or fraud prevention. Name the exemption, keep only what it covers, and explain the rest — you cannot refuse simply because deletion is inconvenient.

Three edge cases catch teams out. If the data is already gone, you can reply saying so — but check properly first. Under GDPR the response is normally free, so charging a fee to deter requests is its own risk. And former employees make these requests too; the same workflow applies.

How do you process a customer data deletion request?

Process every request through the same six steps so nothing depends on who is on duty: receive, verify, inventory, check exceptions, erase and propagate, confirm. GDPR gives one month from receipt, extendable by two for complex cases — tell the person if you use the extension.

1. Log the request and its date. The deadline starts at receipt, and you will need the record as evidence later.
2. Verify who is asking. A logged-in session or a signed link to the address on file works; never read personal data back to an unverified sender.
3. Inventory before touching anything.Map where the data actually lives across your stack, then list every system that stores or forwards it.
4. Check retention exceptions. Paid invoices, tax records and active contracts usually stay. Decide per record: delete it, or redact the identity and keep the business record.
5. Erase and propagate. Run the delete or anonymisation in a reviewed transaction, purge caches, forward the request to every processor, and decide what backups will do. When paid invoices must stay, anonymise instead:

-- Anonymise a customer whose paid invoices we must keep.
-- Irreversible: check the WHERE clause and take a backup first.
UPDATE customers
SET name  = 'Removed',
    email = 'deleted+' || id || '@example.invalid',
    phone = NULL
WHERE id = 412;

That statement permanently overwrites a real customer record — confirm the ID and have a verified backup before running anything like it in production.

6. Confirm in writing. List what was deleted, what was kept and under which rule, then file it with the request.

Where does customer data hide besides the database?

Copies of customer data collect in five places teams routinely miss: database replicas and dumps, application and web-server logs, caches and search indexes, third-party processors, and ad-hoc exports. Walk the full list for every request — a deletion that stops at the primary database is not finished.

Logs deserve a policy rather than per-request surgery: keep access logs short, 30 to 90 days is common, let them age out, and say so in your confirmation. Third parties — payment processors, mailing lists, analytics, support desks — must be notified in writing; keep their replies. Exports are the quiet failure: the CSV someone downloaded in March still holds everything, and the spreadsheets that grow beside every system are where we most often find forgotten data.

What do you do about backups you cannot edit?

Handle backups with one of three deliberate strategies: let the copy expire on its normal rotation, restore it and scrub the person's data before re-archiving, or encrypt per customer and destroy that customer's key — crypto-shredding. Write the choice down; an undocumented backup policy is how audits go bad.

Crypto-shredding only works if per-customer encryption existed before the data was written, so you cannot retrofit it onto old dumps. Restore-and-scrub costs hours of engineer time per request — sensible for rare requests, painful at volume. For most small systems, expiry on rotation is the honest answer, provided you can state the date the last copy dies. With a 35-day rotation, that is roughly five weeks out.

Hardening the workflow: how do you make the next request routine?

Make deletion routine by treating it as a product feature, not a favour: a current inventory, a written retention schedule per data type, an erase path in the codebase and one named owner. Collect less up front — a field you never collected never needs deleting. The cost of a request is engineer hours, not software.

How do you verify a deletion request is complete?

Verify by searching each system for the person's email and phone, running a password reset against the old address, and checking vendor dashboards show the record gone. Note the backup expiry date in your written confirmation so the remaining tail is stated, not hidden.

• Primary database: the row is gone or anonymised; invoice history intact.
• Cache and search index: a lookup by the identifier returns nothing.
• Vendors: written confirmation from each processor, filed with the request.

What are the most common mistakes with deletion requests?

Most deletion failures are organisational rather than technical: the visible database row goes, victory is declared, and every other copy survives untouched. Each mistake below has turned up in a real request, and each is cheap to prevent with a checklist.

• Trusting ON DELETE CASCADE and destroying invoice history the business still needs.
• Purging the database but leaving the session cache, so the profile lingers on screen.
• Saying "deleted" while nightly backups hold the data for weeks, with no expiry date offered.
• Reading personal data back to an unverified caller — a gift to social engineers.

Which deletion approach fits which data?

Match the approach to the data type: hard delete anything with no retention duty, anonymise records the law keeps, let backups and logs expire on rotation, and reserve crypto-shredding for systems designed with per-customer keys from day one. Most small systems need only the first three.

Approach	What it does	Fits when	Main risk
Hard delete	Rows removed in a reviewed transaction	No retention duty applies	A cascade removes records you needed
Anonymise	Identity overwritten, business record kept	Paid invoices, tax records	Free-text fields still naming the person
Retention expiry	Copies age out on their normal rotation	Backups, logs, small systems	Nobody can state the expiry date
Crypto-shred	Per-customer key destroyed, data unreadable	Built in from day one	Retrofitting it onto existing dumps

What does a real request look like end to end?

A customer of a Nepali online store emails asking you to delete their account and personal data. The store logs and verifies the request, cleans the live systems within days, discloses the backup tail, and closes the file when the oldest backup expires.

1. Day 0: request logged with its timestamp; identity confirmed by a signed link to the registered email.
2. Day 1: the customer row anonymised in Postgres, orders kept under "Removed"; Redis session keys purged; the built-in erasure tool run where the store is WooCommerce.
3. Day 2: the erasure forwarded in writing to the payment processor and the mailing list.
4. Day 3: checks run — a password reset finds no account, a system-wide search finds nothing — and a confirmation email lists what stayed (paid invoices) and when backups expire.

In short: verify who is asking, trace every copy — database, backups, logs, caches, vendors, exports — delete or anonymise what you can, disclose the backup expiry, keep only what the law requires, and file written confirmation. Then make the next request routine with a current inventory and a retention schedule.

People also search for

These are the questions readers type next: where the data actually lives, how much to collect in the first place, how long records must stay, and how a customer portal changes the picture. Each item links to a live guide on this blog.

• Where is customer data actually stored in a small business?
• How much customer data should a website collect?
• How do you clean customer data before a migration?
• When does a business need a customer portal?
• What is the GDPR right to erasure?
• How long should a business keep customer records?

If a deletion request has just landed and you are not certain where the copies live, our team can help you map the data, set a retention schedule and build the erase path into the system — custom web application, WordPress site or the hosting underneath. Contact us for a review, or see our full range of services first.