GoTranscript
>
All Services
>

En/blog/participant Withdrawal Workflow Audio Transcripts Checklist

Blog chevron right Legal

Participant Withdrawal Workflow: What to Do With Audio and Transcripts (Checklist)

Michael Gallagher
Michael Gallagher
Posted in Zoom Apr 25 · 27 Apr, 2026
Participant Withdrawal Workflow: What to Do With Audio and Transcripts (Checklist)

When a participant withdraws from a study that includes recorded audio and transcripts, you need a clear workflow: confirm what they mean by “withdrawal,” identify where their data lives, decide what can be removed based on your study design and approvals, and document every action. This article gives a practical, repeatable withdrawal process plus a checklist and tracking fields you can use to stay consistent.

Primary keyword: participant withdrawal workflow

Key takeaways

  • Start by confirming the scope of withdrawal in plain language, then record what you agreed to do.
  • Map and locate the participant’s audio, transcripts, and derived files before you promise deletion.
  • Removal may be limited by consent language, ethics approvals, legal holds, or how your study is designed (for example, fully de-identified datasets).
  • Track each request with basic fields (request date, data located, action taken, confirmation sent) so you can prove what happened later.

1) First: what “withdrawal” can mean for audio and transcripts

Participants often use “withdraw” to mean different things, so you should clarify it before you act. In many studies, withdrawal can include some or all of the steps below, depending on what the participant requests and what your protocol allows.

  • Stop future participation: no more interviews, surveys, or follow-ups.
  • Stop future recording: you may still keep existing data, but you stop capturing new audio.
  • Remove identifiable data: you redact names, voices, locations, or other direct identifiers where feasible.
  • Delete recordings and transcripts: you remove audio files and text transcripts you can still link to the person.
  • Exclude from analysis going forward: you stop using their data in new analyses, even if deletion is not possible.

You should avoid promising deletion until you know what data you have, where it sits, and whether your consent documents and approvals allow full removal.

2) Operational workflow for withdrawal requests (step-by-step)

Use the workflow below as a standard operating procedure for any withdrawal request tied to recordings, transcripts, or both. Keep the steps in the same order so nothing gets missed when the request is urgent.

Step 1: Receive and log the request

Capture the request in a single tracking system as soon as you receive it, even if it comes by phone or during a session. If the participant calls, write down what they said and ask if they can also send a short email so you have a clear record.

  • Assign a request ID.
  • Record the date/time received and who received it.
  • Note the channel (email, phone, in-person, portal).

Step 2: Confirm identity (before you touch any data)

Confirm you are dealing with the right person, especially if you might delete data. Use the minimum identity checks needed to avoid collecting extra personal data.

  • Match the participant to your participant ID using existing contact info on file.
  • Confirm at least one known detail (for example, study nickname, session date, or participant code).
  • If you cannot verify identity, pause and escalate to the study lead or data protection contact.

Step 3: Confirm the scope of withdrawal (in plain language)

Ask specific questions so you understand exactly what the participant wants. Then summarize what you heard and ask them to confirm it in writing.

  • Do you want to stop future contact only, or do you also want existing recordings/transcripts removed?
  • Do you want removal of your audio, your transcript, or both?
  • Do you want us to remove your data from future analysis, even if we cannot delete already de-identified information?
  • Are there specific parts you want removed (name, employer, a story segment) if full deletion is not possible?

Document the final scope as a short “Withdrawal scope statement” you can paste into your tracker.

Step 4: Identify the participant’s data (data map + locations)

Next, identify what data exists for that participant and where it lives. This step prevents partial deletion where backups, shared folders, or vendor systems still contain the files.

  • Raw audio: original recordings, device files, call recordings, Zoom exports.
  • Transcripts: draft transcripts, final transcripts, redacted versions.
  • Derived files: coding spreadsheets, qualitative software exports, annotations, timestamps, summaries.
  • Admin data: consent forms, contact list entries, scheduling emails.
  • Sharing points: shared drives, project tools, email attachments, external transcription or captioning portals.

For each item, record whether it is identifiable, coded (pseudonymous), or truly de-identified.

Step 5: Assess whether removal is possible (and what “removal” means)

