E-discovery and retention requirements under FRCP

A document management, case management, or client communication product built for the legal industry helps lawyers work and often becomes the system that determines what evidence exists when a dispute lands, either the firm's own dispute or one of their clients'. The Federal Rules of Civil Procedure, generally shortened to FRCP, govern what has to be preserved and produced in that situation, and a product's retention and deletion behavior is squarely inside that scope.

What ESI means and why it is the operative term

The rules use the term electronically stored information, generally shortened to ESI, to cover the kind of data most legal software holds: documents, emails, messages, metadata, and any other digitally recorded material relevant to a dispute. Understanding that a product's data is ESI rather than ordinary files is the first step, because the rules attach specific duties to it that do not attach to information in general.

Rule 26: relevant, proportional, and reasonably accessible

Rule 26 sets the general standard for what a party has to produce in discovery: information that is relevant to a claim or defense and proportional to the needs of the case. It also relieves a party of the duty to produce ESI that is not reasonably accessible because of undue burden or cost, though a court can still order production of that information for good cause.

For a product, the proportionality and accessibility language matters because it means not every piece of data your product ever generated has to be producible instantly and cheaply forever. What it does mean is that data your product's design makes reasonably accessible, meaning normal application queries can retrieve it without special effort, is data your customer will likely have to produce if it is relevant. A product that makes older records difficult to retrieve through ordinary means, whether by design or by neglect, can shift what counts as "reasonably accessible," but that shift is not a strategy a product should be built around, since a court's ultimate judgment on accessibility depends on the actual facts of how the system works, not on how convenient a vendor intended the answer to be.

Rule 34: a defined response window

Rule 34 governs the mechanics of a document production request. The responding party has 30 days to respond, either by producing the requested material or by objecting to the request with specificity, meaning a vague objection is not sufficient; the objection has to explain exactly what is being withheld and why.

The engineering implication is narrower but real: a product used for document production needs to support a genuine production workflow within that window, meaning the ability to search, filter, and export the relevant scope of documents without requiring an engineer to write a one-off query. A tool that technically retains everything but has no practical way to search and produce a bounded, relevant subset within 30 days puts its user in a difficult position regardless of how complete the underlying data is.

Rule 37: the sanction that makes retention design matter

Rule 37 is where retention failures become consequential rather than merely inconvenient. It allows a federal court to sanction a party that failed to preserve electronically stored information it had a duty to preserve once litigation was reasonably anticipated, a failure known as spoliation. The available sanctions range from an order to cure the prejudice, up to and including an instruction that permits the jury to presume the missing information was unfavorable to the party that lost it, which is often functionally equivalent to losing the underlying claim.

The rule does not sanction every loss of data. It focuses on whether the party took reasonable steps to preserve the information and whether the loss can be cured. This is exactly where a product's retention design becomes a defense or a liability for its users. A well-defined, consistently applied retention policy, one that is documented, applied the same way to every account and every record type, and suspended in a predictable way when a litigation hold is triggered, is strong evidence that a loss of some data was routine business practice rather than an attempt to destroy evidence. An undefined policy, or one that behaves inconsistently between account types, or one with no mechanism to suspend deletion when a hold is needed, leaves the customer with no good answer when a court asks why a relevant record no longer exists.

What this means for a product's schema

Translated into engineering requirements, three properties matter most.

A single, documented retention rule per record type, applied the same way regardless of which user or account it belongs to. Inconsistency between customers or plans is exactly the pattern that undermines the "consistently applied" defense a firm needs under Rule 37(e).

A litigation hold mechanism that actually suspends deletion, wired into the underlying deletion job rather than living as a flag in the interface. If a firm using your product places a hold on a matter, that hold has to reach every place the data could otherwise be purged, including backups and any downstream export or analytics copy, which is the same enumeration exercise covered in more general form on compliance gaps in legal software.

A production workflow that works within Rule 34's window. Search and export that scope to a specific matter, date range, or set of custodians, tested as an actual capability rather than assumed because the raw data exists somewhere in the database.

Each of those is testable as a check: does a hold placed through the real interface actually prevent the scheduled deletion job from removing the record, does the retention period applied to one account match the one applied to another of the same type, does an export scoped to a date range and a set of users return a complete and accurate set. Building those as automated assertions, rather than trusting that the policy document matches the implementation, is the same argument made in evals as legal compliance evidence.

Whether a specific retention period or a specific hold procedure satisfies a specific court's expectations in a specific matter is a legal judgment a litigator makes case by case, not something this page can settle. What a product can control is whether the technical capability to preserve, produce, and consistently apply a policy actually exists when a firm needs it.