|Checklist: define the goal of your project
☐ Developers have fixed the main goals to be reached by the device and considered the data protection issues that their development and implementation might bring together.
☐ Developers have carefully considered whether the amount of data or the type of processing needed by the service to work properly is compatible with data protection considerations.
☐ Developers can ensure an adequate implementation of Privacy-by-design policies. They can demonstrate how they are aligning with the GDPR and the regulatory framework on location/proximity data. Actions implemented to ensure such alignment have been carefully documented.
☐ Developers have considered the pros and cons of a centralised/decentralised system and made an informed decision that is available to the scrutiny of public opinion. To this purpose, consultations with key stakeholders have been performed and documented.
☐ Developers have consulted stakeholders about possible ethical and legal issues at stake
|Checklist: Introduce a training program
☐ Developers have checked that tool designers and all those who will have to deal with data have acquired an adequate knowledge of the data protection framework, or they have ensured an adequate involvement of professionals trained in data protection issues in the developing team.
☐ Developers have introduced a training program on confidentiality, integrity and availability of data issues.
☐ Developers have involved an expert in ethical/legal uses since the preliminary stages of the research project
|Checklist: legal basis
☐ Developers have checked that they have a legal basis that allows for a lawful data processing
☐ Controllers have checked the EU or national regulatory framework regarding the use of personal data.
☐ If personal data are used for compatible purposes, the controller has performed the compatibility test and ensured that uses are compatible.
☐ If the data are used for a purpose other than that initially sought, the tool is designed to inform the user about this use.
☐ The tool is designed to allow the re-use of personal data only when it is grounded in Union or Member State law which lays down a list of clear compatible purposes for which the further processing may be lawfully authorized or constitutes a necessary and proportionate measure in a democratic society
☐ The controllers are able to demonstrate that, after balancing the circumstances of the processing, they have concluded that consent is the most appropriate legal basis for processing.
☐ The controllers request the consent of the data subjects in a free, specific, informed and unequivocal manner, according to article 7 GDPR.
☐ The controllers have informed the data subjects about their right to withdraw consent at any time.
☐ Broad consent used for processing of special categories of data is compatible with national regulations.
☐ Where broad consent is used, the controller is particularly aware that the data subjects are given the opportunity to withdraw their consent and to choose whether or not to participate in certain research and parts of it.
☐ Controllers have a direct relationship with the subject who provides the data.
☐ The power imbalance between controllers and data subjects does not impede free consent. This is particularly important in certain contexts such as the labor framework.
☐ The controllers ask people to actively opt in.
☐ The controllers do not use pre-ticked boxes or any other type of default consent.
☐ The controllers use clear, plain language that is easy to understand.
☐ The controllers specify why they want the data,what they are going to do with it and for how long data will be processed.
☐ The controllers give separate distinct (‘granular’) options to consent separately to different purposes and types of processing.
☐ The controllers link which pieces of data of categories thereof will be processed for each purpose.
☐ The controllers have informed the data subjects about their right to withdraw consent at any time and how to do so.
☐ The controllers ensure that individuals can refuse to consent without detriment to their access to the service.
☐ The controllers avoid making consent a precondition of a service.
|Checklist: General ethical measures to be implemented
☐ The device does not include tools that allow for a use of the data in a way that is hardly compatible with the preservation of relevant privacy spaces.
☐ The tool is mindful of principles of environmental sustainability, both regarding the system itself and the supply chain to which it connects (when relevant)
☐ The default configuration of the device does not allow disproportionate uses of data for surveillance purposes.
☐ Controllers have made sure that the tool takes the welfare of all stakeholders into account and general reduction of their well-being is not at all foreseeable.
☐ The device is not designed for purposes that are hardly compatible with the EU’s own ethical principles.
|Checklist: is a DPIA necessary?
☐ The controller determined the jurisdictions where data-processing activities will take place.
☐ The controller checked if those jurisdictions have enacted lists indicating the processing that requires a mandatory DPIA and has seen if the intended data processing is covered by those provisions.
☐ If the controller is unsure of the necessity of carrying out a DPIA, they must consult with the DPO or, in lieu of, the legal department of the controller.
☐ If necessary, the controller carried out a DPIA.
☐ If necessary, the controller filed a prior consultation with the appropriate supervisory authority.
☐ If changes were suggested, the controller followed the advice of the supervisory authority.
|Checklist: Ensure security
☐ The controller assessed potential forms of attacks to which the tool could be vulnerable, introduced mitigation measures and documented them.
☐ The controller considered different types and natures of vulnerabilities, such as data pollution, physical infrastructure and cyber-attacks.
☐ The controller put measures or systems in place to ensure the integrity and resilience of the system against potential attacks.
☐ The controller verified how the system behaves in unexpected situations and environments.
☐ The controller considers to what degree the system could be dual-use. If so, the controller took suitable preventative measures against this.
☐ The controller ensured that the system has a sufficient fallback plan if it encounters adversarial attacks or other unexpected situations (e.g. technical switching procedures or asking for a human operator before proceeding).
☐ The data sent to the central server is transmitted over a secure channel. The use of notification services provided by OS platform providers is carefully assessed, and does not lead to disclosing any data to third parties.
☐ Requests are not vulnerable to tampering by a malicious user.
☐ State-of-the-art cryptographic techniques are implemented to secure exchanges between the application and the server and between applications and, as a general rule, to protect the information stored in the applications and on the server.
☐ The central server does not keep network connection identifiers (e.g., IP addresses) of any users.
☐ In order to avoid impersonation or the creation of fake users, the server authenticates the application.
☐ The application authenticates the central server.
☐ The server functionalities are protected from replay attacks.
☐ The information transmitted by the central server is signed in order to authenticate its origin and integrity.
☐ Access to all data stored in the central server and not publicly available is restricted to authorized persons only.
☐ The device’s permission manager at the operating system level only requests the permissions necessary to access and use the communication modules, to store the data in the terminal, and to exchange information with the central server.
☐ The personnel and other physical person in the project has been informed and given awareness of security measures.
|Checklist: Data Breaches
☐ Controllers have implemented adequate policies to notify data breaches as soon as possible and all participants in the development process are well aware of them.
☐ Templates about the information to be included in the notifications have been designed.
☐ Communication policies and tools, aimed at facilitating communcation with the data subjects if a data breach happens, have been created.
|Checklist: Protecting the vulnerable
☐ The controllers have additional checks in place for their profiling/automated decision-making systems to protect any vulnerable groups (including children).
☐ Information and privacy policies should be accessible through different means (from voice, images, video or in an easy-to-understand language). This is especially important if the location device is targeted at a specific users group.
☐ Consent is adapted to vulnerable populations and childrens’ needs.
☐ Use options facilitating the use of the device by vulnerable populations have been considered.
☐ If the controller is willing to use the data for a purpose other than that initially requested, the tool is designed to ask vulnerable users for permission in a way that is compatible with their personal conditions.
|Checklist: Address biases 
☐ The controller has put in place ways to measure whether the tool is making an unacceptable number of biased predictions.
☐ The controller has put in place a series of steps to increase the tool’s accuracy.
☐ The controller has put in place measures to assess whether there is a need for additional data, for example to eliminate biases.
☐ The controller has verified what harm would be caused if the tool makes biased predictions.
|Checklist: Anonymized data
☐ The tool is based on an architecture relying as much as possible on users’ devices.
☐ Requests made by the applications to the central server do not reveal unnecessary information for the purposes of the service to the system.
☐ In order to avoid re-identification by the central server, proxy servers are implemented. The purpose of these non-colluding servers is to mix the identifiers of several users before sharing them with the central server, so as to prevent the central server from knowing the identifiers (such as IP addresses) of users.
☐ The application and the server are carefully developed and configured in order not to collect any unnecessary data (e.g., no identifiers should be included in the server logs, etc.) and in order to avoid the use of any third party collecting data for other purposes.
|Checklist: Minimizing data
☐ According to the data minimization principle, the application does not collect data other than that which is strictly necessary for its purposes.
☐ When possible for the purpose of the processing, controllers will set a preference for the use anonymous data. If personal data must be used, pseudonymous data will prevail over direct personal data.
☐ The tool only collects data transmitted by instances of the application or interoperable equivalent applications. No data relating to other applications and/or proximity communication devices are collected.
☐ Requests made by the applications to the central server do not reveal unnecessary information for the purposes of the service to the system.
☐ Requests made by the tool to the central server do not reveal any unnecessary information about the user, except, possibly, and only when necessary, for their pseudonymous identifiers and their contact list.
☐ The use of the application does not allow users to learn anything about other users, if it is not strictly necessary.
☐ The central server does not maintain nor circulate a list of the pseudonymous identifiers of users
|Checklist: Purpose limitation
☐ The controllers have clearly identified their purpose or purposes for processing, which must be “specific”.
☐ The controllers have documented those purposes.
☐ The controllers include details of their purposes in the privacy information for individuals, ensuring that the data subject is adequately informed, according to art. 12-14 GDPR.
☐ The tool cannot be inadvertently diverted from its primary use.
☐ The tool does not use walls to collect unnecessary data
☐ If the controller initiates a further processing of personal data, a compatiblity test has been carried out and documented in order to comply with the accountability principle. This test must take into account, at least, the factors listed in Art. 6(4) of the GDPR.
☐ If the controller wishes to further process the data for a purpose other than that initially obtained which is incompatible with the original purpose, and in the case that consent is the most suitable lawful basis, the tool is designed to ask users for permission. In any other case, the controller must find the most adequate lawful basis.
☐ If the tool has been designed to work on proximity data, it cannot be used to draw conclusions on the precise location of the users based on their interaction and/or any other means.
☐ If the tool has been designed to work on location data, it cannot be used to draw conclusions on the interaction of the users with other people or to make inferences about further categories of data based on the places visited by the person or any other means.
|Checklist: Storage limitation
☐ Contact history or location data stored on the central server is deleted once they are no longer needed for the purposes of the processing.
☐ The procedure for data erasure is adequately designed and the controller and the users are well aware of it.
☐ Any identifier included in the local history is deleted after X days from its collection (the X value being defined by the purpose of the processing).
☐ Data in server logs are minimized and comply with data protection requirements
☐ If there is a central server and it needs to store data identifiers, these must be deleted once they are distributed to the other applications unless a legal/technical reason recommends otherwise.
☐ The controllers regularly review their processing and, where necessary, update their documentation and privacy information for individuals.
☐ Users are informed of all personal data that will be collected. These data are collected only if a legal basis for processing applies
☐ The controllers explain how people can access details of the information that is used for the services offered by the tool.
|Checklist: The users’ rights
☐ Users are able to exercise their rights via the application.
☐ If the tool has been designed to work on proximity data, it cannot be used to draw conclusions on the location of the users based on their interaction and/or any other means.
☐ If the tool has been designed to work on location data, it cannot be used to draw conclusions on the interaction of the users with other people.
☐ If data are used for compatible purposes, the controller has performed the compatibility test.
☐ If the controller wishes to use the data for a purpose other than that initially sought, the tool is designed to ask users for permission.
☐ The controller has documented how indesirable effects of the system or tool are detected, stopped and prevented from reoccurring.
☐ The controller has documented all the organization’s measures, and the safeguards implemented, to ensure compliance with the data protection regulation.
☐ If data are used for compatible purposes, the controller has adequately documented the performance of the compatibility test.
☐ The controller has documented all DPIAs performed, the activities performed by the corresponding DPO and his or her interactions with the corresponding DPAs (if applicable)
☐ The source code of the application and of its backend is open, and the technical specifications have been made public, so that any concerned party can audit the code, and where relevant, contribute to improving the code, correcting possible bugs and ensuring transparency in the processing of personal data.
|Checklist: Processor due diligence
☐ If there is processing involving international transfer of data, the controllers acquired information regarding where the data-processing activities will take place, and (1) carried out the case law review suggested in the point below; and (2) assessed if the jurisdictions, in the case of non-EU countries, are considered adequate by the EU Commission.
☐ The controllers reviewed case law from the national supervisory authorities where the processor operates to check for potential sanctions.
☐ The controllers required proof of adherence to a code of conduct or certification (this is not strictly necessary but may be considered as good practice).
☐ The controllers required proof of relevant ISO certification (this is not strictly necessary but may be considered as good practice).
☐ If there is a processor involved, controllers required a copy of records of processing activities.
☐ The controllers enquired about the development process of the tool, in particular which kind of data were used for training the tool and the data that it needs to operate and deliver a useful result.
☐ The controllers checked if the institution has already appointed a DPO.
☐ If not, they checked with the legal department if the intended data-processing activities trigger the appointment of a DPO, either by looking at European authoritative interpretations, local regulations, local authoritative interpretations, and relevant national and European case law.
☐ The controllers required the appointment of a DPO if necessary, and its involvement in the tool development process as necessary.
☐ As a general rule, the DPO should be aware of every step taken to allow room for their intervention if deemed relevant.
1This checklist has been built on the basis of these documents: http://www.oecd.org/coronavirus/policy-responses/tracking-and-tracing-covid-protecting-privacy-and-data-while-using-apps-and-biometrics-8f394636/ ↑
2This checklist has been built on the basis of these documents: EDPB, Guidelines 04/2020 on the use of cation data and contact tracing tools in the context of the COVID-19 outbreak Adopted on 21 April 2020; High-Level Expert Group on Artificial Intelligence (2019) Ethics guidelines for trustworthy AI. European Commission, Brussels. Available at: https://ec.europa.eu/digital-single-market/en/news/ethics-guidelines-trustworthy-ai. ↑
3This checklist has been adapted from the one elaborated by the High-Level Expert Group on Artificial Intelligence (2019) Ethics guidelines for trustworthy AI. European Commission, Brussels. Available at: https://ec.europa.eu/digital-single-market/en/news/ethics-guidelines-trustworthy-ai (accessed 20 May 2020). ↑
4This checklist has been built on the basis of the one included in the EDPB, Guidelines 04/2020 on the use of location data and contact tracing tools in the context of the COVID-19 outbreak Adopted on 21 April 2020, at: https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_20200420_contact_tracing_covid_with_annex_en.pdf ↑
5This checklist has been built on the basis of the one included in the EDPB, Guidelines 04/2020 on the use of location data and contact tracing tools in the context of the COVID-19 outbreak Adopted on 21 April 2020, at: https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_20200420_contact_tracing_covid_with_annex_en.pdf ↑
6This checklist has been built on the basis of these documents: EDPB, Guidelines 04/2020 on the use of location data and contact tracing tools in the context of the COVID-19 outbreak Adopted on 21 April 2020; ICO (no date) Principle (b): purpose limitation. Information Commissioner’s Office, Wilmslow. Available at: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/purpose-limitation/ (accessed 17 May 2020). ↑
7This checklist has been built on the basis of these documents: EDPB, Guidelines 04/2020 on the use of location data and contact tracing tools in the context of the COVID-19 outbreak Adopted on 21 April 2020; ICO (no date) Principle (b): purpose limitation. Information Commissioner’s Office, Wilmslow. Available at: https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/principles/purpose-limitation/ (accessed 17 May 2020). ↑
8This checklist has been built on the basis of the EDPB, Guidelines 04/2020 on the use of location data and contact tracing tools in the context of the COVID-19 outbreak Adopted on 21 April 2020 ↑
9This checklist has been built on the basis of the EDPB, Guidelines 04/2020 on the use of location data and contact tracing tools in the context of the COVID-19 outbreak Adopted on 21 April 2020 ↑
10This checklist has been built on the basis of the EDPB, Guidelines 04/2020 on the use of location data and contact tracing tools in the context of the COVID-19 outbreak Adopted on 21 April 2020 ↑