Data Security 5 August 2026
GDPR and Translation: The Regulatory Framework in Europe
The GDPR has produced concrete changes in the translation industry, reaching as far as the interfaces built by tool vendors. We set out the side of the framework that faces translation processes.
The European Union General Data Protection Regulation (GDPR) has left concrete traces on the translation industry since it came into force in 2018. Those traces are visible not only in the wording of contracts but also in the interfaces of translation software.
Contents
A regulation that reaches down into the software
The best sign that a regulation has genuinely settled into an industry is that it changes the design of products. memoQ, one of the translation tools, shows the user a warning that refers directly to the GDPR whenever an external machine translation engine is configured:
The source text will be sent to an external provider. If the text contains personal data, you may not be permitted to send it under the GDPR and national data protection legislation. Please check the provider’s Privacy Policy and Data Processing Agreement.
memoQ warning dialogue, as cited in Pietrzak & Kornacki (2021), p. 25
This warning does two things at once: it informs the user and it hands responsibility over to them. Because the software vendor cannot supervise how the tool will be used, it leaves the decision to the user.
Roles: controller and processor
The most important distinction the GDPR brings to bear on the translation process is the distinction between roles:
- Data controller: the party that decides why and how data will be processed – the company that sends the document for translation.
- Data processor: the party that processes the data on the controller’s instructions – the translation agency.
| Data controller | Data processor | |
|---|---|---|
| Who it is in the translation relationship | The company sending the document | The translation agency |
| What it decides | The purpose and the means of processing | Technical implementation only |
| Legal liability | Mainly here | Limited by contract |
| Breach notification | Notifies the authority | Notifies the controller |
| Sub-processors | Gives approval | Seeks approval |
A written data processing agreement has to exist between the two parties. It defines the subject matter, duration and purpose of the processing, the categories of data and the conditions under which sub-processors may be used. Because tiered subcontracting is widespread in the translation industry, the sub-processor clause matters particularly.
Translation memory: the forgotten database
GDPR debates usually focus on the document itself. Yet what becomes permanent in the translation process is the translation memory. The memory stores every translated sentence in both its source and its target language; personal data appearing in the document is written into the memory inside those sentences and remains there once the project is over.
This creates direct tension with the GDPR’s principle of the right to erasure. Picking out the segments belonging to a single person from a memory that has built up over years and been used across several projects is technically difficult.
The practical solution for documents dense with personal data is to use a separate memory that is destroyed at the end of the project. The advantage of the memory is then retained for corporate texts with a high repetition rate, while personal documents never enter the permanent archive.
What does data minimisation mean in translation?
The GDPR’s data minimisation principle requires that no more data be processed than the purpose demands. In translation this has a concrete counterpart: only the part of a document that actually needs translating can be sent.
If only the methodology section of a technical report is to be translated, for example, there is no need to send the list of participants attached to it. In many organisations this simple filtering is never done: the whole file is passed on as it stands.
What should a data processing agreement contain?
The agreement between data controller and data processor is the backbone of GDPR compliance. For a translation relationship, the following headings need to appear explicitly:
- The subject matter and duration of the processing. “Translation services” is not specific enough: which document types, which languages, for how long.
- The categories of data. If special category data is to be processed, this has to be stated separately; that category is protected more strictly.
- The sub-processor regime. Because tiered subcontracting is widespread in the translation industry, this is the most critical clause: may sub-processors be used, is notification or approval required, will the list be kept up to date?
- The status of the translation memory. Ownership of the memory, how long it is retained, whether it may be used on other clients’ projects.
- The use of machine translation. Which projects it is enabled on, how a request to switch it off is submitted, how the undertaking is documented.
- Breach notification. A deadline expressed in hours and a single point of contact. The data controller’s own notification deadline depends on this information.
- Destruction or return at the end of the service. What becomes of the documents and of the memory.
Most of these clauses appear in standard contract templates. The two that are specific to translation, and usually absent from templates, are the translation memory and machine translation clauses. These have to be added separately.
The GDPR provides for a data protection impact assessment (DPIA) where processing activities carry a high risk. Most translation processes do not cross that threshold, but in some situations an assessment is called for:
- translation of special category data on a large scale (for example, the bulk translation of a hospital archive),
- translation processes involving systematic and regular transfer abroad,
- translation workflows that feed automated decision-making processes.
Translating a single medical report does not require a DPIA. Sending thousands of patient files to a provider abroad on a regular basis does. Scale and continuity are what decide the matter.
What do EU clients ask for in the contract?
For companies working from Türkiye into the EU market, the GDPR mostly shows up not as an abstract debate about legislation but as a list of questions put in front of them during procurement. The requests most frequently met with on supplier assessment forms are these:
- a signed data processing agreement (DPA),
- a list of sub-processors and an undertaking to notify changes,
- a declaration of the countries in which the data is processed,
- an undertaking on the breach notification deadline,
- a retention and destruction policy,
- the existence of confidentiality undertakings from staff.
A supplier that keeps these documents ready shortens the procurement process by weeks. A supplier that does not is often struck off the list even when its price is attractive, because the buyer’s legal department will not approve the process.
This is an overlooked area of competitive advantage for translation suppliers in Türkiye: an agency that has put its paperwork in order gains an edge with EU-facing clients that is independent of price.
The logic of enforcement and the role of record keeping
The GDPR’s high ceilings for administrative fines are much discussed; in practice, what determines the size of the fine is less the scale of the breach than the process maturity of the organisation. Supervisory authorities look at the following when they make their assessment:
- the nature, gravity and duration of the breach,
- whether it was intentional or negligent,
- the steps taken to reduce the harm,
- the technical and administrative measures in place,
- the level of cooperation with the authority,
- how the breach came to light – did the organisation report it itself?
In a translation context the practical consequence is clear: if you have a written policy and a signed data processing agreement, then even if a breach occurs your position is substantially different from that of an organisation which has taken no measures at all. The presence of those measures has a direct bearing on the outcome of the breach.
The reverse holds too: in an organisation where staff upload confidential contracts to free tools, where this is known and yet no rule has been laid down, a breach is judged to be a systematic failing rather than mere negligence.
The GDPR’s accountability principle asks not that you be compliant but that you be able to demonstrate that you are compliant. This distinction is frequently missed in translation processes.
A concrete example: if you say that machine translation was switched off for a confidential document, how do you prove it? A one-line confirmation email obtained at the start of the project carries evidential value in an audit months later. A verbal confirmation does not.
The records that are reasonable to keep and cost little are these:
- which class of document was sent to which workflow,
- confirmations that machine translation was switched off on confidential projects,
- subcontractor notifications and approvals,
- destruction records,
- the dates on which the policy was announced to staff.
None of these records calls for a special system; a shared spreadsheet is enough. What matters is that they are kept regularly: a record produced after the event is no record at all.
The United Kingdom is a separate regime
A point that companies working into the EU often confuse: since leaving the EU, the United Kingdom has maintained its own data protection regime. Although the text runs largely parallel to the GDPR, it is a separate legal order and the supervisory authority is a different one.
The practical consequence is this: if you work for both EU and United Kingdom clients, your contracts are expected to refer to both regimes. A single declaration that “we are GDPR compliant” may not be regarded as sufficient in the procurement process of a buyer in the United Kingdom.
The Türkiye context
For a company in Türkiye the GDPR comes up in two ways. The first is that, where data belonging to people resident in the EU is processed, the territorial scope of the Regulation may be engaged. The second is that EU clients make GDPR compliance a contractual condition, and this is the route met with more often in practice.
The KVKK and the GDPR rest on similar principles but they are not the same. The clearest difference lies in the regime for transfer abroad and in the role of explicit consent. A company subject to both bodies of legislation has to assess them separately; compliance with one does not guarantee compliance with the other.
What does this mean for you?
If you are a company working into the EU market, your translation supplier’s GDPR position is no longer a technical detail but a commercial necessity. The checklist is short:
- Is there a written data processing agreement?
- Is the use of sub-processors declared and made subject to approval?
- Are the ownership of the translation memory and the conditions for its destruction defined?
- Can the machine translation engine be switched off?
- Is there an undertaking on the deadline for breach notification?
We have a working model that covers every one of these points; for your corporate processes, get in touch or take a look at our services.
Note: this article is for general information only and is not legal advice. For your specific compliance obligations, consult your legal adviser.
Frequently asked questions
Does the GDPR bind a translation agency in Türkiye?
If you process data belonging to people resident in the EU, you may fall within the territorial scope of the GDPR. Turkish translation agencies serving EU clients need to consider that possibility.
Is a translation memory personal data under the GDPR?
Yes, if a segment in the memory contains information relating to an identified or identifiable person. The memory then counts as a processing activity involving personal data.
How is the right to erasure applied to a translation memory?
It is technically difficult, because memories build up over years and are used across several projects. For that reason, using a separate memory that is destroyed at the end of the project is good practice for documents dense with personal data.
Are the GDPR and the KVKK the same thing?
They rest on similar principles but they are not the same. There are differences in particular in the regime for transfer abroad, in the role of explicit consent and in administrative sanctions. If you are subject to both bodies of legislation, you should assess them separately.
Sources
- Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation. Routledge, p. 25.
- Regulation (EU) 2016/679 (General Data Protection Regulation).
- Kişisel Verilerin Korunması Kanunu (6698) – mevzuat.gov.tr