Legal hold software: what the category does, and how to evaluate it

This is a category explainer and evaluation framework, not a ranking or product review. It describes legal hold software without recommending a vendor or providing legal advice for a particular matter.

What the legal hold software category does#

A legal hold platform supports the administrative work surrounding a preservation obligation. At its core, it creates a record of who received a hold, what they were told, whether they acknowledged it, and what happened to it later.

The goal is not merely to distribute an email. A useful platform connects notice, custodian management, source-system preservation, escalation, and reporting so that the organization can demonstrate that its preservation activity was deliberate and verifiable.

Administrative tasks that can be automated#

Legal hold tools commonly support several recurring tasks:

• Issuing notices: generating a hold notice from a defined custodian list, including the relevant scope and instructions.
• Tracking acknowledgment: recording whether each custodian confirmed receipt and understanding.
• Sending reminders: applying a schedule for follow-up notices to missing or incomplete acknowledgments.
• Maintaining a notice history: recording who was told what, when it was sent, which version they received, and how they responded.
• Supporting custodian interviews: collecting interview questions, scheduling, notes, follow-up items, and status information.
• Releasing holds: notifying custodians that a hold has ended and documenting the release.

Automation reduces manual work, but it does not establish that the right people or sources were included. The record is only useful if the underlying custodian and source data were accurate when the hold began and remained accurate as personnel and information changed.

Preservation in place versus notice administration#

The most consequential distinction is whether a legal hold platform can take preservation action in connected source systems. A communication-only product may send notices and collect acknowledgments while the underlying mail, files, chat messages, or other ESI continue to follow an existing retention path.

A platform with preservation capabilities may be able to suspend deletion, place a source under preservation, capture content, or preserve associated metadata. The exact action depends on the connected system and the integration. Preserving a mailbox, for example, is not the same as preserving every retained item within it, and protecting a chat workspace does not necessarily preserve content in every application that populated it.

Evaluation should therefore separate three questions: Does the tool administer notices? Does it record responses? Does it actually change the preservation behavior of a source system? A feature described broadly as “preservation” should be tested against specific systems, content types, and actions.

Integration coverage#

Holds are only as effective as the systems they touch. An enterprise tool may connect to mail, file storage, chat and collaboration platforms, and HR systems, but connection does not necessarily mean equal preservation coverage. Authentication rights, data model differences, archived content, and source-specific retention settings can affect what the platform can see or preserve.

Ask for a source-by-source inventory rather than a generic integration list:

• Which applications are connected, and in which direction?
• Can the tool read custodian identity, locate content, and preserve it?
• Does preservation cover active, archived, and deleted-but-recoverable material?
• Are preservation actions confirmed back to the platform with a time-stamped record?
• Can failures, unsupported content, and permission gaps appear in reports?

HR and identity systems serve a different purpose. They help keep custodian lists current as people join, transfer, leave, or change roles. They do not replace preservation integrations for the systems in which those people created information.

Keeping custodian lists current#

Custodian administration is a recurring control, not a one-time upload. Employment changes, reorganizations, acquisitions, and the discovery of additional data sources can all alter who should receive a notice. The platform should support scheduled or event-driven synchronization, while preserving a dated record of how the list changed.

Watch for distinctions among employees, contractors, former employees, and members of shared teams. A person may leave the organization but remain relevant as a custodian whose information remains in a system. The release workflow must not treat departure and release from preservation as interchangeable events.

Access controls also matter. Custodian questionnaires, interview notes, and exported reports may contain sensitive information. Evaluate role-based access and whether the audit trail records administrative changes as well as substantive hold events.

Retention conflicts and deletion pathways#

A hold may encounter an existing retention policy that is already deleting information. The relevant question is not whether the legal hold platform can send a notice to a custodian. It is whether the platform has altered the source system’s deletion behavior before information is removed.

Ask what happens when a preservation action conflicts with a deletion job or a user-initiated deletion. Does the source reject the action, preserve the item, or continue without recording the conflict? Does the platform capture an event that identifies the system, custodian, item, action, and time? Can an administrator distinguish a successful preservation action from a request that merely appeared in an activity log?

This distinction is central to demonstrating reasonable preservation steps. A communication-only record may show that a custodian was instructed not to delete information, but it cannot establish that the source system stopped deleting it.

