Data Security 4 August 2026
Personal Data Stored in Translation Memories
A translation memory is a tool that brings costs down; it is also a sentence-by-sentence archive of your documents. We look at what stays inside it and how it can be cleared out.
The translation memory is the industry’s most useful tool and its quietest data store. It brings costs down, keeps terminology consistent and shortens delivery times. It also builds a sentence-by-sentence archive of the documents that belong to you.
Contents
This article looks at the translation memory from the point of view of personal data: what exactly is stored in it, what the metadata layer says, why deletion is difficult and how a retention policy is built. The questions look technical, but their answers sit largely at the level of contracts and processes.
The aim is not to disparage the memory. A properly designed memory is better than a scattered file archive, on cost as well as on security. The problem is that the design work is usually never done at all.
Does a translation memory store personal data?
The basic unit of a memory is the segment pair: a source sentence and its translation. The tool writes every confirmed sentence to the database in this form. When a similar sentence appears in a new document, the earlier translation is offered as a suggestion.
The issue here is that the content of the sentence is not filtered out. The sentence “Dear Ahmet Yılmaz, your application of 12 March has been rejected” enters the memory exactly as it stands. The name, the date and the decision are all part of the same record. The names of the parties to a contract, a diagnosis appearing in a report, an address in a personnel file: every one of them sits inside the body of a sentence.
The definition of personal data rests on whether a natural person is identified or identifiable. By that measure, a significant share of translation memories contains personal data. And because a memory is a database rather than a file, deleting the document in the folder does not delete the trace in the memory.
Not just the sentence: the metadata layer
Alongside the segment pair sits a metadata layer that most users never open. The standard fields include the identity of the user who created the segment, the creation and modification dates, the source file name, and the project and client tags.
This layer creates risk in two directions. On one side it is personal data about the translator: it carries information on who worked, when and how much. On the other it leaks information on the client side as well, since file names often contain a company name, a case number or a product code name.
Memory files are shared across the industry in open formats such as TMX. Sending a memory file by email means sending not only the translated sentences but this metadata layer too. Whether the metadata fields have been cleaned before sharing is rarely asked.
Metadata also produces context. A sentence that looks meaningless on its own acquires meaning once it is combined with the project tag beside it: it becomes clear which company had a document translated, in which period and on what subject. Inferences of this kind do not need the whole document; a few hundred segments may be enough.
Which document types carry the highest risk?
Memory risk is not the same for every document. It accumulates in documents with a high repetition rate, dense in information about individuals and long-lived.
| Document family | What accumulates in the memory | Risk level |
|---|---|---|
| Medical reports and discharge summaries | Diagnoses, dates, patient statements | High: special category data |
| Case files and pleadings | Details of parties, witnesses and counsel | High: third-party data |
| Human resources documents | Names, pay, performance statements | High |
| Commercial contracts | Names of parties, amounts, penalty clauses | Medium: mainly trade secrets |
| Technical manuals | Descriptions of devices and processes | Low |
| Marketing copy | Campaign language, slogans | Low |
The table is a starting point rather than a rule. The decisive criterion is the content of the document, not its name; even the annex to a single technical manual may hold the contact details of service staff.
The second factor that raises risk is continuity. When documents of the same kind are written to the same memory for years, what emerges is an accumulation far broader than any single document. A five-year-old human resources memory can turn into a silent record of an organisation’s staff movements. Records that look harmless one by one become something else once they are gathered together.
Why is it hard to delete data from a memory?
When a data subject comes forward with a deletion request, the first place anyone looks is the document archive. Yet a copy of the same data sits in the translation memory, and there it is stored sentence by sentence rather than file by file. Extracting one person’s data means finding the segments belonging to that person through search queries.
The second difficulty is copies. A memory rarely sits in a single place: the master memory on the server, the local copy on the translator’s computer, the project-specific working memory, the snapshots in the backup system. A segment deleted from the master memory may carry on living in the backups.
The third is that deletion damages the function of the memory. Removing segments lowers the future match rate and reduces the cost advantage. This can never be a ground for refusing a deletion request, but it does create quiet resistance on the provider’s side.
The practical answer is to start out in a way that makes deletion easy: a separate memory for every client and, where possible, for every sensitive project. A separate memory reduces a deletion request to the destruction of a single database.
How far do anonymisation and masking help?
A common proposed solution is to replace the names in the document with placeholders before sending it. The method works, but it has limits, and those limits are usually assumed to be wider than they are.
First, identity does not arise from names alone. The combination of occupation, institution, date and place often points to a single person. In an account of an incident that took place in a small town, deleting the names may not conceal the identity.
Secondly, translating masked text creates quality problems. In Turkish, placeholders take no inflectional suffixes, so the sentence breaks down; and when the translator cannot see the context, faulty solutions follow. Filling the text back in after masking is a separate source of error.
It is therefore more accurate to treat masking not as a security measure on its own but as a layer that completes the other measures. The real measure is to limit who and which systems the document reaches.
Who owns the memory? The tension between ownership and data protection
Ownership of the memory is an unresolved question in the industry. Translators see the memory as the accumulation of their own labour; clients say it is made up of their own texts. The fact that most freelance translators hold their own tool licence feeds the argument; in one case study that share was measured at 91 per cent (Pietrzak & Kornacki 2021).
From a data protection point of view the ownership argument is secondary. If a memory contains personal data, data protection rules apply regardless of whose labour created it. In other words, even if the memory belongs to the translator, your authority to give instructions about the personal data inside it remains.
In practice there is a middle way that both sides can accept: the memory is treated as belonging to the client, it is handed over at the end of the job and the provider may not use it for other clients; in return, the provider may keep its own general terminology assets in a separate resource. This distinction is established in a single sentence in the contract.
The middle way has a commercial benefit as well. A client that treats the memory as its own asset carries the accumulation along when it changes supplier, and the discount base for repeated text is preserved with the new provider. A client that never asks for the memory starts from zero at every change of supplier; that is a loss of budget as much as of data control.
How is a retention and destruction policy built?
The policy does not have to be a long document. Once the following six decisions are clear, memory management is largely solved:
- For which document types will a separate memory be opened?
- For how many years will memories be kept, and what happens at the end of the retention period?
- Will local copies be allowed, and if so how will they be destroyed?
- Will the metadata fields be cleaned when a memory is released to an outside party?
- What steps will be followed when a deletion request arrives, and who will be responsible?
- How will destruction be recorded?
Having these decisions in writing is the most concrete evidence of accountability at the moment of an audit. A verbal understanding disappears the moment the team changes.
The Türkiye context
In Türkiye the use of translation memory is well established in the large agencies, but memory management is mostly left to the initiative of the technical team. It is rare to see a clause on memories in client contracts; often the very existence of the memory is not disclosed to the client.
The sworn translation workflow creates a situation of its own. Documents such as civil registry records, diplomas and powers of attorney are made up of formulaic sentences and produce very high match rates in the memory. While this raises productivity, it also turns the memory directly into a store of identity information: a single formulaic sentence holds a name, a date of birth and a place together.
The structure of Turkish adds a further layer. In an agglutinative language, proper names appear in inflected forms such as “Yılmaz’ın” or “Ankara’dan”. Automatic extraction tools can miss these forms; relying on automatic tools alone when cleaning a memory carries a higher risk in Turkish.
What does this mean for you?
You do not need to give up the translation memory; you need to make it visible. Four questions clear away most of the uncertainty when you speak to your supplier: is a separate memory kept for us, where is that memory held, who can reach it and what happens to it once the job is finished?
The memory is a cost tool at the same time. A memory that belongs to you travels with you when you change supplier and forms a discount base for repeated text with the new provider. A client that never asks for the memory has left both data control and bargaining power with the provider. We explain the effect of the repetition rate on price on our pricing page.
In our own practice, sensitive projects are given a separate client-based memory, the memory is delivered in TMX format on request, and its destruction is recorded. To design your organisation’s memory policy together, write to us.
This article is for general information only and is not legal advice. For your specific situation, consult your legal adviser.
Frequently asked questions
What exactly is stored in a translation memory?
The basic unit of a memory is the segment pair: a source sentence and its translation. Any name, address, amount or contract clause appearing inside the sentence is stored as part of that pair as well. Information on who translated what, when and in which file is also held as metadata.
Is it possible to delete a single client’s data from a memory?
Technically it is possible, but it is not easy. Segments are stored sentence by sentence rather than file by file; extraction depends on the metadata fields and on search queries. That is why the most practical answer is to use a separate memory per client from the outset.
If I change the names, does that make the memory safe?
Masking reduces the risk but is not regarded as sufficient on its own. Even without a person’s name, the combination of occupation, date and place can make an identity determinable. In Turkish, the fact that names take inflectional suffixes makes automatic masking harder still.
Who does a translation memory belong to?
If the contract says nothing, it is disputed. In practice the memory usually stays in the hands of the provider. You need to establish in writing that the memory belongs to you, that it will be handed over at the end of the job and that it will not be used for other clients.
References
- Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation. Routledge, pp. 25, 68–70.
- Bowker, L. (2005). Productivity vs Quality? A Pilot Study on the Impact of Translation Memory Systems. Localisation Focus, 4(1), pp. 13–20.
- Personal Data Protection Law no. 6698 – mevzuat.gov.tr