GDPR : International Data Transfers

Under the General Data Protection Regulation (GDPR), personal data transfer outside of the EEA (i.e. EU and Norway, Lichtenstein and Iceland) or to international organisations are allowed only if one of the following conditions is met:

 

  • the third country is recognised as providing an adequate level of protection via an adequacy decision adopted by the European Commission;
  • adequate safeguards are implemented (e.g. EU Standard Contractual Clauses, BCR, approved certification or code of conduct.);
  • a derogation provided for in article 49 is applicable (e.g. express consent, vital interest etc.).

However, following the Schrem 2 ruling of the European Court of Justice (ECJ) striking out the Privacy Shield, the international transfer legal regime has become uncertain as the Court’s requirements are more difficult to meet. Indeed, it is now for the controller transferring the personal data to ensure that the legislation of the country do not contradict the implemented safeguards and if so, it must implement additional measures to fill the gap and address the issues.

The purpose of this article is to provide an overview of the requirements to transfer personal data outside of the EU/EEA.

1. Definition of " international data transfer"

Personal data transfer is not defined in the GDPR but according to the EDPB guidelines a processing operation qualify as a transfer if it meets the three cumulative conditions:

1) A controller or a processor is subject to the GDPR for the given processing.

2) This controller or processor (“exporter”) discloses by transmission or otherwise makes personal data, subject to this processing, available to another controller, joint controller or processor (“importer”).

3) The importer is in a third country or is an international organisation, irrespective of whether or not this importer is subject to the GDPR in respect of the given processing in accordance

2. Examples

Example 1: Transfer and onward transfer 

An organisation established in the EU stores its HR data with a cloud service providers whose servers are in the US.

This cloud service provider subprocesses the maintenance services to its subsidiary based in India.

In addition, it allows its headquarter located in Australia to remotely access HR data for the purpose of the global HR management of the group.

There are 2 international transfers and one onward transfer.

  • One transfers to a processor in the US
  • One transfer to a controller in Australia
  • One onward transfer to a processor from the US to India (which should be framed in the same way as an international transfer).

If the first processor in the US was based in the EU, there would be an international transfer between the first processor in the EU and the second processor in India instead of an onward transfer.

Example 2: only the processor is based in the EEA

A company based in the US asks a French company to process its employees data for analysis purpose.

The French company being subject to the GDPR as a processor, the sending back of the data from the French company to the US company is also considered as an international transfer. (Even though the US company is not subject to the GDPR for this specific processing).

However, the guarantee to implement would be much more limited in this case as the processor’s obligations under GDPR are quite limited (i.e. data security).

Example 3 : all the parties are located outside of the EEA

A company established in the US with no establishment in the EU operates a website from the US, which is directed to EU consumers.

A team based in Brazil ensures the maintenance of the website/database.

The US company being subject to the GDPR, the transfer from the US to Brazil is an international data transfer.

Even though it is not explicitly stated in the EDPB guidelines, we are of the opinion that if the IT providers in Brazil was located in the US, it would also be considered as a transfer to a third country insofar as the US are a third country from an EU perspective.

3. Cases where there is no international data transfer

If an employee travels abroad and remotely accesses the data during his travel, it is not considered as an international data transfer as the employee is not a different controller, he is the controller’s employee.

If a controller operates a website from outside the EU with no establishment within the EU, the transfer of data from EU website users/consumers to the US company is not an international data transfer. However, the Company remains subject to the GDPR.

This is due to the fact that the transfer must take place between two parties (i.e. either controller, processor or joint controller). However, in the first example, if the employees were to stay in the third country and become an agency/other body, the analysis may change.

Indeed, controllers or processors may be a natural or legal person, public authority, agency or other body so the terms "parties" should be ready broadly and for example branches (as opposed to subsidiairies) could be considered as another controller or processor.

Even though the notion of "establishment" is not expressly stated in the guidelines, it may be helpful to understand when a transfer take place without taking too much risk of missing out on something.

 

The purpose of the GDPR provisions relating to personal data transfer is to ensure that the data protection legal framework applicable in the recipient third country is essentially the same as the one applicable within the EU.

In particular, it must provide the same rights to individuals regarding the protection and use of their personal data.

Therefore, if a country is considered as providing a similar data protection legal framework, the European Commission may adopt an adequacy decision for this particular country (see adequacy decision section of this article).

Otherwise, it is necessary to implement adequate safeguards  (e.g. SCCs or BCR) in order to fill the gap.

As a last resort, organisations may rely on derogations provided for in article 49 GDPR. However, these derogations should be interpreted restrictively and therefore, should not be relied upon to circumvent the implementation of adequate safeguards.

As previously mentioned, the European Commission may adopt an adequacy decision for countries whose legislation provides similar guarantees to the EU's regarding the protection of personal data.

When a country is considered as providing an adequate level of protection, personal data transfer may take place under the same conditions as a data transfer taking place within the EEA (i.e. only entering into a data protection agreement with processor or joint controller where applicable).

As of today, the following country has been recognised as providing an adequate level of protection by the European Commission :

Andorra, Argentina, Canada (commercial organisations only), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New ZealandRepublic of KoreaSwitzerland , the United Kingdom under the GDPR and the LED, and Uruguay as providing adequate protection.

