COVID-19 contact tracing apps: a stress test for privacy, the GDPR, and data protection regimes.

Digital surveillance has played a key role in containing the COVID-19 outbreak in China, Singapore, Israel, and South Korea. Google and Apple recently announced the intention to build interfaces to allow Bluetooth contact tracking using Android and iPhone devices. In this article, we look at the compatibility of the proposed Apple/Google Bluetooth exposure notification system with Western privacy and data protection regimes and principles, including the General Data Protection Regulation (GDPR). Somewhat counter-intuitively, the GDPR's expansive scope is not a hindrance, but rather an advantage in conditions of uncertainty such as a pandemic. Its principle-based approach offers a functional blueprint for system design that is compatible with fundamental rights. By contrast, narrower, sector-specific rules such as the US Health Insurance Portability and Accountability Act (HIPAA), and even the new California Consumer Privacy Act (CCPA), leave gaps that may prove difficult to bridge in the middle of an emergency.

INTRODUCTION

Digital surveillance and tracking has played a crucial role in containing the Coronavirus outbreak in China, Singapore, and South Korea, among others. On April 10, Google and Apple announced a joint effort to enable public health authorities to build applications to perform contact tracing using iPhone and Android devices. The collaboration between government agencies and Silicon Valley tech giants immediately raised privacy concerns. Whether large-scale tracing of exposure can coexist with more stringent legal protections and norms for individual privacy and autonomy prevalent in Europe and the USA is unclear. Some may even be tempted to suspend data protection mandates in a state of emergency. The need to track individual movements and health status on a broad basis offers a crucial ‘stress test’ of Europe’s nascent, comprehensive General Data Protection Regulation (GDPR) and other privacy and data protection regimes based on OECD Privacy Guidelines.

In this article, we look at the compatibility of the proposed Apple/Google Bluetooth exposure notification system (‘ENS’) and associated applications with Western privacy and data protection principles, including the EU GDPR. Depending on their final details, and how they develop over time, our view is that the Apple/Google ENS will fall within the governance system of the GDPR and, along with associated software applications, can be operated in a way that is compatible with the GDPR rules. In contrast, substantial parts of the Apple/Google ENS and any associated applications may fall outside data protection laws in the USA. As a consequence, uptake of such systems by health agencies and citizens may prove slower. Narrower, sector-specific rules such as the US Health Insurance Portability and Accountability Act (HIPAA), and even the new California Consumer Privacy Act (CCPA), leave gaps that may prove difficult to bridge in the middle of an emergency. Thus, somewhat counter-intuitively, the GDPR’s expansive scope is not a hindrance but rather an advantage in conditions of uncertainty such as a pandemic. The GDPR framework offers a comprehensive, functional blueprint for digital system design that is compatible with fundamental rights. Indeed, it is clear that GDPR’s Article 5 core principles were very much front of mind for the two technology companies as they designed their new interfaces.

WHAT DATA IS BEING COLLECTED?

Many, if not all, EU countries are currently working on applications (‘apps’) aimed at facilitating the fight against the COVID-19 crisis. Some of them are based on geolocation, such as Coronamadrid and StopCovid19 in Spain, whereas others are based on the Bluetooth technology known as a ‘digital handshake’, such as Stopp-Corona-App in Austria, StopCovid in France, ProteGo in Poland, or an app being developed by the National Health Service (‘NHS’) in the UK. The Apple/Google ENS enables interoperability between Android and iOS devices and apps to permit tracking using Bluetooth technology of ‘contact events’ between devices. Apple/Google have stated that only apps designated by public health authorities will have access to this framework and such apps must meet specific criteria around privacy, security, and data control.

The Google/Apple ENS allows iPhone or Android devices to detect other devices that have been within a certain distance for a significant duration. That ‘handshake’ will cause unique identifier codes to be stored, in encrypted form, on both devices. If someone subsequently tests positive for the virus, that person will upload information centrally to an app server together with their unique identifier codes. The ENS will download positive diagnosis identifier codes daily and will match them with codes stored on individual devices. A match will generate an automatic notification from the app, which will appear on any device that recorded the infected individual’s device identifier(s) during the relevant time period. Information about exposure events largely stays on each user’s phone, while the central server and ENS process only ‘de-identified’ information about individuals with a positive diagnosis. In the coming months, Apple and Google will work to enable a broader Bluetooth-based ENS by building the enabling functionality into their underlying operating systems. Removing the need to download an app widens the reach of the platform and would enable interaction with a broader ecosystem of apps and government health authorities.

