Legal Holds: When You Must Stop Deleting

The email from legal reads differently from anything else in your inbox. It says: "Effective immediately, preserve all documents and data relating to Acme Logistics, including electronic files, until further notice." You read it twice. Then you remember that purge-inbox-acme runs at five tomorrow morning. Yesterday, deleting old Acme files on schedule was good practice, the whole point of the retention program you built. This morning, the same deletion would be a serious problem. Nothing on the server changed overnight. The rules around it did.

That instruction is a legal hold. It is the one message that outranks every retention schedule, every automated purge, every contractual destruction clause, and every cleanup instinct you have. For an administrator who has done the responsible thing and automated deletion, a hold creates a genuinely urgent task. Machines are scheduled to destroy data that must now survive, and the clock is running. (The machines do not read email. Until this morning, that was their best feature.)

This article, part of our Retention & Deletion series, is the working guide for that moment and the months after it. It covers what a hold is and what your role is (and pointedly is not). It covers how to stop automated deletion quickly without wrecking the rest of your retention program. It explains how to scope and document the preservation, and how to release it all cleanly when the instruction ends.

What a Legal Hold Is

A legal hold — also called a litigation hold or preservation notice — is a formal instruction to preserve information that may be relevant to a legal matter. That may be a lawsuit that has been filed, one that is reasonably expected, a regulatory investigation, or sometimes an internal one. The hold is issued by lawyers — your organization's counsel or legal department. It exists because courts take a dim view of evidence that vanishes. Destroying potentially relevant information once a matter is on the horizon has a legal name, spoliation. It has consequences that can dwarf the underlying dispute: sanctions, adverse rulings, and a court instructed to assume the destroyed data said the worst.

The crucial subtlety is that a hold makes previously proper deletion improper. Purging ninety-day-old transfer files per an approved schedule is exactly right — until a hold covers them. At that point, the same automated job performing the same action becomes destruction of evidence. Courts generally understand that organizations delete data routinely; what they do not forgive is deletion that continues after the duty to preserve began. That is why the interval between a hold arriving and your automation being paused is the most important few hours in this entire topic.

A hold binds the data, not a folder or a system. It typically describes its scope in business terms — a counterparty, named people, a topic, a date range. It covers that information wherever it lives: transfer servers, archives, home directories, logs, sometimes backups. Translating "all data relating to Acme" into an actual list of paths is your part of the work.

Your Role: Prompt, Verifiable Compliance — Not Interpretation

The lawyers own the what and the why; you own the how and the proof. That framing is what keeps administrators out of trouble. Legal decides that a hold is needed, what it covers, how long it lasts, and when it ends. Your job is to implement the instruction quickly, completely, and in a way you can later demonstrate. Your job is not to judge whether the hold is overbroad, whether the matter has merit, or whether some files "can't possibly" count.

That division is not a demotion; it is protection. An administrator who unilaterally narrows a hold ("surely they didn't mean the staging folder") has made a legal judgment without a law license. If that judgment is wrong, the deleted files are gone and the decision has their name on it. The correct move with an ambiguous scope is to ask, in writing, with concrete options. "Does the hold include the EDI staging folder that briefly holds Acme files in transit? The activity logs recording Acme's sessions? Backup sets containing the Acme folders?" Lawyers answer concrete questions well; they cannot answer the question you never asked. While you wait for the answer, preserve broadly — over-preservation is recoverable, deletion is not.

Two more professional habits complete the role. Treat the hold itself as confidential. Who and what it names is not lunchroom conversation, and in some matters even the hold's existence is sensitive. And resist curiosity: preserving Acme's files does not require reading them. Your access to held data should be exactly what preservation demands and no more. Curiosity is a fine quality in an administrator and a poor one in a custodian.

The First Hours: Stop the Machines

Automated deletion is the immediate threat, because it acts without you. The moment a hold lands, inventory every process that deletes data in or near its scope, and pause each one. On a transfer estate, that list is longer than it first appears:

• Purge jobs — the age-based cleanup tasks from your retention program, for any folder that could hold in-scope files.
• Workflow cleanup steps — the quiet deletes inside transfer jobs themselves: "remove source after successful send," "clear staging after processing." These are easy to forget because nobody thinks of them as retention.
• Archive rotation — jobs that cap an archive folder's size or age by deleting the oldest files.
• Log rollover deletion — if old activity logs are deleted on a cycle and logs are in scope, that cycle pauses too.
• Backup expiry — backup platforms age out old sets automatically. Whether backups are in scope is a question for legal (ask it explicitly). If yes, the backup administrator must suspend expiry for the relevant sets.
• Anything a partner controls — if the counterparty deletes files from your server after pickup, or your job deletes from theirs, flag it. Legal may need to address the other side separately.