Not all study designs allow full removal of all data, so this is the decision point. Base your decision on your consent language, ethics/IRB conditions, contracts, and how your dataset is structured.

  • If data is still linked to the participant: deletion or exclusion is often feasible, but you must do it consistently across systems.
  • If data is de-identified with no key: you may not be able to locate and remove it, so you may need to exclude future use where possible.
  • If results are already aggregated: you usually cannot “pull back” already-published summaries, but you can stop future use of identifiable material.
  • If there is a legal/contract hold: deletion may be prohibited until the hold ends.

If you operate under GDPR and the participant asks for erasure, note that the right to erasure has exceptions and depends on your lawful basis and context. See the GDPR text (Article 17) for the official language.

Step 6: Choose the action path

Pick one action path and stick to it so your team does not mix actions (for example, deleting audio but leaving identified transcript drafts in a shared folder). Common paths include:

  • A) Full deletion (audio + transcript + links): delete files, delete drafts, remove identifiers, and update indexes.
  • B) Partial deletion: delete audio but keep a de-identified transcript, or redact sections.
  • C) Exclude from future analysis: keep files for integrity/recordkeeping but block them from new analysis and publications.
  • D) Stop contact only: keep existing data as approved, but end participation and communications.

Write down the chosen path and who approved it.

Step 7: Execute removals and updates (audio, transcripts, and derived data)

Use a two-person check for destructive actions when you can, since deletions are hard to reverse. If your organization has a retention policy, follow it and document any exceptions.

  • Audio: delete from recorders, cloud storage, shared drives, and any synced folders.
  • Transcripts: delete drafts and exports, and ensure redacted versions replace earlier copies if you keep any version.
  • Derived data: remove rows from coding files, delete annotations, or mark as “withdrawn” to prevent future analysis pulls.
  • Contact/admin: update CRM or participant log to “withdrawn,” and stop automated reminders.

If you use vendors, send a clear written instruction that matches the action path (delete, redact, return, or restrict), and file their confirmation.

Step 8: Document actions (what you did, where, and when)

Your documentation should let someone audit the request months later without guessing. Record what you located, what you removed, what you could not remove, and why.

  • Systems searched and file paths.
  • Items deleted/redacted/retained.
  • Reason for any retained items (for example, de-identified data, approved retention, legal hold).
  • Date/time completed and staff initials.

Step 9: Send confirmation to the participant

Confirm in writing what you did, using the same scope language you agreed on earlier. If you could not delete something, explain it clearly and state what you did instead (for example, stopped future use or removed identifiers).

If your work falls under U.S. health privacy rules, you may need special handling for recordings and transcripts that qualify as PHI. See the HIPAA Privacy Rule (45 CFR 164, Subpart E) for the official regulatory text.

3) Decision criteria: can you remove the audio and transcript?

The hardest part of withdrawal is deciding what is feasible and allowed. Use these criteria to make the call consistently.

Study design factors

  • Linkability: can you still link the audio/transcript to a participant ID or identity?
  • De-identification approach: did you keep a re-identification key, or is it destroyed?
  • Data flow: did files go to external tools (transcription, captioning, qualitative analysis platforms)?
  • Publication stage: has the data already been included in fixed outputs (reports, papers, aggregated charts)?

Governance factors

  • Consent language: what did you promise about withdrawal and data handling?
  • IRB/ethics approval: does the protocol specify retention or limits on deletion?
  • Contracts and sponsor rules: do they require retention for audit?
  • Legal or regulatory hold: does any rule prevent deletion right now?

Practical factors

  • Backups: can you delete from backups, or can you only age out per policy?
  • Copies and exports: did anyone download or email the files?
  • Version control: do you have multiple transcript drafts with identifiers?

4) Withdrawal request checklist (copy/paste)

Use this checklist for every withdrawal request involving audio and transcripts. Keep it in your project folder or ticketing system and require a check-off before closing the request.

  • Intake
    • Request logged with ID and date/time.
    • Identity verified using minimal checks.
    • Scope of withdrawal confirmed and documented.
  • Locate data
    • Audio located (raw + copies) and recorded in tracker.
    • Transcripts located (drafts + finals + redacted) and recorded.
    • Derived files located (coding, notes, exports) and recorded.
    • External tools/vendors checked (portals, shared links, downloads).
  • Assess removal feasibility
    • Consent/IRB/protocol constraints reviewed.
    • Data linkability assessed (identifiable vs coded vs de-identified).
    • Decision made: delete, redact, exclude, or stop contact only.
    • Decision approved by responsible role (PI/data steward/privacy contact).
  • Execute actions
    • Audio deleted/redacted/restricted as decided.
    • Transcripts deleted/redacted/restricted as decided.
    • Derived data updated to remove/exclude as decided.
    • Participant status updated to prevent future contact and processing.
  • Document and confirm
    • Actions logged (what, where, when, by whom).
    • Any limits documented (what could not be removed and why).
    • Participant confirmation sent and logged.
    • Request closed with completion date.

