Data Privacy & Retention

Privacy regulation turns into concrete engineering requirements, and the ones that bite are architectural rather than procedural.

Data minimisation. The cheapest way to protect data is not to hold it. Every personal field you collect is something to secure, audit, retain correctly, and delete on request. "We might want it later" is how organisations accumulate liability.

Know where personal data lives. You cannot honour a deletion request against a system you have not inventoried, and personal data spreads: the primary table, the analytics warehouse, search indexes, caches, logs, backups, and the third parties you forward it to. Most failures to delete are failures to know.

Pseudonymisation is not anonymisation. Replacing a name with an identifier is pseudonymisation — reversible with the mapping, and still personal data under most regimes. Anonymisation means the individual cannot be re-identified by any reasonably likely means, which is genuinely hard: sparse behavioural data re-identifies people surprisingly easily even without direct identifiers.

The right to erasure collides with your architecture, and this is the interesting engineering problem. Soft deletes preserve the row you were asked to remove. Append-only event logs and event sourcing are built never to forget. Backups contain the data by design. The usual resolutions are crypto-shredding — encrypt each subject's data with a per-subject key and destroy the key — or tombstoning plus a documented backup expiry window.

Retention is a schedule you implement, not a policy you write. Keeping data forever because deleting it was never built is the default outcome, and the one that gets found in an audit. Automated expiry is the only version that actually happens.

Logs are a leak vector. Request bodies, error payloads, and analytics events routinely capture personal data into a system with wide read access and long retention. Redact at the point of logging.