This is where disciplined purge design pays its dividend. You may have followed the pattern in automated purge policies — small per-folder jobs plus an exclusion list every job honors. If so, compliance is surgical. Disable the handful of scheduled tasks whose scope touches held data, or add the held paths to the exclusion list. The rest of the estate keeps its normal hygiene. In a tool like Sysax FTP Automation, that means disabling specific named scheduled tasks or adjusting which folders their file operations cover. It is a change of minutes, made without touching any other flow. A monolithic purge-everything script, by contrast, forces a terrible choice: stop retention everywhere or edit deletion logic under time pressure. Build for the surgical option before you need it.

Record the time you paused each process. That timestamp — "hold received at ten fifteen, all in-scope deletion stopped by eleven forty" — is the first line of the compliance story. You may one day need to tell it. I have reconstructed that line from memory, weeks later, and I do not recommend the experience.

Kestrel Payroll's administrator received a hold on a Friday afternoon. They disabled every purge task that touched the client's folders within the hour, and logged the times. The one thing missed was the "remove source after successful send" step inside the client's own outbound job. That step deleted each day's extract from staging as usual on Saturday, Sunday, and Monday morning. The Monday scope review caught it. The three files were recovered from the weekend's backups, whose expiry had already been suspended. The recovery was itself logged with the reason. Legal received an honest note about the gap the same day, along with the evidence that nothing had been lost. It cost a morning. The runbook gained a line.

Scoping: From "All Data Relating to Acme" to a List of Paths

Holds name subjects; servers hold paths. The translation between them is exactly the mapping skill this series began with. The inventory of where transferred files accumulate becomes your scoping worksheet. Walk it asking one question per row: could this location hold information matching the hold's description? For a partner-scoped hold, the obvious hits are the partner's inbox and outbox folders and any archive of their traffic. The less obvious ones are staging folders their files pass through, home directories of the people who handle the relationship, and quarantine areas. They also include the server's activity logs, which record every session and operation for that partner's accounts.

Build the worksheet explicitly — hold reference, each mapped location, what it holds, and the preservation action taken there. Locations you considered and excluded belong on it too, with a word on why ("no Acme data has ever landed here — folder created after relationship ended"). A scope worksheet that shows its reasoning is what turns "we think we got everything" into "here is where we looked and what we did." It is the document your legal team will quietly love you for.

Preserving Without Breaking the Business

A hold rarely means the flow stops — you are usually still doing business with the counterparty, and files must keep moving. Preservation and operation coexist through two patterns, chosen per location with legal's blessing:

1. Preserve in place. Suspend deletion for the folder and let files accumulate. Simplest and safest for evidence quality: files keep their original timestamps, names, and location. The costs are storage growth and the discipline of leaving the folder alone — no reorganizing, no "helpful" renaming, nothing that alters metadata.
2. Copy to a hold area, then continue. The operational flow may have to keep consuming or clearing files. In that case, a scheduled copy step captures each in-scope file to a dedicated, access-restricted hold folder before normal processing proceeds. The hold area gets its own rules: no purge job at all, and access limited to named accounts. Ideally, a hash is recorded for each captured file at capture time so its integrity can be demonstrated later. The mechanics are in our hashing explained guide. The discipline of documenting who touched what belongs to our chain of custody series.

Whichever pattern applies, tighten access. Preservation is not just "don't delete" — a held file that gets edited is nearly as compromised as one that vanished. Read-only permissions for regular accounts on hold areas, and scrutiny of who retains write access, follow directly from the instruction. "Helpful" is the most dangerous word near a held folder.

Documenting Compliance: Make the Hold Auditable

Months or years later, someone may ask you to demonstrate that the hold was honored. The answer is a hold log — a running record kept from the first hour. It records when the hold arrived and from whom, and when you acknowledged it. It records each automated process paused, with timestamps, and the scope worksheet and its revisions as legal answered your questions. It records each preservation action and every later event that touched the held data.

The strongest entries are the ones a system wrote. Your scheduler's task history shows the purge tasks disabled on the right date. The oldest-file check from your purge monitoring now works in reverse: where it once asserted "nothing here is older than ninety days," it now happily reports files aging past the threshold. That is positive, machine-generated evidence that deletion truly stopped. And the server's activity log shows what happened around the held data itself. On Sysax Multi Server, session and file-operation logging to file or database records any access to the held folders. So you can show not only that nothing was deleted but who viewed or downloaded what, and when. Logs that may become evidence deserve protection themselves; our log tamper resistance article covers keeping them credible.

