NEW EDPB GUIDELINES ON THE CONCEPTS OF CONTROLLER AND PROCESSOR – SEVEN PRACTICAL TAKEAWAYS

More than two years after the GDPR came into force, the European Data Protection Board (the “EDPB”) finally published its long-awaited draft guidelines on the concepts of controller and processor on 7 September 2020.

Prior to this date, UK organisations only had the relatively limited guidance set out on the ICO website and the old Article 29 Working Party guidance, which predated the implementation of the GDPR, to go on when attempting to apply these fundamental concepts to real-world scenarios.

The new draft guidelines, which are open for public consultation until 19 October 2020, are split into two parts:

  • Part I addresses the concepts of controller, joint controller, processor and third party/recipient and the scenarios in which these roles should be allocated to parties that are involved in the processing of personal data; and
  • Part II sets out details of the measures that need to be put in place when controller-processor and joint controller relationships arise, providing detailed commentary in relation to the contents of a valid data processing agreement entered into between a controller and processor (“DPA”) and joint controller arrangement.

While the contents of the new draft guidelines largely confirm our existing understanding of these concepts and measures, they do contain some helpful sections which serve to offer clarification in relation to a number of issues that have arisen since the implementation of the GDPR. Other sections, however, arguably serve to complicate certain issues further and it is fair to say that many practical questions that organisations and practitioners have, are likely to remain unanswered.

Taking the positive from the draft guidelines however, we set out below seven practical takeaways for organisations looking to navigate to challenges of these concepts.

1. An organisation does not need to have access to or receive personal data to be deemed a controller

If an organisation instructs another party to carry out processing of personal data, or otherwise has processing carried out on its behalf, the organisation can be deemed a controller without ever having access to or receiving personal data.

This guidance confirms that an organisation that provides detailed instructions to a service provider to process personal data on its behalf (e.g. to conduct market research), but only ever receives statistical output information from that service provider in return will not be excused from having to comply with its obligations under the GDPR as a controller simply because it never sees any personal data.

Although not explicitly addressed, it would seem unlikely when this situation arises that contractual provisions would be sufficient to rebut this assumption. For example, we consider it unlikely that a provision in the contract between an organisation and a processor service provider, expressly prohibiting the service provider from providing the personal data to the counterparty organisation, would be sufficient to avoid the organisation being deemed a controller.

2. A service provider can be a processor even if the main object of the service is not the processing of personal data (but not if it only processes personal data on an incidental basis)

If a service provider provides a service where the main object of that service is not the processing of personal data, but has routine or systematic access to personal data, it will be deemed to be a processor. Conversely, a service provider will not be deemed to be a processor if it only comes across very limited quantities of personal data on an incidental basis.

This guidance clarifies that a service provider such as an IT helpdesk service that routinely accesses personal data (e.g. by liaising directly with a customer’s employees or by screen sharing) will deemed to be a processor even if this is not the main object of its role but another service provider, which has, for example, been instructed to fix a specific software bug and will not have the same level of access to personal data (but might see some inadvertently), will not be deemed to be a processor.

3. A service provider that processes personal data for its own purposes will be deemed a controller in respect of those activities

If a service provider carries out processing of personal data for and on behalf of a customer in accordance with the customer’s instructions, it will be deemed a processor in respect of these processing activities. However, if the service provider also processes personal data for its own purposes in the course of carrying out these services (e.g. to conduct data analytics to assist with improving its services for the benefit of its entire customer base), it will be deemed to be a controller in relation to these processing activities, even if it remains a processor for the majority of the processing activities that it carries out for its customer.

This means that the service provider will need to find a way of complying with its obligations under the GDPR as a controller in respect of these processing activities, including the transparency requirements, and it should also make the extent of these activities clear to its customer in any services agreement.

This guidance also reinforces the idea that a service provider is unlikely to solely act as a processor in relation to all processing activities that it carries out in the context of providing services to a customer and is instead likely to act as a mixture of processor, controller and potentially joint controller in respect of the different processing activities that it carries out under these arrangements. This is something that we regularly see reflected in commercial agreements, although the defining lines between the roles that a party may have are often more difficult to discern.