5) Suggested tracking fields for withdrawal requests

A simple tracker (spreadsheet, ticket, or database) reduces mistakes and helps during audits. Start with the fields below and adjust to match your study.

Minimum fields (include these)

  • Request date
  • Data located
  • Action taken
  • Confirmation sent

Recommended fields (adds clarity)

  • Request ID
  • Participant ID / code (avoid names in the tracker if possible)
  • Request channel (email/phone/etc.)
  • Identity verification method (brief)
  • Withdrawal scope (stop contact / delete audio / delete transcript / exclude from analysis)
  • Audio locations searched (systems + path/link)
  • Transcript locations searched (systems + path/link)
  • Derived data locations searched
  • External vendors/tools involved (yes/no + which)
  • Feasibility assessment outcome (deletable / partially deletable / not deletable)
  • Reason if not fully deletable (de-identified / already aggregated / legal hold / protocol constraint)
  • Approver name/role and approval date
  • Date actions completed
  • Staff initials who executed actions
  • Participant confirmation date and method
  • Notes (keep short; do not paste sensitive content)

6) Common pitfalls (and how to avoid them)

Withdrawal requests fail most often because teams treat them as “delete one file” instead of “change a whole data footprint.” These are the issues to watch for.

  • Promising deletion before you check feasibility: confirm scope first, then assess what you can do.
  • Deleting the final transcript but leaving drafts: search for exports, emailed files, and working copies.
  • Forgetting derived datasets: coding files, notes, and analysis exports can still contain quotes and identifiers.
  • Not coordinating with vendors: you need written instructions and written confirmation.
  • No proof of completion: without a tracker and confirmation log, you may not be able to show what happened.
  • Over-collecting during verification: verify identity with minimal data, then stop.

Common questions

1) If a participant withdraws, do we have to delete the audio recording?

Not always. It depends on what the participant requested and what your consent language, protocol, and applicable laws allow, so you should assess feasibility before confirming deletion.

2) Can we keep a transcript if we delete the audio?

Often you can if the transcript is de-identified and your approvals allow it, but you should document exactly what you kept and why. You should also check for draft versions that still include names or other identifiers.

3) What if we can’t find all copies of a recording?

Document where you searched, what you found, and what you could not confirm. Then reduce risk by disabling sharing links, asking team members to delete local copies, and updating your process to prevent uncontrolled downloads next time.

4) What should we tell the participant in the confirmation email?

Restate the scope you agreed on, list what you deleted or changed (audio, transcripts, derived data), and explain any limits in plain language. Include the date you completed the actions and who they can contact for follow-up.

5) Do we need to remove their quotes from reports or publications?

If a report is already published or the data is already aggregated, you may not be able to remove it, but you can stop future use of identifiable quotes where feasible. Document what is possible and what is not based on your study rules.

6) How long should we keep the withdrawal documentation?

Keep it according to your study retention policy and any sponsor or legal requirements. Store it securely and keep it minimal, since the log itself can become sensitive.

7) Should we redact the transcript instead of deleting it?

Redaction can work when the participant wants identifiers removed but your study needs the content, or when full deletion is not feasible. If you redact, ensure you replace earlier versions and label the redacted file clearly.

Where transcription support fits into a withdrawal workflow

Withdrawal often involves checking transcript versions, confirming what was shared, and making sure no drafts remain in circulation. If you use a transcription provider, build withdrawal handling into your vendor instructions so you can request deletion, redaction, or restricted access in a consistent way.

If you need help managing transcripts alongside your internal process, GoTranscript offers transcription proofreading services when you need to correct or standardize files, and automated transcription for faster turnaround on new audio while you maintain your study’s controls. When you’re ready to outsource transcription in a way that fits your documentation needs, you can use GoTranscript’s professional transcription services.

If your team handles participant audio and transcripts regularly, a consistent participant withdrawal workflow can save time and reduce errors. GoTranscript can support your process with the right solutions for transcription and transcript handling; learn more about our professional transcription services when you need reliable transcripts that fit your study operations.