Close the loop with legal: confirm, in writing, that the hold is implemented, what it covers on your systems, and the date. Silence is compliance nobody can prove.

Living With a Long Hold

Holds routinely outlive the incident energy that greeted them. A year in, the risk is no longer the purge job you forgot to pause — it is drift. New flows get built for the held partner, and their folders must inherit the hold. Staff change, and the successor admin needs to discover the hold exists before they "clean up that weird bloated folder." Storage grows, and someone proposes trimming files that are "just old junk." Guard against all three the same way: the hold log lives in your documentation system. The held folders are labeled in your inventory. A monthly calendar entry re-verifies that pauses hold and captures still run. The retention policy document itself points at active holds so no future cleanup decision is made blind to them. The policy structure in a working retention policy includes exactly that hook. The successor admin will still find the bloated folder; the label just gets there first.

Meanwhile, everything outside the hold's scope keeps aging out normally. A hold is a scoped exception, not a freeze on the estate. Organizations that stop all deletion "to be safe" during litigation build themselves a mountain of new liability and make the eventual cleanup vastly harder. Precision, in both directions, is the professional posture.

Lesser Cousins: Exceptions That Aren't Legal Holds

The hold machinery you build serves smaller occasions too. Consider a billing dispute with a partner that has not gone legal. Or consider an audit team asking that a quarter's files stay put while they sample. Or consider a migration where nothing should be deleted until reconciliation finishes. These are retention exceptions: legitimate, temporary pauses that deserve the same mechanics as a hold with less ceremony. Run them through the same pipeline: a written request from a named owner and an entry in a log. The specific purge tasks are paused or paths excluded. And — the part that separates a managed exception from a permanent hole — there is an expiry date. An exception without an expiry date is how "pause it for the audit" becomes a folder nobody has been allowed to clean in three years. Review open exceptions on the same monthly calendar entry as your holds, and let each one end loudly rather than linger silently. The difference from a real hold stays sharp: exceptions are negotiable and end by schedule; a legal hold is not negotiable and ends only one way.

Release: Ending It Cleanly

A hold ends the same way it began: written instruction from legal, and only from legal. A verbal "I think that matter settled" from anyone — including the data owner — releases nothing. When the written release arrives, reverse the setup deliberately. Re-enable each paused task (your hold log is the checklist, run backward), remove the exclusions, and confirm with the next run's output that purging resumed. Ask the release-era question — what happens to the backlog of files that would have expired during the hold? Usually the answer is that normal retention now applies and they purge on the next cycles. Get that confirmed in writing rather than assumed. Let the automated jobs do the deleting so the removals are logged like any other. Then file the completed hold log with a closing entry. The whole lifecycle — arrival to release — should read like a runbook, because it was one:

LEGAL HOLD RUNBOOK — transfer estate
[ ] 1  Acknowledge receipt to legal in writing; open hold log
[ ] 2  Freeze the risk: pause purge jobs, workflow deletes,
       archive rotation, log deletion for anything plausibly
       in scope; record times
[ ] 3  Ask scoping questions (staging? logs? backups? partner
       side?) — preserve broadly until answered
[ ] 4  Map scope to paths using the folder inventory; write
       the scope worksheet, including exclusions + reasons
[ ] 5  Choose per location: preserve in place / copy to
       restricted hold area (hash at capture)
[ ] 6  Tighten access on held locations; stop any job that
       modifies or renames held files
[ ] 7  Confirm implementation to legal in writing
[ ] 8  Monthly: verify pauses hold, captures run, new flows
       inherited the hold; log the check
[ ] 9  On written release only: re-enable jobs from the log,
       confirm purging resumed, settle backlog handling in
       writing, close the hold log

The Short Version

A legal hold is the instruction that outranks your entire retention machine. Preservation duties begin when it arrives, and automated deletion is the thing most likely to violate it in the first hours. Your role is prompt, verifiable compliance. Pause every in-scope deleter fast, and ask scoping questions instead of interpreting. Preserve in place or capture to a restricted hold area, and write everything down as you go. Scoped per-folder purge jobs make compliance surgical, system-generated logs make it provable, and a written release — nothing less — ends it. Build the runbook into your program now, alongside your purge automation and the one-page retention policy that ties the whole discipline together. The day a hold arrives, you want to be executing a checklist, not inventing one. As for purge-inbox-acme: disabled at ten fifteen, timestamp in the log, and five tomorrow morning arrives without incident.

Frequently Asked Questions