Why We Delete Your Audio After Transcription

Author: Hushscript | Published: May 30, 2026 | Last reviewed: July 21, 2026

We delete your audio the moment the transcript is ready. Not after 30 days, not when you close your account, not on a cleanup schedule that runs overnight. The file is removed as soon as the job finishes, automatically, without you asking.

Retention policies vary across transcription services, and the difference matters. The ICO’s storage-limitation guidance gives the useful principle: personal data should not be kept longer than its purpose requires. Hushscript made a deliberately narrow choice for audio, and this post explains what “zero retention” means here, how deletion works, and how to remove a saved transcript when you are done with it.

The case for deletion

Holding on to customer audio creates several distinct categories of risk. Deleting it removes each one rather than mitigating it, and that difference matters more than it first appears.

Data that does not exist cannot be breached. Any storage bucket that holds recorded audio is a target, and breaches are rarely discovered the day they happen. Security incident reports consistently find that intrusions often go unnoticed for weeks or months after the initial compromise. A recording deleted within minutes of being transcribed simply is not present during that exposure window. There is no copy to exfiltrate.

The same logic applies to legal and compelled access. A subpoena, a court order, or a data request can only reach data that still exists. Audio already deleted at the time of a request is unavailable, not because anyone is withholding it or actively protecting it, but because it is gone. For a journalist with a confidential source, a lawyer holding privileged material, or a therapist recording a session, “we no longer have it” is a much stronger position than “we have it but promise to guard it.”

Deletion also closes off accidental exposure. Storage systems get misconfigured. Public-read buckets are a recurring class of security incident precisely because the mistake is easy to make and slow to notice. A file that does not persist cannot be exposed by a permissions error six months after you uploaded it.

There is a quieter benefit too. Automatic deletion demonstrates intent rather than policy. A privacy statement that says “we will delete your data on request” asks you to trust both the wording and the execution: that the request reaches the right system, that it is processed correctly, and that you remembered to send it at all. A system that deletes by default does not depend on any of that. The safe outcome is the one that happens when nobody does anything.

The trade-off is real and worth stating plainly. You cannot retrieve the audio from us later, because there is nothing to retrieve. If you ever need the original recording rather than the transcript, you keep your own copy. That is a design constraint we chose on purpose, not a gap we forgot to fill.

What “zero retention” actually means

“Zero retention” is a phrase that gets used loosely, so it is worth being precise about what it covers here and what it does not.

It refers to the audio in the speech-processing pipeline. After your file is transcribed, two things are true at once. The audio file is removed from our processing storage, and the speech engine that produced the transcript keeps no copy of it for model training, quality evaluation, or debugging. A service using an external processor has to verify that processor’s policy too; an application-level deletion claim does not answer the subprocessor question by itself. Hushscript’s processing path runs without audio retention, so the answer is the same on both sides: no retained copy after completion.

Zero retention at the audio level is not the same as keeping no data at all, and conflating the two would be dishonest. Your account exists. Your transcript exists in your dashboard until you remove it. A billing record for the minutes you used exists, along with basic job metadata such as the timestamp, the duration, and the detected language. None of that is the audio. What ceases to exist once transcription completes is the recording itself, the one piece of data that actually carries your voice and the content of what was said.

So when you see “zero retention” on this site, read it as a specific, narrow claim about the audio and the speech engine, not a sweeping promise that nothing is stored. The narrow version is the one we can stand behind without an asterisk.

How deletion works in Hushscript

Your audio is only ever in a transient state on our infrastructure. It is never written to a permanent home and never sits in a library waiting to be opened again. The lifecycle is short and one-directional.

1. You upload. You drop a file on a page like audio to text or one of the other upload points. The audio, and only the audio, moves into a processing queue. If the file is a video, its audio has already been prepared in your browser–copied without re-encoding when compatible, converted locally only when required–so the video data stays behind on your device.
2. It is transcribed. The speech engine processes the audio and returns a transcript with speaker labels and timestamps. This is the only stage where the audio is actively in use.
3. It is returned, then deleted. The transcript is written to your dashboard, and the audio file is deleted. There is no fourth stage where the recording rests in storage. It moves from processing straight to removal.

Because there is no resting stage, there is no retention window to configure or forget. The audio is present while it is being transcribed and absent immediately afterward. The technical summary fits in one line: your audio exists on our infrastructure only during the transcription window, on your device before that, and nowhere after.

