Transcription Under NDAs: The Compliance Workflow

When you upload a recorded conversation to a cloud transcription service, you are disclosing that conversation to a third party. Most confidentiality agreements restrict exactly that. The upload does not automatically violate your NDA, but without the right contractual structure in place, it might.

This post covers the contract clauses you actually need to read, how the subprocessor chain works in practice, and a realistic internal approval workflow for teams handling sensitive audio.

Why the Default NDA Language Creates a Problem

A standard confidentiality clause reads something like:

Recipient shall not disclose Confidential Information to any third party without the prior written consent of the Disclosing Party.

A cloud transcription service is a third party. The moment you upload audio, the service receives the content of that recording. The upload is a disclosure in the ordinary meaning of the word.

The resolution does not come from re-reading the definition section. It comes from one of two structural fixes:

1. Your NDA includes a subprocessor carve-out that permits cloud services bound by equivalent obligations.
2. You obtain separate written consent from the other party to use specific cloud services.

Most NDA templates drafted after 2018 include language like: "Recipient may engage cloud or SaaS subprocessors for internal processing purposes, provided those subprocessors are bound by confidentiality obligations at least as restrictive as this Agreement." If your NDA was drafted before that era, check whether this language is present. If it is not, you need an amendment or a side letter before uploading confidential audio.

How to Read the Subprocessor Chain

When you sign up for any cloud transcription service, you are not just engaging that company. You are engaging their subprocessor chain. A realistic chain for a mid-size transcription SaaS looks like this:

1. You (controller of the audio)
2. The transcription service (direct processor)
3. Cloud storage (AWS S3, Cloudflare R2, Google Cloud Storage)
4. The AI model API (Deepgram, AssemblyAI, OpenAI Whisper, or similar)
5. Possibly additional subprocessors: analytics, monitoring, error tracking

Each link must be covered by a confidentiality obligation that flows down from the top. Under GDPR Article 28, processors must impose the same data protection obligations on their subprocessors that the controller imposed on the processor, and processors remain "fully liable" if subprocessors fail to meet those obligations. Outside the EU, the same logic applies to NDA-based confidentiality: if the original agreement requires strict confidence, each downstream processor must be bound by equivalent terms.

When evaluating a transcription provider, ask for their subprocessor list. Specifically ask: which entity processes the audio for transcription, and what is the data retention agreement with that entity? Some AI model APIs operate under a "zero data retention" mode where audio is processed but not stored after inference. Others may retain audio for quality assurance or model improvement unless you opt out. Those are meaningfully different postures for confidential work.

The AI Training Question

A particular concern with AI transcription is whether the AI model counts as "disclosure" in a way that persists. The clean case: a pretrained model processes your audio at inference time, no persistent data is stored, and your audio never appears in any training dataset. The messier case: the provider or its AI subprocessor uses customer audio to improve future models.

If a provider uses customer audio to train its models, that is much harder to defend as a non-disclosure. The Otter.ai class action filed in August 2025 (Brewer v. Otter.ai) included exactly this allegation: that the service used recorded meetings to train its AI models without adequate participant consent. The case consolidated with related suits and remains in litigation as of mid-2026. Whatever the outcome, it illustrates the practical and legal risk of using a provider without a clear "no training" commitment in writing.

Ask any vendor for their explicit policy in their DPA or terms of service. "We don't train on your data" should appear in a signed agreement, not just a marketing page.

What a Good DPA for Transcription Actually Covers

A data processing agreement for confidential audio work should address at minimum:

Scope limitation. Processing only for the purpose of providing the transcription service, not for any secondary use.

No training clause. Explicit prohibition on using customer audio for model training without separate written consent.

Subprocessor list with notice. A list of current AI and infrastructure subprocessors, with a commitment to give advance notice before adding or changing subprocessors and a right for the customer to object.

Breach notification. Notification within a defined window, typically 24-72 hours, of any security incident affecting customer audio.

Data deletion. On contract termination, all customer audio and transcripts are deleted or returned, with written confirmation.

Audit rights. The customer's right to audit, directly or through a third party, the provider's compliance with the agreement.

Cross-border transfer mechanism. For EU-origin audio processed on US infrastructure, the Standard Contractual Clauses adopted by the European Commission in 2021 (or equivalent under Article 46 GDPR) must be incorporated. These are required regardless of whether the vendor has general GDPR language in their privacy policy.

