Guidance

[Withdrawn] The NHS COVID-19 app: data protection impact assessment (early adopter trial, August 2020)

Published 13 August 2020

This guidance was withdrawn on 1 April 2022

This page has been withdrawn because it’s no longer current. Read more about the NHS COVID-19 app.

The app and app user in context

The Department of Health and Social Care (DHSC) is the data controller for several services provided to members of the public (data subjects). DHSC is responsible for taking steps to protect the privacy of individuals, to reduce their identifiability and to ensure that processing is proportionate, and that safeguards are in place. For example, as service users pass through systems, this means ensuring that only the minimum amount of data necessary is shared between services and data sets are held separately.

In the context of a pandemic (a public health emergency), data sharing between services is necessary to support the management of communicable diseases and for the protection of the public. This includes monitoring the effectiveness of services and their impacts on different communities.

The app user (the app data ecosystem)

The use of data collected from app users is subject to the controls and oversight detailed in this DPIA and associated privacy notice.

There are clear commitments to service users required by the law, as part of the commitments to maintaining app user’s privacy, and to protecting their identity from other app users as well as the government.

The user journey and data flows are shown in diagrams throughout this document. More detail is provided within the appendices and annexes of this document.

In future iterations of the app, app users may be asked to voluntarily share more data about themselves, for example their age-band. This data helps to ensure that the service offered through the app, is meeting the requirements of as many communities and needs as possible in the response to COVID-19.

Any change to the data requested will be reviewed, will be lawful, and will be available as an additional choice by the user. Please note that future changes are beyond the scope of the current version of the app and this data protection impact assessment (DPIA).

Data generated and collected by the app is held in three environments. Systems are in place which support the secure and appropriate flow of data between these environments:

• app users’ phone – the NHS Test and Trace App and the majority of data collected by the Apple/Google API will be always (and only) held on the app user’s phone. This is considered a user-held record. For most functionality, data is presented to the user’s phone and is checked against the data held on the phone (for example, visited venue QR codes that could be considered at risk or other users that should be considered at risk)
• product environment – during the app initialisation phase the app user provides their postcode district, make and model. Neither postcode district nor device type identify the user and are not included in data constituting personal data. Additional data items from users as governed by the API are collected as described in the data dictionary within this document.
• analytical environment – subject to additional controls (for example, further deidentification) data will flow to the analytical environment. This is aggregated data and is designed to support learning about the app and COVID-19.

Virology testing

App users who enter symptoms and are recommended to seek a COVID-19 virology (anti-gen) test can generate a reference code (“test code”) unique to themselves and to this particular occasion on which they seek a test. The test code gives the user access to the virology testing website where they can book a test. The functionality of the app will ensure that the test code is transferred to the website. In order for a test to be booked and the results sent to the correct individual, the website requests additional data from the user.

The test result and code are used to feed results back to the app users:

• update the user’s COVID-19 status
• add the relevant code to the list of “at risk” individuals presented to app users’ phones (triggering an update in the status of app users if their “Exposure Log” includes the protected identification code of the individual)

Further use of the data collected as part of the testing process is governed by the website and services’ DPIA and privacy notice.

Venue (QR) alerting system

Details of the venue and postcode district alert systems are still being resolved and will be explained in more detail elsewhere. The data is presented as a list of “at risk” QR codes (protected to obscure the location) sent out by the system. This data triggers the alert functionality within the app.

Using QR codes to check in at venues is a more robust privacy preserving mechanism for the user than manually signing-in with a pen and paper.

This function does not relate directly to the data processed within the app.

Contact tracing (national)

At time of writing, no data from app users is passed to any of the national contract tracing systems in use. App users can choose to use the information held only on their phone to support the contact tracing process when interacting with the service. Data collection and use is governed by the DPIA and privacy notice alongside processes used by that service. No data is shared from the app.

An option being considered is to allow app users the choice to send data held on their phone to contact tracers. This would include the venues they have visited. This option is subject to a change control review - including a review of the legality, proportionality and impacts upon privacy and identifiability.

Contact tracing (local)

The same conditions apply to any local contact tracing by local public health teams. The app user may use the data held only on their phone to assist themselves and the contact tracer, if they choose to.

Apple and Google

The NHS Test and Trace app is available through the Apple App Store and the Google Play Store. Apple and Google provide the app independently of the NHS and Department of Health and Social Care.

The NHS Test and Trace app: data protection impact assessment

Introduction

The NHS Test & Trace App (“app”) is a mobile phone application that is part of the NHS Test and Trace Service, which is designed to break the chains of transmission of COVID-19. By using the app, users will help to protect themselves and those around them – their friends, family, colleagues and local communities, and enable society to return to a more normal way of life. The app is a medical device providing maximum freedom at minimum risk. 

The objectives of the app are to:

• create an enduring new medical technology to manage public health

• promote behaviour change by helping people manage their risk exposure

• identify and inform people to help communities manage health emergencies

• reduce disease transmission by giving users easy access to health services

• support and inform users during isolation

The behaviour sought by the app from users is to:

• download the app and use it daily

• keep the app ‘on’ and carry their phone at all times

• follow instructions issued by the app

• ‘pause’ the app when appropriate

• enter symptoms and take a test quickly when told to

The NHS Test and Trace contact tracing app has 3 core roles:

• precision: to measure distance and time between app users accurately
• reach: to remember which other app users an app user has been near
• speed: to initiate self-isolation quickly through contact detection of positive cases

The data controller

On behalf of the Secretary of State, the Department of Health and Social Care (DHSC) will act as controller for the processing of personal data that supports the functioning of the app. This is overseen by NHS Test and Trace (which is part of DHSC).

Design objectives

The app has 6 user-benefiting capabilities that are designed to encourage mass download and daily use. These capabilities have been designed to meet the remit of breaking the chains of COVID-19 transmission and enable society to return to a more normal way of life.

Three of these capabilities are dedicated to reducing personal risk (the ‘me’ functions as shown in figure 2):

Personal contact risk score (risk score) – functionality not included in the initial phase of the app

The app will provide a visual of where on the risk spectrum the user sits; this will be either unknown, low, or high risk. The user’s risk level will be based on the number of encounters traced by the app over a configurable amount of time and will be updated every hour.

Real-time high-risk postcode matches (alert)

The app will notify the user if their postcode district (as provided by the user during onboarding) becomes a high-risk hot-spot area. The postcode district is the first section of the postcode (before the space). This does facilitate alerts to users in local authority and postcode districts.

Digital check-in diary (venue check-in)

The app will allow the user to check-in and check-out of venues that provide a QR code e.g. restaurants, shops and stadiums. If a venue later reports a cluster of positive coronavirus cases, the app user will be notified if they were present in the venue at the relevant time.

The remaining 3 categories are targeted at reducing public risk (the “we” functions, where “we” refers to public benefit). These are:

Symptoms questionnaire (symptoms)

The app will allow the user to report the symptoms they are suffering with and the date of when they started. Based on which of the symptoms they have selected from a list, the user will receive an initial indication as to whether they may have coronavirus. If the user’s symptoms indicate they may have coronavirus, they will be asked to self-isolate and book a test.

Coronavirus test (test)

If the user’s symptoms indicate they may have coronavirus the app will assist them in booking a test from the GOV.UK website. Once known, the test result will be provided in the app (as well as via other methods). Data entered used for the testing process is managed outside of the app environment and additional information is available elsewhere.

Self-isolation countdown (isolate)

The app will ask the user to self-isolate either because the user has reported symptoms indicative of coronavirus (the index case), or they have received an exposure notification (the contact case). Once asked to self-isolate, the user will have access to a self-isolation countdown which keeps a track of the time they need to spend self-isolating.

This design has been driven through the collection of the requirements and iterated through user research. Further explanation of the functionality and processing that supports these 6 features is set out in this document.

The app has been designed to protect the privacy of those who use it. Fundamental to this design has been the ICO Contact Tracing Principles – responses to these are summarised below.

ICO Contact Tracing Principles and app design responses

Be transparent about the purpose – explain if the current/future purpose is only proximity notification or broader

The purpose of the app is to enable society to return to a more normal way of life. To do this a combination of features are offered to reduce public risk by helping people:

• understand their symptoms
• be able to order a test
• have an easy way to track the days they are recommended to isolate (if required)

The app also has features to encourage the user to engage regularly with the app, i.e. the postcode district risk and venue check-in functionality. More detail is available in the introduction and design section of this document.

The roadmap set out in this document illustrates current planning for future releases. The themes of new functionality relate to:

• Access (translation of language)
• Devolved Administrations (interoperability)
• Medical (taking the symptom checker at the end of isolation)
• Postcode district work (multiple postcode districts for a given user)

For more detail, please refer to the section on the roadmap for future functionality of this app.

The purpose of the app is explained comprehensively in its associated privacy notice.

Be transparent about your design choices – use the least privacy intrusive approach possible. Explain risks.

The initial design for an NHS COVID-19 contact tracing app undertook a centralised approach to managing data, built around a clear focus on the epidemiological understanding of the disease.

With the Google Apple API we have moved to a decentralised approach. This is a design least intrusive on privacy as very little data leaves the phone and all matching happening only on an individual’s device. Our commitment to transparency is further demonstrated by open sourcing our code, which will be published on Git Hub on MVP launch.

This DPIA and privacy notice will also be published.

Be transparent about the benefits – from both your perspective and that of the user. Explain how tensions between these are managed.

The 6 app capabilities have been designed for user benefit. Research has been undertaken with Users to refine these capabilities.

One area of tension in the design is setting the risk threshold to determine the volume of people who are asked to isolate. This determination is based on the deemed risk of the encounter they have had.

The risk threshold is based on several factors including:

• the current reproduction number (R)
• social restrictions
• testing capacity and speed; and
• the likely impact on future compliance from false positives

This value drives the number of people asked to isolate and is regularly reviewed.

This approach has been scientifically determined by the Alan Turing Institute in partnership with MIT. More detail is available below regarding Automated decision making and Article 22 (GDPR requirements).

Collect the minimum amount of personal data necessary – only collect or otherwise process information that is required for the core purpose (e.g. excluding location data).

The app has been designed to use the minimum amount of personal data possible. In all instances, the data required, used or stored is minimised to reduce or remove the ability to identify an app user and to maintain their confidentiality and privacy. As an example, information collected in the app includes the user’s postcode district. The postcode district is shared by ~8,000 households which minimises the possibility of any personal identification.

More detail is available in the section ‘nature of the data’.

Protect your users – use pseudonymous identifiers which are renewed regularly.

The app has no concept of registration, of allocating unique ids to app instances, or holding app instance specific data on the backend services.

Apple/Google exposure notification diagnosis keys are completely random and cannot be linked to the user. These are considered anonymous. A new diagnosis key is generated every day and will not be repeated. Diagnosis keys generate rolling proximity identifiers approximately every 15 minutes.

More detail is available in the section ‘nature of the data’.

Give users control – ensure your users can exercise their rights.

The app has a section called ‘About’ which users can access to discover the information held about them. This information includes:

• postcode district
• venues captured via check in
• last test result

In a future release, this information might also include any symptoms entered by the user.

All data other than postcode district is able to be deleted from the app, with an option to the delete the postcode district available for update in a future release. The app itself may also be deleted.

Keep data for the minimum amount of time – explain what that period will be and why.

Diagnosis keys are kept for 14 days (the incubation duration for the virus). The keys are retained on DHSC secure computing infrastructure, hosted on Microsoft Azure Cloud Services (UK) infrastructure for a further 14 days.

QR codes are kept for 21 days (this accounts for 14-day incubation period and 7-day infectious period of the virus)

The analytics data is anonymous. More detail is available in section ‘retention of data from the app’.

Securely process the data –apply appropriate techniques to secure the confidentiality, integrity and availability of data, both at rest and in transit.

The app system has been designed and developed in accordance with security principles that govern data on the device, data in transit, data processing on the backend.

More detail is available in section ‘security of processing’.

Ensure the user can opt in or opt out without any negative consequences – functions decoupled to allow the user to benefit from one function without being compelled to provide data for others.

The features of the app do not have to be used, i.e. the user has the option to turn on venue check-in functionality to scan the QR code. Users can also choose to enter their symptoms or book a test.

The option to call 111 is available in each function should the user wish to discuss their circumstances, or the advice they have received. Google and Apple have both been keen to assess and understand this position and are satisfied the solution does not contradict their EN API, which does not track or directly / indirectly limit public access.

More detail is available in section ‘overview of the functionality of the NHS Test and Trace App’.

Strengthen privacy, don’t weaken it – do not introduce additional privacy and security risks for the user

We adhere to the principles which the Ethics Advisory Board to the first version of the app set out for us.

These principles are the basis by which any future change requests for the app will be assessed. Any request to add to or change the scope of the app will be formally presented to a Change Board which will convene weekly.

A core value for the app and service is focus on Privacy, specifically that the app must preserve the privacy of our users. In order to adhere to this value, the application and back-end service have considered privacy and security at each stage of design and development and has resulted in the use of a “decentralised” approach whereby data is stored and processed only on the user’s mobile device.

An example is venue check-in. Users are encouraged (but not required) to scan QR codes on official NHS posters posted at venues. This simple act provides user-led control for privacy. In this instance, the QR IDs are only stored on the user’s device and protected using encryption features available from their phone. The data never leaves their device, and can be deleted by the user at any time.

Where user identifiers are required, such as the virologic testing user journey, short-lifetime ephemeral tokens are used to protect the users’ privacy.

The use of SaaS (Software as a Service) means that IP addresses of user devices may be logged by infrastructure components. The solution attempts to remove this association at the earliest possible opportunity.

More detail is available in the section ‘privacy by design and default’, and section on ‘security of processing’.

Information Commissioner’s advice

The Information Commission provided a document setting out expectations of a COVID-19 app. The 10 principles they describe have guided the construction of the NHS Test and Trace App.

The Information Commissioner also raised a number of specific issues relating to the previous iteration of the NHS COVID-19 App, which have been addressed in this document:

1. Data subject rights – see the section on subjects’ rights