For sensitive work, the most useful detail is often where the data is processed. If you are in the EU, EEA, Switzerland, or the UK, your audio is processed in the EU. Everywhere else it is processed in the US. Either way the deletion behavior is identical, and either way the recording does not outlive the transcript. You can follow the full path on the how it works page, and the private transcription page covers the data-handling specifics and how they compare with the storage-by-default norm.

A worked example: where deletion actually bites

Picture a 40-minute recorded client meeting saved as an M4A from a phone. It contains names, figures, and a few things nobody wants sitting on a stranger’s server.

You drop the file into the preview without an account. A 30-second speaker-labeled clip appears so you can confirm the two voices are being separated correctly. That preview is the only step that needs no account. To transcribe the rest you sign up, and new accounts get 30 free minutes to try. A 40-minute meeting runs past the free allowance, so you top up first; the pricing page has the per-minute cost. The full audio is then transcribed, and the moment your transcript lands in the dashboard, the M4A is deleted from our side. You relabel “Speaker 1” and “Speaker 2” to real names, export a DOCX for your records, and the transcript stays in your account, encrypted at rest, until you delete it or a retention rule removes it.

The point of walking through it is to show where the guarantee actually applies. After the work is finished, Hushscript does not keep a stored copy of the meeting audio. The transcript is the artifact that persists, and even that is yours to delete. A service built as a searchable recording archive makes a different trade-off; read its retention controls before choosing that model for sensitive work.

When you do not want a saved transcript

Use private mode. It runs speech recognition only, skips saved transcript storage and post-processing AI, and returns a password-protected archive instead of keeping the transcript in your account.

Removing a normal transcript

Deleting the audio handles the recording. The transcript is the other half, and you control that one directly. After transcription, the text lives in your dashboard until you remove it.

1. Open the transcript.
2. Choose delete.
3. The transcript text is removed.

That is the whole flow. We keep no archive of deleted transcripts, so once you delete, the text is gone from our side rather than moved to a recycle bin you cannot see. If you already know you do not want a saved transcript, private mode is the cleaner path.

If you would rather clear everything at once, you can delete your whole account from your profile after a confirmation step. Worth knowing before you do: any minutes you have already bought are not refunded on account deletion, so spend or keep them in mind first.

The honest part: what we keep, and the encryption limit

A privacy claim is only worth as much as the parts it admits to. Two things deserve a clear, unhyped statement.

First, the residual data. We delete the audio, but the transcript stays until you remove it, and so does the small set of job metadata needed to run and bill the service. That metadata is far lower-risk than the audio, since it describes the job rather than carrying your voice, but it is not nothing, and we would rather name it than imply a clean slate that does not exist.

Second, the transcript that remains is encrypted at rest. If our storage were ever leaked, what an attacker would walk away with is unreadable ciphertext, not a searchable archive of everyone’s words. That is genuine protection against a storage breach, which is the threat encryption at rest is built for. It is also where we stop, deliberately. This is not zero-knowledge encryption. The key is held on our servers, because the app has to be able to decrypt and show you your own transcript when you open it. So we are not claiming that we cannot read your transcripts. We are claiming that a stolen database would be useless to whoever stole it without the key. Anyone who tells you a transcription tool can both display your transcripts on demand and be mathematically unable to read them is glossing over how the keys work.

That is the full honest shape of it. The audio is deleted and the speech engine keeps nothing, which removes the recording entirely. The transcript persists under encryption that defends against a leak but is not a lock against us, and you can delete it whenever you like. We would rather you understand exactly where the line sits than trust a slogan that quietly moves it.

The broader reason

The default in this industry is storage. Upload, transcribe, and keep everything in a library the user can return to. For some people that is a real feature: a podcaster building a searchable archive of their own episodes benefits from having every transcript in one place, and the content is not sensitive.

But storage is a poor default for confidential recordings. An archive of years of privileged consultations, source interviews, or internal negotiations, sitting on a third-party server, is a liability that compounds quietly over time. The longer it exists, the larger the surface for a breach, a subpoena, or a misconfiguration to land on.

Deletion is the right default when the transcript is the thing you need and the audio is only the means to get it. If you already hold the source file, on your own device or in your own storage, there is no reason for us to keep a second copy. So we do not.

For the wider risk picture, including the questions worth asking any transcription tool before you upload to it, see why your audio shouldn’t be uploaded. The deletion behavior described there is the same one covered here; that post zooms out to the full set of privacy trade-offs for sensitive recordings.