Litigation Hold vs Deletion Request: When a Legal Hold Beats the Right to Erasure

A litigation hold beats a deletion request, but not because a hold is more important than a privacy right. It wins because both the GDPR and every US state privacy law contain an exception for complying with a legal obligation, and a preservation duty backed by a court is one. The consequence is narrower than most teams assume: the hold protects the specific records within its scope, for as long as the matter lasts, and nothing else. The rest of that person's data still has to be deleted, on the original clock, with a written explanation of what you kept and why.

The failure mode is almost never the legal analysis. It is that the hold and the request are handled by two different people in two different systems, and neither one can see the other. Legal issues the hold by email to a list of custodians. Privacy runs the deletion in the tools that hold customer data. Whether those two sets overlap is nobody's job to know, which is how companies end up destroying data under hold and, just as often, refusing to delete far more than the hold ever covered.

Does a litigation hold override a deletion request?

For the data inside the hold, yes. A legal hold suspends routine destruction of records relevant to litigation that is anticipated or already under way, and that preservation duty qualifies as a legal obligation under the exceptions written into these laws. What it does not do is suspend the request. You still owe a response inside the statutory window, you still have to delete everything the hold does not reach, and you still have to say what you retained.

Here is how each regime handles it.

Read the two GDPR rows together, because this is where competent teams get it wrong. The instinct is to reach for the legal obligation exception, since that is the one everybody knows. It does not work for American litigation. Article 17(3)(b) is expressly limited to obligations arising under Union or Member State law, and a preservation order from a US federal court is neither. The provision that does the work is Article 17(3)(e), the establishment, exercise or defence of legal claims, and it is a different test: necessity, assessed against the claim, record by record.

What is a litigation hold?

A litigation hold, also called a legal hold, is an instruction to suspend the routine deletion of information that may be relevant to a legal matter. In practice it has three parts: a written notice to the people and systems custodying the data, the suspension of any automated process that would otherwise destroy it, and a record proving both happened. The notice is the part everyone does. The suspension is the part that fails.

The teeth come from Rule 37(e) of the Federal Rules of Civil Procedure, which applies when electronically stored information "that should have been preserved in the anticipation or conduct of litigation is lost because a party failed to take reasonable steps to preserve it, and it cannot be restored or replaced through additional discovery". Where the loss prejudices the other side, a court "may order measures no greater than necessary to cure the prejudice". Where a party "acted with the intent to deprive another party of the information's use in the litigation", the court may presume the lost information was unfavorable, instruct the jury to presume it, or dismiss the case outright.

That second tier is the reason legal teams write holds broadly and lift them reluctantly. An adverse inference instruction can decide a case. Set against that, a privacy fine is a cost, and any general counsel weighing the two will over-preserve. Knowing that is useful, because it tells you the pressure on the scope of the hold runs one way and somebody has to push back the other.

When does the duty to preserve begin?

Before the lawsuit. Rule 37(e) refers to information that should have been preserved "in the anticipation or conduct of litigation", so the obligation attaches when litigation is reasonably anticipated, not when you are served. A demand letter, a regulatory inquiry, an internal escalation that plainly points toward a claim: each can start the clock. This matters for privacy work because it means a deletion request can arrive during the window where a duty exists but no hold has been issued yet, and deleting on schedule at that moment is still spoliation.

It also runs the other way, and this is the more common and more expensive error. A hold issued three years ago for a matter that settled two years ago is often still sitting there, quietly exempting data from every deletion request that touches it. Nobody lifted it, because lifting a hold has no deadline and no owner. Holds typically originate in outside counsel's matter file, where the case chronology and its deadlines are tracked, while the 45-day deletion clock runs in an entirely separate queue on your side. When the matter closes in one system and nothing changes in the other, you are refusing deletions on the authority of a case that ended.

Can a US litigation hold override a GDPR erasure request?

It can justify retention under Article 17(3)(e), but it does not resolve the conflict, and there is now a well-documented example of how that plays out.

In the consolidated OpenAI copyright litigation in the Southern District of New York, In re OpenAI, Inc., Copyright Infringement Litigation, 25-md-3143, Magistrate Judge Ona T. Wang entered an order on May 13, 2025 directing OpenAI, in the court's words, "to preserve and segregate all output log data that would otherwise be deleted on a going forward basis until further order of the Court (in essence, the output log data that OpenAI has been destroying), whether such data might be deleted at a user's request or because of 'numerous privacy laws and regulations' that might require OpenAI to do so."

