Retention and erasure: storage limits enforced, not remembered

What does the capability do?

It turns “keep personal data no longer than necessary” from a policy into an engine that runs on schedule and proves what it did.

• Rules as data, per class and jurisdiction. Each retention rule names a data class, a country, a period, and an action. Because there is no fallback, a data class without a rule shows up as a gap rather than defaulting to keep-forever.
• Scheduled anonymise or delete. A job finds records past their period and either anonymises them, overwriting personal fields while keeping non-personal reporting columns, or deletes them. In non-production it defaults to a dry run, so you can see what would be purged before anything is.
• Every evaluation logged. The engine records that it assessed each data class against its rule and what it found, so the audit log proves a rule was considered, not merely that something was deleted. Absence of deletion is evidence too.
• Legal holds that override. Data under investigation is excluded from purging by a legal hold, applied centrally so no class can skip the check, and kept for audit when lifted.
• Fail safe, not sorry. Where an erasure would touch stored documents that cannot yet be removed cleanly, the run refuses rather than partially erase and leave data orphaned in storage.
• Coverage enforced by a test. A build-time test asserts every table holding classified personal data is either covered by a retention rule or listed as an explicit, documented exemption. New personal data cannot silently escape retention.

Why anonymise-or-delete beats a delete button

The right to erasure and the duty of accountability pull in opposite directions: one says remove the data, the other says keep a record of what happened. Treating removal as a single delete satisfies one and breaks the other.

The platform separates the states instead. Soft deletion hides a record while keeping its history. Anonymisation strips the personal data while keeping the non-personal residue a business needs for reporting and reconciliation, and it reaches soft-deleted rows so nothing hides from a purge. The immutable audit trail is preserved throughout, which is what lets erasure and accountability coexist. The companion guide covers how crypto-shredding extends this to data that must not be mutated.

Why it matters

Storage limitation is the data-protection principle most systems quietly ignore, because keeping everything is the path of least resistance. An operator holding personal data, often for children, has to show it is kept only as long as needed and removed on a defined schedule. Rules per data class, scheduled action, logged evaluations, and legal holds mean the platform can demonstrate that, not just assert it. It builds on data classification, which tells retention where the personal data is, and it is part of the wider platform discipline of designing data protection in. Read more in our approach to GDPR and data protection by design.