An insurance platform must delete data on request while retaining records for regulatory periods. What design satisfies both?

The design

Separate the record from the identity. Business facts — a policy, a claim, a transaction — are retained under a pseudonymous subject reference for their regulatory period. The mapping from reference to person lives in a separate store governed by the erasure rules.

Deleting the mapping renders the retained records non-identifying while preserving them for their regulatory purpose.

This must be designed early, because retrofitting means rewriting every table that embedded a name, an email or a phone number — which in most systems is nearly every table.

What deletion must actually reach

Backups, replicas, caches, analytics copies, search indexes, exports and third-party processors. Deletion that does not reach all of them is not deletion, and every derived copy is a place the obligation is silently unmet.

That requires:

• A data inventory and lineage, since you cannot apply a policy to data whose existence is unknown, and the derived copies are where the unknowns live.
• Deletion propagated as an event with completion tracked rather than assumed.
• An agreed backup policy, because an immutable backup taken before the request still contains the data — usually resolved as a documented retention window agreed with legal rather than assumed by engineering.

Legal hold

A hold must override deletion, including scheduled and user-requested deletion, and be recorded with its scope, its reason and its author.

So deletion cannot be a cron job doing hard deletes. It must go through a service that checks for holds and produces evidence of what it did — because the evidence is what an auditor or a court asks for.

The insurance-specific complication

A claim's lifecycle can span years, and the retention clock frequently starts at closure rather than at creation. A policy holder exercising erasure while a claim is open cannot have the claim's record deleted, and the product must be able to explain that.

Encoding the retention rule as data with an effective date, rather than as code, is what allows the rule to change without a migration — and regulatory retention periods do change.