That is the collision stated as plainly as a court is ever going to state it. A US federal court directed a company to retain data that users had asked it to delete and that privacy laws required it to delete, and the order expressly contemplated both. OpenAI objected on privacy grounds and was directed to preserve anyway. Conversations originating in the EEA, Switzerland and the UK were reported to sit outside the preservation scope, which is itself instructive: the practical resolution was geographic partition, not a legal reconciliation. The going-forward preservation obligation was terminated effective September 26, 2025 by an order filed on October 9, 2025, though logs already preserved remain retained, as does data tied to accounts the news plaintiffs specifically flagged.

Three things are worth taking from it. A preservation order can reach data you have already promised to delete. The obligation is finite and ends, but the data preserved during it does not automatically disappear when it does. And if you operate across both regimes, the question of which users a US order actually reaches is worth resolving early, in writing, rather than during a deposition.

What a legal hold does not let you do

This is the half of the topic that gets skipped, and it is where the regulatory exposure actually sits. A hold is a shield for specific records. It is not a shield for the request.

• It does not stop the clock. You still respond within 45 days under the state laws, or one month under the GDPR. A hold is a reason for a partial denial, not an extension.
• It does not cover the person. It covers records within its scope. A customer under hold for a contract dispute still gets their marketing profile, support history and analytics records deleted, unless those are within scope too.
• It does not excuse the explanation. You have to tell the requester you are retaining data and on what basis. "Legal reasons" is not a basis. Naming the exception is.
• It does not authorize continued use. Preserved data is preserved, not available. Continuing to market to someone whose deletion you refused on preservation grounds converts a defensible retention into an indefensible one.
• It does not survive the matter. The exception lasts exactly as long as the obligation justifying it, which is the same rule that governs every other slice you keep. That principle runs through the whole of what a data retention policy has to disclose, and a hold is not an exception to it.

The related trap is treating your own retention schedule as authority. It is not. Only a statutory exception lets you refuse deletion, and your policy is your decision rather than the law's. The CCPA's list runs to eight, at Civil Code 1798.105(d), and complying with a legal obligation is the last of them; the full set is broken down in the guide to the CCPA right to delete.

How to run a hold and a deletion request at the same time

The workable version of this is a sequence, and it only works if the scope question gets asked before anything is deleted rather than after.

1. Log the request and start the clock the day it arrives. Verification and legal review both run inside the window, not before it.
2. Find where the person's data lives across every system, not just the ones you remember. You cannot compare a hold's scope against a data set you have not assembled, and this discovery step is the one that consumes the 45 days.
3. Check the identified data against every open hold, by matter, by custodian and by system. This is the step that does not exist in most companies, and adding it is most of the fix.
4. Split the record set. Data inside a hold's scope is retained and marked with the matter that justifies it. Everything else is deleted, including for the same individual.
5. Propagate the deletion to service providers, contractors and any third parties you sold or shared the data with, minus the retained slice.
6. Respond, and say what you kept. Name the exception, describe the categories retained, and keep the whole thing dated.
7. Re-run the retained slice when the matter closes. A closed hold turns retained data back into ordinary data, and ordinary data that a consumer already asked you to delete should now be deleted.

Step 7 is the one nobody builds, and it is the one a regulator would find most interesting, because the paper trail proves you knew the data was there. That last step is easier to run when the original request produced a written manifest of exactly which systems held that person's records, which is the artifact deletion request software exists to produce. Without it, reopening a two-year-old request means starting the discovery work over.

Does a legal hold apply to backups?

Usually yes for preservation, and this is where the two obligations pull hardest in opposite directions. Rule 37(e) asks whether lost information "cannot be restored or replaced through additional discovery", which is precisely what a backup does, so a backup that would otherwise rotate out often has to be frozen once a hold attaches. Meanwhile the deletion request you received asks you to erase the same records from everywhere you hold them.

The honest answer for records inside a hold's scope is that they stay in the backup and you say so. For records outside it, the common practice is to delete from live systems, document that backups are on a defined rotation, and delete on restore rather than restoring a backup to erase one person. Whichever approach you take, the requirement is that it is written down before you need it, applied consistently, and disclosed rather than implied. A vague answer here reads as evasion, and it is one of the more frequent grounds for a complaint escalating.

The practical summary

A litigation hold is a legitimate reason to keep specific data past a deletion request, and it is one of the few reasons that will hold up. It is also narrower, shorter and more paperwork-heavy than the way most teams use it. The defensible position is a scoped hold, checked against a real inventory of where the person's data lives, applied to records rather than to people, explained in the response, and revisited when the matter ends.

The indefensible position, and by far the more common one, is a hold nobody lifted, applied to a person nobody re-examined, justifying a refusal nobody documented. Both look identical from the outside until someone asks. If you want the fuller picture of how deletion differs from access in scope and verification, the comparison of a DSAR and a deletion request covers where the two workflows diverge, and the guide to DSAR exemptions covers the other grounds for withholding.