Retention and Purge

Retention is where data governance meets an uncomfortable engineering reality: most architectures are excellent at storing data and have no mechanism for removing it. Storage is cheap, deletion is work, and nobody is measured on it — so data accumulates until a regulator, a breach or a bill makes it a problem.

The obligations pull in both directions, which is what makes it a design problem rather than a policy one. Data protection regimes require personal data not to be kept longer than necessary for its purpose. Financial, tax and sector regulations require specified records to be kept for defined periods. Legal hold overrides both, freezing deletion for material relevant to litigation. A single record can be subject to all three.

The technical difficulty is that data spreads. A customer record deleted from the primary database persists in backups, analytical copies, search indexes, caches, logs, event streams, and the spreadsheet someone exported. A retention capability that only covers the system of record is not one.

What makes it tractable: classify data by retention class at ingestion rather than trying to determine it later, prefer architectures where personal data is centralised and referenced rather than copied, use platform-level lifecycle policies so deletion is automatic rather than a job someone runs, and record deletion events as evidence — because the compliance requirement is not only to delete but to demonstrate it.