Standard contractual clauses (SCCs) issued by the European Commission provide a mechanism for appropriate data protection safeguards for data transfers between EU and non-EU countries. Since June 2021, privacy professionals have been acclimatising to the new EU SCCs and the selection of modules, options in the clauses, plus a UK Addendum. While this has meant more re-papering, much of this has been relatively straightforward and many organisations have put in place a plan to move their existing SCCs onto the new SCCs. However, the new SCCs are not without their complexities. And one of these complications is the inclusion of Module 4 which is designed to cover processor to controller transfers.
In drafting the new SCCs, the Commission considered it was necessary to include a module that covered processor to controller transfers. In its May 2022 FAQs on the SCCs, the Commission states 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). Significantly, the Commission refers to both scenarios when (i) a processor is collecting data in the EEA on behalf of the controller, and when (ii) a processor is processing data received from a non-EEA controller, as relevant for Module 4. Below, we’ll take a look at this distinction. But, putting to one side the Commission’s view, one question being widely raised is whether Module 4 has any relevance at all in today’s commercial world.
Is Module 4 relevant at all?
One argument against the need for Module 4 is that it cannot be appropriate for a processor (vendor) to impose contractual terms on a controller (customer). Therefore, the argument continues, Module 4 is unworkable and illogical. Another objection is that in most/ all instances, a non-EU controller importer will be themselves required to comply directly with the GDPR under Article 3(2) so that the EU SCCs are not available anyway (as confirmed in recital 7 of the Commission Implementing Decision EU 2021/914).
Certainly the Information Commissioner’s Office in its recently updated guidance states that if an entity is a processor (in the UK) acting for a controller outside the UK, ‘it is never a restricted transfer when you send or return data to your controller (provided it is your controller of that same data)’ and, if the data flow is the responsibility of the controller, ‘it cannot be a restricted transfer as it would be a transfer within the same legal entity (ie from the controller back to the same controller). So, it seems that in a UK context, Module 4 is not relevant (although the ICO guidance doesn’t make the distinction between data collected in the UK and processing data received from a non-UK controller). However, clearly the European Commission in drafting the new SCCs thought differently.
Can a processor impose terms on a controller?
In considering the concern around Module 4 that a processor vendor exporter (let’s say in France) cannot impose contractual terms on a controller customer importer (let’s say in the US), it seems unlikely to be the case that a vendor can never impose terms on a customer. Certainly the biggest vendors can usually insist that a customer (especially if they have less bargaining power) has to accept their terms on a ‘take it or leave it’ basis. Additionally, there appears to be a tension with the requirements under Article 28. If a French processor is dealing with a US controller, is the French processor required to comply with Article 28 to ensure that the contract it enters into with a US controller contains those provisions? Under Article 83(4) a processor can be fined for non-compliance with Article 28 so a prudent EU processor would want to ensure its contracts with non-EU customers complies with Article 28 (however watered down and light-touch these clauses might be). Unhelpfully, Module 4 does not actually include Article 28 requirements, which suggests a lack of logic to the drafting. It's additionally at least possible that the French vendor will not want to try to impose European derived contractual provisions on a prospective US customer especially if the vendor is worried that this will ‘kill the deal’.
So what provisions does Module 4 of the SCCs contain and what is the impact on the US customer? Straight off the bat, a US customer could object to Clause 3 which gives individuals third party beneficiary rights, certainly less appealing in an increasingly litigious culture. Clause 8 is mostly concerned with obligations on the French vendor. Sure, the US customer has to implement security measures to protect the data but nothing more onerous. Clause 10 indicates that the parties will assist each other in dealing with requests from individuals and Clause 11 requires the US customer to inform individuals of a contact point to deal with complaints. But Clause 12 is a sticking point since it sets out a liability regime that a US customer may be unwilling to sign up to especially since, on the face of it, Clause 12 can be interpreted as requiring the parties to agree to unlimited liability.
Notably, Clauses 14 and 15 (the so-called Schrems II clauses) only apply where the French exporter combines the personal data received from the US importer with personal data collected by the exporter in the EU. Clause 16 gives the French vendor the power to suspend transfers of data to the US customer or terminate the SCCs if the US customer is in breach of the SCCs. Governing law and choice of forum and jurisdiction are much more flexible under Module 4 and there is no requirement to identify a competent EU supervisory authority or set out a description of security measures.
So the Commission only distinguishes between data collected in the EU and data provided by a non-EU controller for the purposes of Clauses 14 and 15 (to restrict public authority access to data). Indeed, the Commission states that ‘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’ (recital 16 of Commission Implementing Decision). In other words, the Schrems II requirements are not required because the data is already under the remit of the non-EU jurisdiction and subject to public authority access in that country.
However, if the US customer only wants the French vendor to store personal data that the US customer has already collected (in the US) and with no further collection of personal data in the EU, the remainder of Module 4 still applies – including the liability provisions. Arguably, there is a lack of logic here. If Clauses 14 and 15 do not apply because, for example, the only data at issue is data on individuals located in the US, then it seems inappropriate for Clause 3 (third party beneficiary rights), Clause 12 (liability) and Clause 16 (suspension/termination rights) to apply in the way that they do. If the individuals whose data is processed are not EU individuals (whether EU residents/citizens or just passing through), then why would they need to be given the additional protections required by EU law? The protection though should arise if the French vendor collects personal data in the EU (ie about individuals in the EU). But Module 4 does not consistently make this distinction which can add to the confusion about the purpose of Module 4.
Will a non-EU controller be subject to the GDPR anyway?
Then there is the argument that Module 4 will never (or hardly ever) be relevant since the non-EU controller will itself be required to comply with the GDPR directly under Article 3(2) (or even Article 3(1) under Google Spain reasoning). So a US customer who is offering goods or services to individuals in the EU or monitoring the behaviour of individuals in the EU is directly subject to GDPR (the so-called ‘targeting criteria’). This immediately prompts certain questions. What if the US customer is offering a service to businesses rather than directly to individuals? Is that processing subject to the GDPR? And if Article 3(2)(a) is meant to cover such B2B processing, why does it not say something like ‘the offering of goods or services, irrespective of whether a payment of the data subject is required, in the Union which involves processing of personal data’ rather than referring to offering goods or services to individuals (and confusingly recital 23 seems to envisage circumstances only involving consumers)? Also, when considering what ‘monitoring’ means under Article 3(2)(b), the emphasis from the recital appears to be on online monitoring (recital 24) rather than other forms of monitoring (although the European Data Protection Board (EDPB)’s guidance on Article 3 allows that this could encompass a broad range of monitoring activities which includes offline behaviour).
Therefore, the risk of assuming that in all instances a non-EU controller is itself directly required to comply with GDPR, is that there may plausibly be circumstances where processing slips between the cracks and neither fits neatly under Article 3(2)(a) nor (b). As such, there could be a transfer of personal data about EU individuals from an EU exporter processor to a non-EU importer controller where that importer is not directly caught by the GDPR. If Module 4 did not exist, the argument goes, there is a risk that the data would not easily be protected through another solution under Chapter V of the GDPR. Yet, on the other hand, if the non-EU importer is not directly caught by the GDPR, the importer will be subject to additional requirements (ie Module 4) if it uses an EU processor exporter in contrast to if it did not use a processor at all.
We know from EDPB guidance (for public consultation) that transfers to a controller already subject directly to the GDPR does, in their eyes, still require a transfer solution. In the view of the EDPB a transfer takes place ‘irrespective of whether or not this importer is subject to the GDPR in respect of the given processing in accordance with Article 3’ (EDPB draft guidance on interplay between Article 3 and Chapter V). The EDPB further comments that ‘the Article 3(2) situation should be taken into account in order not to duplicate the GDPR obligations but rather to address the elements and principles that are ‘missing’ and, thus, needed to fill the gaps relating to conflicting national laws and government access in the third country as well as the difficulty to enforce and obtain redress against an entity outside the EU’. The Commission has confirmed that it is developing an additional set of SCCs that can be relied upon when an importer is subject to the GDPR itself (Commission FAQs, Question 24). Presumably these will also be available for processor to controller transfers where the controller importer is subject to Article 3(2).
What is the purpose of the rules on international data transfers?
Much of this debate boils down to the key question concerning the purpose of the rules on international data transfers under EU data protection law. The current rules set out under Chapter V follow the same shape as the framework under the old EU Data Protection Directive and an opportunity was lost to shake up this approach when the GDPR was drafted. The purpose of the rules stated by the Commission appears to be ‘to ensure that the level of protection of natural persons guaranteed by [the GDPR] is not undermined where personal data is transferred to third countries’ (recital 1, Commission Implementing Decision which echoes Article 44, GDPR). This undermining must not happen either (i) by private sector entities, including the importer(s), or (ii) by third country public authorities accessing the data.
Currently the GDPR does not provide explicit protection from (ii) since it does not include an Article with the equivalent protections that are found in Clauses 14 and 15 of the new SCCs. This is perhaps unsurprising since Clauses 14 and 15 were predominantly influenced by the Schrems II decision of July 2020 (so after the GDPR had been implemented into law). Additionally, the GDPR specifically recognises (and accepts) that there are situations where that high level of protection under EU law is not provided, hence the inclusion of the derogations in Article 49. Moreover, guidance from the EDPB (and mirrored by the Information Commissioner's Office) has underlined that the direct transfer of personal data from an individual in the EU to a non-EU controller is not a regulated transfer (whether the non-EU controller is caught by Article 3 or not). Critics could argue that this interpretation circumvents the high level of protection EU individuals should receive. But the fact that there is no controller or processor subject to the GDPR (only an individual in the EU) means that the EDPB does not consider this to be a restricted transfer. Moreover, even if the non-EU controller receiving the data from the EU individual is caught by Article 3, there are no equivalent Clauses 14 and 15 restrictions on it concerning public authority access to data. Of course, it would be mostly unworkable to require a non-EU controller, not subject to the GDPR, to in some way, comply with Clauses 14 and 15 like protections when they receive data directly from an individual.
But if one of the purposes of the international data transfer rules is to restrict third country public authorities' access to data, the idea that a transfer within the same company (eg from a company in France to its branch office in the US) is not a restricted transfer poses a dilemma. A transfer of personal data to the US branch office means data becomes subject to domestic US law. The EDPB comments that the sender and recipient are not different entities, so the data is processed within the same controller/processor. Consequently, entering into the SCCs will not be available. However, such a transfer does theoretically risk undermining the high level of protection since there are no restrictions on the US branch recipient from disclosures to US public authorities apart from those the French company may seek to extend to all its activities (including in the US) for GDPR compliance. This would suggest that the high level of protection could be undermined.
Where does this leave Module 4?
The rules on data transfers have become overly complex in recent years. Module 4 may well have been included in the new SCCs by the Commission partly for intellectual completeness. Or perhaps to provide some level of assurance to a category of non-EU customer who wants to engage EU vendors although is required by other pressures to stick more assiduously to the strict letter of the rules. Whatever the rationale, there are aspects of the legal framework for data transfers which are creaking under the weight of all that is now required and Module 4 does not lend itself to easy application.
The Commission evidently believes Module 4 has a role. It indicates that Module 4 should be approached differently as it should ‘reflect the limited self-standing obligations for processors under’ the GDPR (recital 16, Commission Implementing Decision). Module 4 does not though distinguish sufficiently between data that is collected in the EU and therefore requiring protection, from data that has been provided directly from the non-EU controller (and a further layer of complication could arise if the non-EU controller provides data which was originally collected in the EU although not by this EU processor).
For those who think that Module 4 has no role to play in any transfer scenario, Module 4 will continue to be a curiosity only. Others may, however, want the reassurance of signing Module 4 given that it conceives of data transfers from a processor to a controller even if the GDPR applies directly to the recipient controller (since there is currently no SCCs available for that type of transfer). Certainly, the EDPB has indicated that a transfer to a recipient subject to the GDPR is still a transfer where Chapter V applies. And if a transfer takes place, presumably a transfer mechanism is required. A version of the SCCs that covers processor to controller transfers is likely, therefore, to be of help. In time, when the Commission publishes the alternative set of SCCs for transfers to recipients caught by the GDPR, it may become more straightforward to discern where the parameters lie. But until then, Module 4 may leave many a privacy professional scratching their head as another sign of the ‘wheels within wheels’ of data protection law.