2. Automated Decision Making at Article 22 of the GDPR – see the section on automated decision making

3. Transparency requirements – it is intended that the app’s functions will be clearly communicated using the material set out in the section ‘design objectives’

4. Necessity and proportionality – see the section ‘privacy by design and default’

5. PECR (the Privacy and Electronic Communications Regulations 2003 (as amended)) – including clarity of when information is stored on or accessed from user devices, and when opt-in consent is required. See the section on PECR.

Rationale for adopting the Apple-Google Exposure Notification API

See the section on ‘necessity and proportionality’ for an explanation of this decision.

Rationale for this data protection impact assessment (DPIA)

Data controllers are required by the GDPR to conduct a DPIA before introducing data processing which could pose a high risk to subjects in the absence of proper controls. In particular, when using new technologies.

DHSC does process personal data that relates to the health of a very large number of individuals, and there are new types of technology employed in doing this, but all have mitigations in place to substantially reduce risk.

The Information Commissioner’s view that organisations designing contact tracing apps are responsible for ensuring the app complies with data protection law. This is especially important because individuals may believe that the data protection by design and by default principles used in the development of the Contact Tracing Function extend to all aspects of a contact tracing app that is built to use it. Any supporting technology, including centralised processing to support contact tracing, should follow the same principles.

The app is designed to respect the privacy of those who use it. The identities of app users are not revealed as a consequence of its use. The App does not collect any directly identifiable information (for example, it does not collect name, telephone number, NHS number or GPS location data).

It is essential however to assure and formally document how the app works and how it protects the privacy of its users. Success relies on users’ confidence in the information being processed by the app.

This DPIA is a draft version supporting the early adopter trial only. This document will be subject to review and revision in light of insight from this trial.

The nature of the data

It is essential to document the nature of the data and identify whether it constitutes personal data for the purposes of data protection legislation. The data dictionary is presented in appendix 1. Key features of constituent data items are referenced in the table above and described below.

The app makes use of the Apple/Google exposure notification system (hereafter the EN API). This capability is incorporated in the latest versions of iOS and Android operating systems. The EN API can only be activated when an authorised App is installed. The NHS Test and Trace App has been authorised for installation by the Apple and Google app stores.

The Apple-Google exposure notification API

The EN API generates 2 types of identifiers:

• diagnosis keys
• rolling proximity identifiers

Diagnosis keys

Diagnosis keys are generated by the EN API and uniquely reference an instance of the installed app on a user’s device. A new diagnosis key is generated by the EN API every day and will not be repeated. Diagnosis keys are used by the EN API to generate a further set of keys called rolling proximity identifiers (RPIs) approximately every 15 minutes (see below).

Diagnosis keys are released to the app when a positive COVID-19 test result is received. This is only possible with the express permission of the user. Once granted, they are submitted to DHSC secure computing infrastructure, hosted on Microsoft Azure Cloud Services (UK), for distribution to all app instances.

Diagnosis keys (for a user who has submitted them) reside in the following locations:

• the EN API of the submitting user’s phone
• the app data of the submitting user’s phone
• DHSC secure computing infrastructure
• The app data of receiving users’ phones
• The EN API of receiving users’ phones

Diagnosis keys are at no stage associated with any other information. The fact that they have they have been distributed for matching only indicates that the submitting user has been diagnosed as having COVID-19.

When distributed beyond the EN API, diagnosis keys do not relate to an identified natural person. They also do not relate to an identifiable natural person by virtue of the design of the app and its supporting DHSC secure computing infrastructure – i.e. no identifying information is associated with them, technical controls are in place to prevent interception. On this basis they do not in themselves constitute personal data. This allows for their distribution without unlawfully disclosing confidential patient information.

Diagnosis keys residing on the generating EN API may be considered personal data by virtue of their association with the installed phone. The privacy design ensures that the controller cannot have access to these keys - other than for submission to the DHSC secure computing infrastructure.

Rolling proximity identifiers (RPIs)

The EN API uses the daily temporary exposure key (TEK) to generate a new RPI approximately every 15 minutes. RPIs are made available over Bluetooth and collected by the EN API running on other users’ phones. RPIs are random and almost certain to be unique, with only a remote chance of being repeated.

TEKs or RPIs cannot be accessed by the NHS Test and Trace app without a user testing positive for COVID-19. The user must also consent to release the keys. Once approval has been received, TEKs are provided to the App and deleted from the EN API. They then become diagnosis keys. Only when diagnosis keys are known can the RPI be re-generated. RPIs are not considered personal data because they do not relate to an identified or identifiable person.

Postcode district

When the user installs the app, they are asked to provide their postcode district of residence. This is the first part of their postcode up until the space. Postcode district is uploaded to DHSC secure computing infrastructure daily with other anonymous analytics data.

Postcode district does constitute a component of the personal data held on the installed App. Postcode districts only relate to a user who is identifiable in the context of their use of the App. A postcode district typically includes ~8,000 households, thus minimising the possibility of personal identification.

Test results

When a user is recommended to take a virology test, the server allocates them a short-lived unique token. This token is passed to the virology testing platform so that test results can be sent back to the app system. The token replaces the need for any personal identifiable information. The token is destroyed within 24 to 48 hours of test results being received.

The token is associated with fully identifiable personal data relating to the subject throughout the processing of the test. The one-time token and the test result are returned to the Cloud Services database which downloads them to the user’s phone. The token and test result are then deleted.

Test results constitute a component of the personal data held on the installed app. This is because the token relates to a user and is identifiable in the context of their use of the app. The test result and the token constitute pseudonymised personal data whilst they are held temporarily in the Cloud Services database. Test results which are uploaded to Cloud Services daily with other anonymous analytics data only include the test status - and not the token. They are not identifiable to a user.

Personal data held only on the phone

The app processes data entered by the user about their symptoms in order to provide advice on isolation and signpost to testing services.

The app also collects QR codes from venues which the user has visited and checked-in to. Although this information does not leave the phone, the data does relate specifically to the user and therefore constitutes personal data.

Analytics data

Analytics data is collected by the app and submitted to Cloud Services specifically for the purpose of understanding the performance or behaviour of the app system. It is uploaded daily to Cloud services in anonymous form.

Analytics data from postcode district and test results constitute a component of personal data when held on the installed App. This is because they relate to a user and are identifiable in the context of their use of the App.

Symptoms data is not retained on the phone after submission in the daily analytics upload. This data is not considered personal data when held in anonymous form on DHSC secure computing infrastructure.

Postcode district data is not combined with symptoms data for the purpose of identifying where an individual is located. This data is used only for public health purposes, such as the monitoring of infection spread.

Data held on Cloud Services

Table 2 describes a summary of the DHSC secure computing infrastructure data. The server only handles data if it is needed for app operation or for system monitoring. No data held on the DHSC secure computing infrastructure is traceable to an individual.

Table 2: data held on DHSC secure computing infrastructure

Data	Description	Handling	Personally Identifiable?	Where held
Diagnosis Keysets	EN API diagnosis keys from confirmed positives	Created by EN API on app. Transmitted to all app instances.	No. Further, diagnosis keys are deleted from device when extracted.	Central diagnosis key store for maximum of 14 days.
Hotspot QR codes	Venue codes with infection clusters	From manual contact tracers. Transmitted to all app instances.	No. Related to venue.	Central HotSpot QR code store for maximum of 21 days.
Postcode district risk	Infection risk level at postcode district level, as provided by JBC	From Joint biosecurity Centre (JBC). Transmitted to all app instances.	No. Related to postcode district (first portion of post code before the space)	In central store and on app
Virology Test Results	Test results from mass testing services	From NPEx (National Pathology Exchange) database. Retrieved by app using short-lived token.	Yes. Token is temporarily mapped to results. Held on app, server and in virology applications.	On app and in virology systems held separately to the app
App analytics: (Postcode district, exposure events, risk status, symptom results, isolation status, device model, OS Version, app Version, usage stats, data usage)	Analytics data collected	Transmitted anonymously from device. IP address removed before processing. Aggregated by server before persistence.	No. No personal data is included, and all data is aggregated anonymously.	App Analytics Environment

Privacy by design and default

As described in the section above, the app has been built to respect the ICO’s Contact Tracing Principles. Key privacy features of the app are that:

• users’ identities will not be revealed by the app
• no persistent user identifiers will be processed
• the app will collect the minimal amount of data necessary
• as far as possible processing will take place on user’s phone
• personal data does not leave the device without the permission of the user
• analytics data is only collected in anonymous form
• there will be no third-party trackers gathering personal data in the app
• the user can delete the app and its data from their phone at any time
• data in the DHSC secure computing infrastructure will be made available only to individuals that have been formally authorised to access it
• transfer of data from the DHSC secure computing infrastructure to another system or controller, or processing for purposes outside the scope of this DPIA will be subject to further DPIA.

The app makes use of the Google/Apple EN API, which is incorporated in the operating systems of Apple and Android phones. The features which ensure user privacy are outlined in this document.

Contacts, QR codes and postcode district data is processed on the device. Circuit breaker, diagnosis keys and anonymous data are processed off the phone.

The EN API

The app is built upon the contact matching functionality of the Google/Apple EN API.

Generation of daily diagnosis keys and cryptographic rolling proximity identifiers are completely under the control of the EN API and the phone’s operating system. They are not accessible to the app directly from the API.

Access to diagnosis keys by the app is controlled by the EN API and is only enabled with the express permission of the user. The user is presented with a pop-up request for permission, which is controlled by the EN API, not the App.

Rolling proximity identifiers are generated from diagnosis keys approximately every 15 minutes. These identifiers are broadcast for collection by the EN API on any compatible phones in the proximity. RPIs are encrypted in transmission and only accessible to broadcasting and receiving instances of the EN API. They are never available to the app.

Diagnosis keys are downloaded to the app from DHSC secure computing infrastructure. Once downloaded they are passed through to the EN API which regenerates the associated RPIs. The generated RPIs are used for matching against RPIs the phone has received via Bluetooth. Only a direct match is returned to the app.

Stateless and conversational APIs

All of the APIs presented by DHSC secure computing infrastructure are either ‘stateless’ or ‘conversational’:

• stateless APIs do not save data generated in one interaction for use in the next interaction
• conversational APIs generate a token which is returned to the app in the initial communication allowing the App to poll for further communications relating to the same matter – this allows for processing to be conducted whilst the token remains current

Application Programming Interfaces (APIs) used by the app

APIs used to communicate with DHSC secure computing infrastructure are described below:

• Analytics – collects analytical data from the app for aggregation and statistical analysis (stateless)
• Config – provides configuration for the app, possibly based on device state, like language and type (stateless)
• Distribute – access the data used for risk scoring; positive diagnosis keys, hotspot QR codes and postcode district risk levels (stateless)
• Risk – confirm with the cloud services before taking a risk-based action such as isolation (conversational – the app request is returned a short-lived transaction ID. The token is needed as long as the circuit breaker takes to make its decision. There is manual input in this step, so time is not fixed. Rarely above 4 hours)
• Submit – submit exposure diagnosis keys to be added to the positive key set (stateless)
• Control – support the control Panel web monitor (stateless)
• Swab testing – app-facing API used to get a transaction token and get the swab test results (conversational – a transaction ID token is maintained while a swab test is underway, which is expected to be 1 to 4 days)
• TestLab – 3rd party test lab API used by the swab test Labs to submit test results, together with the linking token ID (conversational – a transaction ID token is maintained while a swab test is underway, which is expected to be 1 to 4 days)

No user account or registration process

There is no user account or registration process requiring the submission of direct identifiers. This includes name, email address or telephone number.

A central system, the DHSC secure computing infrastructure, is necessary to facilitate exposure notifications and the communication of test results. Use of the App does not however involve a persistent internal identifier to link data on the App with data in the DHSC secure computing infrastructure.

All communications between the App and the DHSC secure computing infrastructure database are conducted by polling rather than push notification. There is no need for a messaging service or messaging ID.

Distribution of data from the DHSC secure computing infrastructure database to the App is achieved by the App making requests to the relevant API.

QR codes for venues visited never leave the phone

A history of the scanned QR codes for venues a user has checked-in to is accumulated on the phone. This is used for matching against the distributed QR codes for venues identified as infected.

The codes scanned by the user never leave the phone.

The QR scanner is incorporated within the app to ensure that there is control over proper operation.

Details of the venue are encrypted with AES.GCM and the key is stored in private device key storage.

Analytics data is anonymous

App functionality which involves the backend (circuit breaker, key submission, onboarding) is real-time. Other analytics are collected on a daily basis.

The analytics dataset is anonymous. The IP address is removed when the data is collected and the data is aggregated.

Consent

Consent as a basis for lawful processing for GDPR purposes is not being applied.

Installation of the app is entirely voluntary; Specific permission is requested for the app to access Diagnosis Keys, for submission, and to open the camera to scan QR codes.

Location

The app does not use GPS or any other geolocation technology to collect information about the location of a user’s phone.

The collection and recording of proximity encounters rely entirely on the strength of Bluetooth signals between communicating devices.

Security of processing

Threat modelling was conducted during the design stage. A STRIDE review was used to identify all threats to data both in transit and at rest. These cover threats such as Spoofing, Tampering, Repudiation, Information disclosure (privacy breaches or data leaks), Denial of service and Elevation of privilege (STRIDE). Threats are prioritised based on based on potential or actual impact.

Security principles have been established to define the controls needed to protect data:

Securing the systems that enable the app

Stateless microservices are used to deliver services where possible. The use of cloud provider services results in a highly scalable and reliable infrastructure.

All data is stored in encrypted storage.

Static data is monitored to detect change.

Service availability is continuously monitored as part of the operations function.

Securing data in transit

All data in transit is encrypted using TLS1.2+ using modern cipher suites.

Clients and services must mutually identify each other:

• the mobile device app provides an API key to the backend
• third-party services provide an API key to the backend
• the backend service presents a certificate that the connection initiator verifies is issued to the service (certificate pinning)

Data originating from the backend must be signed. Mobile app clients have a public key in the application which is used to verify the signature of data from the backend.