Based on initial specifications released by Google/Apple, the ENS framework will, together with associated apps, generate and collect four types of information:

Bluetooth identifier codes and associated contact event information: generated by the ENS and stored decentrally on individual devices.

Positive diagnosis information: uploaded to the app server by the user along with their associated contact identifiers (‘diagnosed identifier codes’).

Associated information: when an individual notifies via the app that they have the virus, their individual IP address and other metadata will be detectable by the app server. Apple and Google currently require that apps using the ENS promise not to collect and retain this information. ‘Associated encrypted metadata’ including information about the timing and proximity of relevant exposure events will be stored decentrally on user devices, and upon diagnosis, notification will be decrypted locally.

Notifications to exposed users: the ENS will download and broadcast diagnosed identifier codes once per day. The ENS will identify phones with matching codes and will employ an algorithm locally to assess the risk of exposure based on the de-encrypted associated exposure metadata. The ENS will share information with the app about how many alerts were generated and the dates of exposure events. The app will then generate an exposure detection notification to users identified as at risk. At the time of exposure notification, the app server will receive additional information from matched users about the time and attenuation of exposure. Apps may request or require additional information from users at the point of exposure notification. For example, exposed individuals may elect to upload their own unique identifiers to warn those with whom they may have been in contact.

A potential fifth category of information would be a combination of the exposure data collected by apps using the Google/Apple ENS with individual user identities and location data in order to (i) assist law enforcement to ensure quarantine of infected and/or exposed individuals; (ii) use location data in aggregate to track the spread of the virus across a population; or (iii) use individual exposure data to make inferences about health such as a green light or ‘all clear’ indication that could be shared with third parties such as employers. Apple and Google have designed their system to make automated collection of this fifth category of data using their ENS prohibitively difficult. However, those who administer apps using the system could collect some of this information separately at the time of diagnosis or exposure notification. Furthermore, it should be noted that Apple/Google’s ENS has reserved functionality for additional unspecified associated metadata that might be collected later.

PRIVACY AND DATA PROTECTION ANALYSIS

Is This Personal Data Under the GDPR or Relevant US Law?

GDPR: Is This Data Relating to an Identifiable Natural Person?

The information broadcast by devices and collected by the app should be considered personally identifiable information as defined by the GDPR. The GDPR defines personal dataas:

any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier, or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of that natural person.

Any data stored on individual phones is information ‘related’ to an individual. Although encrypted, the unique identifiers broadcast by the ENS could be linked to natural persons. For example, geolocation tracking systems already present on most user devices could reassociate the Bluetooth beacon identifiers with particular devices. Google itself operates some of the most ubiquitous of these trackers. The encrypted beacon signals therefore most likely meet the GDPR definition of personal data, as they are information in relation to an ‘identifiable’ natural person. The technology companies’ promises not to track location data for the Bluetooth signals or access the Bluetooth contact information held on individual phones are helpful technological and organizational measures that minimize the burden on individual privacy and increase security of processing. However, as a matter of law, they do not disassociate the data completely and so the activities remain subject to the GDPR. Similarly, associated apps receive diagnosis information linked to an individual IP address, and will receive individuated information about those in contact with infected persons. If the agencies follow-up with in-person interviews, as is expected, they will have identifiable personal data on at least a subset of people potentially exposed to the virus.

GDPR: Is This a Special Category of Data Concerning Health?

Information concerning health is a special category of personal data under the GDPR that triggers extra protections. COVID-19 diagnosis qualifies as information concerning health. Both the ENS and the app receive identifiers linked to individuals with a positive diagnosis. Whether the Bluetooth rolling identifiers by themselves constitute sensitive ‘data concerning health’ requiring extra protection under the GDPR is a closer question. The definition of ‘data concerning health’ includes data that reveal information about an individual’s health status. The purpose of collecting the Bluetooth identifiers is to determine virus exposure. Organizations would therefore be wise to treat this information as special category data under Article 9 of theGDPR.

