Legal Hold Requirements for IT

This article explains IT compliance and security in a specific industry or context. It is not professional compliance advice. Consult with professionals for guidance specific to your situation.

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 that might be 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 that were 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.

Legal Hold as a Duty to Preserve

Legal hold is triggered by the anticipation or initiation of litigation, regulatory investigation, or audit that might produce a legal dispute. At that moment, your firm has a duty to cease ordinary data destruction and preserve information that might be relevant to the anticipated dispute. This is grounded in the Federal Rules of Civil Procedure (Rule 37(e) covers sanctions for failure to preserve electronically stored information) and in state equivalents that many jurisdictions have adopted. It's also enforced through discovery sanctions, professional responsibility rules, and in some cases through damages imposed in litigation for willful destruction of evidence.

The duty is triggered immediately upon reasonable anticipation of litigation — not when a lawsuit is filed, but when the circumstances suggest that litigation is likely. A demand letter from a lawyer on behalf of a party with a claim against you triggers the duty. A regulatory agency announcing an investigation triggers the duty. A client relationship that's deteriorating in a way that suggests potential malpractice litigation triggers the duty. The exact moment is sometimes fuzzy, but the principle is clear: the moment there's a reasonable basis to believe information might be needed as evidence, the destruction stops.

The scope of legal hold is not "all information in the company." It's information that's relevant to the anticipated dispute. Relevant information is typically defined as 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 that's the subject of the dispute, information about the people involved, and information about decisions made by your firm in connection with the matter. Not your employee directory. Not your financial records unless they're relevant to the dispute. Not your email list for office parties.

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. "Preserve all documents relating to the product version deployed to this customer" 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 might have quotas that delete old versions of documents. Databases might have automated data purging. Instant messaging systems like Slack might auto-delete messages. Phones and laptops might 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.

This is where the IT layer of legal hold becomes critical. 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, to have documented the default destruction settings for each system, and to have 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 (the employee involved in the matter, people who reported to that employee, people with decision-making authority about the matter), 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, where you can preserve specific mailboxes without having to export everything. Legacy systems or systems not designed for legal holds might require manual evidence collection and export to a separate repository.

For file servers, preservation might involve 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 might involve flagging certain records or records within a date range as hold data, changing the automated purging rules to exclude held data, or exporting the 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. Some firms implement holds in one system but forget a critical database. They hold employee email but don't hold cloud storage where similar communications occurred. They hold the file server but don't hold backup systems, leaving the firm vulnerable to the argument that data was destroyed through normal backup rotation.

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 sitting on a file server isn't just the content of the document. It's also the file path, the file name, the date created, the date modified, the user who created it, the user who last modified it, access permissions, and the full sequence of modifications if the system is tracking versions. When you preserve a file, you need to preserve all of this metadata intact. Exporting it to a different system or copying it 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 that users see in their inbox, 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 may be less reliable as evidence. Proper email preservation captures the native format and metadata.

This is where the distinction between legal hold and routine backup becomes important. A routine backup of your email server is great for disaster recovery, but it may not be suitable for legal hold because it might not include all metadata, might have been processed in a way that altered information, or might not be easily reviewable for privilege. Legal hold preservation needs to be designed specifically 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. This requires formal notification. The legal team identifies the relevant custodians — the people whose email, file storage, devices, and information systems contain potentially relevant data — and notifies them of the legal hold with clear instructions about what data to preserve and what they cannot do with their systems.

A legal hold notice to an employee typically instructs them to stop the normal practices they'd otherwise follow: don't delete old email, don't purge files, don't archive to backup media for deletion, don't wipe old devices, don't clean up your workspace. For many people this creates confusion — they're being told to violate the data retention and cleanup practices they're normally expected to follow. The notice needs to be clear about what the hold means and needs to make clear that the hold takes precedence over normal data management practices.

The notification also 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. This creates evidence that the firm took appropriate steps to implement the hold. The acknowledgment also creates a record of who was notified, which matters because if information is destroyed despite notification, the willfulness of the destruction becomes more apparent.

IT also needs to receive formal notification. IT needs to know which systems are under hold, what the hold encompasses (specific users, specific date ranges, specific types of data), and what IT's role is in supporting the hold. If IT is supposed to prevent users from deleting held data, IT needs to implement technical controls. If IT is supposed to monitor for compliance, IT needs to have audit capabilities. If IT is supposed to export data for discovery, IT needs to plan the collection process. The notification to IT creates the operational requirement that IT then implements.

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. This is the difference between a legal hold that depends on the good faith of employees not deleting things and a legal hold that is actually enforced by the systems they use.

For email, this might mean that held mailboxes have permissions set so the user can read and create new messages but cannot delete messages. The system prevents deletion at the user interface level. For files, it might mean that held directories are made read-only, so users can access the files but cannot modify or delete them. For mobile devices, it might mean that remote wipe commands are disabled for held devices, preventing the employee from wiping the device even if they leave the company.

These technical barriers are not just convenience features — they're evidence of the firm's commitment to preservation. If the firm has implemented technical barriers to deletion, it's much harder for opposing counsel to argue that the firm failed to preserve information. The system was configured to prevent deletion. The user couldn't delete the information even if they wanted to.

Of course, technical barriers can themselves be problematic if they prevent users from doing their actual jobs. If held mailboxes are read-only, employees can't function for weeks or months while the hold is in place. This is a trade-off between preservation certainty and operational feasibility. 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 to deletion.

Hold Duration and Release