4. Controllers and processors are equally responsible for putting a DPA in place which meets the requirements of Article 28 of the GDPR

Though the wording of Article 28 does not make it entirely clear as to whether it is the responsibility of: (i) the controller; or (ii) both the controller and processor, to put a DPA in place containing Article 28 compliant provisions, it has traditionally been the controller rather than the processor which has taken it upon itself to ensure that the provisions in the DPA are sufficiently robust and detailed so as to meet this requirement. This is possibly a hangover from the Directive and the Data Protection Act 1998.

The guidelines confirm, however, that fulfilling this obligation is the responsibility of both controller and processor and emphasise that processors are also open to receiving administrative fines under the GDPR, which means that processors need to be equally as proactive and engaged as controllers in relation to ensuring these requirements are met.

5. It is not sufficient for a DPA to merely restate the provisions of Article 28

In the absence of a standard set of regulator-sanctioned DPA clauses, controllers and processors have had to exercise their discretion when determining what to set out in a DPA in order to meet the requirements of Article 28 of the GDPR. Typically, parties tend to set out detailed provisions in a DPA if the processing activities to be undertaken are extensive and/or high-risk, whereas if the processing activities are to be minimal or routine, it is not uncommon to see “light touch” DPA wording which simply cross refers to or incorporates by reference certain elements of Article 28 without any additional detail (e.g. in relation to security, “the processor shall take all measures required under Article 32 of the GDPR”).

The guidelines now make clear that merely restating the requirements Article 28 GDPR is never sufficient or appropriate when drafting a DPA: details of the procedures that processor will follow to assist the controller with meeting the listed obligations under Article 28 of the GDPR (e.g. in relation to personal data breach reporting and adopting adequate technical and organisational measures to ensure the security of processing) will need to be set out, potentially in annexes to the DPA. For many organisations that have spent considerable time and resources repapering their commercial agreements to include Article 28 wording, this push for additional detail which may not already be included in many organisations’ DPAs is unlikely to be welcomed given the time often already required to negotiate the provisions of a DPA with counterparties.

6. A controller-processor relationship will only arise where a processor is a separate legal entity in relation to the controller

The guidelines clarify that a department within a company cannot generally be a processor to another department within the same entity and so it will not be necessary to put a DPA in place when this situation arises.

Although the guidelines do not explicitly address whether this principle also applies to a branch and a head office, it follows that it may also not be necessary to put a DPA in place if one were to process personal data for the other.

7. Attributing the roles of controller, processor and joint controller to parties involved in less straightforward processing relationships will remain a challenging exercise

The guidelines set out a number of new tests to help with applying the concepts of controller, processor and joint controller in practice.

For example, the guidelines state that a party will be deemed to be a controller if exercises a “determinative influence” in respect of the processing and if it determines the “essential means” of processing such as making fundamental decisions with regards to the type of data to be processed, the duration of the processing, the categories of recipients and the categories of data subjects. Conversely, if a party only determines the “non-essential means” of the processing, which might include considerations such as choice of hardware or software to be used, it will be deemed to be a processor.

The guidelines also provide that a joint controller relationship will arise where more than one party holds “decisive influence” in respect of the processing either by making a “common decision” or “converging decisions”, where the processing would not be possible without both parties’ participation and where both parties’ processing activities are inseparable or inextricably linked.

While these new tests are welcome insofar that they serve to flesh out the existing guidance available, they do not make the task of attributing the roles of controller, processor and joint controller to parties involved in complex processing arrangements any easier. In particular, the guidelines do not appear to add much clarity with respect to the concept of joint controllers and when such a relationship will arise. Market practice since implementation of the GDPR has seemed to shy away from parties considering themselves to be joint controllers and the draft guidelines do little to clarify whether such practice is sustainable or not. Arguably, these tests will only serve to complicate matters further by requiring additional layers of analysis to be carried out at the outset of every matter involving the processing of personal data. They also offer no guidance on what to do in circumstances where the contractual parties disagree on the analysis – a situation which is potentially only likely to become more common.

Duc Tran

Duc Tran
Senior Associate, Digital TMT, Sourcing and Data, London
+44 20 7466 2954

Julia Ostendorf

