Back to docs
Research Operations

Legal Hold and E-Discovery for Customer Research Data

How to place a legal hold on interview transcripts, recordings, and research records — what triggers the duty to preserve, how it overrides your deletion schedule, and how to reconcile a hold with GDPR erasure requests.

A legal hold is an instruction to stop deleting. It overrides your retention schedule, your auto-deletion settings, and your instinct to tidy up — and the duty to issue one starts when litigation becomes reasonably foreseeable, not when a complaint arrives. For research teams that means the interview you were about to purge under a 12-month retention policy may need to survive for years, and the tooling decision that matters is whether you can find and freeze it at all.

This guide is written for ResearchOps and research leaders working with legal counsel. It is not legal advice — scope, triggers, and obligations vary by jurisdiction and by matter, and your counsel decides all three.

Why research data is a discovery target

Product and customer research produces exactly the kind of record litigators look for: dated, first-person, and written before anyone was defending a position.

ArtifactWhy it matters in discovery
Interview transcriptsVerbatim customer statements about a defect, harm, or promise
Audio and video recordingsThe primary record; consent status is often contested alongside it
Screener and intake responsesEstablishes who was recruited and what they were told
Consent recordsCentral to any privacy or recording-law claim
Structured question responsesQuantified, timestamped evidence of prevalence
Analysis notes and tagsShows how the organisation interpreted what it heard
Research reports and readoutsContemporaneous evidence of corporate knowledge and its date
Slack or email threads about findingsOften the most damaging, and the most often forgotten

The last two rows are why research teams get pulled into matters they had no idea they were part of. A usability report noting that 8 of 12 participants missed a safety disclosure is not just an insight; in a product-liability matter it is a document establishing notice.

What triggers the duty to preserve

The duty attaches when litigation is pending or reasonably anticipated. In practice, the triggers a research team should escalate include:

  • A demand letter, claim, or notice of arbitration
  • A regulatory inquiry or information request
  • A serious internal complaint or whistleblower report touching a product area you research
  • A decision by your own organisation to bring a claim
  • A pattern of customer complaints that legal is already tracking

FRCP 37(e) is important to understand precisely: it does not create a duty to preserve. It applies only where a duty already existed and in-scope electronically stored information was lost because reasonable steps were not taken. That framing has two consequences. First, information lost before the duty arose is not covered — routine deletion under a documented schedule is defensible right up until the trigger. Second, courts assess "reasonable steps" in context, explicitly considering the routine, good-faith operation of an electronic information system and the proportionality of preservation efforts to the matter and the party's resources.

Which is to say: a documented, consistently applied retention schedule is your protection, and an ad-hoc one is your exposure.

The sanctions ladder, and why intent is the hinge

Rule 37(e) sets out two tiers once in-scope ESI is lost and cannot be restored or replaced:

  1. On a finding of prejudice to another party, the court may order measures no greater than necessary to cure that prejudice — additional discovery, cost-shifting, or permission to present evidence about the loss.
  2. Only on a finding that the party acted with intent to deprive another party of the information's use may the court presume the lost information was unfavourable, instruct the jury that it may or must so presume, dismiss the action, or enter default judgment.

The severe remedies require intent. That is precisely why the process is the deliverable: a dated hold notice, a documented scope, a record of which systems were frozen, and evidence that auto-deletion was suspended are what separate an unfortunate gap from an inference of bad faith.

Scoping a hold across research systems

A hold notice that says "preserve all research documents" is unactionable. Scope it along four axes:

  • Custodians — the researchers, PMs, designers, and analysts who touched the topic. Include people who have since changed teams.
  • Systems — your research platform, repository, transcription tools, cloud storage, note-taking apps, ticketing, and messaging. Research data leaks into personal Drive folders more than anyone admits.
  • Date range — usually open-ended forward from a start date, since new research on the same topic falls in scope too.
  • Subject matter — the product area, feature, cohort, or claim. Be concrete enough that a researcher can answer "is my study in scope?" without emailing legal.

Then do the thing most teams skip: write down what you found and where. A preservation memo listing each system, who searched it, on what date, and with what query is the single most useful artifact you can produce, and it is nearly impossible to reconstruct a year later.