Most professional transcription services offer a DPA on request. If a vendor declines to sign one, that is a meaningful signal about their actual data governance posture.

For a detailed look at GDPR obligations and what to look for in provider agreements, see the post on GDPR-compliant transcription.

Updating the NDA You Sign With Clients

The exposure goes both directions. When you are the service provider transcribing recordings from client engagements, your NDA with the client needs to anticipate your use of cloud tools.

The protective clause looks like this:

Recipient may use cloud-based services, including AI transcription providers, to process Recordings for the purposes of this engagement, provided that such services are bound by confidentiality obligations no less restrictive than those in this Agreement, and Recipient remains liable for any breach by those services.

Without this language, you are technically asking for consent every time you upload a client recording. Most clients will accept this clause without negotiation because the alternative, manual transcription of every audio file, is not a realistic demand. But older engagement templates often lack it entirely. Run a search on your standard NDA template for the word "subprocessor" or "cloud." If it does not appear, add the clause before your next engagement starts.

Role-Specific Patterns

Legal Practice

Lawyers face the highest bar because the confidentiality duty is both contractual and professional. ABA Formal Opinion 477R (revised 2017) established that cloud services are ethically permissible for client data if attorneys conduct due diligence proportionate to the sensitivity. The 2025-6 opinion from the NYC Bar added that attorneys must obtain client consent before recording, independently verify transcript accuracy, and understand whether the tool trains on the content.

As of 2026, 42 states have adopted Comment 8 to Model Rule 1.1 or an equivalent, making technology competence an enforceable ethical standard. "I did not know the tool trained on client data" is not a defense.

Practical checklist for legal use:

• Confirm the provider does not train on customer audio (in writing, in the DPA)
• Configure auto-deletion for a reasonable period after matter close
• Document your due diligence in the matter file
• Check your state bar's specific guidance; some jurisdictions have stricter requirements than the ABA model

For analysis of how privilege interacts with transcription storage and discovery, see transcription and attorney-client privilege.

Journalism

Source-protection concerns are different in character from NDA compliance. The question is not whether a provider has confidentiality obligations but whether those obligations can survive a government compulsion order.

For routine journalism, where sources are attributed or the risk profile is low, cloud transcription with standard DPA terms is appropriate. For high-risk journalism involving whistleblowers, sources in adversarial jurisdictions, or classified material, a cloud service, regardless of its DPA, creates a compellable data trail. In those cases, the right tool is local: Whisper running on your own hardware, with no audio ever leaving your device. The trade is setup complexity and slightly lower accuracy than the latest cloud APIs.

For most daily journalism, the cloud transcription pattern is fine. Configure auto-deletion, avoid logging source-identifying notes alongside transcripts, and understand your provider's jurisdiction before a story goes sensitive.

Corporate Sensitive

M&A discussions, personnel decisions, strategic planning, and financial projections are common in corporate transcription workflows. The relevant structure here is not signing a DPA yourself but getting your transcription tool approved through your organization's vendor management process.

Enterprise procurement cycles for AI tools now average 6-14 weeks according to 2026 vendor management guidance, largely because security reviews have become the bottleneck, not the feature evaluation. Plan accordingly if you need a transcription tool approved for use with confidential materials.

The documents you will typically need to provide in a vendor security review:

• The provider's DPA and subprocessor list
• A completed vendor security questionnaire (most enterprise vendors have a standard format)
• The provider's SOC 2 Type 2 report (if your organization requires it)
• Written confirmation of the no-training policy

Some transcription providers are not yet at the SOC 2 Type 2 maturity level. If your enterprise requires that certification, it narrows the approved vendor list significantly. Factor that in before selecting a tool, not after.

Internal Approval Workflow

Once you understand the contract layer, the approval process for any new transcription tool handling confidential audio follows a predictable pattern. Here is the practical sequence:

Step 1: Read your underlying NDA. Does it have a subprocessor carve-out? If yes, document that. If no, flag it for amendment before proceeding.

Step 2: Check the provider's DPA. Does it address training, breach notification, deletion on termination, and subprocessor disclosure? If the provider does not offer a DPA or will not share their subprocessor list, stop here.

