Legal Hold Software: Building a System That Survives a Deletion Request

Someone asks you to delete their data. You are also required to keep it. Both things are true at the same time, and your document system almost certainly has no way to express that.

This is the part of records retention and legal hold that gets discovered late, usually during an audit or a first real deletion request, and it is an engineering problem rather than a policy one. The policy is often fine. The system cannot represent it.

So this covers four things. What a retention schedule is when you express it as data rather than a PDF. What a legal hold has to do beyond setting a flag. What happens when a deletion right and a retention obligation land on the same record. And what the build costs, staged.

Everything below uses illustrative figures written out so you can substitute your own, and general mechanics rather than the rules of any one jurisdiction. Your obligations are specific to where you operate and what you hold. Check them with someone qualified rather than with a blog post.

The conflict that breaks most document systems

Three rules apply to the same record and they do not agree.

Storage limitation says do not keep it longer than you need. Most privacy regimes carry some version of this. Holding a record with no purpose is itself a problem, so "keep everything forever" is not a safe default.

A retention obligation says keep it for a fixed period. Tax, employment, clinical, financial. The period comes from a statute or a regulator, not from you, and it usually runs from an event rather than from the creation date.

A deletion right says remove it on request. Most regimes that grant this also carve out an exception where another legal obligation requires the data. So the right is real and the exception is real.

A system that can only delete or only keep cannot express any of this. What it needs is a third state: retained, not deletable, not visible for ordinary use, with a recorded reason. Most document systems have two states and a bin.

The practical test for any system you are evaluating: ask what happens when a verified deletion request arrives for a record that is 3 years into a 7 year retention period. If the answer is "it deletes" or "it errors", you have found the gap.

What a retention schedule actually is

On paper a schedule is a table. In software it is three fields per records series, and getting them wrong is where most of the pain comes from.

The trigger. What starts the clock. Not the date the file was uploaded. It is usually an event: contract end, last patient contact, employee leaving, case closed, tax year end. A schedule triggered on upload date is the single most common implementation error, because it starts counting years before the event that matters.

The period. How long after the trigger. Commonly expressed in years, often 3, 6, 7 or 10, and sometimes measured from a moving point such as a minor reaching the age of majority, which can put the real horizon 20 years out.

The disposition. What happens at the end. Delete, review, transfer to archive, or anonymise. Not every schedule ends in deletion, and treating them all as delete is how organisations destroy things they meant to keep.

Work one through. A contract signed on 14 March 2024, with a 5 year period triggered on contract end rather than signature, on an agreement that runs to 31 December 2027. The disposition date is 31 December 2032, which is 8 years and 9 months after the document was created. A system counting 5 years from upload would have destroyed it on 14 March 2029, three years and nine months early.

That single arithmetic difference is most of the value of expressing the schedule properly.

What a legal hold has to do

A hold suspends disposition for records relevant to an actual or anticipated matter. Setting a flag is the easy quarter of it. Four things have to happen.

Freeze disposition. The schedule stops running for held records. Not paused and resumed with the clock still ticking. Genuinely stopped.

Freeze mutation. Held records cannot be edited or overwritten. If your storage supports write once read many, this is where it earns its cost. If it does not, you need an application level equivalent and an audit trail that proves it held.

Record who, what and when. Who issued the hold, on what scope, at what timestamp, and which records it caught at that moment. A hold applied at 11:40 on a Tuesday needs to show what was in scope at 11:40 on that Tuesday, not what is in scope today.

Survive a restore. A backup restored from before the hold was issued must not quietly reinstate the old disposition dates. This is the failure mode nobody tests and it undoes everything else.

Scope is the design decision that matters. A hold defined by custodian, "every document belonging to these 6 people", is easy to apply and catches far too much. A hold defined by matter, "everything related to this contract", is correct and much harder to compute. Most builds do both: a broad custodian hold immediately, then a narrower matter hold once the scope is understood, with the broad one released.

Where the two collide, and who wins

This is the section the reader came for.

A verified deletion request arrives. The record it names is under a retention obligation, a legal hold, or both. What should happen is not deletion and it is not a refusal either.

The record enters a restricted state. It stops being available for ordinary business use. It is not returned in search, not visible to staff who do not need it, not used for analytics or model training. It continues to exist, because something requires it to.

The reason is recorded against the record. Which obligation, which hold, which matter. A restriction without a recorded reason is indistinguishable from a system that simply ignored the request.

The requester is told. Most regimes require you to respond, and a response that says the data is retained under a specific legal obligation is a legitimate answer. Silence is not.

The disposition is re-evaluated when the reason ends. When the hold releases or the period expires, the deletion request should complete rather than being forgotten. This is the part that is almost always missing. The request is closed at the time, the record stays forever, and nobody notices until an audit.

So the honest order is: legal hold beats retention schedule, retention schedule beats deletion right, and the deletion right comes back the moment the other two stop applying. Build the queue that makes that last step happen.

What the build involves

Six stages. Hours are illustrative and assume you are adding this to a system that already stores documents.

