Deleting a customer’s personal data under GDPR or CCPA means erasing it everywhere it’s stored — not just the primary database, but replicas, backups, caches, search indexes, logs, and every third-party tool that touched it — usually within 30 to 45 days of the request.

This guide covers what a genuine deletion request requires, what GDPR (Article 17) and CCPA (§1798.105) actually oblige you to do, where copies of personal data typically hide, and why backups and derived data (like AI/ML models trained on that data) make full erasure harder than a simple DELETE statement.

What counts as a ‘deletion request’ under GDPR and CCPA?

A deletion request means erasing a person’s data everywhere it is stored: primary tables, replicas, caches, logs, search indexes, backups, derived datasets, and third-party processors.

A soft-delete flag is not erasure. Backups usually cannot be edited record by record, so regulators accept putting them “beyond use” until they age out.

For data spread across many systems, crypto-shredding (encrypt per person, then destroy the key) is usually the most reliable way to make every copy unreadable at once.

GDPR & CCPA: what the law actually requires

Under the European Union’s General Data Protection Regulation (GDPR), Article 17 gives a person (the “data subject”) the right to erasure, aka “the right to be forgotten”.

The right to erasure is not an absolute right, however. It can be refused in circumstances where, for example, you’re legally required to keep the data for tax, accounting, or employment reasons. You can respond, but generally only have one month to do so (extendable by two more months for complex requests).

The only times the right to erasure applies with certainty is if, for example, the data is no longer needed for the purpose you collected it, or the person withdraws consent.

In California, meanwhile, a resident can request deletion of their data under Section 1798.105 of the California Consumer Privacy Act (CCPA).

The data holder has 45 days to comply (extendable by another 45).

Both of these laws push the obligation to the company liable for processing the personal data. They’re obligated to instruct all processors, service providers, and contractors to delete the data as well.

What happens if you don’t comply (real enforcement cases)

The penalties for breaking personal data laws are significant. Take the European Data Protection Board’s (EDPB) enforcement report on right to erasure, which found that Finland’s regulator fined a parking enforcement company for keeping data it no longer needed.

Meanwhile in the Netherlands, their regulator (Autoriteit Persoonsgegevens – AP), fined a recruitment firm €6,000 for not having a method in place to handle data removal requests.

And what about in California? Well, in January 2026, the CPPA fined a data broker $45,000 for operating without registering.

Why you can’t treat deletion exceptions as automatic

The EDPB found that certain companies treat exceptions as “automatic”. If you refuse a erasure request, you should document specific legal basis for the refusal – plus delete every part of the data that the exception does not cover.

You can’t delete what you can’t find: building a data map

Personal data is rarely all in one place. The data sits in obvious columns (name, email, phone), but also in free-text fields, JSON blobs, uploaded file attachments, log lines, and denormalized copies.

A person is not “living” in one row; their data is across many related records, in many related or unrelated places. The first step for organizing all this data is the creation of a data map.

A data map, in this instance, is an inventory of which tables and systems hold personal data. This includes information about what each field is, the legal basis for holding that data, and how long to keep it for.

Alternatively, the EDPB suggests creating a data-deletion matrix (or data retention schedule) that cross-indexes the type of data, legal basis, and retention periods.

For those familiar with SQL, our guide on building a privacy-aware analytics layer with SQL is a good place to start.

Why soft delete doesn’t satisfy GDPR or CCPA

In certain cases, applications do not perform a complete deletion. The application might instead put a deleted = true flag marking deletion, known as a soft delete.

Soft delete has its uses, especially for undo, auditing, and not breaking foreign keys. However, soft delete is not true erasure as required by GDPR and CCPA.

Similarly, some companies offer users the “delete your account” button while keeping the underlying records in internal systems, but this also does not satisfy GDPR and CCPA requirements.

The correct way to permanently erase personal data is with a hard delete, where the records (data) are fully removed. However, with this, we run into the issue of referential integrity. You may have deleted a customer row, but what if the data still exists in orders, invoices, and tickets?

To ensure referential integrity, the cascade delete is a viable option. It’s one single transaction which deletes the person and every dependent record in the correct order.

Where personal data copies actually live (and how to erase each)

Cascade deletes, however, only cover primary databases. Every day, we make tons of copies of data, and each individual copy requires deletion.

In more detail, here’s where copies of data live, why they exist, and how to erase the data to satisfy data privacy laws and regulation:

How crypto-shredding makes every copy unreadable at once

Crypto-shredding is the process of encrypting each person’s data with an encryption key unique to them. When they ask to be forgotten, you destroy the key.

The encrypted data still exists but is unreadable without the key. A common crypto-shredding design uses two layers (aka envelope encryption):

To delete a person, you delete their DEK. The catch with crypto-shredding is that your key store must never fail, leak, or lose a key by accident.

The blind spots: derived data and third-party processors

Derived data and third parties are two places where personal data is often not erased.

What is derived data?

Derived data includes recommendation models, machine-learning (AI) features, embeddings, and aggregate tables built from a person’s raw data.

What are third-party processors?

Third-party processors are any entity you share data with – from email and marketing platforms, to analytics, support desk, and customer relationship (CRM tools), to name a few.

Regulators like the GDPR and CCPA make company owners responsible for any data shared with a third-party processor.

That’s why, when you erase someone and their data, you must ensure that the same action is carried out by each of these third parties. It’s best to do this through their deletion API, if they have one (and keep any confirmation/evidence of this.)

How to find every copy of personal data without doing it manually

Most regulatory problems come from not knowing where individual personal data actually is, and how far it’s spread.

To help find and classify personal data, I recommend trying SQL Data Catalog – built to help you map and reduce the number of copies you have to find.

It does not, however, actually run an erasure process for you – this still has to be done yourself.

I’ll also shout out Data Masker, which replaces sensitive data in development and test databases (SQL Server and Oracle) with realistic but fake values, so your non-production environments hold no real people to forget in the first place. It integrates directly with Data Catalog, and both have free trials you can run against your schemas.

However, it’s once again important to note, Data Masker will not run an erasure process for you – and masking is also not the same as erasure in the first place.