The infrastructure is protected through a range of techniques:

Architecture

Separation of environments – Environments are separated by use: development, testing, staging and production.

Use of DHSC secure computing infrastructure via cloud provider services – Where security functionality is available from the cloud service provider, these solutions have been selected over in-house or third-party solutions. These are proven services that are the responsibility of the cloud service provider to maintain. Where appropriate, we have followed the cloud service providers recommendations and guidance relating to secure configuration.

Use of microservices – Limited functions integrated into the SaaS architecture. Where possible these are stateless.

Use of web-based services – All web-based services use TLS v1.2 and all services require authentication (with the exception of requests from mobile devices where we attempt to preserve anonymity).

Repeatable delivery – The use of Infrastructure as Code is mandated to enable repeatable delivery of the environment and assurance of repeatability of test results.

System user management

Role based access control – All users are granted permissions through roles. Access is granted on a per-environment basis.

Authentication – Multi-factor authentication is required.

Monitoring

Monitoring – Activities of highly privileged users and high impact actions are alerted in near real-time. These alerts are monitored by the app operations team.

Protective monitoring is described further below.

Test the effectiveness of the security measures and respond to any security issues

Security measures are tested throughout the delivery lifecycle for both the applications and backend services:

• Design – Threat modelling is performed, prioritising threats and identifying suitable controls.
• Build – During deployment, backend security controls are explicitly tested to ensure that the configuration of the solution does not inadvertently lead to information leakage.
• Test – Active penetration testing is performed using an independent third-party supplier. Cloud service provider compliance services are used to verify that the service meets CIS recommendations.
• Operate – In addition to the ongoing performance of the activities described in the Test phase, protective monitoring is undertaken. To the extent possible, all source code is made available as open source, enabling anyone to identify potential security issues. Reports are encouraged through the HackerOne Vulnerability Disclosure Programme are triaged and responded to.

In addition to system protection, a number of components also detect compromise:

• Protective security monitoring is deployed on the AWS platform and service running on the platform
• Proactive security alerting is implemented to notify when a privileged role has been used or a high impact event occurs
• Security logs are sent to the Cyber Defence Operations Centre for analysis of anomalous or malicious behaviour
• As a result of these alerts, security incidents are triaged by the incident management team who respond appropriately.

Data flow lifecycle and data architecture choices

Data flows through the system have been described in relation to each feature in the section ‘overview of the functionality of the NHS Test and Trace App’.

The following principles have been used throughout the solution:

• No User State or Identifier is stored on the DHSC secure computing infrastructure
• All APIs are stateless where possible
• When stateful behaviour is required, short-lived tokens are used as identifiers. As described in the flow below this exist only as long as are needed
• Some interactions are in place to support future functionality
• Rich analytics are collected, protecting the app user’s identity. For example, a user’s IP addresses will not be recorded.

All web-service APIs owned by the project use TLS encryption and DHSC secure computing infrastructure require all app user’s data to be embedded in the content of the payload.

The following data items are sent from the end user and stored in the DHSC secure computing infrastructure or persistent storage:

• diagnosis keys – A set of device keys encountered by the device. This data is only uploaded when the user has a positive test and they have specifically consented to sharing through the app. If the user gives permission then this data is distributed to all devices periodically. The validity of the duration of the keys is defined by the Apple/Google API.
• analytics data – This is aggregated and made available for query by authorised users. This data is exported to the App Analytics Environment (AAE).
• interactions with the service which are logged through cloud provider services. These records are provided to the Cyber Defence Operations Centre to enable them to perform protective monitoring.
• venue check-in – this is distinct to the app and outside of the scope of this DPIA. The process includes the email address and venue location. Where venue owners request a poster, they are required to provide an email address and location. This is used to send the poster to the individual registering the venue. A list of poster IDs and their associated location is provided to JBC.

The following data items are sent from the end user and are not stored in cloud databases or persistent storage:

• symptoms submission (Not in use in the present version)
• virology testing – This uses a pass-through mechanism to allow a user to register for a test. A temporary token is created to allow the user device to poll for results that are returned from virology testing labs.

The following data relating to individuals is stored as a result of back-end integrations with third parties:

• Virology test results delivered via the NPEx informatics system. This token is then matched to the temporary token, enabling a device to verify the results. (NPEx is a system owned and operated by Calderdale and Huddersfield NHS Foundation Trust in support of the national COVID testing operation.)

Rationale for collecting postcode district

When the user installs the app, they are required to provide their postcode district. This is the first part of their postcode up until the space. On the EN Server this is included in the analytics dataset but is not considered personal data as it is fully anonymous.

The postcode district is collected in order to understand the geographical distribution of:

• app uptake
• reported symptoms of coronavirus
• potential transmission events

This data will be used to understand where the virus is spreading, and how fast it is spreading in different locations. This information could be used to coordinate local responses - be it by increased provisioning at the local NHS Trust or deploying more Test and Trace resources. The postcode district will also provide insight into regional variation in the uptake of the app as well as regional infection rates. The postcode district will also be used to alert users when their postcode district is at a higher risk from coronavirus.

Regional variation information will provide improved epidemiological insights. In future versions of the app, this information would allow the implementation of a localised risk function, including messaging within the app to provide users with information about COVID prevalence and services in their area. This could contribute to a more granular loosening/tightening of social distancing rules at a more geographically granular level. This would ultimately help to get more people back to normal life quickly and safely.

Confidential patient information

Diagnosis keys are an indicator that a referenced individual has become infected with COVID-19. If the individual were identifiable, then this would constitute confidential patient information for common law purposes.

Using or disclosing confidential information requires one of three bases for it to be lawful:

1. consent
2. overriding public interest
3. statutory permissive power or obligation

Diagnosis keys more precisely represent an approximate 24-hour period within which the EN API (operating on a user’s phone) broadcasts rolling proximity identifiers (which expire and are replaced approximately every 15 minutes).

As neither the diagnosis keys nor the rolling proximity identifiers can be used to identify a user or their phone, they are not considered to constitute personal data away from the user’s phone. Nor are they considered confidential patient information.

As described above, the receipt and communication of test results by the DHSC secure computing infrastructure involves the result being associated with a temporary one-time use token. The use of this code requires that it is associated with information that does reveal the subject’s identity, such as name and telephone number – but only outside the app.

In the context of the DHSC secure computing infrastructure database, the token and the test result are transient. The only purpose being to facilitate communication to the user when requested by the app.

The token and the test results are considered pseudonymised, as no linkable identifying information is available to the controller. In order to provide maximum protection and privacy however, they will be treated as though they are sensitive personal data relating to health - and therefore confidential patient information.

Necessity and proportionality

At every stage of development, the intention of the UK government has been to adopt the technical solutions which support efforts to control the spread of COVID-19.

Initially, an app was designed which allowed for both effective contact tracing and provision of additional epidemiological functionality to manage the spread of COVID-19. The focus of this app was on collecting the minimum data necessary.

A new exposure notification framework was developed by Google and Apple however, which supported digital contact tracing through slightly different means. A review was subsequently taken to assess the Google/Apple API against the functionality judged beneficial for managing the spread of COVID-19.

The functionality of the Google/Apple API was assessed alongside rigorous testing of the original app. Testing revealed that reliability of the original app was not sufficient and would therefore not be effective in helping manage the spread of COVID-19.

The government decided that the Google/Apple approach had the highest likelihood of achieving the stated goals, while collecting the minimum data necessary. Following advice from his advisers, the UK Secretary of State for Health and Social Care, announced on 18 June that the government had begun the next phase of development in building a new app that supports the end-to-end NHS Test and Trace service. This app would use the Google/Apple decentralised exposure notification framework to achieve this goal.

The ICO opinion on the Google/Apple API is available

The roadmap for future functionality of this app

Improvements and enhancements within the functionality of the app will be processed through change control, adhere to data subject rights and privacy requirements. This is appropriate as the app responds to the developing public health emergency and receives feedback regarding areas for improvement.

No major changes to functionality are currently expected, however potential app users will be made aware that the app will continue to develop. As new changes emerge, this message will be clearly communicated.

The scope of future functionality will continue to develop. New scope will always be subject to review based upon policy decisions and requirements. Many policy decisions will be for ministers to decide and cannot be pre-empted here. The following areas however are under consideration for future releases:

• improvement of distance calculation (API update). We anticipate that a release in the immediate future will focus on minor issues and accessibility improvements following national roll out
• tailored messaging, branding, logos and use of other languages as appropriate for release in devolved administrations should they choose to adopt the app
• improvement of the medical analytics functionality where possible and appropriate
• refinement of the alert level functionality in relation to multiple postcode district use

The app is part of NHS Test and Trace and will consider the broader roadmap for the whole programme. This will be produced by the programme and made available in future iterations of this document.

Assessment of application of the Privacy and Electronic Communications Regulations 2003 (as amended) (‘PECR’)

We accept that regulation 6 is engaged as regards some portions of the app’s functionality. We will set out in due course what storage of, or access to, information held on the app will be subject to the user’s consent and what will be exempt from consent because it is strictly necessary to the provision of a service requested by the user. We will do so, and will make sure to be compliant with regulation 6, before the national rollout of the app.

Automated decision making and Article 22 (GDPR) requirements

We consider it is arguable as to whether or not Article 22 is engaged by the contact tracing function of the app. On one view, Article 22 might be said to apply where a user comes into contact with someone who has tested positive and so is advised by way of a notification sent via the app to self-isolate and order a test. It is noted that in order for Article 22 to apply, there must be a decision that has a legal or similarly significant effect on an individual that is based solely on automated processing of personal data.

In any event, whether or not Article 22 applies as a matter of law, in order to try and maximise the ICO’s and the public’s confidence in the app, we have decided to take all the relevant steps and implement all the appropriate protections to comply with Article 22 as if it were engaged.

For the purposes of its effective compliance with the requirements of Article 22, DHSC considers that any automated decision making is authorised by law, specifically section 2A of the NHS Act 2006 which permits the Secretary of State to take such steps as he considers appropriate for the purpose of protecting public health. This is the power that the Secretary of State relies on to authorise the design, implementation and operation of the App by DHSC. We have also sought to implement suitable measures to safeguard the data subject’s rights, freedoms and legitimate interests as would be required by Article 22.

Informing the app user

Upon downloading the app, the user will be informed that the app’s contact tracing function includes a type of automated decision making.

Support and advice 111

When a user is receives a notification to the effect that they should self-isolate, they will be able to call NHS 111 to discuss the implications of this advice and their personal circumstances.

This will be particularly helpful, for example, should an individual receive a notification despite the fact that they have not been in direct contact with anyone for an extended period. The user would be able to discuss these circumstances with the NHS 111 operator who might advise that self-isolation and ordering a test is not necessary.

Circuit breaker

The ‘circuit breaker’ is a backend feedback and control service. It enables the app to manage notifications by the app where there are concerns about accuracy or where a significant number of app users may be told to self-isolate.

The circuit breaker kicks in automatically when conditions are met. These conditions are set by human intervention and stop exposure notifications from being sent. Two examples of where this may apply are:

• Concerns over accuracy of testing results or data (referred to as compromised)
• Concerns over venue notification

The functionality will not be utilised in the initial release of the app. A review of the processes and criteria for intervention will be undertaken during this period by the Public Health functions responsible for the intervention

We look forward to continuing to discuss the above with the ICO, and particularly whether any further proportionate additional measures could be implemented for the benefit of App users.

For further context on contact tracing functionality, we set out below how we arrive at the risk threshold for recommending self-isolation.

Risk threshold for isolation

The app uses EN API to measure Bluetooth Low Energy (BLE) signal attenuation— device calibrated received signal strength between transmitting and receiving smartphone devices. The API defines 2 user types: affected users (those that have tested positive) and potentially exposed users (all other app users). The API estimates the duration that a potentially exposed user spends near to an affected user who has been diagnosed with Covid-19, associated with 3 BLE signal attenuation buckets, corresponding to near, medium and far. A high-risk encounter is currently defined as an encounter within 2 metres for more than 15 minutes. If the medical advice were to change, this might be revised.

On notification of a positive test, an affected user shares their diagnosis keys with the server. If a potentially exposed user’s recorded diagnosis keys align with any affected users’ diagnosis keys, then a risk score is computed as a weighted combination of the time spent (in seconds) at each of the BLE signal attenuation buckets. If the calculated risk score is above a chosen threshold, the encounter is considered high risk and triggers the notification to self-isolate.

The identification of the optimum risk threshold takes into account 4 factors:

1. the reproduction number (R): controlling the spread of the disease by minimising false negatives
2. maximising social and economic benefits by minimising false positives
3. testing, and
4. the importance of building public trust in the value of the app

To identify the impact of different risk threshold settings, the team from the Alan Turing Institute used statistical modelling to generate data for 100,000 simulated encounters. In order to calibrate the statistical model, experimental data from Massachusetts Institute of Technology (MIT) was used. MIT have run a series of real-life scenarios conducted in a controlled environment where device signal attenuation and precise distance have been recorded. The statistical model was then used to generate 100,000 known encounters, enabling an understanding of whether the app would categorise these encounters as risky or not.

From this, the modelling compares the numbers of true positives (correctly identified as high risk), true negatives (correctly identified as not at high risk), false positives and false negatives, for different risk thresholds. The model estimates that an even balance of false positive rate and false negative rate are expected with a risk threshold of 1010. This can be seen below, as the crossing point between the false positive rate and false negative rate (red and blue lines, risk threshold on the x-axis).

This is the scientific basis of the automated decision rights. We have also researched the approaches being taken by Denmark, Italy, Germany Switzerland, Ireland and Northern Ireland, where a difference can be observed in aligning to likelihood of more false positives or more false negatives.

Use of the app by children

The app is currently only for use by those aged 18+. We will engage widely if any changes are made.

Retention of data from the app

Diagnosis keys are retained on the user’s phone for 14 days and are then deleted (14 days is the incubation period for the virus). Submitted diagnosis keys are retained on the DHSC secure computing infrastructure for 14 days and then deleted. So, the maximum age of a diagnosis key that has been distributed to DHSC secure computing infrastructure is 28 days.

