Compliance

Data Retention & Erasure

Intermediate

Every piece of data has a lifespan: a time it should be kept until, and a time it must be gone by. Holding data too long is a liability and a GDPR breach. Deleting regulated data too soon is destruction of evidence. Retention is the discipline of getting both ends right, deliberately and automatically.

Two duties pull in opposite directions, and both are mandatory. GDPR's storage limitation says: do not keep personal data longer than its purpose needs. AML law says: keep KYC, transaction, and SAR records for the statutory period and never destroy evidence. The system must satisfy both. So retention cannot be ad hoc. It must be a defined policy enforced in code.

The answer is per-category retention rules, plus the right deletion method for each: hard-delete what GDPR says must go, soft-delete (never destroy) what AML says must stay. The dangerous failures are silent: data that stays forever because nothing deletes it, or regulated records hard-deleted because someone reused a generic delete path.

Define and enforce retention

AlwaysGive every data category an explicit retention period tied to its purpose and the governing regulation, and enforce it automatically.
DoRun retention as a scheduled, audited process. Data is deleted or anonymised when its period ends, without relying on someone remembering.
DoTell the categories apart clearly: ordinary personal data (delete when its purpose ends) versus statutory AML/KYC records (keep for the legal period).
DoAnonymise rather than delete where you need the data's analytical value but not the identity behind it.
ConsiderLegal-hold support that can pause deletion for specific records under investigation, with the hold itself audited.
NeverRetain personal data indefinitely or with no defined retention rule.

Erase safely and provably

DoUse soft-delete for regulated records, with a role gate, tenant scope, and an audit entry. Never an irreversible destroy.
DoWhen honouring a GDPR erasure request, erase across all stores (primary, replicas, backups per policy, caches, exports), not just the main table.
DoRecord the erasure itself (what category, when, on what basis) so you can prove the obligation was met.
ConsiderCrypto-shredding (destroying the key) for data that is hard to physically delete from backups.
Do notRoute regulated records through a generic hard-delete path shared with disposable data. Keep the methods separate so a mistake cannot cross over.
NeverHard-delete regulated records (customer, KYC, AML, audit, SARs). Soft-delete with a role gate, tenant scope, and an audit entry.

One delete path for everything public void Delete(Guid id) => db.Execute("DELETE FROM Records WHERE Id=@id", new { id });

Used for a disposable draft today, reused for a KYC record tomorrow. The AML evidence is then gone with no audit trail. Regulated records must never reach a hard-delete.

Category-aware deletion

// regulated record: soft-delete, gated, audited
db.Execute("UPDATE KycRecords SET DeletedUtc=@now, DeletedBy=@u WHERE Id=@id AND TenantId=@t", ...);
audit.Record("KycRecord.SoftDelete", id, user);

The record survives for the statutory period, the action is linked to a person, and tenant scope is enforced.

Self-review checklist

AskDoes every data category this touches have a defined retention period — and is it enforced automatically?
AskIs this delete path correct for the category — hard-delete for GDPR, soft-delete for regulated records?
AskOn a GDPR erasure request, would every copy actually be removed?
AskCould a generic delete ever reach a regulated record?

Why it matters: Both failure directions are serious: over-retention breaches GDPR and grows the blast radius of any breach, while destroying AML evidence is a regulatory offence in its own right. Automatic, category-aware retention is how we satisfy two opposing legal duties without depending on anyone getting it right by hand.