GDPR: Is the Data Anonymized or Pseudonymized?

Apple and Google claim that user data broadcasted through their ENS has been ‘anonymised’ by virtue of deidentification and decentralization. However, anonymization is a moving target legally. The European Data Protection Board (‘EDPB’) has made it clear that true data anonymization is a very high bar and data controllers often fall short of actually anonymizing data. Information is anonymized, and outside of the reach of the GDPR, if, taking into account the means reasonably likely to be used, including the available technology at the time of the processing and technological developments, the information cannot be associated with a natural individual. Recent research has demonstrated that a large range of techniques exist to re-identify individuals using seemingly anonymous information. That more such technologies are being developed every day means that users can never be confident that data shared ‘anonymously’ will not be associated with them in the future. Data controllers equally cannot be sure that they will not be found liable for failing to protect de-identified data. Perhaps for this reason, although Google and Apple claim the data processed through the ENS is ‘anonymous’, they have still instituted multiple controls to prevent re-identification in their design, in keeping with the GDPR’s data minimisation and security of processing principles. These controls result in data that is at least pseudonymized. In contrast to anonymization, Article 4(5) GDPR defines pseudonymization as “the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person.” By implementing pseudonymization as a security of processing measure, data controllers can benefit from several relaxed standards under GDPR, including potentially processing for other compatible purposes pursuant to Art. 6(4)(e)GDPR.

For public health authority apps, these controls may render the ENS data fully anonymous. However, depending on how the apps are designed, the operating entities could collect personally identifiable information, such as IP addresses, in addition to the encrypted diagnosis keys generated by the ENS. It is not possible to judge whether the apps process only anonymized information without analyzing the design of a specific app and understanding what information collection practices, such as manual contact tracing interviews or third party tracking, might be used alongsideit.

Application of the GDPR

Based on the information currently available, automated notification of exposure using the ENS and associated apps is a personal data processing system subject to oversight under the GDPR. Article 24 of the GDPR mandates that data controllers, including joint controllers, implement appropriate technical and organizational measures to ensure and to be able to demonstrate that covered processing is performed in accordance with the Regulation. All of the GDPR Article 5 principles, (i) lawfulness, fairness, and transparency, (ii) purpose limitation, (iii) data minimisation, (iv) accuracy (v) storage limitation, (v) integrity and confidentiality, and (vi) accountability, must be observed in the design and implementation of these systems.

These principles translate into a specific architecture of protection and enforcement for data subjects. Articles 12–23 of the GDPR mandate clear ‘pre-defined’ rights for the data subject, including rights of access, rectification, and erasure. To ensure accountability, each Member State must empower a competent and independent supervisory authority to enforce the terms of the Regulations, including the power to investigate and impose fines and other penalties. Controllers and processors must maintain records of processing activities, including the purpose for the processing, and ensure the processing is technologically and organizationally secure. Controllers must also conduct specific impact assessments (Data Protection Impact Assessment or ‘DPIA’) including risk mitigation measures for processing activities that pose a high risk to data subject rights. Data subjects themselves have the rights to lodge complaints with the supervisory authority, to seek judicial remedies and to receive compensation.

Comparison with US Law: HIPAA and CCPA

By way of comparison, the application of US privacy laws such as the Health Insurance Portability Act (HIPAA) Privacy Rule or the CCPA of 2018 to a proximity tracking system is more limited. This lack of coverage might seem to encourage innovation, but there is a greater risk that the absence of comprehensive standards could undermine public trust and delay roll-out of contact tracing technology at a critical moment.

