Voice dictation is one of the fastest ways to get a session note drafted. But whether it's compliant with HIPAA depends entirely on the mechanics of the tool you're using — not the marketing copy on its homepage. Most clinicians asking "are voice notes HIPAA compliant?" get vague reassurances. Here's what actually matters.
The plain answer
Voice notes can be HIPAA compliant, but only if every system that touches the audio has a signed Business Associate Agreement (BAA) with you, and only if the tool handles audio storage and deletion in a way that limits PHI exposure. The voice recording itself isn't the problem. The problem is what happens to the audio file after you stop talking.
Generic consumer dictation tools — think your phone's built-in voice memo app, or a general-purpose AI assistant — are not HIPAA compliant for clinical use. They have no BAA, they store audio on vendor servers under terms designed for consumer data, and they may use your recordings to improve their models. None of that is acceptable when the audio contains protected health information.
Why generic voice tools fail the HIPAA test
HIPAA's Security Rule requires covered entities and their business associates to implement safeguards for electronic PHI (ePHI). When you dictate a note that includes a client's name, diagnosis, or session content, that audio file is ePHI the moment it leaves your device.
Here's where generic tools break down:
No BAA. A BAA is a contract in which a vendor agrees to handle PHI according to HIPAA requirements. Without one, using a tool with PHI makes you — the covered entity — solely liable for any breach. Most consumer voice apps don't offer BAAs at all, and some enterprise tools only offer them on expensive plans.
Audio retained on vendor servers. Many transcription services keep your audio files for days, weeks, or indefinitely. Some use retained audio for quality assurance or model training. Every day that audio sits on a server you don't control is a day it can be breached, subpoenaed, or misused.
Opaque subprocessors. Even if a tool offers a BAA, that BAA may not extend to the third-party transcription engine the tool uses under the hood. If the vendor routes your audio through an uncovered subprocessor, the chain breaks.
Training data use. Some AI tools explicitly reserve the right to use your inputs to improve their models. That's incompatible with HIPAA regardless of what their marketing says about privacy.
What a compliant setup actually requires
Compliance isn't a feature — it's a set of contractual and technical conditions that have to be true simultaneously.
A BAA with every vendor that touches PHI. This includes the app you're using and any transcription engine it calls. If your dictation tool sends audio to a third-party speech-to-text API, that API needs its own BAA. "We use a HIPAA-compliant transcription service" is not the same as "we have a signed BAA with our transcription provider that covers your data."
Audio deleted after transcription. Once the audio has been converted to text, the original file should be deleted automatically. There's no clinical reason to retain raw audio — the transcript is what you need. Retention of audio files beyond transcription is a liability with no upside.
Session content handled with minimal server exposure. The less PHI that travels to and persists on external servers, the smaller the attack surface. The ideal is that session-level content stays in your environment as much as possible, and what does leave is encrypted in transit and at rest.
Encryption and access controls. Data at rest should be encrypted. Data in transit should use TLS. Access should be scoped so that only your account can reach your data — not shared infrastructure with other tenants.
How this works in Wren
Wren's dictation and transcription mechanics are designed around these requirements specifically.
Every account gets a BAA signed at onboarding — not gated behind a higher-tier plan. Transcription runs through AssemblyAI, and Wren maintains a BAA with AssemblyAI under Wren Clinical LLC. That means the subprocessor chain is covered, not just the top-level app. You can verify the full subprocessors list at wrenclinical.com/legal/subprocessors and review the BAA itself at wrenclinical.com/legal/baa.
Audio is automatically deleted after transcription completes. The original file doesn't persist on Wren's servers. What remains is the transcript text, which you control: you set the retention window (up to 30 days) in Transcript Settings, and transcripts are permanently deleted when that window closes. Notes generated from transcripts are stored separately in the Document Library and aren't affected by transcript expiry.
Session content is handled browser-side during active use — it isn't stored on Wren's servers in a way that persists beyond the session. Audio that is temporarily stored (during upload and transcription) lives in S3 under your tenant's prefix, encrypted at rest with SSE-S3, with public access blocked.
This isn't a claim of absolute security — no system is — but it's a specific, verifiable set of mechanics you can evaluate against your own compliance requirements.
The 4-question checklist before using any dictation tool with PHI
Before you dictate a single session note into a new tool, get clear answers to these four questions:
1. Is there a signed BAA, and does it cover every subprocessor that handles audio? Ask specifically: "Does your BAA cover the transcription engine you use?" If the answer is vague or the vendor can't name their transcription provider, that's a red flag.
2. How long is audio retained after transcription, and where? You want a clear answer: audio is deleted automatically after transcription, on a defined timeline, from specific infrastructure. "We take privacy seriously" is not an answer.
3. Is my data used to train AI models? This should be covered in the BAA or terms of service. If the vendor can't confirm this in writing, assume the answer is yes.
4. What encryption is applied to audio and transcript data, in transit and at rest? Look for TLS in transit and AES-256 or equivalent at rest. Bonus: ask whether data is isolated per-tenant or shared across a common infrastructure.
If a vendor can't answer all four questions clearly and in writing, that's your answer.
FAQ
Can I use Apple's built-in dictation or Siri for therapy notes?
No. Apple's dictation and Siri process audio through Apple's servers under consumer terms. There is no BAA available for standard Apple services, and audio may be retained and reviewed under Apple's privacy policy. These tools are not appropriate for dictating content that includes PHI.
Does a BAA alone make a dictation tool HIPAA compliant?
A BAA is necessary but not sufficient. The BAA creates legal accountability, but the tool also needs appropriate technical safeguards — encryption, limited retention, access controls, and subprocessor coverage. A BAA with a vendor that stores your audio indefinitely in plaintext still leaves you exposed.
What's the difference between dictation and transcription for HIPAA purposes?
Dictation is the act of speaking into a tool to create text. Transcription is the automated conversion of audio to text. For HIPAA purposes, both involve ePHI if the content includes patient information. The key compliance questions apply to both: who handles the audio, where does it go, how long is it kept, and who has signed a BAA.
If I dictate a note without client names or identifiers, is it still PHI?
Possibly. HIPAA defines PHI broadly — it includes information that could reasonably identify an individual when combined with other data. If your note includes diagnosis, dates, session content, and you're the only clinician seeing that client, the combination may still be identifiable. The safest practice is to treat all dictated clinical content as PHI and use a compliant tool regardless.