A GDPR erasure request arrives for a patient whose data sits in an append-only clinical audit log. What do you do?

Start by not deleting anything

The instinct to run a delete is the wrong first move, and in a clinical system it can be an offence in its own right. The right to erasure is conditional in both directions. It arises in defined circumstances - the data is no longer necessary for the purpose it was collected for, the processing rested on consent and that consent has been withdrawn, the processing was unlawful - and it is displaced in other defined circumstances, including where processing is necessary to comply with a legal obligation the controller is under, where it is needed to establish or defend legal claims, and where it serves specified public-interest purposes in the area of health. Both halves are conditions on the same right. "Erase everything" is not a command a controller is obliged to obey; it is a request that triggers an assessment.

What you owe the requester is a decision, reached and communicated within the statutory response window, that says what was erased, what was retained, and on what grounds. That is a very different deliverable from a script.

The request is not one request

The single sentence in the email maps onto many datasets, each with its own lawful basis, and the answer differs across them. Roughly, the estate sorts into three groups.

Data that is retained under an obligation. The clinical record itself normally falls here: professional and statutory rules require medical records to be kept for a defined period after the last episode of care, with longer periods for records concerning children and for certain categories of treatment. The period is set by national law and varies between jurisdictions, so the engineer's job is to find the retention schedule the organisation operates under and apply it, never to assume one. Transfusion and implant traceability and safety-reporting data often carry separate and longer obligations again.

Data that has no basis to survive the request. Marketing consent, an appointment-reminder opt-in, a satisfaction-survey response, a research cohort membership the patient consented into: where consent was the basis and it is withdrawn, there is nothing left holding the data. Analytics copies, feature stores and warehouse extracts built for secondary use are frequently in this group too, and are usually the largest and least catalogued part of the estate.

Data that is retained but must stop being used. This is the middle case that most designs have no mechanism for, and it is where the audit log ends up.

Why the audit log is a special case

A clinical audit log records who accessed and changed which record and when. It exists to answer questions the patient benefits from: was your record read by someone with no clinical relationship to you, who altered this result, what did the system look like at the moment the decision was made. It is required by access-control and accountability obligations, it is evidence in an investigation or a claim, and its append-only, usually hash-chained construction exists specifically so that nobody - including an administrator responding to an erasure request - can quietly revise history. Deleting entries from it destroys the mechanism that protects the subject, and if the chain is genuinely tamper-evident the deletion will also be detectable forever afterwards as a gap.

There is one thing append-only storage is very good at, though, and it is worth using: appending. Record the erasure decision itself as a new event in the log - the request, the datasets in scope, the determination, who authorised it, what was suppressed - so the log stays internally consistent and the handling of the request is itself auditable.

Crypto-shredding and pseudonymisation, and where they stop

Crypto-shredding is the strongest technical option and the most oversold. You encrypt each subject's payload under a key held per subject in a key management service, and to render that data unintelligible you destroy the key. It genuinely helps with immutable and offline media, because you cannot rewrite a WORM object or a tape but you can destroy a key held elsewhere. Its limits are all practical and all decisive if you miss one.

Key granularity has to match the subject: a key covering a whole log file or tenant cannot be destroyed for one person, and if events for several patients share a key you would be destroying other people's evidence. The key must not survive anywhere - escrow, an HSM backup, a stale replica of the key store, or a developer's export all defeat it. Only what was encrypted is affected, so search indexes, log lines, metrics, cached projections, message-queue archives, and derived aggregates that were computed in the clear remain readable. And the ciphertext still exists, so whether key destruction constitutes erasure or only a strong restriction of processing is a judgement about the regulator's position, not a fact you can establish from the architecture.

Pseudonymisation is weaker than it sounds in this context. Replacing direct identifiers with a token keeps the log structurally useful while reducing exposure, but pseudonymised data remains personal data for as long as re-identification is possible, so it does not by itself discharge an erasure obligation. The mapping table is the whole problem: keep it and you have not erased anything, destroy it and you have broken the log's purpose, because the point of an access log is precisely to link events to an identified person. What it does buy is proportionate: the log still serves tamper-evidence and pattern analysis while casual identification becomes hard, which can satisfy a minimisation argument even where it cannot satisfy erasure.

The mechanism that usually carries the middle case is suppression. You mark the subject, remove them from every read path, user interface, export and secondary-use dataset, block re-derivation, and leave the retained records reachable only through a deliberate, logged, individually authorised access for the obligation that justified keeping them. The retained data then ages out under the retention schedule rather than being deleted on request. Backups get handled the same way - not rewritten, but expired on their own cycle, with restores routed through the suppression list so a recovery does not silently reinstate what you suppressed.

Whose decision this is

The genuinely senior part of the answer is knowing that you are not the decision-maker and that this is not an evasion. An engineer who deletes unilaterally may have destroyed a medical record and its audit trail; an engineer who refuses unilaterally has denied a data subject right on their own authority. Both are the same mistake in opposite directions.

What you produce instead is the thing nobody else in the organisation can produce: a complete inventory of where this person's data actually is, including the copies that are not in the record system, and for each location the lawful basis it is held under, what is technically possible, what it costs, and what risk remains after each option. Then the data protection officer, the records manager and, where clinical safety is implicated, the clinician responsible for the record make the determination and it is documented with reasons. You implement that decision and you keep the reasoning, because the next request will be similar and because a regulator asking about this one will be asking how it was decided.

The failure mode to avoid naming late

The trap here is arriving with crypto-shredding as the answer. It is a good technique, it is the correct answer for immutable media, and offering it makes a candidate sound informed - but reaching for it first quietly reframes an erasure request as a solved engineering problem and skips the two things that were the substance of the question: that different datasets are held under different lawful bases and therefore have different fates, and that the residual call belongs to legal and clinical records ownership with the engineer's job being to surface it accurately rather than to settle it in a migration.

Erasure in healthcare is not a delete, it is a determination. The engineer's deliverable is an accurate inventory, a set of options with their residual risk, and a documented decision made by the people entitled to make it.