Defensible deletion: how to destroy personal data and keep the proof

Defensible deletion means destroying data in a way you can justify afterwards. The data is removed on a defined timeline, and you can still show what it was, why it qualified for deletion, when it happened, and that nothing under a legal hold was caught in the sweep.

Anyone can delete a file. The problem is that once it is gone, the evidence that you handled it correctly is usually gone with it. Defensible deletion solves that by capturing the proof before the data disappears.

Why delete-and-forget fails

Delete-and-forget fails because deletion is itself a compliance action, and the accountability principle in Article 5(2) makes you prove you did it correctly. Once the file is gone, you have nothing left to prove it with. Deletion is not optional cleanup: the GDPR pushes you to delete personal data once its purpose ends, and Article 5(1)(e) makes over-retention a breach.

That is the trap. If your process is “delete the file and move on,” you have satisfied the deletion duty and failed the accountability duty. When a former employee complains to a supervisory authority, or an auditor samples your retention practice, the question is not “is the data gone.” It is “show me that you deleted the right thing, on time, and left everything you were obliged to keep.” Delete-and-forget has no answer to that.

The two ways deletion goes wrong

Deleting too much. You sweep a retention period and catch a record that was under a legal hold for an active dispute. Destroying data you had a duty to preserve is spoliation. A defensible process checks for every hold before it destroys anything, and blocks the destruction if one is active. The hold itself is enforced at the storage layer.

Deleting without proof. You delete correctly but keep no record of it. Two years later you cannot show which categories you erased, what you retained, or why. In practice this looks the same as never having deleted at all, because you cannot demonstrate it. Accountability you cannot evidence is accountability you do not have.

Defensible deletion is the discipline that avoids both.

What defensible deletion requires

Five things have to be in place before, during, and after the destruction:

1. A trigger you can justify. The deletion is driven by a retention schedule or a valid erasure request under Article 17, not by an ad hoc decision. The reason is recorded.
2. A legal hold check. Before anything is destroyed, the process confirms the record is not under a duty to preserve. If it is, destruction is blocked and that block is logged.
3. A scoped decision. You record exactly what is being destroyed and what is being retained, per category, with the legal ground for anything kept.
4. The destruction itself. The data is put beyond use, including in backups, on a defined timeline, not a promise of instant deletion that never reaches the backups.
5. A certificate of the event. A dated record that captures all of the above and survives the data it describes.

Miss any one of these and the deletion stops being defensible. A destruction with no hold check is reckless. A destruction with no certificate is invisible.

Delete-and-forget vs defensible deletion

The difference is not whether the data is deleted. It is what survives the deletion.

What a certificate of destruction should contain

A certificate of destruction is the artifact you keep after the data is gone. It is the proof, so it has to stand on its own. A useful one records:

• What was destroyed, identified without reproducing the personal data itself. A content hash or a pseudonymous identifier does this well: it proves which record you mean without recreating it.
• When the destruction was decided and when it completed, with a trustworthy timestamp rather than a system clock value that anyone could edit.
• Why the record qualified: the retention rule or erasure ground that triggered it.
• The hold status at the time, showing nothing under preservation was caught.
• The assurance level, stated honestly. A certificate that overclaims is worse than none, because it fails the first time someone checks it. A good certificate says exactly what it attests and what it does not.

That last point is the one most vendors skip. A certificate that says “destroyed and verified” without explaining how verification worked is a marketing artifact, not evidence. A certificate that states its own limits is one an auditor can actually rely on.

Where this fits with retention and erasure

Defensible deletion is the execution layer under two things you already have to do. Your HR retention schedule decides when data may be deleted. The right to erasure creates on-demand deletions between those scheduled dates. Defensible deletion is how both of those actually happen without creating an accountability gap. The legal hold mechanism that overrides them is enforced at the storage layer.

The same principle that makes a Legal Evidence Pack useful for proving a document existed makes it useful for proving when, why, and to what scope a record’s destruction was decided and recorded. In both cases the evidence has to be captured at the moment of the event and has to be verifiable by someone who was not involved.

How SealDoc makes deletion defensible

SealDoc models each protected record as a subject with a retention state and a hold state. Destruction is a controlled sequence, not a single delete. When you request destruction, SealDoc first checks that the subject is not under a legal hold and is genuinely past its retention. It records the decision, the timing, and the scope as timestamped, tamper-evident evidence, linked into a hash chain so the order of events cannot be rewritten later.

At the end of the sequence, SealDoc produces a certificate artifact and an evidence pack. The certificate identifies the record by content hash and pseudonymous identifier rather than by reproducing the data, records the trigger and the timeline against an RFC 3161 timestamp, and states its assurance level plainly.

To be exact about the split: SealDoc records and attests the decision, the hold check, the timing, and the scope, and produces the certificate and evidence pack to a stated assurance level. The physical put-beyond-use, including the purge from backups, is carried out by your configured storage and confirmed against the record. The proof layer is SealDoc’s job, not a claim that the bytes vanished the instant you clicked. If a step could not be fully assured, the certificate says so instead of hiding it. That honesty is the point: the artifact is designed to hold up when an auditor tests it, not to look impressive until someone does.

Everything runs on EU infrastructure with no US hyperscaler in the path, so the proof of deletion does not become a data transfer problem of its own.