Collect Less, Risk Less
The most effective privacy control is not collecting data in the first place. Data minimization is the principle that a system should collect only the data strictly necessary for its stated purpose — nothing more. Under GDPR Article 5(1)(c), this is a legal requirement, not a suggestion.
In practice, data minimization means asking hard engineering questions before building any data pipeline:
- Purpose limitation: Why are we collecting this field? What specific feature or legal obligation requires it?
- Retention limits: How long do we actually need this data? What is the cost of keeping it indefinitely vs. deleting it on a schedule?
- Access controls: Who needs to read this data? Can we restrict access to a smaller set of services or engineers?
A common failure mode: engineers add fields to a database schema "just in case we need it later." Each such field is a liability — a potential breach vector, a compliance obligation, and a future deletion headache.
The Right to Erasure (GDPR Article 17)
GDPR grants individuals the "right to be forgotten" — the right to request that a company delete all personal data it holds about them. This sounds simple but creates significant engineering challenges:
The distributed data problem: User data is rarely in one place. It may exist in:
- Primary relational databases (PostgreSQL, MySQL)
- Data warehouses (BigQuery, Snowflake)
- Backup tapes and snapshots
- Analytics pipelines and derived datasets
- Caches (Redis, CDN edge nodes)
- Log files (application logs, access logs, audit trails)
- Third-party integrations (CRM, email marketing, analytics tools)
Engineering solutions:
-
Data inventory (data mapping): Maintain a catalog of every system that stores personal data, what data it stores, and how long it retains it. Without this, you cannot fulfill erasure requests reliably.
-
Pseudonymization as a deletion proxy: For systems where true deletion is technically difficult (e.g., immutable audit logs, append-only event streams), replace the user's identifier with a random token and delete the mapping. The records remain but are permanently de-linked from the individual.
-
Retention policies as code: Implement automated deletion jobs that purge data after its retention period expires. Tools like Apache Airflow or cloud-native schedulers can run nightly deletion pipelines.
-
Differential Privacy for analytics: If you've applied DP to aggregate analytics, individual records are already mathematically hidden — erasure of the underlying record has negligible impact on the published statistics.
The right to erasure is not absolute — legal holds, fraud prevention, and contractual obligations can override it — but the default engineering posture should be: data has an expiration date, and deletion is a first-class operation, not an afterthought.