Julia Ostendorf
Trainee Solicitor, London
+44 20 7466 2154

High Court says bank need not comply with numerous and repetitive DSARs which were being used for a collateral purpose

The High Court has dismissed a Part 8 claim against a bank for allegedly failing to provide an adequate response to the claimant’s Data Subject Access Requests (DSARs). This is a noteworthy decision for financial institutions, particularly those with a strong retail customer base, as it highlights the robust approach that the court is willing to take where it suspects the tactical deployment of DSARs against the institution: Lees v Lloyds Bank plc [2020] EWHC 2249 (Ch).

The claimant alleged, among other things, that the bank had failed to provide adequate responses to various DSARs, contrary to the Data Protection Act 2018 (DPA 2018) and the General Data Protection Regulation (EU) 2016/679 (GDPR). The court found that the bank had adequately responded, but gave some strongly-worded obiter commentary on the court’s discretion to refuse an order, even where the claimant can demonstrate that the bank has failed to provide data in accordance with the legislation. In the court’s view, there were good reasons for declining to exercise its discretion in favour of the claimant in this case (even if the bank had failed to provide a proper response), including that: the DSARs issued were numerous and repetitive (which was abusive), the real purpose of the DSARs was to obtain documents rather than personal data, and there was a collateral purpose underpinning the requests (namely, to use the documents in separate litigation with the bank).

In financial mis-selling cases, DSARs are often used by claimants as a tool to obtain documents from a financial institution in advance of the issue of proceedings or during litigation to build their case. DSARs can be made in addition to pre-action and standard disclosure under the CPR, and will often seek to widen the scope of documents that could be obtained via traditional disclosure routes. This can create significant workstreams for the bank, which are time-consuming and costly. The present decision provides some helpful guidance as to when it may be appropriate for banks to resist “nuisance” DSARs. It is unclear whether the conclusion in this case would take precedence over the UK privacy regulator’s guidance with respect to DSARs, which has previously been that they should be “motive blind”, but has more recently suggested that there is no obligation to comply with DSARs that are “manifestly unfounded”.

Finally, a significant practical difficulty for financial institutions, is that DSARs can be received by a number of internal teams within the financial institution, either at intervals or all at once. This decision is an important reminder of the need for centralised monitoring of DSARs.

Background

The claimant individual entered into buy to let mortgages in respect of three properties with the defendant bank between 2010 and 2015. The claimant submitted a number of DSARs to the bank between 2017 and 2019 alongside claims in the County Court and High Court concerning the alleged securitisation of the relevant mortgages in an attempt to prevent possession proceedings by the bank in relation to the properties (which were all held to be totally without merit). The bank responded to all the DSARs it received from the claimant.

The claimant subsequently issued a claim alleging, amongst other things, that the bank had failed to provide data contrary to the DPA 2018 and GDPR.

Decision

The court held that the bank had provided adequate responses to the claimant’s DSARs and was not in breach of its obligation to provide data. Given the DSARs under consideration, the court concluded that the DPA 1998 was the legislation in force at the relevant time and this provided data subjects with rights of access to personal data to similar to those under the GDPR. However, given that the subject access rights under the DPA 1998 were essentially the same as those now provided for under the GDPR (and the DPA 2018), it seems likely that the court’s conclusion would have been similar if the case had been considered under the current legislation.

The court commented that even if the claimant could show there was a failure by the bank to provide a proper response to one or more of the DSARs, the court had a discretion as to whether or not to make an order.

In this case, in the court’s view, there were good reasons for declining to exercise the discretion to make an order in favour of the claimant in light of:

  • The issue of numerous and repetitive DSARs which were abusive.
  • The real purpose of the DSARs being to obtain documents rather than personal data.
  • There being a collateral purpose that lay behind the requests which was to obtain assistance in preventing the bank bringing claims for possession.
  • The fact that the data sought would be of no benefit to the claimant.
  • The fact that the possession claims had been the subject of final determinations in the County Court from which all available avenues of appeal had been exhausted. It was improper for the claimant to mount a collateral attack on these orders by issuing this claim.

The court therefore dismissed the claim as in its view it was totally without merit.

Interaction with Information Commissioner’s Office (ICO) guidance

