The data transfer regime for processors does not make sense and requires clarification

Under the GDPR, certain provisions become directly applicable to EU processors, including the data transfer requirements. Article 46 of the GDPR provides that controllers and processors may only transfer personal data to third countries that do not provide for an adequate protection (non-adequate countries), if the controller or processor has provided "adequate safeguards," and on condition that individuals are provided with enforceable rights and effective legal remedies. But is it correct to impose the same regime that applies to controllers also to processors?

I think not. The transfer requirement should only apply to processors when they transfer data to a sub-processor in a non-adequate country (and not when they transfer data to a controller, whether back to the original controller or to a subsequent third-party controller) and then in respect of their own data processor obligations only – and not the full scope of the GDPR. The regime should therefore neither apply when the processor transfers the data back to the original controller on whose behalf the processor is processing the data nor when transferring to subsequent controllers if the processor is instructed to do so by the original controller.

The issue may only be understood if we discuss the background on why the GDPR now imposes direct obligations on processors. The reason for this is interlinked with the ‘long arm’ applicability regime of the current Data Protection Directive, which has as an unforeseen result that EU data protection law applies also a controller in a non-adequate country (for example, the U.S.) without establishments and activities in the EU, that involves an EU processor – all while the original data processing by the U.S. controller is not governed by EU data protection law.  

Outsourcing by US controller to EU processor

Article 4(1)(a) of the directive contains the main provision for the application of EU data protection law. The directive applies to the processing of personal data “in the context of the activities of an establishment of the controller on the territory of a Member State.” To avoid circumvention of the directive, article 4(1)(c) provides that the directive also applies in the event that the controller is not established in the EU, but processes personal data making use of “equipment” situated in a member state unless this equipment is used for transit purposes only.

An example of potential applicability of Article 4(1)(c) that was totally unforeseen by EU legislators is when a U.S.-based company (without establishments and activities in the EU) outsources its data processing activities to an EU data processor (or locates its own processing activities in the EU). As a consequence, U.S. data will be stored and processed on servers located in the EU (the servers qualifying as equipment) whereby such data processing cannot be considered merely for transit purposes. As a consequence, EU data protection law is applicable while the data processed concerns (in this case) U.S. data only, which falls within the EU scope only because the data is exported to the EU and transferred back again to the U.S.

This is confirmed by the WP29 in its Opinion on applicable law (p. 20 and 25). Many EU DPAs have indicated that insofar as the relevant data is indeed coming from outside the EU and transferred back again, EU data protection law applies and therefore also the EU data transfer rules, but that enforcement of these rules “will not be their priority.”According to the WP29, the result that EU law applies to these data processing activities has “unsatisfactory consequences” and is also not satisfactory in that “European data protection law is applicable in cases where there is a limited connection with the EU,” which “may have undesirable consequences in terms of economic impact and enforceability” (Opinion on applicable law, p.21 and 24).

Replacing the “equipment” criterion by the criterion of article 3(2) the GDPR, whereby the processing activities should be related to: (i) the offering of goods or services to such data subjects in the EU; or (ii) the monitoring of their behaviour in the EU,  however, would have in its turn as a consequence that EU data protection law does not apply to a U.S. controller with an EU processor. Also the data security requirements under EU data protection law would not apply, which might lead to inadequate security in EU territory potentially exposing the EU to cybercrime. Further, it creates an inherent risk that the EU will be used as a digital haven as there will be no legal basis under EU data protection law to act against these data processing activities in EU territory – even if the relevant data processing would be considered unethical to EU standards. In the words of the WP29: “There is a need to prevent situations where a legal gap would allow the EU being used as a data haven, for instance when a processing activity entails inadmissible ethical issues.”

However, rather than applying the full scope of the directive also to EU data processors, the WP29 suggested as an option (Opinion on applicable law, p. 31 – 32) that the data processor becomes subject to  specific EU data protection provisions only, such as in any event the EU data security provisions (as inadequate security in EU territory may expose the EU to cybercrime). The GDPR indeed now solves this issue by limiting the scope of the GDPR (by dropping the equipment criterion) and imposing certain direct obligations on processors.

The EU legislators therefore made the choice that the GDPR only triggers the limited processor obligations when a U.S. controller (not subject to EU law) involves an EU processor rather than impose the full scope of the GDPR upon such U.S. controller. They clearly rejected the alternative (in the current directive) whereby any data transferred by a U.S. controller (or another non-adequate country) to the EU processor and subsequently transferred back to the U.S. (or another non-adequate country) would attract the full scope of EU data protection law. With this background, an interpretation of the transfer rules under the GDPR, which would require EU processors to yet impose the full scope of protection of the GDPR on the U.S. controller when transferring data back to such controller or to a third-party controller, would be in contradiction with the choices made by EU legislators when drafting the GDPR. This would mean that via the backdoor of the transfer requirements, the full scope of the GDPR would yet be imposed on such controllers, which was clearly not the intention of the EU regulators. 

