{"id":112790,"date":"2026-09-11T12:00:00","date_gmt":"2026-09-11T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=112790"},"modified":"2026-09-08T15:44:10","modified_gmt":"2026-09-08T15:44:10","slug":"how-to-delete-personal-data-gdpr-ccpa-compliance","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/data-security-privacy-compliance\/how-to-delete-personal-data-gdpr-ccpa-compliance\/","title":{"rendered":"How to delete personal data for GDPR & CCPA compliance"},"content":{"rendered":"\n

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

This guide covers<\/strong> what a genuine deletion request requires, what GDPR (Article 17) and CCPA (\u00a71798.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<\/code> statement.<\/p>\n\n\n\n

What counts as a ‘deletion request’ under GDPR and CCPA?<\/h2>\n\n\n\n

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.<\/strong><\/p>\n\n\n\n

A soft-delete<\/a> flag<\/strong> is not erasure<\/strong>. Backups usually cannot be edited record by record, so regulators accept putting them “beyond use” until they age out. <\/p>\n\n\n\n

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

GDPR & CCPA: what the law actually requires<\/h2>\n\n\n\n

Under the European Union’s General Data Protection Regulation (GDPR)<\/a>, Article 17<\/a> gives a person (the “<\/em>data subject”) the right to erasure, aka “the right to be forgotten”.
<\/strong>
The right to erasure is not an absolute<\/em> 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<\/strong> to do so (extendable by two more months for complex requests).<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

In California, meanwhile, a resident can request deletion of their data under Section 1798.105 of the California Consumer Privacy Act (CCPA)<\/a>.<\/strong><\/p>\n\n\n\n

The data holder has 45 days<\/strong> to comply (extendable by another 45).<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Aspect<\/strong><\/td>GDPR (EU\/UK)<\/strong><\/td>CCPA \/ CPRA (California)<\/strong><\/td><\/tr><\/thead>
The right<\/td>Right to erasure (Art. 17)<\/td>Right to delete (\u00a71798.105)<\/td><\/tr>
Response time<\/td>1 month (+2 months if complex)<\/td>45 days (+45 with notice)<\/td><\/tr>
Absolute?<\/td>No, several exceptions<\/td>No, several exceptions<\/td><\/tr>
Common exceptions<\/td>Legal retention duty, freedom of expression, legal claims<\/td>Complete a transaction, detect fraud\/security incidents, legal obligation<\/td><\/tr>
Reaches third parties?<\/td>Yes; you must inform other controllers (Art. 17(2))<\/td>Yes; service providers and contractors must delete too<\/td><\/tr>
Backups<\/td>Accepted practice: put “beyond use” until overwritten<\/td>Deletion may be delayed until the backup is next restored or accessed<\/td><\/tr>
Maximum penalty<\/td>\u20ac20 million or 4% of global annual turnover<\/td>Per-violation fines enforced by the CPPA<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

What happens if you don’t comply (real enforcement cases)<\/h2>\n\n\n\n

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

Meanwhile in the Netherlands, their regulator (Autoriteit Persoonsgegevens – AP<\/a>), fined a recruitment firm \u20ac6,000 for not <\/em>having a method in place to handle data removal requests.<\/a><\/p>\n\n\n\n

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

Why you can’t treat deletion exceptions as automatic<\/h2>\n\n\n\n

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<\/strong> – plus delete every part of the data that the exception does not<\/em> cover.<\/p>\n\n\n\n

You can’t delete what you can’t find: building a data map<\/h2>\n\n\n\n

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<\/a>, uploaded file attachments, log lines, and denormalized<\/a> copies. <\/strong><\/p>\n\n\n\n

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><\/strong>.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Alternatively, the EDPB suggests creating a data-deletion matrix<\/strong> (or data retention schedule<\/strong>) that cross-indexes the type of data, legal basis, and retention periods. <\/p>\n\n\n\n

For those familiar with SQL, our guide on building a privacy-aware analytics layer with SQL<\/a> is a good place to start.<\/strong><\/p>\n\n\n\n

\n
\n
\n
\n

Protect your data. Demonstrate compliance.<\/h3>\n
\n With Redgate, stay ahead of threats with real-time monitoring and alerts, protect sensitive data with automated discovery & masking, and demonstrate compliance with traceability across every environment. <\/div>\n <\/div>\n Learn more<\/a>\n <\/div>\n <\/div>\n<\/section>\n\n\n

Why soft delete doesn’t satisfy GDPR or CCPA<\/h2>\n\n\n\n

In certain cases, applications do not<\/em> perform a complete deletion. The application might instead put a deleted = true<\/code> flag marking<\/em> deletion, known as a soft delete<\/a><\/strong>.<\/p>\n\n\n\n

Soft delete has its uses, especially for undo, auditing, and not breaking foreign keys<\/a>. However, soft delete is not<\/em> true erasure as required by GDPR and CCPA.<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

The correct way to permanently erase personal data is with a hard delete, where the records (data) are fully removed.<\/strong> 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?<\/p>\n\n\n\n

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

Where personal data copies actually live (and how to erase each)<\/h2>\n\n\n\n

Cascade deletes, however, only cover primary databases. <\/strong>Every day, we make tons of copies of data, and each individual copy requires deletion. <\/p>\n\n\n\n

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:<\/p>\n\n\n\n

Stored in<\/strong><\/td>Why it is around<\/strong><\/td>How to erase<\/strong><\/td><\/tr><\/thead>
Read replicas<\/td>Copies of production for scaling reads<\/td>Deletes usually replicate automatically<\/td><\/tr>
Transaction logs<\/a> (write-ahead log, binary log)<\/td>Every change is journaled for recovery<\/td>You cannot edit history. Log’s own retention window will age it out<\/td><\/tr>
Caches (in-memory, content-delivery network)<\/td>Copies kept for speed<\/td>Invalidate keys on delete, or rely on a short  Time To Live (TTL) so stale copies expire<\/td><\/tr>
Search indexes<\/td>A separate searchable copy of the data<\/td>Issue an explicit delete to the index<\/td><\/tr>
Message queues \/ streams<\/td>Events carrying personal data in transit<\/td>Use compaction or short retention<\/td><\/tr>
Data warehouse \/ analytics<\/td>Loaded by\u00a0Extract, Transform, Load (ETL)<\/a> jobs on a schedule<\/td>Delete in the warehouse separately<\/td><\/tr>
Application and audit logs<\/td>Personal data written into log lines<\/td>Minimize what you log + log retention<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

How crypto-shredding makes every copy unreadable at once<\/h2>\n\n\n\n

Crypto-shredding is the process of encrypting each person’s data with an encryption key unique to them<\/em>. When they ask to be forgotten, you destroy the key.<\/strong><\/p>\n\n\n\n

The encrypted data still exists but is unreadable without the key. A common crypto-shredding design uses two layers (aka envelope encryption<\/a>):<\/p>\n\n\n

\n