It is worth noting here that the UK privacy regulator’s guidance with respect to DSARs has previously been that they should be “motive blind” and any collateral purpose should not impact whether or not a controller is required to comply.

The latest draft guidance from the ICO refers to DSARs potentially being “manifestly unfounded” (with therefore no obligation to comply) when: (i) the individual clearly has no intention to exercise their right of access (for example an individual makes a request, but then offers to withdraw it in return for some form of benefit from the organisation); or (ii) the request is malicious in intent and is being used to harass an organisation with no real purposes other than to cause disruption.

However, the court’s comments seem to extend this position and it is unclear whether the decision in this case would therefore take precedence over the regulatory guidance – something which would undoubtedly be welcomed by controller organisations.

Julian Copeman

Julian Copeman
Partner
+44 20 7466 2168

Miriam Everett

Miriam Everett
Partner
+44 20 7466 2378

Ceri Morgan

Ceri Morgan
Professional Support Consultant
+44 20 7466 2948

Nihar Lovell

Nihar Lovell
Senior Associate
+44 20 7374 8000

 

German Regulator Publishes Schrems II ‘Checklist’

The Baden-Württemberg data protection authority (“LfDI”) has issued guidance to controllers and processors following the Schrems II judgement.  The guidance includes helpful, practical tips which entities can take with respect to their current and future international transfers. Whilst aimed primarily at organisations subject to the jurisdiction of the LfDI, the guidance may be helpful for organisations throughout Europe who are grappling with the impact of the Schrems II decision.

In summary, exporting entities which are supervised by the LfDI are expected to:

  1. review the instances in which they export personal data to third countries;
  2. contact their contractual partners or service providers to inform them of the consequences of the Schrems II case;
  3. check whether there is an adequacy decision for the relevant third country;
  4. research and consider the legal environment in the relevant third country;
  5. check if the SCCs which were approved by the European Commission can be used; and
  6. if so, verify that SCCs are in place and that there are additional transfer guarantees to supplement the SCCs.

In our view it is the underlined step 4 above that is likely to cause the most difficulties and this is an area where further guidance is required. An obligation on exporters to undertake due diligence on the complete legal environment in a third country (some of which may not be completely transparent) goes beyond what most organisations undertake at the moment and it is not clear how this will be achieved going forwards.

Amendments to the Standard Contractual Clauses

The LfDI also suggests that exporting controllers amend or supplement the controller-processor Standard Contractual Clauses in the following ways:

  1. Clause 4(f): The LfDI recommends that exporting entities inform affected persons that their data is being transferred to a third country which does not have an adequate level of protection not only when transmitting special categories of data, but when transferring any personal data in these circumstances. This notification should occur before or as soon as possible after the transfer;
  2. Clause 5(d)(i): The data importer should inform not only the data exporter, but also the data subject(s) of all legally binding requests from an enforcement authority to pass on the relevant personal data. If such contact is otherwise prohibited by law, the data importer should contact the supervisory authority and clarify the procedure as soon as possible;
  3. Clause 5(d): Data exporters should contractually oblige the data importer to refrain from disclosing personal data to third country authorities until the competent court orders or requires them to disclose personal data; and
  4. Clause 7(1): Exporting and importing entities should only include Clause 7(1)(b) (which allows the data importer to refer any dispute to the courts of the Member State in which the data exporter is established in the event that a data subject asserts rights as a third party beneficiary and/or claims for damages against the data importer based on the contractual clauses) and not include Clause 7(1)(a) which allows a data importer to refer the dispute to an “independent person”.

Although it is clear that ‘amendments’ to the Standard Contractual Clauses are not permitted, it has long been recognised that the clauses may be ‘supplemented’ with additional provisions provided that the effect of those provisions is not to amend the substantive content of the clauses themselves. As such, the suggested ‘amendments’ above (with the exception possibly of the rejection of clause 7(1)(a) of the Standard Contractual Clauses) should be lawfully possible. However, from first looks, it appears that there may be logistical challenges with some of the suggestions. For example, is it practical or even desirable for the data processor/data importer to have an obligation to notify data subjects of an access request received by a third country law enforcement agency? The processor is unlikely to have a direct relationship with the data subjects and may not even be able to contact them depending on the data being processed. There also remains the fundamental issue that nothing in a contract between exporter and importer is going to prevent law enforcement access.