HIPAA’s Privacy Rule applies only to data collected by health providers themselves, or businesses hired by health providers to process their data. An individual’s diagnosis from a diagnostic lab would, therefore, be subject to HIPAA’s Privacy Rule, but a Bluetooth exposure proximity system such as the one designed by Google and Apple would seem to fall completely outside HIPAA’s parameters. In fact, the reality might be somewhere in between, because associated apps could depend on diagnosis validation from health care providers who are subject to the HIPAA Privacy Rule. However, as long as it is the individuals themselves who disclose health information to the ENS, and not the health provider directly, HIPAA would most likely not apply to the system. This regulatory gap might provide an opportunity for experimentation and market competition for anyone to create virus tracking apps using GPS location data, Bluetooth handshake signals, or other personal biometric or commercial data. However, in a national emergency, increased business experimentation is a dubious virtue. A proliferation of products, some less reliable and trustworthy than others, could undermine adoption of reliable notification systems. Furthermore, those whose participation is most important, health providers and public health agencies, may hesitate to share information (such as COVID-19 diagnoses) in machine readable formats without assurances that other system users are engaging in privacy protective practices. The lack of protection could delay uptake by US health authorities and providers at the moment when such involvement is most needed.

The reach of the CCPA is also limited. CCPA is a consumer protection statute. By its terms, it excludes data covered by the HIPAA Privacy Rule and other state laws concerning the privacy of medical information. Furthermore, the CCPA does not apply to information collected by small businesses unless data brokerage is their principal business. The CCPA also does not clearly state whether its obligations apply to personal information that has been pseudonymized. The Bluetooth signals gathered by an ENS may qualify as ‘de-identified’ or anonymized information under the CCPA even if they would not under the GDPR. Clarifying how these different exclusions and carve-outs apply to a virus tracking and notification system and associated apps is no small task. The law lacks a specialized regulatory agency tasked with its interpretation that can issue necessary guidance in a crisis. Finally, even if the law applied to a proximity notification system or associated applications, it would not necessarily prevent the use or sale of individual data collected through these systems for other purposes unless the user objected. By prioritizing individual notice and opt-out over shared principles, the law requires more engagement by individuals at a moment, such as the point of diagnosis with a serious illness, when they are not well-equipped to provide it. Any uncertainty patients and health providers have about how health information shared with third party applications could be used in the future may disincentivize use of the app. Lack of clarity about potential liability may cause companies to shy away from participating in the system. Individuals may hesitate to share diagnosis information without assurances that their illness history and any associated health, contact, and lifestyle information will not be shared broadly in a way that could draw unwanted attention or impact employment, credit scores, or insurance rates. Meanwhile, widespread immediate adoption of the technology may be crucial for its success in containing spread of the virus. Even if adoption is widespread, damage to fundamental rights of privacy and security of individuals from unregulated sharing could linger for years.

What is the Lawful Basis for Processing?

When a contact tracing ENS, or associated app, falls within the GDPR’s governance, processing of personal data must have a ‘lawful basis’, and processing of personal data concerning health must meet further ‘lawful basis’ thresholds. The public/private collaborations envisioned by digital COVID tracking systems raise interesting questions in this regard. Public health and disaster response functions are typically overseen by democratically accountable public agencies. But here private, commercial tech companies are getting involved—either as initiators, partners, or organizations picking up outsourced tasks. Understanding the scope and purpose under which public and private entities may perform these functions will be crucial for complying with the ‘lawful basis’ requirements in the GDPR. It will also be crucial for public trust.

Apple and Google have presented their ENS technology as a public-spirited and voluntary effort to assist in a time of crisis. This characterization may be reasonable. Nevertheless, Apple and Google are commercial entities accountable in governance and operation to profit-minded shareholders. In China, where Alipay and WeChat hosted the Health Code app used to track coronavirus exposure, those companies have asserted rights contractually to keep the data once the crisis is over. One German technologist lamented to Reuters that it was a less than ideal solution to have large private technology platforms in control of the architecture holding ‘all the contacts plus the medical status of citizens around the world . . . .’ At the same time, others are similarly wary of authoritarian governments and their law enforcement apparatus having unfettered access to such information. The risk of ‘function creep’ and use of data for purposes unintended by the data subjects exists whether the government or private entities collect this data.