As the above may be somewhat abstract, here are three situations whereby a controller in a non-adequate country (again, let's take the U.S. as an example) involves an EU processor, which subsequently transfers personal data (i) to a sub-processor established in a non-adequate country; (ii) back to the original controller in the U.S.; and (iii) to a third-party controller in a non-adequate country.

Situation A. US data controller with EU data processor that transfers the data to a sub-processor in a non-adequate country

There are two options. The first is when the data processing by the U.S. controller is not governed by the GDPR and the second is when the data processing by the U.S. controller is governed by the GDPR. 

1. Processing by a US controller not governed by GDPR 

In this situation the original data processing by the U.S. controller is not governed by the GDPR, e.g. the controller does not have establishments in the EU and further the data processing is not related to (i) the offering of goods or services to data subjects in the EU; or (ii) the monitoring of their behaviour. The EU processor is subject to the GDPR and has to comply with the processor obligations that are directly applicable to processors under the GDPR. Pursuant to Article 28(3) GDPR, the EU processor should process data only based on a contract governed by EU law that contains a number of mandatory processing provisions. Pursuant to article 28 (2) GDPR the processor further requires the prior written authorization of the controller to involve a sub-processor and pursuant to article 28 (4) GDPR the processor has to impose the samedata protection obligations on such sub-processor as agreed by such processor in its contract with the controller.

Article 28 GDPR therefore does not require the EU processor to impose further requirements on the sub-processor than such processor itself has under its data processor agreement with the controller. This should also apply when the processor involves a sub-processor in a non-adequate country.

The fact that the data is transferred to a non-adequate country should not suddenly trigger an obligation to impose on the sub-processor the full material scope of the GDPR. The data transfer provisions in the GDPR, however, do not reflect this. Rather, they require processors (like controllers) to implement “adequate safeguards,” which seems to refer to the full scope of the GDPR rather than just the obligations of the processor.

This seems a drafting mistake rather than a purposeful decision to deviate from this system. The way to solve it is to interpret this requirement to mean that processors should provide “adequate safeguards” insofar as their own obligations are concerned only. This is also in conformity with the draft Standard Contractual Clauses for Processor to Processor transfers as proposed by the WP29 These proposed Processor SCCs also impose only the processor obligations on the relevant sub-processor in the non-adequate country (such as the security obligations, data breach notification obligations, etc.) and not the full scope of the GDPR. The same applies for the requirements set by the WP29 for authorization of Binding Corporate Rules for Processors. Also, these require that the processor obligations are imposed on the group companies of the processor involved in the data processor services rather than the full scope of the GDPR.

2. Processing by a US controller governed by EU law‎

In this situation the original data processing by the U.S. controller is already governed by the GDPR (e.g., because the data is also processed in the context of the activities of an establishment of the U.S. controller in the EU). In this case the transfer by the processor to the sub-processor also involves a transfer by the controller to the sub-processor (at least this is how many of the DPAs have interpreted this). These DPAs interpret the transfer requirement under the directive as imposing a requirement on the controller “to adduce adequate safeguards.”

The GDPR now imposes a similar requirement on the processor without indicating whether compliance by one (e.g., the controller) releases the other (e.g., the processor) or vice versa. I would assume that if the transfer is to a sub-processor, it should be sufficient that the processor complies and imposes its obligations on such sub-processor. If the data is transferred to a third-party controller, it is the controller who has to impose its obligations (i.e., the full scope of the GDPR) on the third-party data controller.

Situation B. US data controller with EU data processor that transfers the data back to the original controller

Again, there are two options.

1. Processing by US controller is not governed by GDPR 

Now the relevant processing is not governed by EU data protection law, the transfer rules should not apply at all. Otherwise the result would be that a processor should impose requirements (either its own, or the full scope of the GDPR) upon the original controller, while the original processing was not governed by the GDPR. The system chosen by EU regulators is that the GDPR does not apply to such processing and that only a limited number of obligations apply to the EU processor. Requiring that if the EU processor transfers the data back to the U.S. controller the full scope of the GDPR should be imposed on the controller is contrary to the intentions of the EU legislators. The transfer rules should in this case simply not apply.

2. Processing by US controller governed by EU law‎

If the original data processing by the U.S. controller is governed by the GDPR, the full scope of protection already applies to the controller also after the processor transfers the relevant data back to the original controller. Here, imposing additional requirements by the processor onto the original controller is not useful and the transfer rules therefore do not add any value. Also, the transfer rules should simply not apply.

Situation C. US data controller with an EU data processor, which transfers data to a third-party controller

Again, there are two options.

1. Processing by original US controller is not governed by GDPR 

The EU processor may only transfer data to a third-party controller when the processor is instructed to do so by the original controller. As the data is not governed by EU law, the transfer in fact takes place between two parties in non-adequate countries, with an in-between stop at the EU processor where the processor is subject to the direct obligations applicable to EU processors.

Here, the data transfer rules should not apply at all. The system chosen by EU regulators is that the GDPR does not apply to such processing and that only a limited number of obligations apply to the EU processor. Requiring that if the EU processor transfers the data to the third-party controller the processor should impose requirements (either its own, or the full scope of the GDPR) on the controller is contrary to the intentions of the EU legislators. The transfer rules should in this case simply not apply.

2. Processing by US controller governed by EU law‎

The processing activities that the original controller has instructed the EU processor to process on its behalf are already subject to the GDPR. Therefore, the EU data transfer requirements already apply to the U.S. controller when the U.S. controller instructs the EU processor to transfer the data to a third-party controller. 

Imposing the data transfer rules on the data EU processor therefore has no added value. Here the data transfer rules should not apply to the data processor.  

 Conclusion

The transfer rules should only apply to processors insofar as they transfer data to a sub-processor in a non-adequate country and then only in respect of their own legal obligations under the GDPR.

The WP29 already made draft Processor SCCs for this situation, and therefore I think we do not need any other SCCs. It would help if the WP29 could clarify that this is indeed how the data-transfer requirements for processors should be applied. The current provision whereby processors are required to impose “adequate safeguards” in case of transfers to all third parties in a non-adequate country – therefore both controllers and processors – seems incorrect.