That being said, whilst regulators across Europe published some initial thoughts and guidance immediately following the Schrems II judgement, this is the first piece of practical guidance that we’ve seen published by a supervisory authority. It will now be interesting to see whether other supervisory authorities and/or the EDPB follow a similar approach in their Schrems II guidance.

Miriam Everett

Miriam Everett
Partner, Head of Data Protection and Privacy, London
+44 20 7466 2378

Lauren Hudson

Lauren Hudson
Associate, Digital TMT, Sourcing and Data, London
+44 20 7466 2483

Schrems II: Reaction from European Regulators and Technology Companies Suggest an Uncomfortable Road Ahead for Transatlantic Data Transfers

To recap, last week, the European Court of Justice (“ECJ”) ruled that the Privacy Shield is invalid and placed significant emphasis on the due diligence which exporting controllers, recipients and supervisory authorities are expected to undertake in relation to transfers of personal data to third countries which are governed by the Standard Contractual Clauses (“SCCs”).  As foreshadowed in our initial reaction to the Schrems II judgement, and now that we’ve had the benefit of the full judgement and initial commentary from some of the European regulators, the EDPB, and some of the big tech companies, the immediate future of transatlantic data transfers appears to be uncertain and commentary is divided on what is and isn’t possible in light of this new judgement. Continue reading

UK SWITCHES TO DECENTRALISED APPROACH TO CONTACT TRACING APP

In a move that marks a major U-turn for the Government, the UK’s proposals for a centralised contact tracing app have been abandoned in favour of a decentralised model. The new model is based on technology developed by Apple and Google and replaces the original app designed by NHSX, which recently has faced criticism due to privacy concerns as well as technical issues and delays.

The UK follows Germany and Italy, who have already made the switch from centralised contact tracing apps to decentralised models. The UK’s health secretary, Matt Hancock, confirmed the news at the UK Government press conference last night.

To centralise or decentralise?

The UK Government had previously asserted the superiority of a centralised contact tracing model, but what exactly is the difference?

A ‘decentralised’ data model requires individual users to provide an anonymous ID to a centralised server. The user’s phone then downloads information from the centralised database and carries out contact matching and risk analysis on the phone itself before sending alerts to other users if necessary. Information on whether a user has come into contact with an infected person will be shared with that user, but not with the central server.

In contrast, a ‘centralised’ data model would require users to provide not only their own anonymous ID to a centralised database, but also to send any codes collected from other phones. The computer server then carries out contact matching and risk analysis using that information, making the decision as to whether someone is ‘at risk’ and sending alerts accordingly.

The UK’s previous preference for the centralised model was based on the belief that storing data in a centralised manner would promote a more considered approach to contact tracing based on risk factors, and would enable epidemiologists to use valuable data on the spread of the virus for further research. However, the centralised model was criticised for potentially encroaching on privacy by using more data than necessary, and using the data for purposes other than contact tracing.

What next?

NHSX, the health service’s innovation arm, has confirmed that its current leaders will step back from the project, and that Simon Thompson, current chief product manager at Ocado, will take over management of the new app.

While this move will be welcome to privacy campaigners and critics of the centralised model, concerns over the limitations of Bluetooth-enabled technology, as well as the uneasiness over allowing Apple and Google to control the UK’s response to the pandemic, may cause further obstructions to the eventual rollout of a UK-wide contact tracing app. The additional delays resulting from this change in approach may also result in a lower than ideal take-up rate, with much of the population of the view that the time for contact tracing has passed given the current downwards curve of the pandemic.

Miriam Everett

Miriam Everett
Partner, Head of Data Protection and Privacy, London
+44 20 7466 2378

Hannah Brown

Hannah Brown
Associate, Digital TMT, Sourcing and Data, London
+44 20 7466 2677

Katie Collins

Katie Collins
Trainee Solicitor, London
+44 20 7466 2117

COVID-19: ICO OPINES ON APPLE AND GOOGLE’S CONTACT TRACING TECHNOLOGY (UK)

