A retention policy nobody implemented is a false statement
3 August 2026 · 6 min read
If your privacy page says data is deleted after two years, something in your codebase has to actually delete it. Usually nothing does.
Read your own privacy policy and then grep your codebase for the deletion. On most projects there is nothing there. The policy is a document the lawyer wrote and the engineers never saw.
That gap is not a technicality. Telling customers you delete their data after two years, while keeping it forever, is a false statement about your processing - and it is trivially discoverable by anyone who files an access request.
Make the code the source of truth
Put the windows in config. Stamp a retention_until on each row when it is created, from that config. Run a nightly command that deletes expired rows. Write a test that fails if the command stops deleting.
Stamping the deadline per row rather than comparing against config at purge time matters: shortening the policy then applies to new data immediately, while existing rows keep the window that was actually disclosed to the people they describe.
Not everything can be deleted
Consent records are the evidence that an erasure was requested and lawful. Anonymise the identifying part and keep the rest. A suppression entry has to outlive the data it refers to, or a future import will mail someone who asked to be forgotten - so store the hash and drop the address.