How We Handle GDPR Data Deletion Requests at Scale

"Delete my data" sounds like a single database operation. In practice, a survey response's data can be referenced across a primary database, analytics aggregates, search indexes, backups, log files, and third-party integrations — and GDPR compliance requires accounting for all of them.

Mapping Every Data Location

Before building a deletion pipeline, we audited every system that stores or references personal data: the primary Postgres database, pre-computed analytics aggregates, exported CSV files, webhook delivery logs, and email service provider records. Any deletion system that misses even one of these isn't actually compliant.

Cascading Deletes vs Soft Deletes

We use hard deletes for personal data fields specifically (name, email, IP address) but retain anonymized aggregate statistics (the response still counts toward the survey's total response count and rating average) since aggregate statistics no longer constitute personal data once identifying fields are removed.

Backup Retention Windows

Database backups present a genuine challenge — you can't selectively delete one row from an encrypted backup snapshot. We solved this with a documented backup retention policy (30 days) and application-layer encryption on personal data fields, so that even if a backup is restored, the encryption key rotation renders the deleted data unreadable.

Third-Party Propagation

If a customer's data was pushed to a third-party integration via webhook or export before the deletion request, we can't directly delete data from systems we don't control — but we log exactly which integrations received the data and provide the customer with that list so they can independently propagate the deletion request.

Turnaround Time

Our deletion pipeline completes primary database deletion within minutes and confirms full propagation, including backup rotation, within our documented 30-day window — well within GDPR's 30-day response requirement, with most requests resolved same-day.

Auditing the Deletion Pipeline Itself

Because a broken deletion pipeline is a serious compliance risk that's easy to miss until someone specifically checks, we run a scheduled automated audit that submits a synthetic deletion request weekly and verifies the data is genuinely gone from every system on our documented list. This catches regressions introduced by unrelated code changes — a new analytics table added without being included in the deletion pipeline, for example — before they become a live compliance gap discovered during an actual customer request.