Step 3: Confirm the AI training policy. Find the explicit language in the DPA or terms of service, not in marketing copy. "We do not use customer data to train models" must appear in a signed agreement.

Step 4: Configure retention. Set auto-deletion to the shortest window practical for your workflow. If the provider supports configurable deletion windows, use them. See the post on auto-delete transcription files for practical settings.

Step 5: Document the chain. Keep a record of the agreements you have in place: the DPA with the provider, the provider's subprocessor list, and the language in your client NDA that authorizes subprocessor use. If a client or regulator asks, you need to be able to produce this.

Step 6: Train the team. The contractual layer only works if the people uploading audio know which content categories require it. "All client calls" is a policy. "Client calls about strategy or M&A" is a policy. A vague sense that sensitive stuff should not be uploaded is not.

The one-time setup is the bulk of the work. After it is done, the daily workflow is routine: upload audio to a meeting transcription tool, review the output, file the transcript. The contractual layer runs quietly in the background.

When No Contract Is Enough

Some content cannot be sent to any cloud service, regardless of the DPA:

• Government classified material: requires CJIS, FedRAMP, or equivalent certifications and specific cleared networks. No commercial transcription SaaS qualifies.
• Content under active judicial gag orders: the existence of the content in a third-party system may itself be a problem.
• Source material where the source is in a jurisdiction with compelled-disclosure laws that would override your provider's contractual obligations.
• Trade secrets where the exposure risk is catastrophic and no contractual remedy would make the organization whole after a breach.

For these, local Whisper is the correct path. The accuracy gap between a locally-run Whisper large-v3 model and the best cloud APIs has narrowed, and for genuinely high-stakes material, the privacy guarantee of no third-party involvement outweighs any accuracy advantage.

For everything else, the cloud transcription pattern with a proper DPA and documented approval is standard practice in law firms, consulting practices, and regulated enterprises. If you need a quick transcription of a confidential recording without deploying a meeting bot, ConvertAudioToText accepts direct file uploads and does not train on customer audio. But verify that claim in the DPA just as you would with any other provider. The contractual layer is the standard, not the exception.

FAQ

Does uploading audio to a cloud transcription service violate an NDA?

It depends on the NDA language. Most NDAs prohibit disclosure to third parties without consent, and a cloud service is a third party. However, most modern commercial NDAs include a subprocessor carve-out: the recipient may use cloud services provided those services are bound by equivalent confidentiality obligations. If your NDA predates that language, you need an amendment or a separate written consent before uploading.

What should a DPA with a transcription provider actually include?

At minimum: an obligation to process audio only to provide the service; a prohibition on using audio for AI model training without consent; a subprocessor list with advance-notice provisions; breach notification within a defined window (24-72 hours is common); data deletion on termination; and, if audio crosses EU borders, incorporation of the Standard Contractual Clauses or an equivalent transfer mechanism under GDPR Article 46.

What questions should I ask a transcription vendor about their subprocessor chain?

Ask for their current subprocessor list and the DPA terms they impose on each. The critical questions are: which AI model provider processes the audio, does that provider have a zero-data-retention agreement in place, and does the provider use customer audio to train future models. A vendor that cannot answer these questions in writing is a vendor you should treat as high-risk for confidential work.

Can lawyers use AI transcription tools for client recordings?

Generally yes, with due diligence. ABA Formal Opinion 477R (2017) permits cloud computing for client data if attorneys conduct reasonable security due diligence proportionate to the sensitivity. The NYC Bar's 2025-6 opinion adds that attorneys must obtain client consent before recording, independently verify transcript accuracy, and understand whether the tool trains on the content. Many state bars follow similar reasoning, but the specifics vary, so check your jurisdiction's ethics rules.

Sources

• GDPR Article 28: Processor obligations
• NYC Bar Formal Opinion 2025-6: Ethical Issues Affecting Use of AI to Record, Transcribe, and Summarize
• ABA Formal Opinion 477R (cloud security and attorney ethics)
• Fireflies.ai Data Processing Agreement
• Otter.ai Data Processing Addendum
• AI Notetaking Tools Under Fire: Lessons from the Otter.ai Class Action
• European Commission: Standard Contractual Clauses
• ICO: What needs to be included in the contract (Article 28 DPA)
• Vendor onboarding workflow 2026: Moxo