On 17 April 2020, the ICO published an opinion by the Information Commissioner (the “Commissioner”) on Apple and Google’s joint initiative to develop COVID-19 contact tracing technology (the “Opinion”, available here).

Summary

  • The Commissioner found the CTF to be aligned with principles of data protection by design and by default.
  • Controllers designing contact tracing apps that use the CTF should ensure alignment with data protection law and regulation, especially if they process personal data (which the CTF does not require).
  • The Commissioner raised concerns regarding individuals assuming that the CTF’s compliance with data protection principles will extend to all aspects of the contact tracing app – which is not necessarily the case.
  • Therefore, it should be made clear to any app users who is responsible for data processing, especially if the app processes data outside of the CTF’s limited scope.
  • Data controllers designing CTF-enabled contact tracing apps must be transparent with potential and actual app users on the type of information they will be processing.
  • Finally, when it comes to a user’s ability to disable Bluetooth, the Commissioner observed that with regard to contact tracing apps in general: “a user should not have to take action to prevent tracking”.

As set out in our previous blogpost (available here), contact tracing is one of the measures being contemplated or implemented by European governments (including in the UK and Germany) in order to be able to put an end to lockdowns while containing the spread of the virus.

The scope of the Opinion was limited to the design of the contact tracing framework which enables the development of COVID-19 contact tracing apps by public health authorities through the use of Bluetooth technology (the “CTF”).

It is also worth noting that this Opinion has been published in the midst of a heated debate on contact tracing technology and fears that it may be used for mass surveillance – in an open letter published on 20 April 2020, around 300 international academics cautioned against creating a tool which will enable large scale data collection on populations.

How does the CTF work?

The CTF is composed of “application programming interfaces“ as well as “operating system level technology to assist contact tracing”. The collaboration between Apple and Google will result in interoperability between Android and iOS devices of apps developed by public health authorities using the CTF.

When two devices with contact tracing apps come into proximity, each device will exchange cryptographic tokens (which change frequently) via Bluetooth technology. Each token received will be stored in a ‘catalogue’ on the user’s device, effectively creating a record of all other devices a user has come into contact with. Once a user is diagnosed with COVID-19, and after they have given their consent, the app will upload the stored ‘catalogue’ of tokens to a server. Other users’ devices will periodically download a list of broadcast tokens of users who have tested positive to COVID-19. If a match is found between the broadcast tokens and the ‘catalogue’ of tokens stored on each user’s device, the app will notify the user that he/she has come into contact with a person who has tested positive and will suggest appropriate measures to be taken.

How does the CTF comply with data protection laws?

The Opinion finds that, based on the information released by Google and Apple on 10 April 2020, the CTF is compliant with principles of data protection by design and by default because:

  1. The data collected by the CTF is minimal: The information contained in the tokens exchanged does not include any personal data (such as account information or usernames) or any location data. Furthermore the ‘matching process’ between tokens of users who have tested positive for COVID-19 and tokens stored on each user’s phone happens on the device and therefore does not involve the app developer or any third party.
  2. The CTF incorporates sufficient security measures: The cryptographic nature of the token which is generated on the device (outside the control of the contact tracing app) means that the information broadcast to other nearby devices cannot be related to an identifiable individual. In addition, the fact that the tokens generated by one device are frequently changed (to avoid ultimate tracing back to individual users) minimises the risk of identifying a user from an interaction between two devices.
  3. The user maintains sufficient control over contact tracing apps which use the CTF: Users will voluntarily download and install the contact tracing app on their phone (although this may change in ‘Phase 2’ of the CTF as discussed below). Users also have the ability to remove and disable the app. In addition, the process of uploading the collected tokens of a user to the app once he/she has tested positive by the developer requires a separate consent process.
  4. The CTF’s purpose is limited: Although the CTF is built for the limited purpose of notifying users who came into contact with patients who have tested positive for COVID-19, the Commissioner stresses that any expansion of the use of CTF-enabled apps beyond this limited purpose will require an assessment of compliance with data protection principles.

What clarifications are required?