The GDPR’s insistence on a lawful purpose for processing, while not an absolute structural safeguard, can help to hold organizations legally accountable for the uses they make of data. Article 6 of the GDPR requires organizations to have a legal basis for processing personal data. In addition, Article 9 states that processing of special category data such as information concerning health is forbidden unless a specific exemption applies. Organizations must therefore have a general lawful basis and a special category exemption lawfully to collect and analyze data concerning health. Any use of data, which exceeds what is necessary for the stated lawful basis, is prohibited by the GDPR unless it is covered by a separate permissible basis. A data controller needs only one lawful basis in each of Articles 6 and 9 as a ‘floor’, but it might choose to go above the floor. For example, the lawful basis for a public health authority’s processing of data in a COVID-19 tracking app might be to protect the public from infectious disease. In addition, it might state that citizens have a choice whether or not to download or delete the app. The processing allowed by the GDPR is thus based on multi-dimensional limits that sometimes differ from what an individual considers appropriate protection. In contrast, the floor in notice-and-choice-based systems, such as the CCPA, depends on users individually setting boundaries as to what organizations can and cannot collect and for what purposes. If an individual is poorly informed, or for one reason or another is not a rational or fair decision-maker, the GDPR’s approach is preferable.

COVID-19 Tracing Systems Have Multiple Controllers

The lawful basis that is open to a COVID-19 ENS under the GDPR will depend on the particular controllers involved. Each controller will need its own lawful basis. Under the GDPR, the data ‘controller’ is the entity that alone, or jointly with others, determines the purposes and means of the processing of personal data. A data controller can be a private or public entity, but the lawful bases that each can rely upon differ.

Apple and Google’s ENS could have multiple controllers. In May 2020, both companies released APIs that enable interoperability between Android and iOS devices using ‘official’ apps from public health authorities. Second, in the following months, Apple and Google will enable a broader Bluetooth-based contact tracing platform by building this functionality into their underlying operating systems. These changes would enable interaction of the ENS platform with a broader ecosystem of apps (some of which might be offered by private entities) and government health authorities. The purposes of those using the tracking technology are important for determining which lawful basis they may rely upon. They are likely to differ. For instance, public entities will have public functions that private entities donot.

Lawful Bases for Public Health Agencies Managing Apps

The simplest cases under the GDPR involve apps managed by public health authorities. Apple and Google plan to limit access to the ENS to apps designated by a single public health authority in each state. This section considers the lawful basis for processing carried out by a COVID-19 exposure app designed and managed by a public health authority.

While many people will consent to health systems using their data for the purpose of tracking exposure, the EDPB has emphasized that consent is not the optimal basis for public authorities. Consent given to public authorities is generally not considered to be given freely due to the power or potential power of public agencies to compel compliance. Users also may withdraw consent at any time, which could compromise the agency’s public health mission if consent were withdrawn after notification of a positive diagnosis. Instead, the EDPB has clarified that public authorities should most likely rely on Article 6(1)(e) “necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller.” An additional basis under Article 6 would also be subsection (1)(d) “to protect the vital interests of the data subject or of another natural person.”

Recital 46 of the GDPR states explicitly that both vital interests and the public interest are proper bases in the midst of humanitarian crises such as an epidemic:

Some types of processing may serve both important grounds of public interest and the vital interests of the data subject as for instance when processing is necessary for humanitarian purposes, or in situations of humanitarian emergencies, in particular in situations of natural and man-made disasters.

Where an app uses the Google/Apple ENS functionality and collects additional data (beyond proximity), such as user location, equipment details or subsequent health status, the public agency controller will need to evaluate such processing separately. Additional lawful bases may be required to justify it.

Organizations also need a special category exemption in order lawfully to collect and analyze data concerning health. Article 9 provides for several exemptions for special category data relating to public health. Agencies using data concerning health could do so pursuant to Articles 9(2)(g) (‘substantial public interest’), (2)(i) (‘preventative medicine’), or (2)(h) (‘public interest in the area of public health’.). Many national health authorities are sufficiently empowered through their implementing or public health regulations to process contact tracing data according to one of these special category conditions. However, the EDPB has suggested that Member States may want to pass specific implementing legislation to promote voluntary use of the app and setting out functional requirements for its use.

