Transfers of personal data from the EEA to countries outside the EEA are regulated by the General Data Protection Regulation (GDPR), which mandates that such transfers ensure an 'adequate level of protection,' comparable to that mandated by the European regulation.

For certain countries, including Argentina, Japan, or Switzerland, the Commission adopted an 'adequacy decision,' by which it recognizes that their legal frameworks do provide the required level of protection.

In the absence of such adequacy decision, organizations transferring personal data to non-EEA countries must employ alternative measures to legitimize the transfer, such as the Standard Contractual Clauses (SCCs) issued by the Commission.

The new set of SCCs is designed to: (i) define the controller-processor relationship in compliance with Article 28(3) and (4) of the GDPR; and (ii) serve as a tool for organizations to facilitate secure data transfers from the EEA to third-country recipients, ensuring adequate safeguards in line with GDPR requirements.

The introduction of new SCCs did not come without intricacies, and one notable complexity is the incorporation of Module 4. Module 4 is an entirely new addition crafted to address data transfers from a processor (the data exporter) to its controller (the data importer). Historically, transfers falling under Module 4 did not fall under the purview of SCCs. In practice, data processing agreements concluded in compliance with Article 28(3) of the GDPR were the customary means of addressing such transfers.

The inclusion of Module 4 has sparked considerable inquiry and discussion.

What is the purpose of Module 4?

In formulating the new SCCs, the Commission deemed it essential to incorporate a module specifically addressing transfers from a processor to a controller.

In its New Standard Contractual Clauses - Questions and Answers overview on the SCCs, the Commission clarified that 'Module 4 should be used where a processor in the EEA is hired by a controller outside the EEA, either to collect data in the EEA on behalf of the controller or to process data received from the controller in the EEA' (question 30).

The Commission specifically identified two situations as relevant to the scope of Module 4: (i) where a processor is involved in collecting data within the EEA on behalf of a controller; and (ii) where a processor processes data received from a non-EEA controller.

For instance, a company in Chile uses cloud services for data storage and backup from a company in Luxembourg. Module 4 can be used by the Luxembourg company (the data exporter) to transfer the data from its server in Luxembourg (back) to the client in Chile (the data importer).

Who can use Module 4?

As stated above, according to the Commission, Module 4 pertains to the association between non-EEA controllers (e.g., a company located in Chile) and an EEA processor (an EEA service provider, e.g., a company located in Luxembourg).

Skeptics have raised queries regarding the relevance of such a module, contending that, in most instances, the non-EEA controller would likely be subject to the GDPR under Article 3(2)(i.e., when the non-EEA controller is offering goods or services to individuals in the EEA or monitoring the behavior of individuals in the EEA).

It is crucial to recall that non-EEA entities, whether acting as controllers or processors, and obligated to comply with the GDPR under Article 3(2), are not required to establish SCCs at all. In this regard, the Commission considered in Recital (7) of its Implementing Decision EU 2021/914 that:

'[…] The standard contractual clauses may be used for such transfers only to the extent that the processing by the importer does not fall within the scope of Regulation (EU) 2016/679. This also includes the transfer of personal data by a controller or processor not established in the Union, to the extent that the processing is subject to Regulation (EU) 2016/679 (pursuant to Article 3(2) thereof), because it relates to the offering of goods or services to data subjects in the Union or the monitoring of their behaviour as far as it takes place within the Union.'

Regardless of such queries, and in all cases where controllers are not subject to the GDPR, it is essential to emphasize that EEA service providers (acting as processors) are consistently subject to the GDPR, including data transfer restrictions. In this context, the SCCs predominantly aim to impose obligations on EEA service providers. The SCCs, in principle, do not impose heavy obligations on non-EEA controllers, except for the obligation to refrain from providing instructions to the processors that would hinder their compliance with the GDPR and to adequately safeguard personal data against breaches.

Interestingly, in respect of the position under the UK GDPR, the Information Commissioner's Office (ICO) states that for processors established in the UK, it is never a restricted transfer when that UK-based processor sends or returns data to a non-UK based controller. The ICO states that this data flow is the responsibility of the controller, as it must always have been initiated and agreed by the controller. This means such transfer cannot be a restricted transfer as it would be a transfer within the same legal entity (i.e., from the controller back to the same controller). Processors are only responsible for complying with the transfer rules if it is the processor which has initiated and agreed to the data flow (in the case of processors, this would usually be transfers to sub-processors). The example in the ICO's A guide to international transfers states that:

'A Bolivian company uses a UK processor to store and manage its customer database. Under its processor agreement, the UK processor is instructed to send reports containing personal data directly to the Bolivian company's parent company in Argentina. This is not a restricted transfer, as it has been initiated and agreed by the Bolivian company.

If the Bolivian company instructs the UK processor to return all the personal data back to it, there is no restricted transfer.

If the Bolivian company instructs the UK processor to forward all the personal data to a new replacement processor also located in Bolivia, then there is no restricted transfer by the UK processor.

But, if UK GDPR applies to the Bolivian company about the processing of its customer database, then there is a restricted transfer between the Bolivian company and its Argentinian parent company, and between the Bolivian company and its new replacement processor located in Bolivia.'

On this basis, the  ICO confirms that where the non-UK based controller has initiated and agreed the transfer, then it is the controller which is responsible for complying with the transfer rules. If the UK GDPR does not apply to the controller, then the UK GDPR transfer rules do not apply at all.

Whilst a moot point given the different UK and EU regimes post-Brexit, perhaps the ICO's reasoning can or should have been applied to the Commission's position under the GDPR and use of Module 4. On the basis of the ICO's practical approach, Module 4 is seemingly redundant, save for instances where the transfer is made from the processor established within the relevant territory (i.e., the UK or EU) to a different controller based outside of the UK or EU, or where such transfer is carried out by the processor on its own initiative to different controller - a scenario which would have to be contemplated in the relevant agreements between the parties.

What if non-EEA processors are operating on behalf of non-EEA controllers? 

Evidently, if the criteria outlined in Article 3(2) of the GDPR are not satisfied, neither organization falls under the scope of the GDPR. Consequently, there is no obligation for them to employ any SCCs and any such use would be on a voluntary basis. However, in cases where the GDPR is applicable, it is likely that the entities are mandated to adhere directly to the GDPR under Article 3(2), making the use of SCCs once again optional.

What is the content of Module 4?

Module 4 specifically impacts certain clauses of the SCCs.

Firstly, Clause 8 is focused on imposing obligations on the EEA processor for processing data on documented instructions, while the non-EEA controller is tasked with implementing appropriate technical and organizational measures to safeguard the data. Both parties are obligated to demonstrate compliance with their respective responsibilities.

On the other hand, Clause 10 outlines that the parties will mutually assist each other in addressing requests from individuals, and Clause 11 necessitates the non-EEA controller to inform individuals of a designated contact point for handling complaints.

A critical aspect arises with Clause 12, establishing the liability regime for both parties. This clause suggests that the parties might be construed as agreeing to unlimited liability for any damages resulting from a breach of these clauses.

Moreover, it is crucial to recognize that Module 4 introduces a distinct set of obligations contingent on whether the processor solely processes data received from the controller or combines it with data collected within the EEA. Notably, Clauses 14 and 15 are only applicable when the EEA processor integrates personal data received from the non-EEA controller with data collected within the EEA. Indeed, according to the Commission, 'no such requirements (in Clauses 14 and 15) are justified where the outsourcing merely involves the processing and transfer back of personal data that has been received from the controller and in any event has been and will remain subject to the jurisdiction of the third county in question.' In other words, the requirements of Clauses 14 and 15 are unnecessary because the data is already within a third-country jurisdiction.

Finally, the provisions regarding governing law and jurisdiction (Clauses 17 and 18) are notably more flexible under Module 4, and there is no requirement to identify a competent EU supervisory authority or provide a detailed description of security measures.

Conclusion

The introduction of Module 4 under the EU SCCs has added a new layer of complexity in the data protection landscape, particularly for data transfers between EEA-based processors and non-EEA controllers.

From a commercial perspective too, the overall relevance of Module 4 is doubtful. On one hand, large vendors, typically acting as processors, may not tailor their contracts specifically for individual customers (controllers). On the other hand, smaller vendors may not have the weight to impose terms on their clients. Whilst the existence of Module 4 may offer clarity and legal certainty in the processing and transferring data on behalf of non-EEA controllers (which for internal compliance or other reasons do require SCCs in place), the need for Module 4 to be used in every circumstance is debatable.

Charlotte Gerrish Founding Lawyer
[email protected]
Evane Alexandre Trainee Lawyer
[email protected]
Gerrish Legal, Paris