The operational checklist

  1. Acknowledge the hold notice in writing, with a date.
  2. Suspend automated deletion for in-scope studies — this is the step with the shortest fuse.
  3. Suspend routine participant-data purges for in-scope participants only.
  4. Freeze the analysis layer, not just the raw data: tags, notes, and report versions.
  5. Export a preservation copy in a stable format and store it under access control.
  6. Notify custodians individually and confirm receipt.
  7. Log the whole thing.
  8. Re-issue reminders periodically; holds routinely outlast the people who received them.

Step 4 is the one researchers underestimate. If your repository lets someone re-tag or edit a report in place, the version that mattered may already be gone. Preserve the readout as it existed, not as it currently reads.

When a hold collides with privacy obligations

This is the genuine hard case, and the one that paralyses teams. A participant submits a GDPR erasure request for data that is under an active legal hold. Deleting breaches the hold; refusing appears to breach the GDPR.

It does not. Article 17(3)(e) states that the right to erasure does not apply to the extent processing is necessary for the establishment, exercise or defence of legal claims. That is the lawful basis for declining, and it exists precisely for this situation.

Handle it properly:

  • Apply the exception only to the data actually within the hold's scope — erase everything else the request covers.
  • Tell the individual that their request has been restricted, on what basis, and that it will be revisited. Silence is what turns a lawful refusal into a complaint.
  • Document the decision, the scope, and the approver.
  • Diary the request against the hold so it is honoured automatically on release.
  • Remember that Article 5(1)(e) storage limitation still applies to everything outside the hold. A hold on one matter is not a licence to stop deleting generally.

Similar carve-outs exist in other regimes — US state privacy laws generally permit retention necessary to exercise or defend legal claims — but the precise wording and scope differ, so confirm with counsel for each jurisdiction you operate in.

Records management: the boring work that makes holds possible

You cannot freeze what you cannot find. Three habits make holds tractable:

  • A research records inventory. One list: every system holding research data, its owner, what lives there, and its default retention. Most teams discover three systems they had forgotten during their first real hold, at exactly the wrong moment.
  • A retention schedule with categories, not one global setting. Raw recordings, transcripts, structured responses, consent records, and published reports usually warrant different periods. Consent records typically need to outlive the recordings they authorise.
  • Consistent study metadata. Product area, cohort, date, and legal-basis tags recorded at study creation are what make "find everything about the checkout flow from 2025" a query instead of an archaeology project.

How Koji supports preservation and production

Koji is built so that a hold is a scoping exercise rather than a database dump.

  • Everything is tied to a study and an interview record. Transcripts, structured responses, and generated reports hang off the study they belong to, so a hold can be scoped by study, date range, or participant rather than by exporting everything and sorting later.
  • Structured questions produce machine-readable evidence. Koji's six structured question types — open_ended, scale, single_choice, multiple_choice, ranking, and yes_no — mean prevalence claims are backed by discrete, timestamped fields instead of by someone's summary of a call. In a dispute about what the research actually showed, that distinction is worth a great deal.
  • Consent and intake are captured with the interview, not in a separate spreadsheet that has to be reconciled under time pressure. See Intake Forms and Consent.
  • Export produces a stable preservation copy. You can export study data — transcripts, structured responses, and reports — for storage in your own controlled environment, which is what a preservation copy needs to be.
  • Workspace roles are explicit. Koji workspaces have three roles — owner, admin, and member — so you can state who had access to what, a question that comes up in nearly every discovery dispute about a research system.
  • Analysis is generated from the transcript, not typed over it. Because Koji's AI produces reports directly from the interview record, the chain from customer statement to reported finding stays intact and reviewable. Traditional workflows — a moderator's memory, a Google Doc of notes, a deck assembled a week later — break that chain at three points, and every break is a place for an opposing party to argue the finding was constructed rather than observed.

The practical benefit compounds with volume. A team running continuous AI-moderated research has hundreds of consistently structured interview records rather than a decade of inconsistently named recordings in shared drives — which turns a hold from a multi-week fire drill into a scoped export.