Even where consent is not relied upon as the ‘lawful basis’ under Articles 6 and 9 for processing, European authorities have been clear that voluntary use is an important safeguard under the GDPR. The foundational 1980 OECD Principles on the Protection of Privacy, including the principles of Collection and Use Limitation, as well as Security Safeguards and Individual Participation, require that any use of personal data should be undertaken with the knowledge and consent of the data subject where possible. Requiring explicit consent supports the autonomy and control of the data subject over their personal information as well as inherently limiting the type of data that can be collected and how long it is kept. As such, a consent requirement should be viewed as an ‘organisational measure’ under the GDPR that facilitates GDPR principles of data and storage minimization, and lawfulness and transparency of processing. Even though public authorities do not need consent as a lawful basis, the GDPR requirements for Privacy by Design and Default require that it be sought as a safeguard where possible. User consent is also required under related legislation, such as the EU ePrivacy Directive, which protects individual data located on mobile devices from being accessed via mobile communication networks. The articulation of these principles through legislation has caused designers of tracing and notification systems to prioritize voluntary use. In contrast, officials in China and Israel, for example, have imposed virus exposure tracing software automatically. India’s mobile app began as a voluntary tool, but the government recently mandated its use as a condition of returning to the workplace. Such non-consensual tracking, as well as default sharing of data with law enforcement and national security services, greatly increases the risks that agencies may abuse their authority and use public health data for illegitimate surveillance, law enforcement, or targeting purposes. For this reason, the Israeli Supreme Court recently barred the Israeli security service from continuing to access citizen mobile data for virus tracking without specific legislative authorisation. Furthermore, the Court specified that even under such legislation, mobile tracking should be voluntary.

Note, however, that if a system is ‘voluntary’ but does not depend on consent for a ‘lawful basis’ under Article 9 of the GDPR, controllers can define informed consent in a way that differs from the GDPR’s definition of ‘consent’. For example, information about choices may not be as specific and extensive (they might seek what is known as ‘broad consent’), and some choices may be opt-out. Furthermore, controllers would not be obligated to provide the same automatic rights of withdrawal or erasure. However, data subjects will retain other GDPR default rights, such as the to object to processing, to rectify any inaccurate data held, and to seek associated legal remedies.

Lawful Bases for Private Companies

Any company acting as a controller as part of the ENS, and arguably Google and Apple themselves in administering and updating the ENS, will be a separate ‘data controller’ from the public authorities discussed above and thus will need their own distinct lawful basis for processing under Articles 6 and 9. Other private companies are not currently expected to be involved as data controllers with the Apple/Google ENS. Commercial entities coming into contact with the ENS in its first phase will most likely be doing so as processors for these public health authority systems. For example, the national health services in the UK and Australia operating their own notification systems have contracted with Amazon and Microsoft for certain data storage and information management tasks. Processors act according to the instructions of the data controller and so do not need their own legal justification. It is possible, however, that in the second phase of the rollout of the Google/Apple system, a greater variety of apps will be permitted to use the interface. A company running an app on the Google/Apple system could be a separate data controller. In addition, a public health agency in a Member State might delegate management of their system to a private company in such a way that it becomes a data controller, at least for some aspects of personal data management.. We consider first apps managed under the authority of private entities, and then the role of Apple/Google themselves.

To qualify for the public health-related bases set out in Article 6, such as vital interests or task carried out in the public interest, a commercial entity would most likely need to act in concert with and under the direction of public health authorities. The GDPR is clear that there must be some basis in Member State or EU law that defines the nature of a ‘public interest’, ‘vital interest’, or ‘legal obligations’ for these bases to apply. A private entity cannot just cloak itself in good intentions and claim to act for the public. For example, Israeli spyware firm Group Technologies Ltd. (‘NSO’) , the firm suspected of helping the Saudi government track down dissident Jamal Khashoggi, is also marketing to various governments its software capabilities for monitoring individual virus exposure. While such tracking might be broadly in the public interest during a pandemic, the GDPR requires some foreseeable basis in law before such an entity can purport to represent the public good. Recital 41 GDPR clarifies that “where this Regulation refers to a legal basis or a legislative measure, this does not necessarily require a legislative act adopted by a parliament […] However, such a legal basis or legislative measure should be clear and precise and its application should be foreseeable to persons subject to it.” Private entities that exercise a clear public function, such as a university conducting medical research or a public utility, may also be able to rely on a public interest or official authority basis for processing if supported by law.