Stage	Hours	What it covers
Records series and schedule model	40 to 70	The data model, trigger types, period arithmetic
Trigger wiring	60 to 120	Connecting real events to the clock, per source system
Hold engine	50 to 90	Apply, scope, freeze, release, and the audit record
Restricted state and access rules	40 to 80	Retained but not usable, per role
Disposition queue and review	40 to 70	What expires, who approves, what is destroyed
Evidence and reporting	30 to 60	Proving on demand what was held, when, and why

The middle of those ranges totals near 500 hours, which is above the 120 to 250 the healthcare industry page puts on a compliance layer. The difference is trigger wiring. If your events already exist as clean data, you are at the low end. If "contract end" lives in a spreadsheet, you are building that first.

Clinical records are the case that stretches every assumption here, which is why healthcare software development carries retention and legal hold as its own build module rather than a footnote. Periods run from last contact rather than from the record date, a minor's records can run decades past the last appointment, and a practitioner holds obligations over material the platform is merely storing. A schedule model that handles a 6 year commercial period will not survive contact with any of that without the trigger types being right first.

Trigger wiring is the stage that decides the estimate. Count your records series, then count how many have a trigger event that exists as queryable data today. That ratio predicts the cost better than any other question.

The phrase worth knowing for the last stage is defensible deletion: being able to show that a record was destroyed under a written schedule, at the right time, by a process that ran the same way for everything in that series. Deletion on its own is an act. Defensible deletion is an act plus the evidence that it was routine rather than convenient, and that difference only matters once, in the one conversation where it matters enormously.

So the evidence stage is not reporting in the ordinary sense. It has to answer three questions on demand: what was held on a given date and why, what was destroyed in a given period and under which series, and what falls due for disposition next. A system that can answer the first two and not the third is a system where things quietly stop being destroyed, and nobody finds out for years.

What it costs

Take a mid sized estate: 12 records series, 9 with triggers already available as data, 3 needing new capture, and 180,000 documents.

Build lands near 500 hours on the table above. The running cost is small and mostly storage, because retained records are cold. At 180,000 documents averaging 400 KB, that is roughly 72 GB, which is not a meaningful line item on any platform.

The cost that surprises people is review. A disposition queue produces work every month. If 4 percent of 180,000 documents reach their disposition date in a given year, that is 7,200 documents, and if 1 in 20 needs a human decision rather than an automatic action, that is 360 decisions a year, or about 7 a week. That is a real ongoing task and it needs an owner.

Add the people cost properly. If 7 decisions a week take 20 minutes each, that is about 2.3 hours a week, or 120 hours a year, which at a fully loaded 45 USD an hour is roughly 5,400 USD. Against a 500 hour build that is a small recurring line, but it is not zero and it needs a named owner rather than a rota.

Where the money actually is. Not in the build. It is in not holding 8 years of documents you were required to destroy after 5, and in being able to answer an audit in an afternoon instead of a fortnight. Both are avoided costs, which makes them harder to put in a business case and no less real.

The failure modes that only appear at audit

The clock started at upload. Covered above and worth repeating because it is the most common defect. Every period is wrong, usually in the direction of destroying things early.

The hold was applied but never scoped. Everything belonging to 6 custodians is frozen, including 4 years of unrelated material, and nobody will release it because nobody can tell what is relevant.

The hold released and the queue did not catch up. Records that should have been destroyed two years ago sit there because release only cleared the flag and never re-evaluated disposition.

A restore reinstated old dates. The one nobody tests. Run the test: apply a hold, restore a backup from before it, and check the hold survived.

Deletion requests were closed rather than queued. The requester was told the data is retained. The retention ended. Nothing happened. There is no record the request ever existed.

Nobody owns the monthly queue. A disposition queue with no owner becomes a list that grows. Twelve months later it is evidence of a policy nobody follows, which is worse in an audit than having no policy at all.

When you do not need any of this

When you hold nothing with a statutory period. Plenty of businesses do not. If your records are commercial and your only obligation is storage limitation, a simple age based cleanup and a documented reason is proportionate.

When the volume is small enough to handle by hand. Below a few thousand documents with two or three series, a spreadsheet and a calendar reminder is honest and cheap. Automating it costs more than it saves.

When the schedule does not exist yet. You cannot implement a schedule nobody has written. That work is legal and operational, not technical, and it has to come first. A system built against a guessed schedule is worse than no system, because it destroys things confidently.

When your storage cannot prove immutability and the matter is serious. If you are likely to face litigation where preservation will be tested, get that capability first. An application level freeze on mutable storage is better than nothing and it is not the same thing.

Summary

Records retention and legal hold is a three way conflict between storage limitation, a retention obligation and a deletion right, and most document systems have no state that can express it. The missing state is retained, not deletable, not usable, with a recorded reason.

A schedule in software is three fields per records series: the trigger event, the period, and the disposition. Triggering on upload date instead of the real event is the most common defect, and on the worked example above it destroys a contract three years and nine months early.

A hold has to freeze disposition, freeze mutation, record who and when and what was in scope at that moment, and survive a restore. Scope by matter rather than by custodian as soon as you can compute it.

When a deletion right meets a hold, the hold wins, the record enters a restricted state with a recorded reason, the requester is told, and the request is queued rather than closed. That last step is the one almost everybody misses.

Budget near 500 hours for a full build, dominated by trigger wiring, and expect a small ongoing review load rather than a large one.