Releasing a hold

Holds end, and they should end deliberately:

  1. Written release from counsel, dated.
  2. Confirm no other matter covers the same records before resuming deletion.
  3. Resume normal retention and process the backlog of deferred deletions.
  4. Fulfil any privacy requests that were restricted during the hold — this is the step that gets forgotten, and it converts a defensible refusal into a live complaint.
  5. Record the release in the same log as the hold.

Holds that are never released quietly become a policy of indefinite retention, which is itself a privacy and security liability. Closing them out is part of the job.

Related Resources

Frequently asked questions

What triggers a legal hold on research data? The duty to preserve attaches when litigation is pending or reasonably anticipated — which is usually well before a complaint is served. A demand letter, a regulatory inquiry, a serious internal complaint, or a decision by your own company to sue someone can all trigger it. FRCP 37(e) does not create the duty; it governs the consequences when material that should have been preserved is lost.

Are interview transcripts and recordings discoverable? Generally yes. Interview transcripts, audio recordings, screener responses, consent records, structured question data, analysis notes, and the resulting research reports are all electronically stored information. Research reports are particularly consequential because they can be read as contemporaneous evidence of what the company knew about a problem and when it knew it.

Does a legal hold override our data retention schedule? Yes. A legal hold suspends routine deletion for the records within its scope, including automated deletion configured in your research tools. Continuing to auto-delete in-scope material after a hold is issued is the most common route to a spoliation finding, because the deletion is documented and dated by the system itself.

What happens if we delete research data that was under a legal hold? Under FRCP 37(e), if lost ESI cannot be restored or replaced, a court may order measures no greater than necessary to cure the prejudice. If it finds the party acted with intent to deprive another party of the information, it may instruct the jury to presume the lost information was unfavourable, or dismiss the action or enter default judgment. The severe sanctions turn on intent, which is why documented, good-faith hold procedures matter so much.

How do I handle a GDPR deletion request during a legal hold? Article 17(3)(e) provides that the right to erasure does not apply where processing is necessary for the establishment, exercise or defence of legal claims. You can decline the erasure for the specific data within the hold's scope, but you should document the basis, limit the exception to the data actually needed, tell the individual their request has been restricted rather than ignored, and honour it once the hold is released.

Can I export everything tied to one participant from Koji? Yes. Koji lets you export study data — transcripts, structured question responses, and generated reports — and interview records are tied to the study and participant they belong to, so a hold or a subject-access request can be scoped to the specific study, date range, or participant rather than requiring a full-database dump.

Related Articles

Enterprise Security for AI Customer Research Platforms: SOC 2, SSO, and Vendor Review

A procurement-ready guide to evaluating the security of an AI customer research platform — SOC 2, encryption, SSO/SAML, data residency, sub-processors, and the questions your security team should ask.

GDPR-Compliant AI User Research: A Practical Guide

How to run AI-moderated customer interviews under GDPR. Lawful basis, consent flows, data minimization, retention, sub-processors, and how Koji handles each requirement.

Intake Forms and Consent

Collect participant information and consent before interviews begin with customizable form fields.

Interview Recording Consent Laws: One-Party, All-Party, and Biometric Rules (2026)

Federal law allows one-party consent recording, but roughly a dozen US states require all-party consent - and biometric laws like Illinois BIPA add a separate written-consent duty for voiceprints. Here is how research teams stay on the safe side of both.

Managing Research Participants: The Complete Guide to Koji's Recruit Tab

How to track, filter, import, and export research participants in Koji — including personalized links, quality management, and CRM integration.

Research Data Retention and Deletion: How Long Should You Keep Interview Data?

There is no universal legal number - which is exactly why having no retention schedule is itself the compliance failure. A tiered, per-artifact schedule for recordings, transcripts, quotes, and reports, plus how to handle deletion requests without losing your insights.

How to Build a UX Research Repository: The Complete Guide

A research repository transforms scattered insights into a searchable organizational asset. Learn how to build one that teams actually use.

Structured Questions in AI Interviews

Mix quantitative data collection — scales, ratings, multiple choice, ranking — with AI-powered conversational follow-up in a single interview.