Instead of a public interest basis, private companies could claim a ‘legitimate interest’ basis for processing exposure-related data, but, with exceptions, this will also require coordination with a public health authority or the agreement of the data subject. Article 6(1)(f) of the GDPR allows processing that is “necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject.” Third parties certainly have a legitimate interest in knowing whether they have been exposed to COVID-19. However, a private company controller must have a legitimate claim to be the appropriate entity to vindicate that third-party interest based on their relationship to the data subject. This could include some kind of affiliation with a public health authority that typically would conduct contact tracing. Other situations include an employer–employee relationship where a safe workplace is an expectation, or situations where data subjects are clients and infection exposure is a concern (eg clients of a gym). Otherwise, the processing would be outside of the “reasonable expectations of data subjects based on their relationship with the controller” and therefore the rights of the data subject would likely override the third-party interest. Furthermore, any processing permitted under this basis must be limited only to what is necessary and proportionate.

An alternative basis for processing is where it is ‘necessary for performance of a[n existing] contract’ with the data subjects. For this basis to apply, it would not be sufficient that the contract terms might allow tracking of exposure events, unless such tracking has a close and substantial link to the contract’s main purpose. Furthermore, tracking of exposure must be necessary to achieve the contract’s purpose, and the data subject must have been informed that this processing would occur. As an alternative, affirmative and informed consent can provide a basis for exposure tracking so long as the consent is given freely.

All considered, it is likely that, absent an employment or other relevant and close relationship, commercial entities providing tracking architecture through an app must either act together with and under the supervision of a public health organization or obtain affirmative individual informed consent for the processing of infection exposuredata.

As mentioned, Google and Apple themselves in administering and updating the ENS could be in a situation where they independently manage collection of exposure data and exchange of Bluetooth identifiers. In this case, they would also need to specify a lawful basis for this processing. It appears that Apple and Google are trying to take steps to minimize situations where they would qualify for ongoing duties of a data controller. The result of these steps is debatable. On the one hand, because the ENS stores data locally on individual devices, Google and Apple may claim that they themselves do not determine the purposes and means of processing or actually process any personal data. The GDPR defines a data controller as “the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data.” On the other hand, this definition does not require that entities store or physically process data to be a controller: determination of means and purposes of processing by others is sufficient. Just as designers of algorithms that engage in automatic processing are still ‘data controllers’, it could be claimed that by virtue of designing, updating, and operating the ENS, Google and Apple are either joint ‘data controllers’ or in a ‘data controller-data processor’ relationship with public health authorities. If they are joint data controllers, Apple and Google should also specify the lawful basis underlying their design and management of the ENS. As stated above, notwithstanding good intentions, these technology platforms would most likely need to rely on affirmative consent. It is unlikely that broad contact tracing, undertaken without regard to the services Apple and Google typically provide, would qualify as ‘legitimate interests’ of those businesses within the ‘reasonable expectations’ of their customers or ‘necessary for performance of a[n existing] contract’ with the data subjects. Furthermore, the ePrivacy Directive requires explicit consent for processing of data collected automatically via the operation of a publicly available electronic communication service.

The notion of consent under the GDPR is more robust than consent as defined under the HIPAA and the CCPA. Under the GDPR, consent is only valid if it was given freely and in response to clear, plain disclosures devoid of unfair terms. For special category data, such as data concerning health, enhanced consent requirements apply. These are discussed below.

Processing of Special Categories of Personal Data

A similar requirement for public oversight exists when special category data is involved. All of the conditions in GDPR Art. 9, which relate to processing data concerning health for the substantial public interest, public health, or preventative medicine, require that such processing be undertaken ‘on the basis of Member or Union law’. Several of the Art. 9 conditions also impose additional substantive conditions (see Table 1).

Table 1

Analysis of legal basis of processing for special category.

Subsection	Processing Basis	Requirements
9(2)(g)	Substantial public interest	Processing must be proportionate to the aim pursued, respect the essence of the right to data protection, and provide for measures to safeguard the fundamental rights and the interests of the data subject.
9(2)(h)	Preventive or occupational medicine, medical diagnosis, … or … the management of health or social care systems	Data must be processed by or under the responsibility of a professional subject to the obligation of professional secrecy under Union or Member State law or rules established by national competent bodies.
9(2)(i)	Public interest in the area of public health	Union or Member State law must provide for suitable and specific measures to safeguard the rights and freedoms of the data subject, in particular professional secrecy.

