The Right to Be Forgotten

The story

The request arrived through the patient portal’s contact form, polite and precise, from a woman named Ruth Adeyemi: she had moved abroad, her care had ended, and she wanted her account and personal data erased. Under the regulation, she cited, she had the right. She did.

Four years earlier this email would have started a two-month archaeology project. Ana had once mapped where a single user’s data lived in the old system: seventeen tables, four log pipelines, a backup rotation measured in years, and an audit trail whose entries — the ones proving who had accessed Ruth’s chart — contained her name. That last one was the trap. Delete the entries and the record of care has holes an assessor would read as tampering, because episode eight had made tampering detectable. Keep them and you haven’t erased her. The two obligations — remember everything, forget on demand — appeared to be enemies.

The request took an afternoon, and it took an afternoon because the system had been built to expect it. First the export: a structured bundle — profile, org memberships, sessions, security events, linked identities — because the right to erasure travels with the right to a copy, and Ruth had asked for both. Then the erasure, a privileged operation fenced to global administrators and, naturally, written to the ledger itself: her user record anonymized, her account disabled, every authenticator deleted — password, passkeys, TOTP enrollments, recovery codes — so the account wasn’t merely unnamed but unusable. The test suite states the property Ana cared most about in nine words: Login_is_impossible_after_erasure.

And the trap — the audit entries, the backups? That’s where the cryptography did the disappearing. Ruth’s personal fields in durable records had been encrypted under a per-subject key from the day they were written. Erasure destroyed the key. Every copy of the ciphertext — live rows, aged audit payloads, last year’s backups — became noise in place, irrecoverable by construction. The ledger’s chain still verified end to end, because the chain had always committed to payloads by digest, and the digests survive shredding. The history of what was done remained provable; who it was done to was gone.

Ana sent Ruth the confirmation and the export, and closed the ticket. It was a Thursday. Nothing about it made the news, which was the entire point — and, she thought, a fitting place for the season to end: the system had finally learned to forget a person as carefully as it remembered everything else.

Why this is hard the traditional way

Personal data replicates by design — into logs, analytics, search indexes, audit trails, and backups whose whole purpose is to resist deletion. A literal reading of erasure means finding and scrubbing every copy, including the tape in the vault, which is somewhere between heroic and impossible. So teams settle for deleting the primary row and hoping — a compliance posture best described as erasure of the easy parts.

The audit conflict is sharper in regulated industries. Clinical and administrative records must be retained for years and provably unmodified; privacy law demands the person inside them be removable on request. Systems that discover this tension after the first erasure request resolve it badly in one direction or the other — a hole in the evidence, or a “no”.

How Sentinel changes the ending

Sentinel resolves the tension by construction, with three cooperating pieces. Crypto-shredding: personal values encrypt under a per-subject AES-GCM key (SentinelCryptoShredder); destroying the key via the key store erases every copy of the ciphertext everywhere it was ever replicated — Shred_round_trip_encrypt_destroy_decrypt_fails is the property, and keys are strictly per-subject, so erasing Ruth touches only Ruth. Erasure as a modeled operation: export and erase are privileged, audited flows (Export_and_erase_require_global_manage) that anonymize the user, disable the account and delete every authenticator — with the finale’s invariant tested from both sides: the erasure redacts while the chain still verifies, and tampering with a redacted entry still breaks it. Retention as policy: aged security events delete outright, aged audit payloads redact to their digests on schedule — with defaults that keep the admin ledger’s structure forever, because the digest commitment means forever and forgotten can finally coexist.

What it costs you to ignore this

• Erasure requests are legal instruments with deadlines. A months-long scramble per request doesn’t scale past the first few, and regulators notice patterns.
• “We deleted the row” is not erasure while backups, logs and audit payloads still spell the name — and each replica is a separate finding.
• Resolving privacy vs. audit ad hoc corrupts one of them. Holes in the chain read as tampering; retained PII reads as violation. Pick neither.
• The finale compounds everything before it. Erasure done right needs the ledger from episode eight, the fenced admin from episode four, the events from episode one — identity debt is the interest on all ten stories, billed together.