Non-custodial sources#

Some sources do not map neatly to individual custodians. Shared mailboxes, team spaces, project repositories, archives, and data inherited through a corporate transaction may contain relevant material without having an obvious custodian. The evaluation should address how these sources are classified, assigned, and reported.

Do not accept an assumption that a source without a named custodian is outside the hold. Conversely, the platform should not treat every shared location as a custodian record without a defined owner and scope. Ask how source-based preservation appears alongside person-based notices and acknowledgments in the audit record.

Release management#

Releasing a hold involves more than sending a release email. The platform should record which hold ended, when it ended, which custodians and sources were affected, and who authorized the action. It should also identify any sources or custodians that remained subject to another hold.

Separate the legal act of release from the technical disposition of data. Restoring ordinary deletion after release is a system action with different consequences from confirming that a notice was sent. Reports should make those events distinguishable.

A defensible release record answers basic questions without reconstruction: Which obligations ended? Which sources changed status? Were there exceptions or duplicate holds? What instruction did each affected person receive?

Auditability and exportability#

Auditability requires more than a dashboard. The underlying event record should support a reconstruction of the hold’s administration and, where supported, source-system preservation activity. Reviewers should be able to identify notice creation, delivery, acknowledgment, reminder, escalation, source-preservation action, exception, and release.

The export is itself an evaluation item. Determine whether an administrator can export the complete history outside the platform in a usable format. A record locked inside the application may be difficult to produce, compare with another hold, or inspect when circumstances change.

Look for event timestamps, actor identity, affected custodian or source, action type, notice version, and outcome. Reports based only on current status are less useful than reports that show how the status developed.

Questions that expose the limits of a demonstration#

A polished notice workflow can conceal a limited preservation architecture. These questions are designed to move the evaluation beyond the demo:

1. What happens when a custodian never acknowledges? Ask which reminders are scheduled, who receives escalation reports, whether the status can be overridden, and whether the history preserves every attempt and response. Then ask whether a missing acknowledgment changes anything in connected source systems or remains purely an administrative status.
2. How does the tool interact with a retention policy that is already deleting? Request a specific explanation of the source action, the timing, the failure behavior, and the record generated. “The tool preserves data” does not answer whether the preservation occurred before deletion, covered the relevant content, or can be verified later.
3. Can the audit export be inspected? Ask to see an export containing notices, delivery events, reminders, acknowledgments, source-preservation events, exceptions, and releases. Then ask whether another reviewer can reconstruct the history without relying on the live dashboard.
4. What remains outside the tool? Ask which connected sources provide only notice delivery, which support preservation, and which produce no record of a technical action. The answer should be specific enough to reconcile the platform report with the organization’s actual systems.

Evaluation criteria#

The following framework keeps the comparison focused on functions that affect preservation and evidentiary confidence:

Reasonable steps and the record under Rule 37(e)#

Legal hold technology is relevant to eDiscovery because it can make preservation activity demonstrable. It can show that custodians and sources were identified, notices were issued, responses were tracked, preservation actions were attempted, exceptions were recorded, and releases were documented.

Rule 37(e) addresses electronically stored information that should have been preserved and was lost. Under the first tier, on a finding of prejudice, a court may order measures no greater than necessary to cure the prejudice. Under the second tier, only on a finding that a party acted with the intent to deprive another party of the information may a court presume the information was unfavorable, instruct the jury that it may so presume, or dismiss the action or enter default judgment.

Tooling does not replace the need to establish what the rules require in a particular matter. It does, however, help preserve evidence that reasonable steps were taken and where gaps occurred. Rule 26(f) requires the parties to confer before the scheduling conference, and Rule 16(b) governs the scheduling order, making preservation sources and unresolved implementation issues appropriate subjects for that planning process.

A defensible operating model#

The strongest legal hold platform is not necessarily the one with the longest feature list. It is the one whose custody records, preservation actions, exceptions, and exports can be reconciled across the systems that actually contain ESI.

Evaluation should therefore end with a coverage statement: Which sources were preserved technically, which were addressed through notice alone, which custodians did not acknowledge, which integrations failed, and what record supports each conclusion. That statement converts legal hold software from an email tracker into evidence that the organization can examine when the hold, the litigation, or the scrutiny arrives later.