QR codes that are scanned by the user when visiting venues are automatically deleted after 21 days. This is to take into account the 14-day incubation period, and 7-day infectious period of the virus.

The retention period for analytics data is subject to confirmation. As the data are is anonymous, GDPR Article 5(e) which requires that personal data is kept in identifiable form for no longer than is necessary, is not engaged.

Retention of data sets outside of Data Protection Legislation

Data submitted by app users will not contain direct, indirect or consistent identifiers meaning that retention should not be considered in the context of GDPR. However, retention of data sets and records needs to be set even where it does not constituent personal data. This applies to the analytical data noted above.

Retention of records associated with the app are likely to fall into 2 categories, records which are used to:

• hold organisations to account is held for 8 years;
• monitor communicable diseases, for example in the COVID-19 Public Health Emergency, are retained for 5 years (if they contain personal data which is not the case in this instance) and 20 years for anonymous data prior to any review

Retention for these records is governed by the relevant Section 46 Code of Practice, Public Records Act and statutory duties of the organisations accountable (the Department of Health and Social Care).

Subjects’ rights

Data held on DHSC secure computing infrastructure

As described in the section above, the personal data processed on DHSC secure computing infrastructure (i.e. the test code and test result) does not enable identification of a data subject by the controller. In order to respond to a subjects’ rights request DHSC would need to associate additional information with the data held. This would undermine the privacy controls that we have incorporated.

Under GDPR Article 11(1) a controller is not obliged to maintain, acquire or process additional information for the sole purpose of complying with the Regulation – e.g. responding to subjects’ rights requests. On this basis we will respond to requests made in relation to data held on DHSC secure computing infrastructure that we are unable to provide the information as the exemption in Article 11(1) applies.

Data held on the phone

Subject access and right to erasure

We have discussed in previous versions of the app the importance for individuals to exercise their rights, specifically the right to access the information held about them. For the initial launch this will contain postcode district, last test results, reported symptoms date and venue history.

To access this information, the user selects the ‘About contact tracing’ menu item, then in the ‘Your data’ section selects ‘Manage data’. From here all data held is displayed. At the bottom, the red text ‘Delete all my data’ can be selected. There is a prompt to check this action on the next screen.

This user flow is displayed below. These screens may slightly differ from those actually within the app.

Users may also uninstall the app at any time, at which time all the data held on the phone is erased. Should the user have submitted diagnosis keys these will be deleted from the DHSC secure computing infrastructure database within 14 days as a matter of routine.

Subjects’ rights - summary

How will you action requests from individuals (or someone acting on their behalf) for access to their personal information?

Subject access requests will be facilitated by a feature of the app to present personal data held in the App on the phone. This will include: the post district you have entered, the venues you have captured via the check in, and your most recent test result.

We are working towards all data on the app being viewable for the user.

No personal data can be retrieved from the DHSC secure computing infrastructure database. As above, this is only the test code and result, and the exemption in Article 11(1) is engaged.

How would you locate all personal data relevant to an individual?

All personal data that can be provided to app users will be on their phones

What is the procedure for this system to responding to data subject’s request to be forgotten – Article 17

Users can delete the personal data associated with the venues they have checked into and their most recent test result. They may also uninstall the App from their phone at any time which will cause deletion of all personal data from the device.

This will not cascade to the DHSC secure computing infrastructure database the diagnosis keys are deleted after 14 days automatically. However, diagnosis keys away from the user’s phone are not considered personal data

Article 16 – Right to rectification

Not available – controller does not have access to the personal data on the phone. If a user disagrees with a test result, they will need to contact the test provider.

Article 18 – Right to restriction of processing

Not available – controller does not have access to personal data on the phone.

Article 19 – Notification obligation regarding rectification or erasure of personal data or restriction of processing

Not available – controller does not have access to personal data on the phone.

Article 20 – Right to data portability

This right is not available because the processing is not based on consent pursuant to Article 6(1)(a) or Article 9(2)(a); or on a contract pursuant to Art. 6(1)(b).

Article 21 – Right to object

Available by uninstalling app.

Article 22 – Automated individual decision-making including profiling

See discussion above.

Human rights

Human rights are a key consideration for an app that may involve millions of users and the management of the COVID-19 Public Health emergency. However, the advice to app users are not enforced by the app and are set by broader Public Health Policy. A human rights review has been carried out by the programme and is summarised here.

Whilst the ECHR and HRA does not enshrine rights as absolute, especially in the context of a public health emergency and pandemic, the app continues to uphold those rights and where possible support them in the context of COVID-19.

Rights that have been considered include:

• ECHR Article 8 – respect for private and family life
• ECHR Article 5 – right to liberty
• ECHR Article 2 – right to life
• ECHR Article 11 – right to freedom of association
• ECHR Article 9 – right to freedom of religion
• ECHR Article 14 – prohibition of discrimination

Workstreams to support human rights obligations and agenda include:

• Policy, strategy and communication work streams that directly address, consider or contribute
• The equalities and health inequalities work, related to the DHSC legal duties under the relevant statutes and various policies

Public health purposes and value of the app

The app is intended to influence the behaviours of a proportion of the public sufficient to alter the trajectory of the COVID-19 outbreak. By providing alerts and monitoring app users’ proximity to those who present a risk of infection or may be at risk of infection this is intended to alter the behaviour of a proportion of those groups.

The app will give citizens maximum freedom with minimal risk during a public health emergency by:

• Driving safer behaviour by helping people manage their risk exposure
• Identifying and alerting known and unknown contacts when transmission may have occurred
• Enabling users to isolate and test to reduce transmission
• Supporting and informing users during isolation
• Creating an enduring new medical technology to manage public health emergencies

In doing so, it will contribute to the objective of the Test and Trace programme: breaking the chains of transmission by minimising the frequency and extent of the COVID-19 outbreaks, to enable society to return to a more normal way of life.

The app will also provide information to support the tactical and strategic management of the COVID response. These secondary purposes are described in this DPIA in outline.

Overview of the functionality of the NHS Test and Trace App

Each of these features is summarised below, including overall description, pointer to the appropriate user journey in the relevant annex, summary of data flows, list of requirements gathered which determined this feature.

User flow diagrams for each of these features can be found in annexes 1 to 6 of the data protection impact assessment.

Personal contact risk score (risk score) – Not within initial release

The app will provide a visual of where on the risk spectrum the user sits; this will be either unknown, low, or high risk. The user’s risk level will be based on the number of encounters traced by the app over a configurable amount of time and will be updated every hour. This feature will be a fast follower post the initial launch. The DPIA will be updated to reflect this.

Real-time high-risk postcode matches (alert)

The app will give users the ability to view the current risk level in the local authority they live in based on the Postcode district entered during the registration process. It will also alert them to any changes in this and provide advice on what users should do next to get further information and guidance.

Risk levels and alerts will be sourced from the Local Authority Watchlist determined each week by the Secretary of State for Health and Care drawing on epidemiological advice from the CMO, NHS Test and Trace, JBC and Public Health England. Published on a weekly basis, it identifies Local Authorities of greatest concern across the country.

The watchlist is produced by first considering the lower tier local authorities with the highest weekly incidence rate and its trend, combined with a range of other indicators including the test positivity rate, an assessment of the local response and plans, and the trend of other metrics such as healthcare activity and mortality. The classification decision is therefore a blended assessment drawing on professional judgement. It contains three levels of classification based on the following definitions:

• Area(s) of concern—for areas with the highest prevalence, where the local area is taking targeted actions to reduce prevalence e.g. additional testing in care homes and increased community engagement with high risk groups
• Area(s) for enhanced support—for areas at medium/high risk of intervention where there is a more detailed plan, agreed with the national team and with additional resources being provided to support the local team (e.g. epidemiological expertise, additional mobile testing capacity)
• Area(s) of national intervention—where there is divergence from the measures in place in the rest of England because of the significance of the spread, with a detailed action plan in place, and local resources augmented with a national support

These classifications will be mapped to ‘High’ and ‘Medium’ risk indicators displayed in the app. Local Authorities not featured in the watchlist will be deemed ‘low’ risk by default. To determine local risk levels and generate alerts, the app will match the postcode district users enter on registering for the app to the local authority in which that district resides.

There are 343 local authorities in England, so the risk of identifying specific individuals from assessments formed at this level is extremely low.

Where a postcode district maps to more than one local authority the app will show the status of the local authority with the highest assessed risk. We are also working with the ONS to develop a one-to-one mapping of postcode districts to local authorities based on population weightings, but this may not be in place for the initial MVP launch.

The user journey flow for this feature can be found in relevant annex – alert user journey

App feature	What data does the user enter to use this feature?	Where does the data go/ is the data stored?	Does the app do anything automatically with the users’ data?	What data does the app receive?	Can the user opt out of this feature?	Level of risk to personal data
Alert	Their postcode district of residence (= first section of post code)	The app will send the risk score for each district to all phones	The app automatically rechecks the risk score for the stored postcode district to identify updates	The risk score for all postcode districts	The user can avoid seeing the risk score for their area by deleting the app.	Low

The data flows relating to the Alert feature are summarised in the diagram below:

Summary of requirements which led to this feature:

• There must be an alert if the user’s postcode district is no longer risky.
• The app must store the postcode district locally in an encrypted way to ensure of the user’s privacy.
• The current risk level for the user’s postcode district must be shown on the home screen.
• The app must check the user’s stored postcode district against a provided cluster of known high-risk postcode districts in order to determine the current risk level for the user’s postcode district.
• The user must be notified if the risk level for the postcode district stored in the app changes.
• The user must be able to enter the postcode district (first 2-4 characters of postcode) in the onboarding journey of the app. This step is mandatory.

Digital check-in diary (venue check-in)

Users will be able to ‘check in’ to a venue via the app. The user must have the NHS Test and Trace app installed (they cannot use native, or other, QR apps for this feature).

Venues across a wide range of settings will be encouraged to support this capability, including workplaces, restaurants, pubs, leisure facilities and anywhere else where groups of people are likely to gather. If any of these venues are later confirmed as the source of a COVID-19 outbreak, users who visited them during a specified period time will receive an alert from the app advising them of this and what they should do next. Discussions are currently underway with PHE to agree the content and form of this advice.

The app will give users the ability to collate a ‘Digital Diary’ of locations they have been to over the last 21 days stored locally on their device. Users will create this via the QR code feature to ‘check-in’ to venues they visit and record the date and time they arrived. They will also have the ability to delete this data.

The app and its venue check-in and alert capability will align with the following high-level summary of the process for identifying, confirming & responding to local outbreaks:

• Local Health Protection teams (HPT) are responsible for identifying and planning an appropriate response to COVID-19 outbreaks (2 or more cases in the same place) in their region
• To do this they receive data from manual contact tracing, local sources and, over time, the JBC to identify potential outbreaks
• Health Protection Teams (HPTs) then investigate/follow up with an on the ground investigation to form an assessment of whether it should be confirmed as an outbreak and active measures put in place to contain it (e.g. testing anyone known to have visited the venue on a particular day/time)
• HPTs record details of outbreaks in the HPZone web application. Details are then shared with JBC and the Joint Situational Awareness Team (JSAT) on a daily basis
• JSAT collate inputs from all nine regions into a national overview to monitor where outbreaks are taking place and the overall scale/severity. This helps prioritise national and regional resources in response to it (e.g. the deployment of enhanced testing capacity)
• Details of these outbreaks (QR code, date and time window) will then be entered into the app system. It will broadcast a message to each instance of the app that triggers an alert for any app users who had been to that venue during a specific timeframe and could therefore have been at risk of exposure

Details of where a user has checked-in to are recorded securely on the device and are not shared with the App backend system or database. Data from this service cannot, therefore, be used to either track movement over time or re-identify the user. This data can also be deleted by the user.

The user journey flow for this feature can be found in the relevant annex – check in user journey

App feature	What data does the user enter to use this feature?	Where does the data go/ is the data stored?	Does the app do anything automatically with the users’ data?	What data does the app receive?	Can the user opt out of this feature?	Level of risk to personal data
Check-In	The user scans QR codes of venues visited.	The phone retains the QR codes visited and when they were visited for 21 days	No. The data of where the user has been stays on the phone. The user may choose to use it as an aide memoir when talking to a human contact tracer.	List of QR codes with date and time for impacted venues.	The user can simply not check in to any venues.	Low

The data flows relating to the check-in feature are summarised in the diagram below:

Summary of requirements which led to this feature:

• To be compliant with Apple’s terms and conditions the scanned venues must be automatically and permanently deleted from the device after a maximum of 28 days.
• To be compliant with Apple’s terms and conditions a readable list of captured venues must be readily visible to the user within the app.
• To be compliant with Apple’s terms and conditions and for privacy reasons, all records of venue check-in activities are kept exclusively on the device.
• The venue name, ID and rounded check-in and check-out time must be shown in the venue history in “my data”.
• The venue name and exact check-in time must be shown in the check-in confirmation.
• The app must store the following information: venue ID, venue name, timestamp of check-in (rounded down to last completed quarter), timestamp of check-out (rounded up to next completed quarter).
• It must be possible to suppress alerts about infected venues by a “circuit breaker” on the backend.
• There should be an option to cancel a check-in to cover the case that the user accidentally scans a wrong QR code (e.g. fake poster).
• The number of days the venue code is stored must be configurable.
• The app must provide automatic check-out options for visited venues. In v3/MVP check-out happens automatically at midnight or when there is a check-in to another venue.
• The user must be notified in case of a visited venue reporting high infection risk.
• The app must regularly check the stored user’s venue codes for high-risk venues.
• The app must securely store the scanned QR codes for a time configurable by the backend. The initial value is 21 days.
• The user must be asked to grant permission to use camera for QR-code scan.
• The app must enable QR code scanning from within the app and also when offline since connectivity might be limited at some venues.

Symptoms questionnaire (symptoms)

The app will allow the user to report the symptoms they are suffering with and the date of when they started. Based on which of the symptoms they have selected from a list, the user will receive an initial indication as to whether they may have coronavirus. If the user’s symptoms indicate they may have coronavirus, they will be asked to self-isolate and book a test.

The symptomatic questions are provided to the app team by the Chief Medical Officer (CMO) based on current epidemiological guidance. The questions and advice are captured in a version-controlled file on the DHSC secure computing infrastructure. As needed symptoms will be updated by the CMO. To capture the latest information, the questionnaire file is periodically synchronised from the back-end servers to make sure users are displayed the latest questions and advice.

For launch the current questionnaire includes the following symptoms: a high temperature (fever), a new continuous cough, a new loss or change to your sense of smell or taste, a runny nose, sneezing, feeling feverish, diarrhoea, nausea, vomiting, loss of appetite.

The user journey flow for this feature can be found in the relevant annex – symptoms checker user journey

App Feature	What data does the user enter to use this feature?	Where does the data go/ is the data stored?	Does the app do anything automatically with the users’ data?	What data does the app receive?	Can the user opt out of this feature?	Level of risk to personal data
Symptoms	User selects boxes relating to symptoms they have	Anonymised data on symptoms is retained for epidemiological purposes	No. The user actively chooses to submit their symptoms.	The app receives/holds the algorithm identifying if the symptoms checked according with COVID-19 risk	The user can avoid reporting any symptoms if they wish.	Low

Summary of symptoms checker requirements which led to this feature:

• If an index case reports symptoms and is asked to isolate, the system should block the symptoms report for the isolation period. (This does not apply to contact cases).
• The algorithm evaluating the reported symptoms must be executed on the device in order to minimise the amount of data exchanged between the app and backend, and to ensure the backend is not considered a medical device.
• The user needs to give their consent every time any data reported on the symptoms report questionnaire is uploaded to the backend.
• The result of the questionnaire must be determined using a fixed algorithm.
• The symptoms report questionnaire must be configurable without the user having to update the app in order to quickly adapt to changes in policy.
• The default date for the symptoms onset in case users don’t remember the date must be configurable as policy may change.
• The symptoms report questionnaire must contain a date for the onset of (all) symptoms in order to determine the remaining self-isolation period for the index case and to determine which contacts need to receive an exposure notification.
• The user must be able to quickly fill out the symptoms report questionnaire in order to increase the number of entries. It should therefore fit on a single page.

Coronavirus test (test)

A symptomatic app user will be invited to click a link from the iOS and Android applications to launch the testing service. Clicking the link within the app launches an external mobile browser and loads a page within the test registration journey with a unique app reference code (CTA token) passed as a query string parameter in the URL.

An example of this URL is below, where xxxx-xxxx is replaced by the unique CTA token.

https://self-referral.test-for-coronavirus.service.gov.uk/antigen/name?ctaToken=xxxx-xxxx

Once the user has been taken to the testing website, they will follow exactly the same journey as users who visit the testing website via a different platform (e.g. computer browser), but the CTA token that was passed to the website will be associated with the test booking. The information captured during the standard test registration journey (such as name, date of birth, phone number, address etc.), will be stored in the relevant testing informatics technology system (NPEx,), which is held separately to the app, along with the user’s CTA token. The user will then take their test at a test centre or at home, and the test kit will be sent to a laboratory for processing. The CTA token is not sent to the test lab. The completed lab result (positive, negative or void), will then be sent to NPEx and re-associated with the app user’s details.

If the test result received by NPEx is for a user who has a CTA token associated with their test record, then a three-field JSON file will be sent to the mobile application back end. The three fields are included in each file sent – the CTA token, the test result (positive, negative, void) and the hour range in which a test result was received.

The mobile application will poll the app back end to confirm whether a test result has been received. Once a result is received, it will notify the user whether they have a positive, negative or void test result. If the result is positive, then proximity contacts will be notified.

The user journey flow for this feature can be found in Annex 1 – risk score user journey

App feature	What data does the user enter to use this feature?	Where does the data go/ is the data stored?	Does the app do anything automatically with the users’ data?	What data does the app receive?	Can the user opt out of this feature?	Level of risk to personal data
Test	The user clicks through to a website to order a test. The necessary data (e.g. address) is not entered into the app. The link that a user opens contains an 8-digit unique alpha-numeric code (“CTA Token”) that the test system needs, in order to associate the user’s app and test kit.	The test and trace programme retain the user’s data long enough to associate the test taker with their result. Once the test result has been conveyed to the person, this data is deleted.	The ‘early adopters’ phase requires that the app reference code be passed to the test booking system. A user will not have the ability to edit this code during the booking process. An app user can still book a test via alternative channels if they do not wish for the app to be associated with a test kit.	If a user has started their test registration journey from the app, the mobile application will receive data that indicates whether a user has received a positive, negative or void test result.	If the user starts their test journey via the app, it will not be possible to opt out of the feature. However, a user can bypass this feature by visiting the test registration via a different channel.	Low

The data flows relating to the test feature are summarised in the diagram below:

In addition to the overall data flow, the following is provided on how tokens will be generated, managed and secured. As per the diagram there are three tokens. All 3 are generated by the cloud service when an app user is recommended a virology test. The Lambda nodes refer to code that presents the respective APIs – listed above.

This includes the diagnosis key submission token, the test result polling token and the CTA token. Three tokens are employed as a security measure so that we do not use the same identifier in multiple locations.

The CTA token is the human readable random code that is displayed to a user and passed to the virology test system.

The test result polling token is the token used by the app to ask the DHSC secure computing infrastructure if the test result has been received yet.

The diagnosis key submission token is used by the app when a user is confirmed to be positive via test and consents to sharing their keys, so that the DHSC secure computing infrastructure can be sure the keys do relate to a confirmed positive case.

The diagnosis key submission token is used by the app when a user is confirmed to be positive via test and consents to sharing their keys, so that the DHSC secure computing infrastructure can be sure the keys do relate to a confirmed positive case.

Summary of test ordering requirements which led to this feature:

• The app generates a token whenever the user clicks on “book a test”. This token temporarily links the user’s test result to the app and thereby allows the result to be reported back to the app without entering personal details in the app.
• The user must be asked for consent before uploading the diagnosis keys stored on the user’s phone. The request for consent is triggered after the user has seen the positive virology test result in the app. In order to avoid turning the app into IVD, it must not be the primary source for reporting the virology test result to the user.
• For v3/MVP the app must ensure automatic result retrieval and user notification of the virology test results for all test options connected to MPEX.
• The app must send a token to the virology testing website (in the background) when the user navigates to the website from the app.
• The app must allow the order of a test kit and will do this by providing a link to the virology testing homepage from within the app. In v3/MVP this is only provided to users who have reported symptoms in the app and are still in self-isolation.

The diagnosis key submission token is used by the app when a user is confirmed to be positive via test and consents to sharing their keys, so that the DHSC secure computing infrastructure can be sure the keys do relate to a confirmed positive case.

Self-isolation countdown (isolate)

The app will ask the user to self-isolate either because the user has reported symptoms indicative of coronavirus (the index case), or they have received an exposure notification (the contact case). Once asked to self-isolate, the user will have access to a self-isolation countdown which keeps a track of the time they need to spend self-isolating.

The data flows relating to the Isolation feature do not leave the phone. The date that a user tells us they are experiencing COVID-19 symptoms is stored on the phone and used to drive the timing of the advice given. The isolation timing is configurable in a similar mechanism to the symptomatic questionnaire. The only data that is communicated to the back-end services in relation to the isolate feature is an analytics statistic to understand how many app users are currently self-isolating.

The user journey flow for this feature can be found in the relevant annex – isolate user journey

App Feature	What data does the user enter to use this feature?	Where does the data go/ is the data stored?	Does the app do anything automatically with the users’ data?	What data does the app receive?	Can the user opt out of this feature?	Level of risk to personal data
Isolate	The user enters symptoms or a test result (see features above)	The app retains the date when a symptom entry was made so as to be able to offer a countdown until isolation ends.	If the user enters symptoms that accord with COVID-19 the app will automatically advise them to isolate. They may discuss this advice with NHS 111	This feature uses data entered into other features (see above)	Having entered positive symptoms, the isolate countdown will be automatically activated. The user could avoid this by deleting the app.	Low

Summary of self-isolation advice requirements which led to this feature

• If multiple test results come through in sequence for a given user, the first negative/positive test result will remove the user from being an index case/a contact case. The user will not be sent back to self-isolation based on later contradicting results.
• If multiple test results come through at the same time for a given user, only the most recent will be acted upon.
• The app must provide the user with information about the remaining self-isolation duration in days. In v3/MVP receiving new encounter notifications must not restart the self-isolation period if the user is already in self-isolation.
• The app must regularly check and compare the self-isolation period with the newest configurations based on policies.
• The app must alert the user if the remaining self-isolation period has changed or expired.
• The app must use a defined algorithm to determine the self-isolation duration depending on the type and date of the isolation trigger.
• Users can be a contact and index case at the same time. During that time the longer self-isolation period is displayed. The self-isolation countdown may therefore be adapted when a test result arrives.
• A contact case must not be released from self-isolation by a negative test.
• The durations of self-isolation for different cases must be configurable by the backend based on policy changes.
• The maximum duration for self-isolation must be configurable by the backend.
• The app must provide 3 triggers to stop self-isolation: Negative test result (index case only), isolation completed, isolation exceeded maximum duration.
• The app must provide 2 triggers for starting self-isolation: Reported Symptoms (index case), and Exposure Notification (contact case).

Functionality to pause the app exists whereby the Bluetooth-based contact detection can be temporary disabled. No contacts will be made or recorded during the time that the pause is in effect. Users are provided with a clear visual indication on the home screen to indicate that contact detection is disabled.

The ability to pause the app is provided to ensure that users who are in engaged in close proximity activities and have taken appropriate measures (such as a barber who is wearing a PPE face mask) can prevent erroneous exposure notifications.

No interaction with the backend services is involved in this feature. Time idle during periods of pause is recorded by the app and submitted as part of the anonymous analytics data. This ensures that appropriate use of this feature can be assessed in aggregate.

These screens may slightly differ from those actually within the app:

Data protection impact assessment screening questions

Documenting which of the screening questions are applicable to your initiative will help to draw out the particular privacy considerations that will help formulate your risk register later in the template. This will also assist in ensuring that the Department’s investment will be proportionate to the risks involved:

Ref	Question	Yes	No	Unsure	Comments
I	Is the information about individuals likely to raise privacy concerns or expectations e.g. health records or other information people would consider particularly private?	x	-	-	In the absence of proper controls, and transparency about how the App functions and how the data collected is used, the deployment of the App could give rise to privacy concerns.
Ii	Will the initiative involve the collection of new information about individuals?	x	-	-	-
Iii	Are you using information about individuals for a purpose it is not currently used for, or in a way it is not currently used?	x	-	-	-
Iv	Will the initiative require you to contact individuals in ways which they may find intrusive?	-	x	-	-
v	Will information about individuals be disclosed to organisations or people who have not previously had routine access to the information?	-	x	-	-
vi	Does the initiative involve using new technology which might be perceived as being privacy intrusive e.g. biometrics or facial recognition?	x	-	-	Whilst the Bluetooth technology underpinning the proximity recording is not new technology, the use of the technology for this purpose in the context of a large-scale pandemic response is new.
vii	Will the initiative result in making decisions or taking action against individuals in ways which can have a significant impact on them?	-	x	-	No

Section 1: Background Information

Asset/Project Name

Organisation: Department of Health and Social Care

Assessment completed by: NHSX IG Policy Team

Name of IT BP: Sam Cremins/Tracy Strathie

DPO: Lee Cramp

Email: data_protection@dhsc.gov.uk

Section 2: Purposes

Project/Change Outline – Provide a description that provides an outside party with a good understanding of what the initiative is about.

The introduction at the start of this document provides a fuller description of the app.

The NHS Test and Trace App is a mobile phone application that is part of the NHS Test and Trace service. It is designed to reduce personal and public risk by providing support for:

• COVID-19 symptom identification and monitoring
• alerting users if they have been in contact with someone who has tested positive for COVID-19 or been to a high-risk location or area
• responding to the public health emergency

Aims/Objectives - Why is it being undertaken? What is the purpose of processing the personal information? What do you want to achieve?

The app will give citizens maximum freedom with minimal risk during a public health emergency by:

• driving safer behaviour by helping people manage their risk exposure
• identifying and alerting known and unknown contacts when transmission may have occurred
• enabling users to isolate and test to reduce transmission
• supporting and informing users during isolation

From the user’s perspective, the app will help them take action to break the chains of transmission. Users will need to:

• download the app and use it daily
• keep the app ‘on’ and carry their phone at all times
• follow instructions issued by the app
• ‘pause’ the app when appropriate
• enter symptoms and take a test quickly when required

To achieve the above the detailed primary and secondary purposes of the app are as follows:

Primary purposes

The primary purposes of the app are:

• to facilitate self-symptom analysis for COVID-19
• to enable users to order tests and receiving test results
• to alert users when they have come into proximity with someone who has been tested positive for COVID-19
• to alert users when they have visited a venue that has subsequently been found to have been infected with COVID-19

These purposes are achieved by 2 key components:

• instances of the app downloaded and installed on users’ mobile phones
• A DHSC secure computing infrastructure, hosted on Microsoft Azure Cloud Services (UK) supporting the app, which includes a database holding exposure notification diagnosis keys

These components function as follows:

The instance of the app installed on a user’s phone

a) Collects postcode district and device type on installation and reports these to the Cloud Services database

b) Initiates the Apple-Google Exposure Notification API to record proximity encounters between users of the App on their respective devices, using Bluetooth technology

c) Gives users a risk score for their area

d) Provides a facility for users to check their symptoms and get advice on what to do

e) Provides a facility of users to submit their Diagnosis Keys to the Cloud Services database should they be tested positive for COVID 19

f) Receives Diagnosis Keys from the Cloud Services database form users that have submitted them on positive diagnosis for COVID-19

g) Interacts with the EN API to establish whether an exposure event with an infected user has taken place and alerts the user should this be the case with advice on what to do

h) Provides a facility for users to scan QR codes for venues they visit

i) Obtains QR codes for infected venues, matches them to those visited and alerts them if a match with advice on what to do

j) Provides a facility for users to request a one-time use token which they can use to order a test for COVID-19

k) Receives the result of the test through the App from the Cloud Services database and reports this to the user (results can also be obtained through text/email to the user)

l) Reports and anonymous analytics data set to the Cloud Services database.

DHSC secure computing infrastructure

a) Receives Diagnosis Keys submitted by users that have tested positive for COVID-19

b) Distributes these keys to all users’ apps

c) Receives and distributes the QR codes for infected venues

d) Issues a unique one-time use token which users can use to order a test for COVID-19

e) Receives the results of tests ordered from swab testing systems using the one-time use token

f) Reports test results back the app on request using the token

g) Collects analytics data on a daily basis

See this document’s appendices for the data dictionary, APIs presented by Cloud Services and Operational Stages.

Secondary purposes

Performance and usage

The DHSC secure computing infrastructure database holds the anonymous analytics dataset specified in the Data Dictionary – see this document’s introduction and appendices.

We are establishing a separate App Analytical Environment. This will involve processing of anonymous analytics data transferred from the DHSC secure computing infrastructure database to a separate database.

The data protection impact assessment for the initial NHS COVID-19 app helped shape and inform this DPIA.

Section 3: The data involved

Information that identifies the individual and their personal characteristics

There must be justification for processing a particular dataset.

Postcode (postcode district)

Justification: Postcode district (the first digits up to the space) is needed to show users the COVID-19 risk level in their local area

Medical / health / genetic information

Justification: Self-reported information indicating that a user has symptoms indicating that they may have coronavirus (these reside temporarily on the local app before submission in anonymous form to DHSC secure computing infrastructure). Test results received into the DHSC secure computing infrastructure database and local app. Data indicating that a user has been in proximity with another user that has reported COVID-19 symptoms.

The submission of diagnosis keys to the DHSC secure computing infrastructure indicates positive COVID-19 diagnosis – but is not considered personal data.

Unique identifying codes

Justification: Cryptographic keys (diagnosis keys/rolling proximity identifiers) with no link to user identity (direct identifiers) held by the controller.

Sensitive/special category of information

Information relating to the individual’s physical or mental health condition

Justification: Self-reported information indicating that a user has symptoms indicating that they may have coronavirus (these reside temporarily on the local App before submission in anonymous form to DHSC secure computing infrastructure). Test results received into the DHSC secure computing infrastructure database and local app. The submission of diagnosis keys to the DHSC secure computing infrastructure indicates positive COVID-19 diagnosis – but is not considered personal data.

Section 4: Overview of processing, necessity and proportionality

Why is the processing of personal data necessary?

The functionality of the app and nature of the data are explained in the introduction of this document.

Research and public health management

Users are asked to provide their postcode district – that is, the first portion (up to the space) of the users’ home address postcode (e.g. SW1A) when they initially install the app. The app will not collect data about which postcode district a user might be in from time to time as they move around.

The postcode district data will primarily be used for alert notifications to users, but may also be used for public health planning purposes, in conjunction with reported diagnoses and proximity information (for example, to help Local Government and NHS organisations to understand the spread of the disease in their area), and may also be used for research purposes. Such research will not have impact on individuals and would address GDPR requirements in relation to research e.g. the safeguards set out in Article 89.

Section 5: the organisations involved and their roles

Are other organisations involved in processing personal data? If yes, please complete the table below.

Name	Please state whether they’re a data controller (DC) or a data processor (DP)
Amazon Web Services	Processor (Hosting of Cloud Services)
The Health Informatics Services (THIS) hosted by Calderdale and Huddersfield NHS Foundation Trust (CHFT) utilising the NPEx	Processor (Provision of test code with result)

Has a data flow mapping exercise completed? See appendix 3

Does the project involve employing contractors external to the organisation? Yes

Data processors – Amazon Web Services: Cloud hosting services, hosting for Cloud Services database

How is the information collected by this organisation? Electronic

Where will the information be stored? (including country location of data storage/back up) Amazon Web Services – cloud hosting servers located in EEA.

How will the information be kept up to date? Local instances of the App (user mobiles) interacting with the app; Communication of test results from National Pathology Exchange. AWS have no direct interaction with the data.

Which team(s) and roles have access to the information within this organisation? N/A – hosting only

What security measures are in place to protect this information from unauthorised use?

Security measures set out in the AWS GDPR Data Processing Addendum.

5) Security of Data Processing

5.1) AWS has implemented and will maintain the technical and organisational measures for the AWS Network as described in the AWS Security Standards and this section. In particular, AWS has implemented and will maintain the following technical and organisational measures:

(a) security of the AWS Network as set out in Section 1.1 of the AWS Security Standards; (b) physical security of the facilities as set out in Section 1.2 of the AWS Security Standards; (c) measures to control access rights for AWS employees and contractors in relation to the AWS Network as set out in Section 1.1 of the AWS Security Standards; and (d) processes for regularly testing, assessing and evaluating the effectiveness of the technical and organisational measures implemented by AWS as described in Section 2 of the AWS Security Standards.

10) AWS Certifications and Audits

10) AWS ISO-Certification and SOC Reports. In addition to the information contained in this DPA, upon Customer’s request, and provided that the parties have an applicable NDA in place, AWS will make available the following documents and information:

(i) certificates issued in relation to the ISO 27001 certification, the ISO 27017 certification and the ISO 27018 certification (or the certifications or other documentation evidencing compliance with such alternative standards as are substantially equivalent to ISO 27001, ISO 27017 and ISO 27018); and

(ii) the System and Organization Controls (SOC) 1 Report, the System and Organization Controls (SOC) 2 Report and the System and Organization Controls (SOC) 3 Report (or the reports or other documentation describing the controls

AWS GDPR Data Processing Addendum 5 implemented by AWS that replace or are substantially equivalent to the SOC 1, SOC 2 and SOC 3).

Is there a Data Sharing Agreement/protocol/data processing agreement in place? Yes – the AWS GDPR Data Processing Addendum

Data Processor – The Health Informatics Services (THIS) hosted by Calderdale and Huddersfield NHS Foundation Trust (CHFT) utilising the NPEx: processor (Provision of test code with test result)

How is the information collected by this organisation?

Data is provided through the testing process, with the data subject (the user undergoing test) informed of the process. They have a choice to use the app generated test code or not. The test code and result are taken from the testing process and provided via NPEx to the App central system.

Where will the information be stored? (including country location of data storage/back up)

Calderdale and Huddersfield NHS Foundation Trust (CHFT) systems, based in the UK

How will the information be kept up to date?

Long standing systems and processes meeting Lab quality standards for accuracy and currency subject to UKAS oversight and ISO15189 compliance.

Which team(s) and roles have access to the information within this organisation?

Test Result Database and system (NPEx) support team.

What security measures are in place to protect this information from unauthorised use?

The system and service are subject to the standard expectations on an NHS organisation for processing personal data. This is measured through audit, testing and the Data Security and Protection Toolkit

Is there a Data Sharing Agreement/protocol/data processing agreement in place (as applicable)?

The NPEx service provided by THIS is subject to the standard contracts conditions of an NHS Foundation Trust supplemented by the requirements of the lab information systems.

Note on Apple and Google

Apple and Google are considered independent data controllers or controllers for the services which support the app. Any processing they undertake is distinct to processing of personal and other data by the app.

Section 6: assessment

Data protection principle: lawfulness, fairness and transparency

Question	Response
What is the legal basis for processing the information? (see appendix 3 & 4 for legal grounds for processing)	6(1)(e) “…exercise of official authority…” Underpinned by common law powers For special categories: 9(2)(h) “…necessary for the management of health or social care systems and services…” Underpinned by DPA 2018 – Schedule 1, Part 1, s. 2(2)(f) – Health or social care purposes This condition applies because it is necessary to process the personal data for symptom checking and test management as this is an essential process in delivering care to App users. 9(2)(i) “…necessary for reasons of public interest in the area of public health…” Underpinned by DPA 2018 – Schedule 1, Part 1, s. 3 – Public health 3 This condition is met if the processing— (a) is necessary for reasons of public interest in the area of public health, and (b) is carried out— (i) by or under the responsibility of a health professional, or (ii) by another person who in the circumstances owes a duty of confidentiality under an enactment or rule of law. This condition applies because the objectives of the App include public health planning. See the section on ‘confidential patient information’ and table above.
Is the processing of an individual’s information likely to interfere with the ‘right to privacy’ under Article 8 of the Human Rights Act?	No. Although DHSC could invoke the exception in Article 8(2) “…where necessary in a democratic society…for the protection of health…” the decentralised approach built on the Apple/Google API achieves its objectives without the necessity to interfere with this right.
How and when are data subjects made aware of how their data will be used? E.g. Privacy statement	App users will receive a privacy notice via the App, that explains what information will be collected, how it will be used, the rights available to them, and sources of further information.
If you are relying on consent to process personal data, how will consent be obtained and recorded, what information will be provided to support the consent process?	Not applicable.
Do we inform individuals about the use of cookies and other tracking technologies	Cookies or other tracking technologies are not used by the App.
Do you receive information about individuals from third parties?	Yes – the DHSC secure computing infrastructure database will receive test results with temporary identifying token from the NPEX (National Pathology Exchange) system.

Data protection principle: purpose

Question	Response
Does the initiative involve the use of existing personal data for new purposes?	No
Are potential new purposes likely to be identified as the scope of the initiative expands?	Yes – these would only be related to the response to the COVID-19 emergency, efficacy of the App and services that users interact with. Any change to processing of personal data would require revision to this DPIA. As the Analytics data collected as a by-product of the operation of the App is anonymous, any new purposes for this data are unlikely to raise privacy concerns.
Are we consolidating and linking files and systems and if so how?	No.
Are we changing the technology we use and if so, how are we mitigating the privacy affects?	No – this is a new implementation built on the Google Apple API. Any future changes would be subject to revision to this DPIA.

Data protection principle: automated decision making

Question	Response
Will the processing result in a decision being made about the data subject solely on the basis of automated processing (including profiling)?	See the section on automated decision making
If yes, is the decision necessary for entering into, or performance of, a contract between the data subject and a data controller? Or authorised by law based on the data subject’s explicit consent?	No. See the relevant section.
Please describe the logic involved in any automated decision-making.	The design of the App’s contact tracing function means that App users will be notified automatically if they come into sufficient contact with someone who has tested positive for coronavirus. The notification will advise them to self-isolate and order a test. How the risk threshold is decided for issuing a notification is described in the section ‘automated decision making’. It is integral to the design and operation of the contact tracing function that users be notified automatically, so that they can take appropriate steps to protect themselves, in a way that does not identify to anyone, including DHSC, the person who’s positive test result caused the notification to be issued

Data protection principle: adequacy

Question	Response
Is the data adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed?	Yes. Please refer to the section ‘nature of the data’.
How have you ensured that only the minimum data is used to meet the purpose of processing? e.g. each data item is justified and periodically reviewed?	All persistent personal data is held on the phone and is not accessible to the controller. With the exception of test results with their associated tokens (which are transient and short-lived) the data held on the DHSC secure computing infrastructure backend is anonymous.
How many individuals are processed through this system in a given time period?	The use of the app is voluntary. It will be effective at any level of uptake, but most effective if more people download and use it. We are expecting mass download and use of the app. If 80% of adult smartphone users use the app, it would represent around 56% of the population or around 37 million people

Data protection principle: accurate and up to date

Question	Response
How are personal data checked for accuracy?	Diagnosis Keys are generated by the EN API and are not under our control. We rely on the EN API to generate unique keys that are not repeated for each instance of the installed app. We also rely on the EN API to generate Rolling Proximity Identifiers that are unique to an instance of the installed app. We also rely on the EN API to re-generate the correct set of RPIs from diagnosis keys distributed by DHSC secure computing infrastructure We are reliant on the user’s self-symptom analysis, but symptom checker questions have been carefully designed with professional oversight. We are reliant on the user to submit their Postcode district but can check that it is a valid postcode district code. The anonymous Analytics dataset (and risk action etc.) are generated and submitted automatically by the App.
What action would be taken to correct inaccurate personal data?	Current implementation of postcode district validation uses the following: Min length 2 Max length 4 Matches the regex ^[A-Z]{1,2}[0-9R][0-9A-Z]? The user can delete and re-enter the postcode district if they have entered one in error (subject to the same validation outlined above).
How frequently is the personal data updated or what would trigger the information being updated?	Data on the users’ phones is updated as they come into proximity with other users, so the frequency depends on this. The DHSC secure computing infrastructure database is updated once (per infection) when the user submits their Diagnosis Keys. It is also updated when test results are received – so once per test request.
Is the quality of the information good enough for the proposed purposes?	Yes
Are the sources of the personal data recorded?	No. It is a privacy feature of the design of the App that this information is not necessary.

Data protection principle: retention

Question	Response
What are the retention periods for the personal information	See section ‘retention of data from the app’
What is the justification for holding the information for this length of time?	See section ‘retention of data from the app’‘
How will the retention schedule be managed and enforced?	See section ‘retention of data from the app’
How often is this retention period reviewed?	At least every 6 months
Are there any exceptional circumstances for retaining certain data for longer than the normal period?	There are none anticipated at present however in the context of a national emergency this is a possibility.
How will information be fully anonymised, archived or destroyed after it is no longer necessary?	The diagnosis keys and analytics data held on the DHSC secure computing infrastructure database is anonymous when collected. The diagnosis keys are retained for a maximum of 28 days (14 days on the phone and 14 days on the DHSC secure computing infrastructure database. They are permanently deleted from the phone after 14 days, and from DHSC secure computing infrastructure after 14 days from submission. Test results and associated tokens are transient and short-lived.

Data protection principle: rights of the individual

Question	Response
How will you action requests from individuals (or someone acting on their behalf) for access to their personal information?	Subject access requests will be facilitated by a feature of the app to present all information held in the app on the phone. No data will be retrieved from the DHSC secure computing infrastructure database. There is a feature planned for a follow up release that allows a user to view all captured data on the app. Given that this data never leaves the app that is the only place they will be able to view it.
How would you locate all personal data relevant to an individual?	It’s on the phone.
What is the procedure for this system to responding to data subject’s request to be forgotten – Article 17	Users may uninstall the app from their phone at any time which will cause deletion of all the app data from the device. Although this will not cascade to the DHSC secure computing infrastructure database the diagnosis keys are deleted after 14 days automatically.
Article 16 – Right to rectification	Not available – controller does not have access to the personal data on the phone. If a user disagrees with a test result, they will need to contact the test provider.
Article 18 – Right to restriction of processing	Not available – controller does not have access to personal data on the phone.
Article 19 – Notification obligation regarding rectification or erasure of personal data or restriction of processing	Not available – controller does not have access to personal data on the phone.
Article 20 – Right to data portability	This right is not available because the processing is not based on consent pursuant to Article 6(1)(a) or Article 9(2)(a); or on a contract pursuant to Art. 6(1)(b).
Article 21 – Right to object	Available by uninstalling App.
Article 22 – Automated individual decision-making including profiling	See section ‘automated decision making’

Data protection principle: appropriate technical and organisational measures

Question	Response
What procedures are in place to ensure that all staff with access to the information have adequate IG/Data Protection training?	Both DHSC (the controller) and NHS England and NHS Improvement have well established mandatory IG training that must be accessed annually by all staff.
How will the information be provided, collated and used by these staff?	DHSC – internal procedures NHS England and NHS Improvement – online training provided and monitored via the Electronic Staff Record.
What are the access restrictions and permissions in place, including a JML process?	See section ‘security of processing’
What are the security measures in place for this data?	Data are held on the user’s device. See section ‘security of processing’

Data protection principle: transfers both internal and external including outside of the EEA

Question	Response
Will an individual’s personal information be disclosed internally/externally in identifiable form and if so to who, how and why?	No.
Will personal data be transferred to a country outside of the European Economic Area? If yes, what arrangements will be in place to safeguard the personal data?	There are no expectations that personal data will be transferred outside of the UK or EEA.

Consultation

Question

Response

Identify both internal and external stakeholders.

DHSC – the controller NHS Test and Trace – part of DHSC, with overall responsibility for delivering the Test and Trace programme NHSX – comprising DHSC, NHS England and NHS Improvement (TDA and Monitor). The legal entities comprising NHS England and NHS Improvement provide resources/staff for DHSC through NHSX. We have a stakeholder engagement plan which we are using to reach out to groups in the health sector, social care, patient representatives, communities, charities, business and academia to inform the development of the app. We are in dialogue with privacy groups and are engaged with the National Data Guardian, Information Commissioner’s Office, Understanding Patient Data and the Centre for Data Ethics and Innovation.

Guidance used

Question	Response
Details of any link to any wider initiative or list any national guidance applicable to this initiative.	This initiative accompanies analytical work to support the COVID-19 emergency generally, in particular the NHS England COVID-19 Privacy Protected Data Hub. However, no linkage of data between the data sources is possible.

Is the provision of personal data obligatory or voluntary?

Question	Response
Is the provision of personal data obligatory or voluntary?	The provision of diagnosis keys to the DHSC secure computing infrastructure database is a voluntary action for app users, requiring a positive action.
If obligatory, why/how is that the case?	Use of the app is voluntary No obligation to use symptom checker (data held locally anyway).
What are the possible consequences for a data subject if there is a failure to provide the requested personal data?	If a user does not upload diagnosis keys then opportunities may be missed to carry out proximity alerting for that user (and the other users with whom they had proximity encounters).

Outcomes

Question

Response

will be the effects of the processing (i.e. what actions/decisions will result from the processing)?

Users will be (i) notified about proximity encounters that mean they may have contracted COVID-19, and given advice on the steps to take; and (ii) will have the opportunity to self-diagnose on the basis of a symptom checker (both apply if the user displays symptoms); and (iii) be given the opportunity to request a test for COVID-19; and (iv) be notified when they have visited a venue where cases have been reported

Common law duty of confidentiality

Question	Response
Are any of the data subject to a duty of confidentiality (e.g. clinical records, OH details, payroll information)? If so, please specify them.	Yes. Test code and results – held temporarily in the Cloud Services database. (diagnosis keys submitted to the DHSC secure computing infrastructure database indicate positive COVID-19 diagnosis associated with a set of derived rolling proximity identifiers. diagnosis keys nor RPIs are considered personal data)
Where it is planned to use or disclose such data, what are the grounds for doing so?	To enable a test result to be passed back to the user’s phone, which will allow them to see it and be asked whether they are willing to release their Diagnosis Keys to the cloud so that the App’s contact tracing function can be initiated. The Health Service (Control of Patient Information) Regulations 200 set aside the CLDC for this purpose.
If the processing is of data concerning health or social care, is it for a purpose other than direct care?	Public Health Management

Privacy and Electronic Communications Regulations 2003 (as amended) (‘PECR’)

Question	Response
Does the processing engage the Privacy and Electronic Communications Regulations 2003 (as amended) (‘PECR’)? If so, how are the requirements of the regulations met?	See relevant section

Section 7: Privacy Issues Identified and Risk Analysis

7a) Identify the privacy and related risks (see Appendix 1 for further information)

Please refer also to the accompanying security risk register.

Ref No	Privacy issue – element of the initiative that gives rise to the risk	Risk to individuals (complete if appropriate to issue or put not applicable)	Compliance risk (complete if appropriate to issue or put not applicable)	Associated organisation/corporate risk (complete if appropriate to issue or put not applicable)	Risk score (see tables at Appendix 2) Likelihood	Risk score (see tables at Appendix 2) Impact	Risk score (see tables at Appendix 2) RAG Status	Proposed solution(s) /mitigation action(s)	Result: is the risk accepted, eliminated, or reduced?	Risk to individuals is now acceptable? Signed off by?
R001	Transferring of data outside of the EEA without proper controls	Risk to individuals arising from inadequate controls to protect privacy in non-adequate country.	Non-compliance:- No adequacy arrangement results in serious non-compliance with the data protection legislation. This faces regulatory action and exposes the vulnerability of an organisation as it is a breach.	If consequently there is any loss of personal data to non-trusted sources this is a further breach and risks privacy re onward sharing of personal data; reputational damage; loss of trust by data subjects.	1	2	Green	Current Mitigations: All data collected by the app and potentially accessible by any data processors is not directly identifiable (pseudonymised in GDPR) terms; Contracts and Data Processing Agreements are based on Government GCloud Framework and prevent processing outside of the EU with permission and adequate controls	Reduced (Likelihood)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R002	Misuse of information by those with access	Loss of personal data to non-trusted sources; privacy risk due unauthorised sharing of personal data.	Non-compliance with data protection legislation.	Vulnerability of organisation to data breach and possible regulatory action; reputational damage; loss of trust by data subjects.	1	2	Green	Current Mitigations: Limited and controlled access to data environments (product) and systems that support the app, Staff contracts (both direct and if employed as data processors); Data Processing Agreements based on GCloud framework; Data does not reveal app user’s identity	Reduced (Likelihood)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R003	Inadequate data processing agreements with data processors.	Risk to individuals arising from inadequate controls to protect privacy.	Non-compliance with Article 28 requirements.	Vulnerability of organisation to data breach and possible regulatory action; reputational damage; loss of trust by data subjects.	2	3	Amber	Current Mitigations: Data sets associated with the app do not make app users directly or indirectly identifiable (-); Limited, controlled and audited access to data stores and services (-); Contracts in place with suppliers including Data Processing Agreement (for example, covering data breaches) based on GCloud framework (-)	Reduced (Likelihood)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R004	Lack of technical or organisational measures implemented to ensure appropriate security of the personal data	Risk to individuals arising from inadequate technical or organisational controls to protect the data. data breach due to technical weakness (e.g. cyber-attack); access by unauthorised people.	Non-compliance with the data protection legislation – in particular Article 32.	Vulnerability of organisation to data breach and possible regulatory action; reputational damage; loss of trust by data subjects.	1	2	Green	Current Mitigations: Data held by the app product, backup or analytical is not likely to constitute personal data as defined by GDPR (+, data dictionary); Hosting arrangements are within standard NHS governance structures, subject to routine review and backed by contracts/oversight at least equivalent to GCloud (-); Oversight and scrutiny by the National Cyber Security Centre [NCSC] (-); PEN Testing undertaken on environment (-, PEN test report)	Reduce (Impact)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R005a	Personal data not being encrypted in transit or at rest	Risk to individuals arising from inadequate technical controls to protect the data. data breach due to technical weakness (e.g. cyber-attack); access by unauthorised people.	Non-compliance with the data protection legislation – in particular Article 32.	Vulnerability of organisation to data breach and possible regulatory action; reputational damage; loss of trust by data subjects.	1	2	Green	Current Mitigations: The data transmitted to the app, and between environments does not constitute personal data or has protections sufficient to reduce identifiability (-); Data flows to the app from the environment are undertaken through secure methods (-); Oversight by NSCS (-); PEN testing (-)	Reduce (Impact)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R005b	Personal data not being encrypted at rest	Risk to individuals arising from inadequate technical controls to protect the data. data breach due to technical weakness (e.g. cyber-attack); access by unauthorised people.	Non-compliance with the data protection legislation – in particular Article 32.	Vulnerability of organisation to data breach and possible regulatory action; reputational damage; loss of trust by data subjects.	1	2	Green	Current Mitigations: (applicable to non-user held data) The data held does not constitute personal data or has protections sufficient to reduce identifiability (-); Data is held on Amazon Web Services solutions, including S3, which is subject to security protections and encryption (Please confirm); The Analytical environment is hosted on Azure services and is subject to similar controls (-); PEN testing of environments (-); Oversight by the NCSC (-);	Reduce (Impact)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R006	Lack of testing which would assess and improve the effectiveness of such technical and organisational measures	Risk to individuals arising from inadequate technical controls to protect the data. data breach due to technical weakness (e.g. cyber-attack); access by unauthorised people.	Non-compliance with the data protection legislation – in particular Article 32.	Vulnerability of organisation to data breach and possible regulatory action; reputational damage; loss of trust by data subjects.	1	2	Green	Current Mitigations: Limited identifiability of app user’s data rendering unlikely to be considered personal data (within the context of the app) (-); Testing undertaken by contractor (Zulke) to ensure functionality and systems are tested (-)	Reduce (Impact)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R007	Inadequate or misleading transparency information	Data subjects are not appropriately informed about the controller, purposes for processing, legal basis and other requirements of Articles 12 and 13.	Non-compliance with DP legislation in particular Articles 12 and 13; reputational damage.	Vulnerability of organisation to regulatory action.	1	4	Amber	Current Mitigation: Data and Privacy page in the app (as part of entry into system) (-); Privacy Notice for the app (-); Communication campaign for public about app (-); Outreach to community groups (-); User Research (comms and app) (-);	Accepted	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R008	Misuse of token issued by App for test requests and results management	If reference code obtained and used by another individual, they could order a test pretending to be them.		Reputational risk.	3	1	Green	Current Mitigations: Tokens issued by the App are unique and subject to randomisation. They do not allow other tokens to be deduced.	Reduce (Likelihood)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R009	Malicious access to DHSC secure computing infrastructure database by cyber attack Extraction and re-identification of DHSC secure computing infrastructure database data by combination with other data	Risk to individuals arising from inadequate technical controls to protect the data. Data breach due to technical weakness (e.g. cyber-attack); access by unauthorised people.	Non-compliance with the data protection legislation – in particular Article 32. Notifiable security breach. Breach of confidentiality. Reputational damage. Undermining purpose of app.	Reputational damage. Undermining purpose of app.	1	5	Amber	Current Mitigations: Data does not reveal app users’ identity (+, data dictionary); Technical protections in place (-); Oversight by NCSC (-); PEN Testing (-)	Accepted	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R010	Identification of infected individual due to minimal contact - e.g. isolated person with carer who is only contact	Identity of infected person implicitly revealed	Use of the App may be considered to breach confidentiality by implication.	Reputational damage. Undermining purpose of app.	3	3	Amber	Current Mitigations: Broader COVID-19 Public Health Emergency context and contact tracing (-);	Accepted	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R011	Malicious or hypochondriac incorrect self-symptom analysis on app.	Proximity users receive false proximity alerts and advice.	The App does not control accuracy of the data submitted to it.	Reputational damage. Undermining purpose of app.	3	3	Amber	Current Mitigation: Information provided within the app and to app users about symptoms and description (-); Wider Public Health programme on learning from self-diagnosis (-); User Research and feedback programme (-)	Accepted	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R012	Absence of controls over access to app by children	Inappropriate use by children resulting e.g. in false self-reported symptoms and proximity alerts.	The App does not control accuracy of the data submitted to it.	Undermining purpose of app.	1	3	Green	Current Mitigation: Controls within the app store allows parents to limit access to the app but this is beyond the control of the organisation (-); App aimed at users 18+ and listed in app stores in line with age requirement (-)	Reduce (Likelihood)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R013	Lower than expected public trust at launch	The public do not benefit from the App due to inaccurate reports (or high-profile debate about the relative merits of a decentralised -v- centralised model) a suboptimal number of people download the App.	Failure to fulfil statutory duties	Risk of damage to the reputation of the organisation and effectiveness of the response to COVID-19.	2	3	Amber	Current Mitigations: Being confirmed	Reduce (Likelihood)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R014a	In the current implementation of the App, there is no mechanism for users see what data deriving from them is held on the DHSC secure computing infrastructure database (because it is not possible to relate the data back to individuals)	Users unable to assure themselves that their personal data is not held exercise their other subjects’ rights.	None. Article 11(2) applies. For the right to object (Article 21) DHSC should be able to demonstrate compelling legitimate grounds. No data rights are being unreasonably or illegally curtailed	Reputational risk.	2	4	Amber	See relevant section of document. Current Mitigations: As app users are not identifiable within the context of the app data subject rights need to be understood in that context (-); Information provided to app users about the use of their data, the limitations on identifiability as part of the Privacy Notice (-); Contents of app and broader comms (-);	Reduce (Impact)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R014b	In the current implementation of the App, there is no mechanism for users to exercise their rights in relation to personal held on the phone	Users unable to exercise relevant data subject rights (such as Subject Access Requests) as far is applicable	None	Reputational risk	2	3	Amber	Current Mitigations: The app allows users to see data it holds, such as the venues that were visited and the timing. There is a function to delete this data (management of risks and coercion). (-); Data held on the app may only be identifiable to the app user (-); Data should be treated as a user held record (-); Information provided to app users about the use of their data, the limitations on identifiability as part of the Privacy Notice (-); Contents of app and broader comms (-);	Accepted	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R015	Uncertainty over retention of individual data items	There is a risk that app users will not know how long their data is to be retained at the start of processing	Compliance with Data Protection legislation (if applicable) and broader principles of data storage	Compliance with Data Protection legislation (where applicable), failure to be clear and transparent with app users	4	1	Green	Current Mitigations: Details on retention of data items where known is included in the DPIA and PN (+); Limited identifiability places retention outside of GDPR (but still needs to be set) (-);	Reduce (Impact)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R016	Unauthorised disclosure of a user’s health status to other app users	Unlawful disclosure resulting in breach of confidentiality and distress to user.	Breach of Article 5(1)(a) – processed lawfully, fairly and in a transparent manner	Vulnerability of organisation to regulatory action and reputational damage.	1	5	Amber	Current Mitigation: Diagnosis Keys that are distribute for contact matching do not relate to identifiable individuals (-); Secure and privacy preserving method of returning results to app users (-);	Reduce (Impact)
R017	Disclosure by linkage to information held outside the App.	Unlawful disclosure resulting in breach of confidentiality and distress to user.	Breach of Article 5(1)(a) – processed lawfully, fairly and in a transparent manner	Vulnerability of organisation to regulatory action and reputational damage.	1	5	Amber	Current Mitigation: Within App: Process of returning results to app users uses single use token and removes identifiability once results are delivered (-) External to App: Controls around data sets associated with test ordering and test results (-);	Reduce (Likelihood)	Sign off on Risk - Senior Information Risk Owner and Chief Executive for Test and Trace programme Sign off for DPIA - Data Protection Officer
R018	As test ordering requires the submission of directly identifiable information, there should be clear signposting to the user that they are leaving the App environment.	Data subjects are not appropriately informed about the controller, purposes for processing, legal basis and other requirements of Articles 12 and 13.	Non-compliance with DP legislation in particular Articles 12 and 13; reputational damage.	Vulnerability of organisation to regulatory action.	1	3	Amber/Green	Current Mitigations: External to App: Privacy Notice, guidance and information to those ordering a virology test via the website (-); Privacy statement (+, https://test-for-coronavirus.service.gov.uk/appointment); Information about use of data (+, https://www.gov.uk/government/publications/coronavirus-covid-19-testing-privacy-information.) ; Test ordering user journey provides information prior to app user (or non-app users) submitting data (-); Separation out of data sets (-);

Section 8: Document Signoff

Business lead: Simon Thompson, 6 August 2020

Data owner: David Williams (Deputy, Lorraine Jackson), 7 August 2020

IT business partner: James Hatch, 7 August 2020

DPO: Lee Cramp, 7 August 2020

Appendices to this DPIA

Appendix 1 – data dictionary

This section lists the data that is produced by the app system. It is divided into 2 sections:

• operational data
• analytical data

For the purpose of this document data can live on the iOS or Android app (App) or the app specific backend cloud services (Cloud).

Operational data

This is data collected by the app during its normal operation.

Name	Description	Capture	Processing	Distribution	Lifespan	Benefit of processing
Contacts Detected	Contacts detected inside the EN API	Apple / Google EN API	Not available for processing	Within the OS, not accessible to the App	Completely managed by Apple/Google	Not applicable
Exposure Events	Matches between Positive Keys and Contacts Detected. Never discloses the user that was matched	Apple/Google EN API, when a contact match is made	Aggregated on the cloud platform to provide statistics	Generated on the App, shared with Cloud	Short. From match detection until aggregated into statistics	Statistics on matches being made are critical to understand and improve the performance of the contact matching configuration
Diagnosis Key Sets	Diagnosis Keys from the EN API that are requested when a user is confirmed positive and shared with other users	Apple/Google EN API, when a suspected positive user is requested to submit their keys	A transmission risk is added to the key set before it is sent to the cloud.	Generated on the App, stored on Cloud. Sent to all App instances	14 days.	Essential that these keys are distributed to all participating apps as they are the data that is matched against to identify contacts with index cases
QR Venues Visited	QR codes derived from scanning QR images	Captured using phone’s camera QR code scanning function under full app control	QR code is decoded to capture venue identifiers and stored encrypted on the phone.	Generated on the App. Never shared.	21 days	Used to match HotSport Venue codes
Hotspot QR Venues	QR codes for venues that could have caused users to become infected	Identified outside of the app system by Manual Contact Tracing teams	Used with the app to look for matches identifying when an app user has visited a hotspot location.	Passed to the Cloud by 3rd party. Shared will all App instances.	21 days	Used to match visited venue codes
Postcode district	First half (2 to 4 digits) of Post Code	Entered by the app user in app onboarding sequence	Stored on the app securely. Included in analytics when transmitted anonymously to the cloud	Stored on the App. Shared with Cloud with Analytics	As long as the app is installed	Enables system to present captured statistical data on a regional basis, to understand behaviour and infection rates in specific areas. Allows for user to be presented with local information such as infection risk.
Postcode district Risks	Infection Risk Level (Low, Medium High) for a Postcode district. See Note 1	Published by the Joint Biosecurity Centre	Distributed to all app instances	Passed to the Cloud by 3rd party. Shared will all App instances.	As long as the app is installed	Allows for the user to be presented with infection risk for local area and other areas
Swab test Results	Results of Swab Testing	NPEx (National Pathology Exchange) National Test Database, which is passed the data by the Testing Labs	Distributed to all app instances	Passed to the Cloud by 3rd party. Shared will all App instances.	As long as the app is installed	Essential to determine which app users are positive index cases.

Note: Data analysts are building LTLA models for JBC, which will allow lookup of data using a postcode district. This uses a public feed from PHE. Expected to be available late July.

Analytics data

This is data which is collected explicitly for the purpose of understanding the performance of behaviour of the app system.

Name	Description	Capture	Processing	Usage	Lifespan	Benefit of processing
Postcode district	First half (2 to 4 digits) of Post Code	Entered by the app user in app onboarding sequence. Text string	Sent to the cloud with other stats, then aggregated into summary statistics	Used to understand data differences on a regional basis	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Enables system to present captured statistical data on a regional basis, to understand behaviour and infection rates in specific areas.
Phone Model	Device type as reported by the operating system	Reported by phone OS as text string	Sent to the cloud with other stats, then aggregated into summary statistics	Used to understand phone types the app is deployed to	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Enable understanding of what mobile devices need to be supported, and if particular devices are behaving differently
Operation System Version	The version number of the phone operating system	Reported by phone OS as text string	Sent to the cloud with other stats, then aggregated into summary statistics	Used to understand phone OS versions the app is deployed to	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Enable understanding of what phone OSs need to be supported, and if particular OS versions are behaving differently
App Version Number	The version number of the app release	Reported by the App as text string	Sent to the cloud with other stats, then aggregated into summary statistics	Used to understand how many users have not upgraded to the latest version	Aggregated in to summary statistics, which are then maintained as long as the app system is operational	Used to direct what comms or nudges are needed to encourage users to upgrade
Usage Status	How many hours the app has been active/running on the phone in the past 24 hours	Captured within App as hour counts	Sent to the cloud with other stats, then aggregated into summary statistics	Used to contact active users and understand whether the app is running all 24 hours as expected	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Used to understand how many of the population are actively using the app, and if further promotion is needed/proving effective
Opt-in Selections	If some features are optional to the users, which ones they select	Captured within app as text string	Sent to the cloud with other stats, then aggregated into summary statistics	Used to understand what features users have opted-in to	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Used to understand how many of the population are using particular app features, to gauge their popularity
Storage Usage	How many bytes of persistent phone storage are we using	Measured by asking phone OS as integer byte count	Sent to the cloud with other stats, then aggregated into summary statistics	Used to understand how much of the phone’s storage data is in use	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Used to understand if the app is causing problems due its data storage requirement, and what action might be needed
Data Download Usage	In the past 24 hours how many bytes of data were downloaded and uploaded by the device	Measured by asking phone OS as integer byte count	Sent to the cloud with other stats, then aggregated into summary statistics	Used to understand how much of the phones download data is being used	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Used to understand if the app is causing problems due its data download requirement, and what action might be needed
Contact Counts	Counts of contacts with any other app users that are around, and what distance. It does not count how many app users it has been in contact with because the RPI changes approximately every 15 minutes Note: Not currently available on the EN API.	Captured within App as integer contact count	Sent to the cloud with other stats, then aggregated into summary statistics	Used to understand whether the app is detecting the number of contacts expected	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Enables refining the configuration of the EN API to refine the level of contacts being detected, to improve performance on the app
QR Code Check-in Counts	Count of QR check-ins logged by the phone	Captured within app as integer check-in count	Sent to the cloud with other stats, then aggregated into summary statistics	Used to understand whether the app is capturing the number of QR check-ins expected	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Informs programme on whether QR code programme is operating well, and what management actions are required
Risk Accumulator Status	The results of the apps risk analysis	Captured within App as structured data for a risk scored event	Sent to the cloud with other stats, then aggregated into summary statistics	Used to characterise performance of the app risk scoring	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Enables risk scoring to be tuned and refined, to improve the performance of the app
Symptomatic Questionnaire Results	Results of any symptomatic questionnaire submissions	Captured within app as structured data capturing the questionnaire submission	Sent to the cloud with other stats, then aggregated into summary statistics	Used to understand what % of users (and wider population) are reporting COVID-19 like symptoms	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Enables future infection, testing and health provision to be predicted, helping to manage healthcare provision
Isolation Status	Whether/how the user has been asked to isolate	Captured within App as structured data capturing the current isolation status	Sent to the cloud with other stats, then aggregated into summary statistics	Used to understand what % of users (and wider population) are isolating	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Gauge impact of app in isolating potentially infectious users, a key success measure for the app
Swab Test Status	Whether the user has been recommended to take a test, and if/what the result was	Captured within app as structured data capturing test results	Sent to the cloud with other stats, then aggregated into summary statistics	Used to understand how users have tested, which can be compared to what direction the app gave them	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Gauge impact of app in helping users get access to tests and identifying infectious individuals
Risk Decisions	Decisions made by the cloud server Risk API when asked to adjudicate on a risk score. Includes the advice that is given as a result of the decision.	Cloud Risk API service decision results.	Sourced on the cloud and aggregated in summary statistics	Understand advice given to users	Aggregated into summary statistics, which are then maintained as long as the app system is operational	Gauge the number of people who are asked to isolate or apply for tests.

Appendix 2 – APIs presented by Cloud Services

COVID proximity app – operational stages and system flows

• Analytics – Collects analytical data from the app for aggregation and statistical analysis (stateless)
• Config – Provides configuration for the app, possibly based on device state like language and type (stateless)
• Distribute – Access the data used for risk scoring; positive diagnosis keys, hotspot QR codes and postcode district risk levels (stateless)
• Risk – Confirm with the cloud services before taking a risk-based action such as isolation (conversational – the App request is returned a short-lived transaction ID, which the app uses to check to see when the decision is made. Token is likely to be needed for up to 4 hours)
• Submit – Exposure Diagnosis keys to be added to the positive key set (stateless)
• Control – Support the Control Panel web monitor (stateless)
• Swab testing – App-facing API used to get a Transaction Token and get the Swab test results (conversational – a transaction ID token is maintained while a Swab test is underway, which is expected to be 1 to 4 days)
• TestLab – 3rd party Test Lab API used by the Swab test Labs to submit Test Results, together with the linking Token ID (conversational – a transaction ID token is maintained while a Swab test is underway, which is expected to be 1 to 4 days)

Appendix 3: data flows

Inflows

Sender	Content	Pseudonymised?	Mode	Security	Recipient
User – installed App	Diagnosis Keys	No - not identifiable	Submit API		DHSC secure computing infrastructure
User – Installed App	Daily Analytics	Anonymous	Analytics API
National Pathology Exchange (NPEx)	When test results are received from a lab, NPEx matches result to ref code and sends the code, result and test date to DHSC secure computing infrastructure.	Yes	CSV file	Security: TLS with API key, IP source address restriction	DHSC secure computing infrastructure

Outflows

Sender	Content	Pseudonymised	Mode	Security	Recipient
DHSC secure computing infrastructure	Diagnosis Keys submitted by COVID-19 positive users	No - not identifiable	Distribute API		User / Local Application
DHSC secure computing infrastructure	Infected venue QR Codes	Not person-identifible	Distribute API		User / Local Application

Appendix 4: Guidance for completing a risk register

All risks need to be assigned a likelihood and impact score. The likelihood and impact scores will be calculated and used to understand the level of severity / importance:

Likelihood scores

Likelihood score	Descriptor	Frequency – how often might it happen?
1	Rare	This probably will never happen
2	Unlikely	Do not expect it to happen/reoccur, but it is possible it may do so
3	Possible	Might happen or reoccur occasionally
4	Likely	Almost certain to occur, but it’s not a persisting issue or circumstance
5	Most certainly	Almost certain to happen/occur; possibly frequently

Impact scores

Likelihood score	Descriptor	Frequency – how often might it happen?
1	Very low	Unlikely to have any impact
2	Low	May have impact
3	Medium	Likely to have an impact
4	High	Highly probably it will have a significant impact
5	Very high	Will have a major impact

Using a Red, Amber and Green (RAG) system for scoring risks means they can be ranked such that the most severe are addressed first. Decisions to prioritise risks can be made using the RAG rating and mitigating actions put in place to alleviate the risk.