With the European General Data Protection Regulation in full force since 25 May 2018, companies handling the personal data of people within the European Economic Area are required to comply with the stipulations set out in the directive. What should freelance translators do to make sure they fulfil the requirements? This article list five best practices around the GDPR for translators.

The GDPR for translators

The GDPR does not need any introduction anymore. In the past few months, and especially in the last weeks, people were flooded by emails requesting them to give consent for use of personal data, urged to sign new contracts and informed about their rights as ‘data subjects’. That translators were struggling with the new regulation as well, was made clear by all the reactions I received on my previous blog about the GDPR for translators. The blog post really struck a chord, offering a fundamental overview of everything translators (and other professionals as well) should know and do in regard to the GDPR. In some cases the GDPR really requires tons of work, but there is also a positive side of the coin: in the last few months I translated tens of thousands of words about privacy, consent and data protection officers. And given the comments of many colleagues, I am not the only one enjoying an intense workload about something that was affectionately called ‘Lawyer’s Paradise’.
However, what could translators do to make sure all aspects of the complex matters are covered? The five best practices below can offer a helping hand.

1. First things first: know your position with regards to the GDPR

Although the General Data Protection Regulation is forbidding companies and organizations alike to use ‘transparent’ and ‘unambiguous’ methods and information, and to avoid ‘[utilizing] long illegible terms and conditions full of legalese’ (source), the regulation itself is a real maze for people not used to policy and politics. As a result translators might overlook rules they should implement or implement measures that they are not obliged to. In order to help you a bit I created the flowchart below, which contains the GDPR requirements in a nutshell.

Do you finish in the green box? Than make sure to read on in this blog. If not, rest assured that you do not need to implement any rules, unless you change your business in the future.

2. Get insight into the personal data you are collecting

It is important to know what personal data you are collecting, and where they come from. If you are working for business only and specialize in technical translations, literature or something similar, you should not worry about data collection in light of the GDPR. If you are working for individuals outside the European Economic Area (EEA) there’s no reason to worry either. However, even one tiny private client can shake up your business as a whole. Also be alert when you are handling data from individuals from all countries belonging to the (EEA): you are required to comply to the GDPR then. The difficult thing is that when you are translating individual’s data for a client, similar employee data for a company or medical data you received in a project from a translation agency, you should cover all GDPR aspects as well. This also applies when you do not serve European individuals in business, but are collecting email addresses in order to send out newsletters.

There are loads of different personal data you might collect — and for various reasons. Translators working for individuals generally collect the following ‘general’ data:

• Name
• Address
• Email address
• Telephone number

For this type of data no special requirements apply.
There are however also special types of data, called ‘sensitive data’.
These data concern:

• Race and ethnicity
• Political, religious or philosophical beliefs, including union membership
• Health, sex life and sexual orientation
• Genetic and biometric data

Article 9(1) of the GDPR states:

‘Processing of personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person’s sex life or sexual orientation shall be prohibited’.
These types of data may only be processed if there has been explicit consent by the data subject or if processing is necessary for different reasons.

3. Stick of using Google Translate (and other translation engines)

I admit, professional translators should not make use of Google Translate and the like for their translations. However, given the comments of people in business, you are certainly not the only one to make use of translation engines to look up a specific word or find a useful synonym. Making use of Google Translate and its competitors for translating texts containing personal data however, is out of the question now. The terms of service for Google, for instance, state:

‘When you upload, submit, store, send or receive content to or through our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works (such as those resulting from translations, adaptations or other changes we make so that your content works better with our Services), communicate, publish, publicly perform, publicly display and distribute such content’.

If you still want to make use of Google Translate, DeepL and other translation engines, you should sign a data processing agreement, but chances are small that these giants are willing to draft a special agreement for freelance translators seeking to ease their work by making use of automatic machine translations.

4. Implement controls to anonymize and pseudonymize data

The GDPR has introduced requirements to anonymize and pseudonymize personal data. With pseudonymization data are separated from direct identifiers so that linkage to an identity is not possible without additional information, which is held separately. By using pseudonymization the risks associated with data processing might be limited, but the data can still be used.
Pseudonymization and anonymization might be burdensome however. You can ease the pain and speed it up by using macros or find and replace features. If you are using SDL Trados Studio you might make use of projectAnonimizer, a tool designed to protect data during a translation project by converting it to tags. After a project, users can ‘unprotect’ the data as well, so the tool does not entirely prevent you from obeying the GDPR requirements.

5. Make sure you are using encryption

Having said this, implementing the GDPR is not released from its human aspects. In the whole process both people and technology can be the weakest link. To avoid leaking personal data in the unfortunate situation of a hack or theft, you can apply encryption. Encryption can take many forms, but the most common solution is to apply a password to files, folders, data repositories and software. There are many tools out there, so feel free to find an encryption solution that works best for you. And don’t forget to create a user account with password for your computer (which you should actually apply when you leave your computer to avoid your data being compromised or viewed by prying eyes).

What are the risks of not complying?

The GDPR introduces a penalty of €20 million or 4% of the global annual turnover, whichever is more, for companies not complying with data protection rules. That is scary of course, but it is the price for the big fish: multinational companies which can afford to loose such a sum. That does not mean however that freelancers and small business are set free of their responsibilities. All companies that do not prove to be compliant can expect fines. In The Netherlands however, the secretary of state has said that small companies should not readily expect a fine after 25 May as long as they can prove that they are in the process of implementing the directive. At the same time the authority responsible for enforcement fears that it does not have the required capacity to enforce the data protection stipulations itself.
Conclusion: do not be too afraid, but make sure you are implementing all rules that apply to you!