The Commissioner raises a number of questions on the practical functioning of the CTF, especially in respect of collection and withdrawal of user consent post-diagnosis. It is unclear how the CTF will facilitate the uploading of stored tokens to the app. Although consent will be required from the user, clarity is needed on: (i) management of the consent signal by a CTF-enabled app and (ii) what control will be given to users in this respect. In addition, the Commissioner lacks information on how consent withdrawal will impact the effectiveness of the contact tracing solutions and the notifications sent to other users once an individual has been diagnosed.

Issues for developers

The Commission will pay close attention to the implementation of the CTF in contact tracing apps. In particular, the CTF does not prevent app developers from collecting other types of data such as location. Although reasons for collecting other types of user information may be “legitimate and permissible” in order to pursue the public health objective of these apps (for example to ensure the system is not flooded with false diagnoses or to assess compliance with isolation), the Commissioner warns that data protection considerations will need to be assessed by the controller – this includes the public health organisations which develop (or commission the development of) contact tracing apps.

Another issue raised by the Commissioner is the potential user assumption that the compliance by the CTF with data protection laws will radiate to all other functionalities which may be built into contact tracing apps. In this regard, the Commissioner reminds app developers that, in addition to assessing data protection compliance in relation to other categories of data processed by the app, they will need to clearly specify to users who is responsible for data processing – in order to comply with transparency and accountability principles.

Finally, the Commissioner stressed that data controllers, such as app developers, must assess the data protection implications of both (i) the data being processed through the app and (ii) data undertaken by way of the CTF in order to ensure that both layers of processing are fair and lawful.

What has the ICO said about ‘Phase 2’ of the CTF?

‘Phase 2’ of development of the CTF aims to integrate the CTF in the operating system of each device. The Commissioner notes that users’ control, their ability to disable contact tracing or to withdraw their consent to contact tracing should be considered when developing the next phase of the CTF.

With regard to user’s ability to disable Bluetooth on their device, the Commissioner observes in respect of ‘Phase 2’ of the CTF, and contact tracing apps in general, that “a user should not have to take action to prevent tracking”.

How does this Opinion affect the development of Decentralized Privacy-Preserving Proximity Tracing protocol?

The Opinion can be applied to Decentralized Privacy-Preserving Proximity Tracing (or DP-3T) protocol in so far as it is similar to the CTF. The Commissioner states that the similarities between the two projects gives her comfort that “these approaches to contact tracing app solutions are generally aligned with the principles of data protection by design and by default”.

Insight

This Opinion is an important step in the development and roll out of contact tracing apps in the UK. As mentioned above, contact tracing is one of the tools necessary for the UK Government to lift the lockdown measures while minimising the impact of a potential second wave of infections. This has an indirect impact on the private sector as it will affect how and when employees will be able to go back to work.

The fact that the principles on which the CTF is based are compliant with data protection laws is crucial to the successful roll out of contact tracing apps. In order for these apps to be effective, they must be voluntarily downloaded by a large number of mobile users. Given the concerns around letting governments accumulate data on the population under the guise of putting an end to the pandemic, trust is a determining factor in this equation. The fact that the Commissioner is approving the foundation for these contact tracing apps will certainly play a role in gaining the public’s trust and its acceptance to give up some privacy rights in order to put an end to the current public health crisis.

Miriam Everett

Miriam Everett
Partner, Head of Data Protection and Privacy, London
+44 20 7466 2378

Hannah Brown

Hannah Brown
Associate, Digital TMT, Sourcing and Data, London
+44 20 7466 2677

Ghislaine Nobileau

Ghislaine Nobileau
Trainee Solicitor, London
+44 20 7466 7503

COVID-19: ICO publishes details of its regulatory approach during COVID-19 (UK)

The ICO has published details of its regulatory approach during the ongoing COVID-19 emergency; this is an approach which should reassure entities who are adapting to the economic and practical realities of operating in the current climate, as well as balancing their data protection obligations.  The UK regulator has continued to be reasonable and pragmatic, as outlined in our previous post in relation to response times to DSARs, and has stated that they are “committed to an empathetic…approach”.  Overall, the key takeaways from this guidance are that: Continue reading

Revised ePrivacy Regulation Draft introduces ability for organisations to rely on “Legitimate Interests” legal basis in relation to cookies