Employers may process special category data under 9(2)(h) for the purpose of evaluating the working capacity of an employee, which might provide employers with an independent basis for conducting some form of targeted contact tracing. Processing necessary to carry out obligations in the field of employment and social security and social protection law is also allowed in so far as it is authorized by Union or Member State law. This basis could allow employers and other commercial entities who have a defined social care function under local law to conduct some form of health care monitoring. Member States could also pass specific legislation or issue administrative guidance authorizing commercial parties without a social care function to manage an app or other architecture for contact tracing. That legal instrument could provide the basis for commercial entities offering tracing functionality such as Apple and Google to claim to act according to one of the above special category conditions. That same measure could establish governance and accountability mechanisms to ensure that private use of the data remains responsive to public concerns and democratic principles. Depending on the special basis employed, some processing may also require obligations of professional secrecy. Note that even under the authority of such implementing legislation and professional secrecy, there is a strong argument that use of the app should still be voluntary to enhance public trust and to meet GDPR principles of privacy-by-default and privacy-by-design.

Rather than a justification based on public interest reasoning or a special relationship of care, private entities processing data concerning health may rely instead on explicit consent. Enhanced consent requirements apply. The data subject will need to provide explicit, informed consent to the processing of personal data for each specified purpose. Furthermore, under the GDPR, independent supervisory authorities are empowered to investigate any abuses as well as to ensure that rights to the data subject such as right of access, rectification, erasure, ‘right to be forgotten’ are respected. By contrast, in the USA, the CCPA requires merely that businesses that collect personal information from California residents inform those consumers of the uses will be made of their data. Consent is not required; it is up to the consumer affirmatively to object. The HIPAA has consent requirements analogous to those found in the GDPR, but these only restrict covered health entities and their business associates. Other businesses, such as Apple and Google, which are not health care providers or insurers, may collect health data freely and need not seek consent if they obtain sensitive health-related data other than from a covered entity. Consent under the GDPR is therefore a substantial use limitation that can help ensure that information provided to apps will not be used to target or disadvantage users. In the USA, where consent does not provide firm limitations, a recent poll found that nearly three in five people would not be willing to download and use an infection-tracing app largely due to mistrust of tech companies and their willingness to safeguard privacy.

CONCLUDING REMARKS

The GDPR is known to have an expansive scope. COVID-19 app tracking systems are likely to fall within its purview, unlike narrower sector-specific rules such as the US HIPAA, and even the new CCPA. Counter-intuitively the scope of the GDPR is not likely to be a hindrance, but rather an advantage in conditions of uncertainty.

The principles in the GDPR offer a ready-made functional blueprint for system design that is compatible with fundamental rights. The principles are flexible enough to accommodate either a centralized system run under the auspices of a public authority, or a completely decentralized system designed by private entities with user consent. The utility of any ENS will depend on the reliability of diagnosis information and the broad availability of testing once notified of exposure. With these complementary capabilities, exposure tracing and notification is a proportionate response to the coronavirus public health threat that justifies some intrusion on the privacy rights of individuals.

Each system—decentralized processing by private entities or more centralized tracing overseen by public health agencies—has privacy advantages and disadvantages. Public health bodies are, at least in theory, more democratically accountable. On the other hand, users have, at least in theory, more robust rights to withdraw from commercial systems operating based on user consent. Combining both approaches is also possible. It will be important for data protection authorities closely to monitor either type of system to protect against function creep. In addition, each jurisdiction may choose to promulgate official regulations, legislation, or orders that set out the rights and obligations of all parties involved in contact tracing even when users consent. These provisions could include requirements that the data not be kept, except in aggregate form, after the public health crisis. It will also be helpful to involve civil society organizations and ensure representation of groups such the elderly, minors, the incarcerated, etc to provide oversight and advice on use of the technology. This is in keeping with the GDPR’s mandate to ensure ‘lawfulness, fairness and transparency’ in processing.