Introduction
The Information Commissioner’s Office (ICO), the data protection regulator in the United Kingdom (UK), recently issued a consultation paper (CP) on the UK legal regime for international data transfers. This regime is provided for under the UK GDPR, the law that imports the EU GDPR into post-Brexit UK law. The CP and connected documents are available here.
The questions in the CP can be grouped into three themes relating to the UK GDPR: (1) its territorial scope (2) the concept of a ‘restricted transfer’ and (3) the conditions and safeguards applied to restricted transfers, including a new draft ‘international data transfer agreement’ (IDTA) that is the UK version of the standard contractual clauses (SCCs) accompanied with a tool for parties to conduct transfer risk assessments (TRA).
The ICO plans to use this consultation to finalise the IDTA, to update its interpretation of the UK GDPR which it publishes in official guidance and to inform its inputs being provided to the UK Government as the latter contemplates a more innovation-friendly approach to data protection.
We had, on September 27th, requested comments from our members on the CP. We submitted our responses to the ICO on 11th October. This post provides a theme-wise summary of the same.
A brief note on terminology
‘Processing’ is used to capture any operation performed on personal data, including accessing, copying, modifying, or transferring data. This is an intentionally broad term.
A ‘controller’ is the party that decides the purpose (the ‘why’) and means (the ‘how’) of processing. Two or more controllers that jointly decide the purpose and means of processing become ‘joint’ controllers.
A ‘processor’ is a party that carries out the processing on behalf of a controller. A processor may also appoint its own processor; these are called ‘sub-processors’.
Notably, parties are allocated roles based on the level of control they have over processing as per actual practice. Parties cannot merely contractually allocate roles.
The CP also uses two common terms in the context of international data transfers. An exporter is the party transferring data overseas. An importer is the overseas recipient.
Territorial scope
The UK GDPR has certain tests at two levels to define its territorial scope.
At the first level, it applies to any processing activity carried out by a controller or processor that has a UK establishment – even if the processing of personal data itself takes place outside the UK.
At the second level, it also applies to any processing activity carried out by a controller or processor without a UK establishment if that activity involves targeting UK data subjects with goods or services or involves the monitoring of their behaviour.
The CP asks questions on both levels. On the first, it posits the following. A controller has a UK establishment and is thus covered by the UK GDPR. Should the ICO adopt a presumption whereby this means that any processor or overseas joint controller of that UK GDPR controller is also, by extension, automatically covered by the UK GDPR?
We disagreed with this presumption. The legislative intent behind the first level is to apply the UK GDPR to a party based on the presence or absence of an establishment in the UK. To automatically infer from the controller’s circumstances instead is to deviate away from that legislative intent. This creates legal uncertainty on the operation of the first level.
On the second level, the CP posits the following. A controller without a UK establishment is carrying out an activity that targets or monitors a UK data subject. It is also covered by the UK GDPR. Does this mean any overseas processor of that controller involved in that activity is also automatically covered by the UK GDPR?
Here, unlike with the first level, we agreed with this presumption. An overseas processor would only be targeting or monitoring UK data subjects on behalf of the relevant controller. This presumption therefore makes it clearer to allocate roles to overseas processors that are involved in monitoring or targeting UK data subjects on behalf of controllers.
The concept of a restricted transfer
The UK GDPR imposes conditions on the transfer of personal data to overseas territories. The CP raised several questions on the concept of a restricted transfer itself.
First, is it a restricted transfer if only entity is involved? We stated that a restricted transfer must involve a handover of data from one entity to another. It should not cover, for example, a controller transferring data to another branch. This is to avoid the incidence of onerous costs to business.
Second, is it a restricted transfer if a processor governed by the UK GDPR returns data back to an overseas controller? Our response stated that this is not a restricted transfer if the UK GDPR does not apply to the overseas controller, which should not be required to be bound by transfer conditions flowing from a law that does not apply to it.
Third, does it matter the UK GDPR only applies to an exporter but not to its overseas importer? Our response stated that the applicability of the UK GDPR to the importer is not relevant. A restricted transfer takes place if an exporter transfers data to an overseas importer. This better ensures certainty by not requiring exporters to check if the law applies to their importers.
We also commented on the need for more guidance on the concept of a ‘transfer’ itself. We noted, for instance, that a risk-based approach is required. It is not appropriate, for example, for every mode of remotely accessing data located in the UK from overseas to be regarded as a transfer.
Transfer conditions and safeguards
The UK GDPR contains various frameworks under which restricted transfers may validly take place. The first framework, that is not discussed in the CP, is the reliance on adequacy decisions, whereby transfers may take place freely to territories deemed ‘adequate’ by the UK Government.
The second framework is the use of an appropriate safeguard – like SCCs, or, here, the IDTA. This has gained new significance after the Schrems II case that also applies to the UK GDPR (for more on the Schrems II case, read our study available here).
Here, an exporter may transfer personal data to importers in territories not yet deemed adequate if the exporter first conducts a TRA and then adopts a safeguard. The CP provides a draft tool for conducting a TRA in a structured manner. We considered the tool to be a good start but noted that its use is limited when more complex transfers involving multiple parties and jurisdictions are involved. We also suggested the need to incorporate a risk-based approach to the treatment of new technologies.
We suggested that the IDTA needs a more user-friendly format and should come with guidance on its use in complex transfers. The CP also asked whether the IDTA, as a standalone document, should be accompanied with adapted versions that can be attached to existing SCCs used in other jurisdictions. We agreed with this approach – particularly with the suggestion to adapt the IDTA as an addendum to the SCCs under the GDPR. This is useful for data transfers involving both the UK and the EU.
As a general comment on transfer frameworks, we asked the ICO to emphasise party flexibility. For example, even if exporters do not use an appropriate safeguard and use a ‘derogation’ instead – like asking for explicit consent to make a transfer – the ICO’s approach should not limit their flexibility to do so.
Conclusion
After Brexit, the UK Government has found space to navigate data protection law on its own. As a beneficiary of an adequacy decision from the EU, it is likely to not deviate from the GDPR too much. As the ICO consultation indicates, however, this navigation has already begun.
This is likely to be followed with the execution of plans to explore more ‘innovation-friendly’ reforms to UK data protection law (currently quite complex post-Brexit) and to build data adequacy partnerships with trading partners in two stages (India is on the list for Stage 2).
For more information or any questions on our submission – which is attached with this post - please contact Varun or Apurva at varun@nasscom.in and apurva@nasscom.in respectively.
