Legal Hold Requirements for IT
Reviewed by Fully Compliance editorial team
Legal hold requires IT teams to stop all routine data destruction and preserve information relevant to anticipated litigation. This means reconfiguring email purging, backup rotation, and file cleanup systems while maintaining complete metadata, implementing technical barriers to deletion, formally notifying custodians, and documenting every step to avoid sanctions under Federal Rule 37(e).
When litigation is anticipated or threatened, the duty to preserve evidence kicks in immediately. This is legal hold: the obligation to cease normal data destruction and retention practices and to preserve any information relevant to the dispute. It sounds straightforward in theory — stop deleting things — but the practical obligation depends entirely on what your IT systems are actually doing and whether they can be repurposed to preserve information rather than destroy it.
Legal hold is not something IT implements in isolation. It requires a conversation between the lawyers identifying what needs to be preserved, the IT team understanding what the systems can and cannot do, and clear procedures for notification, implementation, and verification. This is where many firms stumble. The litigation partner receives a litigation notice and tells IT to put a hold on relevant data, but IT doesn't know whose systems to hold, what retention settings to change, or how to verify that nothing's been deleted in the meantime. Worse, IT systems designed for efficient data destruction — automatic backup rotation, email purging, temporary file cleanup — now have to be reconfigured for preservation. This isn't something you figure out for the first time when litigation arrives.
The Duty to Preserve Begins Before a Lawsuit Is Filed
According to a 2023 Hanzo survey, 67% of organizations reported difficulty implementing litigation holds across all relevant data sources. Federal Rule of Civil Procedure 37(e) covers sanctions for failure to preserve electronically stored information, and state equivalents in most jurisdictions enforce similar obligations. The duty is triggered immediately upon reasonable anticipation of litigation — not when a lawsuit is filed, but when circumstances suggest litigation is likely. A demand letter from a lawyer triggers the duty. A regulatory agency announcing an investigation triggers the duty. A client relationship deteriorating in ways suggesting malpractice litigation triggers the duty.
The scope of legal hold is not "all information in the company." It's information relevant to the anticipated dispute — anything that has a tendency to make a fact more or less probable than it would be without the information. In practice, this means communications about the matter in question, data related to the product or service at the center of the dispute, information about the people involved, and information about decisions made by your firm in connection with the matter.
This requires lawyers to be precise about what's relevant. "Preserve everything" is overly broad and creates impossible preservation obligations. "Preserve communications with the client" is clear. The legal team needs to think through what information would actually matter in a dispute and instruct IT accordingly. This precision protects IT from impossible preservation tasks and protects the firm from over-preserving information that should be deleted once the hold is lifted.
IT Systems and the Preservation Problem
Preservation sounds like IT's responsibility, but it requires IT to understand what information exists, where it's stored, and how the systems currently manage it. Email systems typically have automatic purging — messages older than a certain age are deleted, backup tapes are rotated and eventually destroyed. File servers have quotas that delete old versions of documents. Databases have automated data purging. Instant messaging systems like Slack auto-delete messages. Phones and laptops have settings that delete data when devices are wiped or when employees leave. If litigation is anticipated and none of these systems have been paused or reconfigured, relevant information is still being destroyed even as the firm believes a hold is in place.
The lawyers can issue a hold instruction, but the instruction only works if the IT systems supporting the hold are actually designed to support preservation. This requires IT to have catalogued what systems hold relevant data, documented the default destruction settings for each system, and established a procedure for implementing preservation — changing those defaults, pausing automatic purges, flagging data for retention.
For email, this means identifying the mailboxes of relevant people, placing those mailboxes on litigation hold within the email system, and ensuring the system understands that held messages should never be auto-purged. Most modern email systems support this through a "litigation hold" or "in-place hold" feature. Legacy systems require manual evidence collection and export to a separate repository.
For file servers, preservation involves placing a specific folder or matter directory on a retention hold, preventing any files within that directory from being automatically deleted or archived. For databases, it involves flagging certain records as hold data, changing automated purging rules to exclude held data, or exporting data to a separate preservation repository.
The key requirement is that preservation must be comprehensive and verifiable. You need to know that all relevant data is being preserved, that nothing relevant is being deleted despite the hold, and that you can prove this through documentation and log files.
Metadata and the Completeness Problem
One of the most frequent failures in legal hold implementation is preserving the data without preserving the metadata. Metadata is the data about the data — creation dates, modification dates, who created the file, who last modified it, email metadata like sender, recipient, subject, date sent. This information is critical to establishing relevance in litigation, establishing authenticity, creating a chain of custody, and establishing that information wasn't altered.
A document on a file server isn't just the content. It's also the file path, file name, date created, date modified, user who created it, user who last modified it, access permissions, and the full sequence of modifications if the system tracks versions. When you preserve a file, you need to preserve all of this metadata intact. Exporting to a different system or copying to a backup location risks stripping metadata if the process isn't designed carefully.
For email, metadata includes the full headers — not just the To, From, and Subject users see, but all the internal routing information, timestamps, and system information that shows the path the message took. Email systems that export messages to PDF or print them strip this metadata and create documents that are less reliable as evidence.
This is where the distinction between legal hold and routine backup becomes important. A routine backup is great for disaster recovery but is not suitable for legal hold because it won't include all metadata, was processed in a way that altered information, or isn't easily reviewable for privilege. Legal hold preservation needs to maintain complete metadata and defensible chain of custody.
Notification, Acknowledgment, and Compliance
Legal hold only works if the people who control the data know about the hold. The legal team identifies the relevant custodians and notifies them with clear instructions about what data to preserve and what they cannot do with their systems.
A legal hold notice to an employee instructs them to stop normal practices: don't delete old email, don't purge files, don't archive to backup media for deletion, don't wipe old devices. The notice needs to make clear that the hold takes precedence over normal data management practices.
The notification needs to be documented. You need to show that custodians received the notice, understood the hold, and acknowledged their responsibilities. Many firms use signed acknowledgments — the employee signs a form confirming they received the notice and understand what they must and must not do.
IT also needs formal notification specifying which systems are under hold, what the hold encompasses, and what IT's role is in supporting the hold.
Technical Barriers to Deletion
In a mature legal hold program, IT implements technical barriers that prevent deletion of held data even if a custodian tries to delete it. For email, held mailboxes have permissions set so the user can read and create new messages but cannot delete messages. For files, held directories are made read-only. For mobile devices, remote wipe commands are disabled for held devices.
These technical barriers are evidence of the firm's commitment to preservation. If the firm has implemented technical barriers, it's much harder for opposing counsel to argue that the firm failed to preserve information.
Technical barriers can be problematic if they prevent users from doing their actual jobs. Some firms use a tiered approach — most held data is preserved through policy and monitoring, but data deemed most critical to the dispute is locked down with technical barriers.
Hold Duration and Release
Legal holds last for months or years. During that time, IT systems are in preservation mode, databases aren't being purged, email isn't being auto-deleted. This creates significant operational challenges and costs.
The hold continues until explicitly released when the underlying dispute is resolved. The legal team instructs IT to lift the hold, and IT can resume normal data destruction practices.
Release creates risk. Some firms wait for written confirmation from counsel that the matter is fully concluded. Others use gradual release — first releasing clearly irrelevant information, then data beyond the relevant date range, working through held data methodically.
Documentation of hold release is as important as documentation of hold implementation. Maintain records showing who released the hold, when, and what instruction was given to IT.
Intersection with Retention Policies
Legal holds create a tension with ordinary data retention policies. If litigation is anticipated during the retention period, the legal hold overrides standard policies. Information that would normally be deleted under the retention schedule is preserved indefinitely until the hold is lifted.
The safest approach is for IT to have a specific hold status in its data management systems. Data under legal hold is flagged, excluded from ordinary retention processing, and handled only according to legal hold instructions. Regular reports show what data is currently under hold and when it's expected to be released.
Integration with e-discovery systems creates additional complexity. The formats and metadata preserved during the hold need to remain intact through the e-discovery process. Preservation and e-discovery need to be designed together.
Consequences of Hold Failure
Hold failure is one of the most serious problems in litigation. Under Federal Rule 37(e), if a party fails to preserve electronically stored information due to intentional or reckless conduct, the court can order sanctions including striking claims or defenses, ordering default judgment, or instructing the jury to presume the lost information would have been harmful to the spoliating party.
For a law firm, hold failure creates direct liability to clients (malpractice claims) and liability to opposing parties (sanctions for spoliation). The adverse inference instruction can be outcome-determinative.
This is why legal hold is not a discretionary compliance item — it's a professional liability issue. The cost of implementing a robust legal hold program is trivial compared to the cost of hold failure.
Building Hold Capability Into IT Systems
Legal hold needs to be built into your IT architecture long before litigation arrives. This means email systems that support litigation holds, file servers with retention management capabilities, procedures for identifying custodians, notifying them, implementing technical barriers, and monitoring compliance. It means regular testing and training for IT staff.
The firms that manage legal holds smoothly have thought through the process in advance, tested it, trained their teams, and designed their IT systems to support it. The firms that struggle are figuring it out for the first time when the litigation notice arrives.
Frequently Asked Questions
How quickly does a legal hold need to be implemented once litigation is anticipated?
Immediately. Courts have sanctioned organizations for delays of even days when information was destroyed during the gap. The standard is "reasonable promptness," and given that automated deletion happens continuously, anything beyond 24-48 hours creates risk. Pre-built hold procedures and tested systems are the only way to meet this timeline consistently.
Does a legal hold apply to personal devices employees use for work?
Yes. If employees use personal phones, laptops, or tablets for work-related communications or document storage, those devices fall within scope if they contain relevant information. BYOD policies need to address litigation hold scenarios explicitly.
What happens to a legal hold when an employee leaves the firm?
The hold survives the employee's departure. Their accounts cannot be deleted, their devices cannot be wiped, and their data cannot be destroyed while the hold is active. The firm must preserve the departing employee's data and ensure continued access for e-discovery purposes.
Can cloud-stored data be preserved under a legal hold?
Yes, and it must be. Microsoft 365, Google Workspace, and most enterprise platforms support litigation hold features. The firm should enable these features, verify that cloud backup and archiving settings preserve rather than purge held data, and document the cloud provider's preservation capabilities as part of the hold record.
Who is responsible for implementing a legal hold — the legal team or IT?
Both. The legal team defines what needs to be preserved and issues the hold notice. IT implements the technical preservation — pausing automated deletion, configuring system-level holds, monitoring compliance. Neither team can do it alone, which is why coordination procedures need to be established before litigation arrives.