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:
- 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.
- 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.
- A scoped decision. You record exactly what is being destroyed and what is being retained, per category, with the legal ground for anything kept.
- 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.
- 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.
| Step | Delete-and-forget | Defensible deletion |
|---|---|---|
| Trigger | Ad hoc, when someone notices | Retention schedule or valid erasure request, recorded |
| Legal hold | Not checked | Checked, and destruction blocked if a hold is active |
| Scope | The whole file | Per category, with a legal ground for anything kept |
| Destruction | Delete and move on | Put beyond use on a defined timeline, backups included |
| Proof | None | A dated certificate that outlives the data |
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 principle behind a Legal Evidence Pack applies here too: 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 supports defensible deletion
SealDoc keeps a SHA-256 hash of every document and records each event in its life in a hash-chained audit trail, so any later change is detectable and the order of events cannot be rewritten without it showing. SealDoc’s API refuses to erase a document within its retention period. Once the period allows it, an erasure on request is recorded in the same audit trail.
Everything runs on EU infrastructure with no US hyperscaler in the path, so the audit trail does not become a data transfer problem of its own.