Translation Is a Data Transfer
It is easy to think of video translation as a processing operation — content goes in, translated content comes out — and to overlook that the operation involves transmitting your content to someone else's infrastructure.
For a marketing video, this is unremarkable. For a recorded internal meeting, a customer support call, a training video containing employee footage, a clinical recording, or anything under a confidentiality obligation, it is a data transfer with legal and contractual consequences.
The assessment does not need to be onerous, but it does need to happen once, at the program level, before content starts flowing. Organizations that skip it typically discover the gap during a security review, an audit, or a customer questionnaire — at which point content has already been processed under arrangements nobody evaluated.
What Is Actually in Your Video
The first step is knowing what the content contains, which is less obvious than it sounds.
Personal data of identifiable individuals. Faces, voices, names, and any information about a person. Video is unusually rich in this: a training video shot in an office captures employees who are not the subject of the video, and a customer testimonial contains a named individual's likeness and voice.
Special category data. Health information, biometric identifiers, and other categories carrying heightened protection under many data protection regimes. Voice recordings raise a specific question here, discussed below.
Confidential business information. Internal strategy, unreleased product details, financial information, and anything under a nondisclosure obligation.
Third-party confidential information. Content containing a customer's or partner's confidential material, which you may hold under terms that restrict onward transfer.
Regulated content. Clinical information, financial advice, legal privileged material, and anything subject to sector-specific rules.
Incidental capture. Screens visible in the background, documents on a desk, conversations audible off-camera, and metadata embedded in the file. This is the category most often missed, and it is frequently where the sensitive material actually is.
Audit a representative sample of your content against this list before assessing vendors, because the requirements follow from what the content contains.
Data Residency and Processing Location
Where processing physically occurs matters under several regulatory regimes.
Determine where the provider processes content, including where any subprocessors operate. Processing may occur in a different jurisdiction from where the company is headquartered or where data is stored at rest.
For organizations subject to data protection regimes with transfer restrictions, moving personal data across certain borders requires a legal basis and often specific contractual mechanisms. Whether these are in place is a contract question, not a technical one.
Some sectors and some public-sector contracts impose residency requirements directly, mandating that data remain within a specified jurisdiction. Where these apply, they are typically non-negotiable and determine which providers are viable at all.
Ask specifically: where is content processed, where is it stored, which subprocessors are involved, and where do they operate. Get the answer in writing. Verbal assurance about processing location is not sufficient documentation for a compliance file.
Retention and Deletion
Retention practices vary substantially between providers, and the defaults are frequently longer than users assume.
Establish: how long source content is retained after processing, how long outputs are retained, whether deletion is available on request, whether deletion is verified or merely scheduled, and how backups are handled.
Backups are the common gap. A provider may delete content from active systems promptly while retaining it in backups for a considerably longer period. Whether this satisfies a deletion obligation depends on the applicable regime, but knowing the actual behaviour is necessary either way.
For content with defined retention limits — regulated material, content under a customer contract specifying deletion, or personal data subject to storage limitation principles — the provider's retention must be compatible with your obligation, not merely reasonable in the abstract.
Where you need deletion, confirm the mechanism exists and works before relying on it. An arrangement where deletion requires a support request that takes weeks is functionally different from one with an API-driven deletion capability.
Training Use
Whether submitted content is used to train or improve the provider's models is one of the most consequential questions and one where practices differ sharply.
Some providers do not use customer content for training at all. Some use it by default with an opt-out. Some distinguish between tiers, with enterprise plans excluding training use while consumer tiers do not.
For confidential business content, training use is generally unacceptable regardless of the safeguards described, because the content leaves your control in a form that cannot be retrieved.
For personal data, training use raises separate questions about lawful basis and about the rights of the individuals whose data is involved, who did not consent to that use.
Get the position in writing, tied to the specific plan or contract you are on rather than to general marketing statements. A provider's public position may describe their enterprise offering while the tier you are actually using operates differently.
Voice Data Specifically
Voice recordings occupy a distinctive position because a voice is identifying.
Several data protection regimes treat voiceprints and voice-derived biometric identifiers as a special category requiring heightened protection, additional lawful basis, and in some jurisdictions explicit consent. Some regional laws impose specific requirements on biometric identifiers with meaningful penalties for non-compliance.
Whether ordinary voice recording constitutes biometric data depends on how it is processed. A recording used for transcription is generally treated differently from a voiceprint created for identification or for generating a synthetic voice.
Voice cloning is the case requiring most care. Creating a synthetic voice modelled on a specific person involves processing that person's voice characteristics, and the individual should consent to that specific use. Consent to being recorded is not consent to having a synthetic version of one's voice created.
Practical requirements for voice cloning:
Obtain explicit, informed, documented consent from the person whose voice is cloned, covering the specific use.
Be clear about scope — which content, which languages, for how long, and whether the voice model is retained after the project.
Establish what happens on withdrawal, including whether the voice model is deleted and whether previously generated content is withdrawn.
Confirm the provider's handling of voice models: retention, access controls, whether models can be used outside your account, and deletion on request.
For employees, be aware that consent given in an employment relationship carries questions about whether it is freely given, which may mean an alternative lawful basis is needed.
For public figures and third parties who are subjects of content rather than participants, the analysis is considerably more restrictive.
Access Control and Internal Handling
Provider security is only half the picture; internal handling is the other half and is more often the weak point.
Establish who in your organization can submit content for translation, since an unrestricted capability means sensitive content will eventually be submitted by someone who did not evaluate whether it should be.
Establish where outputs are stored and who can access them. Translated versions of sensitive content have the same sensitivity as the source, and they frequently end up in less controlled locations than the original.
Control credential handling. API keys and account credentials for translation services provide access to submitted content and should be managed accordingly.
Consider what reviewers can access. Native-speaker reviewers, whether internal or contracted, receive the content in full. For sensitive material this means reviewer arrangements need confidentiality terms, and it may mean restricting which reviewers can handle which content.
Log what was submitted. In an incident or an audit, knowing what content went where is necessary and is difficult to reconstruct retroactively.
Vendor Assessment
A practical assessment covers the following, in writing:
Processing and storage locations, including subprocessors.
Retention periods for inputs and outputs, and the deletion mechanism.
Training use position for your specific plan.
Encryption in transit and at rest.
Access controls on the provider side, including which provider personnel can access content.
Subprocessor list and notification practice for changes.
Security certifications and whether audit reports are available for review.
Incident notification commitments and timelines.
Data processing agreement availability and terms, including transfer mechanisms where relevant.
Voice model handling where cloning is used.
For most organizations this is a one-time assessment per provider, refreshed periodically and on material change. The effort is modest and it converts an unexamined risk into a documented decision.
Matching Controls to Content
Not all content needs the same treatment, and applying maximum controls uniformly is both expensive and unnecessary.
Public marketing content carries essentially no confidentiality concern. Standard arrangements are fine.
Internal general content — training on non-sensitive topics, internal announcements — needs basic confidentiality terms but not special handling.
Content containing personal data needs a data processing agreement, defined retention, and attention to transfer mechanisms.
Confidential business content needs training-use exclusion, defined deletion, and appropriate contractual terms.
Regulated content — clinical, financial, legal — needs whatever the applicable regime requires, assessed specifically.
Content with identifiable third parties who have not consented may not be processable at all without addressing the consent question first.
Classify content categories once, define the applicable handling for each, and route accordingly. This is far more sustainable than assessing each asset individually and far safer than applying one standard to everything.
Reducing the Problem
Some of the risk is avoidable through content design rather than through controls.
Produce training and demonstration content with scripted scenarios and consenting participants rather than with real recorded interactions, where feasible. This removes most of the personal data question at the source.
De-identify where possible before processing. Blurring incidental faces, removing identifying details from screen recordings, and using synthetic sample data in demonstrations reduces what is being transferred.
Check for incidental capture during production rather than after. A background screen showing customer data is far easier to avoid at recording time than to remediate afterward.
Separate sensitive content from routine content in your workflow, so that the routine majority moves quickly while the sensitive minority receives the handling it requires.
Answering Customer and Auditor Questions
Organizations that sell to enterprises or operate in regulated sectors will eventually be asked about their translation processing, and having the answers ready is considerably easier than assembling them under a deadline.
The questions that recur: which processors handle your content, where do they operate, what data do they receive, how long do they retain it, is it used for training, what contractual protections are in place, and how would you know if there were an incident.
Maintaining a short record covering these — one page per processor, refreshed annually — converts a scramble into a lookup. It also surfaces gaps before a customer does.
Where your customers' data is involved, your contracts with them likely govern onward transfer. A customer contract restricting subprocessors, or requiring notification of new ones, applies to a translation provider as much as to any other vendor. Adding a processor without checking these terms is a common and avoidable breach.
Subprocessor changes deserve monitoring. Providers add and change subprocessors, and a change may move processing to a jurisdiction that affects your compliance position. Where the provider offers change notification, subscribe to it and route notifications to someone who will read them.
Incident response should include translation providers in scope. If a provider suffers a breach, the content you submitted is affected, and your own notification obligations may be triggered by their incident.
Getting Started
Audit what your content actually contains, using a representative sample rather than assumptions.
Classify content into handling categories and define the requirements for each.
Assess your provider against the checklist above, in writing, for the specific plan you use.
Control internal submission so that classification is actually applied rather than bypassed.
Handle voice cloning consent explicitly and separately from recording consent.
Document the assessment and revisit it periodically.
None of this is difficult, and most of it is a single afternoon's work at program inception. The alternative — discovering during a security review that content has been flowing to an unassessed processor for two years — costs considerably more and is entirely avoidable.