Another revised draft ePrivacy Regulation (“ePR”) was recently published which introduces the ability for organisations to rely on the “legitimate interests” legal basis to drop cookies on end users’ devices.

This change has been criticised by some commentators for ambiguities and watering down data protection rights despite accompanying safeguards. It remains to be seen if it will be retained in future draft iterations or indeed, the agreed version of the ePR, in relation to which there is no clear timetable for implementation at present.

Background

First published in January 2017, the ePR covers specific data regulation reforms such as cookies, electronic direct marketing, over-the-top services and machine-to-machine communications. The overall approach, including a more stringent sanctions regime, would bring ePrivacy regulation into much closer alignment with the GDPR and was originally intended to coincide with the GDPR’s implementation in 2018.

Despite revised proposals from numerous Presidencies of the Council of the European Union, Member States have been unable to agree a final version of the ePR. At the moment, this means that it is unlikely to take effect before 2023 as a grace period of up to 2 years will need to elapse following adoption of the final draft.

With regards to Brexit, since the ePR is unlikely to be effective by the end of the transition period, it will not be incorporated into UK law under the withdrawal legislation (in contrast to the intended implementation of a UK GDPR). Therefore, the existing Privacy and Electronics Communications Regulations 2003 (“PECR”) will continue to apply following the end of the transition period. Once the ePR takes effect, the UK may choose to mirror the drafting or bring in its own drafting which diverges from the ePR. In any event, the ePR (in its current form) will likely still have implications for UK organisations dealing with individuals in the EU due to its intended extra-territorial scope.

The Proposed Amendments to the Draft ePrivacy Regulation

The latest draft, which simplifies the text of the core provisions and further aligns them with the GDPR, was proposed by the Croatian Presidency when it became clear that the majority of the Member States would not support the existing text.

One of the key proposals has been the introduction of the “legitimate interests” ground for introducing cookies (or similar technology) on end users’ terminal equipment represent a notable change in position from prior drafts and a step away from the consent-based model dictated by the most recent ICO cookies guidance and implemented by most organisations via cookie banners preventing users from accessing a webpage until they have set their cookie preferences accordingly. Critics have argued that this consent model is flawed as their ubiquity is leading to users ignoring them and “consent fatigue”. The introduction of the “legitimate interests” legal basis expands on previous ePR drafts’ attempts to help address this problem although the latest drafting is subject to various safeguards including fairly restrictive commentary as to when the “legitimate interests” legal basis can be relied on (e.g. not where the end user is a child, the organisation intends to use cookies to collect special categories of data or where the cookies are used to profile end users).

Commentators have criticised the drafting which seems to contain some inconsistencies. Firstly, it directly contradicts the EDPB’s statement in May 2018 that ePrivacy Regulation should not allow processing “on open-ended grounds, such as “legitimate interests” that go beyond what is necessary for the provision of an electronic communications service.” The introductory text to the draft, conversely, states that proposed safeguards mean that the new legal ground remains “in line with the GDPR”. Furthermore, tech advertisers wishing to rely on the “legitimate interests” ground may do so on condition that the end user is provided with clear information and has “accepted such use”. How an end user would confirm acceptance in practice is however unclear and this seems to cut across the prohibition on using the ground for profiling purposes.

The new proposal clearly intends to address some of the more contentious drafting points and cater to business needs (e.g. advertising). Nonetheless, given the lack of agreement to date and the ambiguities in the drafting, it remains far from certain that this draft will become the enacted version of the ePR.

Miriam Everett

Miriam Everett
Partner, Head of Data Protection and Privacy, London
+44 20 7466 2378

Duc Tran

Duc Tran
Senior Associate, Digital TMT, Sourcing and Data, London
+44 20 7466 2954

Tamsin Rankine-Fourdraine

Tamsin Rankine-Fourdraine
Trainee Solicitor, London
+44 20 7466 7508

COVID-19: How governments are using personal data to fight COVID-19

Background

The COVID-19 outbreak has resulted in an unprecedented focus on the power of data to assist in resolving national emergencies. From health tracking, to volunteer coordination, to accurately identifying the vulnerable, data is being harnessed in both the public and private sectors to try to help bring COVID-19 under control and mitigate its impact. Continue reading