Legal holds can last for months or years, from initial litigation anticipation through the conclusion of litigation or regulatory proceedings. During all that time, IT systems are being held in preservation mode, databases aren't being purged, email isn't being auto-deleted, files aren't being archived. This creates significant operational challenges and costs. IT resources are devoted to maintaining the hold. Storage costs increase because data that would normally be deleted or archived is being retained. Employees on hold are working with constrained systems.

The hold continues until it's explicitly released. Release happens when the underlying dispute is resolved — litigation concludes, the regulatory matter is closed, the potential claim is resolved. The legal team instructs IT to lift the hold, and at that point, IT can resume normal data destruction and management practices. Backup systems can resume their normal rotation. Email systems can resume auto-purging old messages. File servers can resume archive processes. The data that was being held can be deleted according to normal retention schedules.

But release also creates a risk. When you lift a hold, you start destroying information again. If you lift the hold but the matter isn't fully concluded, you may end up destroying information that's still relevant to ongoing disputes. Some firms are cautious about lifting holds until they have written confirmation from counsel that the matter is fully concluded and that there's no possibility of subsequent litigation. Others use a gradual release — first releasing information that's clearly not relevant, then data beyond the relevant date range, gradually working through the held data to minimize the risk of inadvertent destruction of still-relevant information.

Documentation of hold release is as important as documentation of hold implementation. You should maintain records showing who released the hold, when it was released, and what instruction was given to IT. This documentation protects the firm if subsequent litigation raises questions about whether information was properly preserved during the initial hold period. The records show that the hold was in place for the relevant time period and was only released after the matter concluded.

Intersection with Retention Policies

Legal holds create a tension with ordinary data retention policies. A law firm's standard retention policy for email might be to keep messages for three years, then delete them. A retention policy for client documents might be to keep them for seven years after the matter closes. But if litigation is anticipated during the retention period, the legal hold overrides these policies. Information that would normally be deleted under the retention schedule is instead preserved indefinitely until the hold is lifted.

This intersection requires that your firm's legal team and IT team have agreed in advance on how holds interact with retention. If someone issues a legal hold and IT doesn't understand that the hold takes precedence over ordinary retention schedules, IT might continue destroying information according to the regular schedule. If IT implements the hold but doesn't remove the information from the normal deletion queue, the hold might not actually prevent destruction.

The safest approach is for IT to have a specific hold status in its data management systems. Data under legal hold is flagged as such, excluded from ordinary retention processing, and handled only according to legal hold instructions. Regular reports show what data is currently under hold, how long it's been under hold, and when it's expected to be released. This creates visibility into how legal holds are affecting ordinary data management and creates an opportunity for the legal team and IT team to discuss release timing and sequencing.

Integration with e-discovery systems creates additional layers of complexity. Once data has been preserved under a legal hold, it often needs to be collected, reviewed for privilege and relevance, and produced to the other side in litigation. The preserved data becomes the source for e-discovery. The formats and metadata that were preserved during the hold need to remain intact through the e-discovery process. This is why the preservation process and the e-discovery process need to be designed together rather than in isolation — what gets preserved and how it's preserved determines what can be discovered.

Consequences of Hold Failure

Hold failure — when information that should have been preserved was instead destroyed — is one of the most serious problems that can occur in litigation. The consequences range from judicial sanctions and adverse inferences to malpractice exposure for the law firm.

Under Federal Rule of Civil Procedure 37(e), if a party fails to preserve electronically stored information and it's lost in the ordinary course of business without intentional or reckless conduct, the court may order payment of reasonable costs incurred in trying to restore the information or may order other sanctions if the information cannot be restored. If the failure is due to intentional or reckless conduct, the court can order sanctions including striking claims or defenses, ordering default judgment, or in some cases, instructing the jury to presume that the lost information would have been harmful to the spoliating party. These are severe remedies that can determine the outcome of litigation.

For a law firm, hold failure creates both direct liability to clients (malpractice claims for failure to preserve their information) and liability to opposing parties (sanctions for spoliation). The adverse inference instruction — where a court tells a jury to assume that lost information would have been unfavorable to the spoliating party — can be outcome-determinative. Clients with destroyed information may have viable claims against the firm for millions in damages if the destroyed information would have been valuable evidence.

This is why legal hold is not a discretionary compliance item — it's a professional liability issue. Firms that implement legal holds thoughtlessly or that fail to test whether their IT systems actually support legal holds are exposing themselves to significant risk. The cost of implementing a robust legal hold program is trivial compared to the cost of hold failure.

Building Hold Capability Into IT Systems

The practical lesson is that legal hold needs to be built into your IT architecture and practices long before litigation arrives. This means email systems that support litigation holds. It means file servers with retention management capabilities. It means procedures for identifying custodians, notifying them, implementing technical barriers, and monitoring compliance. It means regular testing of the hold mechanisms to ensure they actually work. It means training for IT staff on what legal hold means and what their responsibilities are.

Some firms maintain designated repositories for litigation information — separate from the ordinary file servers and email systems — where information subject to holds is collected and managed. Others use enterprise content management systems with built-in legal hold capabilities. The specific technology matters less than the principle: your IT systems should be designed to support legal holds, not to make legal holds an emergency improvisation done without proper systems.

The firms that manage legal holds smoothly are the ones that have thought through the process in advance, have tested it, have trained their teams, and have designed their IT systems to support it. When litigation arrives, they can implement a hold quickly and confidently because the process is familiar and the systems are ready. The firms that struggle are the ones that are figuring out legal hold for the first time when the litigation notice arrives, discovering in real time what their systems can and cannot do, and hoping they can implement a hold without destroying information in the interim.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about legal hold requirements as of its publication date. Legal hold obligations vary by jurisdiction and continue to evolve. Consult with qualified legal counsel for guidance specific to your firm and matters.