Except for the United Kingdom, these adequacy decisions do not cover data exchanges in the law enforcement sector which are governed by the Law Enforcement Directive (Article 36 of Directive (EU) 2016/680).

Since most countries and most notably the USA are not recognised as adequate countries by a decision of the EU commission, the GDPR allows to transfer of data to these third countries provided that adequate safeguards are implemented.

The adequate safeguards

These adequate safeguards are as follows:

  • Standard contractual clauses / SCCs (adopted by the European Commission or a EU member states) : it is a set of clauses that the data exporter and importer must enter into before transferring data. A different set of clauses is applicable depending on whether the transfer take place between two controllers, a controller and a processor, two processors etc. (see here for more detailed about the SCCs).
  • Binding Corporates Rules / BCR (processors and/or controllers), which are only aimed at covering international data transfers within a same group of companies. it is made up of a binding documents, which looks like the SCC  to which the entities of a same group can abide to.  The main difference is that one of the EU entities is the representative of all those located outside of the EU.
  • Code of Conduct and Certifications: these tools being relatively new, we have not seen much of these being developed. The closest example of that kind of tool may be the late Safe Harbor and Privacy Shield, allowing transfers to the US,  which have been both struck out by the ECJ).
  • Ad hoc contractuals clauses / international agreements (none of these tools exists as of today)
Additional measures may be required for certain countries (e.g. USA)

Since the ECJ ruling Schrems 2 of July 2020, controllers must also assess the legal framework applicable in the third country and ensure it does not contradict the SCCs (and by extension, other transfer tools).

If it does contradict the SCCs, additional measures must be implemented in order to address the risks not covered by  the “adequate safeguards” and fill the gap.

For example, the ECJ, in its Schrems 2 ruling, considered that using SCCs to transfer data to the USA was not sufficient because of the mass surveillance programme carried out in this country.

Therefore, additional measures preventing the US authority from accessing the data on demand had to be implemented. If such measures could not be implemented then, the ECJ considered that data should not be transmitted.

In a recent decision of the Austrian Data Protection Authority on the transfers carried out by Google Analytics, the authority seems to have implied that only encryption or anonymisation implemented by the exporter beforehand were valid additional measures in the case of the transfer to the US.

However, the validity of the measure depends on the type of transfer and of the risk to address, and therefore may change from one country to another and from one transfer to another.

As a result, identifying the gap and addressing them is a big burden placed on the exporter controller of the data.

The EDPB has provided guidelines to carry out such an assessment and identify the additional measures to be implemented but it still remains a difficult exercise. In this regard, the European Commission failed twice when carrying out such assessement as both the Safe Harbor and the Privacy Shield allowing data transfers to the USA, were struck out by the ECJ.

Article 49 GDPR provides for a set of derogations allowing the international transfer to take place in particular situations where it is not possible to implement adequate safeguards such as the SCCs or BCR.

The EDPB recalls that these derogations should only be interpreted restrictively and should not be used for systematic data transfers or for sending a large volume of data. Most of the derogations may only apply when the transfer is occasional.

Indeed, the principle is to implement adequate safeguards, the exception is to rely on the derogations set out in the articles 49 (see below).

The derogations
  • Explicit consent: the data subject must have explicitly consented to the proposed transfer, after having been informed of the possible risks of such transfers for the data subject due to the absence of an adequacy decision and appropriate safeguards.
  • Performance of a contract:  in this case the transfer must be necessary for:
    • the performance of a contract between the data subject and the controller (or in the interest thereof between the controller and another person); or
    • the implementation of pre-contractual measures taken at the data subject's request.

Besides, the transfer must be occasional and necessary for the performance of the contract and not stemming from the controller's organisation, which remains under its control. For example, a travel agency could potentially rely on this derogation when it needs to send its clients data to the hotel in a third country where its customers decided to stay for their holidays.

  • public interest: the transfer is necessary for important reasons of public interest; (are excluded the request from a third country authority in the absence of an international agreement).
  • legal claims: the transfer is necessary for the establishment, exercise or defence of legal claims.
  • vital interests: the transfer is necessary in order to protect the vital interests of the data subject or of other persons, where the data subject is physically or legally incapable of giving consent.
  • public register: the transfer is made from a register which according to Union or Member State law is intended to provide information to the public and which is open to consultation either by the public in general or by any person who can demonstrate a legitimate interest, but only to the extent that the conditions laid down by Union or Member State law for consultation are fulfilled in the particular case.
Compelling legitimate interests (if none of the derogations applies)

If none of the derogations is applicable, it is still possible to transfer the data if the following conditions are met:

  • the transfer is not repetitive, concerns only a limited number of data subjects;
  • is necessary for the purposes of compelling legitimate interests pursued by the controller which are not overridden by the interests or rights and freedoms of the data subject;
  • the controller has assessed all the circumstances surrounding the data transfer and has on the basis of that assessment provided suitable safeguards with regard to the protection of personal data;
  • The controller must inform the supervisory authority of the transfer;
  • The controller must inform the data subject of the transfer and on the compelling legitimate interests pursued.

All these conditions being very restrictive,  relying on a compelling legitimate interest is very risky from a legal perspective.

 



CONTACT

If you have any question, do not hesitate to contact Arnaud Blanc, French & UK qualified lawyer based in France.

GDPR : International Data Transfers
Tagged on: