The initial business understanding phase is key in terms of data protection issues, since it focuses on understanding the project objectives from a business perspective, converting this knowledge into a data mining problem definition, and then developing a preliminary plan designed to achieve the objectives. It is a crucial moment since the data protection by design (see data protection by design and by default subsection in the concepts section) requires that data protection risks are taken into account when drafting the business case and are followed up during the progress of the project. Data protection by design should be a given mindset which is established within an organization and project team.[1]
In practice, this means that whoever is willing to develop an ICT tool using geospatial data should start by asking themselves what the goal of the tool is. This is key in terms of designing their data protection policy. The developers of the device must know from the outset what they expect it to do. If the goal of the device cannot be reached without processing a disproportionate amount of personal data, if those data should be kept for months or years, if it involves important privacy risks for the users, if safeguards needed cannot be put in place, etc., the development process might be better left out. Furthermore, there might be some goals that collide with the key principles of the GDPR or the EU Charter of fundamental rights. This might happen, for instance, when geospatial data are used to inadvertently gather sensitive data, such as religious beliefs of the data subject. For instance, in 2017, an interactive “Global Heat Map” showing the movements of users of the Strava fitness app inadvertently revealed the locations of deployed military personnel in classified locations[2]. This incident highlights some of the broader legal and ethical issues associated with open data sharing and public data sharing by default. Automatic activation of geolocation without human intervention must be carefully avoided, since it would provoke unlawful data processing.
| Box 1: Examples of different devices using location or proximity data, and their consequences in terms of data processing and data protection issues
It is not the same to design a device aimed at protecting a person with a certain level of dementia as one that is only intended to let a healthy person know what trips he or she has made in the last few months. The former will probably require the use of tools that can determine their position very precisely, while the latter will be satisfied with a less precise location. The former will use more detailed personal data than the latter. In the same way, there will be products that need technologies that do not need to specify the time that the user is spending in all concrete locations, while some others do (as in the case of the person with severe Alzheimer’s disease). Furthermore, the design of the tool should always include options that allow a proportional use of data. Even in the case of someone suffering from Alzheimer disease, it should be possible to graduate the use of geospatial data according to their real needs. Finally, a developer has to know from the first moment whether it is necessary to keep the data gathered for longer or shorter periods of time. A device that only wants to know if its user has been in a place where a virus growth was detected will probably only need to keep location data for a few days, while another that wants to report on the travels made in the last few months will need to keep the data much longer. Each of these variants will have major implications in terms of personal data protection. What is undeniable is that the developers can hardly define their data protection policies if they have not defined adequately the goal of the device to be developed. |
Developers should be particularly aware of the fact that sometimes any marginal increase in terms of accuracy of the location or contact tracing calls for a significant increase in the amount of personal data needed.[3] For instance, postal code-based location is much less precise and therefore less privacy invasive than exact location-based systems. The first one may be enough for advertising local restaurants to passing people, while the second one will be required for a service calculating the shortest route by bike between two points. Therefore, if data controllers are considering a fundamental modification in the level of accuracy of the location or tracing required, they should carefully consider if this works well with the data minimization principle. See further detail about this in the “Minimize data” section below in this module.
Finally, developers should make a decision on whether the product will implement a centralized or a decentralized approach. Both should be considered viable options, provided that adequate security measures are in place, each being accompanied by a set of advantages and disadvantages. However, it is usually considered that decentralized systems respect users’ privacy better. Indeed, the starting point for data processing should be decentralized systems that look to shift processing on to individuals’ devices where possible. Safeguards and security measures need to accompany this, together with information and any needed additional safeguards when there are international transfers of data.[4]
Thus, the conceptual phase of a device or system development should always include thorough consideration of these alternatives concepts carefully weighing up the respective effects on data protection/privacy and the possible impacts on individuals rights.[5] If developers opt for the centralized system, the data processed by the centralized server should be in general limited to the bare minimum.
Whenever possible and relevant, stakeholders should be consulted about what ethical and legal issues they believe are at stake and how these issues should be dealt with. Stakeholders consulted should include representatives of the major groups that will be affected by the system – directly or indirectly. In this way an appropriately diverse range of ideas and preferences will inform design choices.
| Checklist: define the goal of your project[6]
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 centralized/decentralized 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 |
References
1JRC Technical Reports, Guidelines for public administrations on location privacy, at: https://publications.jrc.ec.europa.eu/repository/handle/JRC103110 ↑
2See: The Strava Heat Map and the End of Secrets, Wired, 2018, at: https://www.wired.com/story/strava-heat-map-military-bases-fitness-trackers-privacy/ ↑
3Norwegian Data Protection Authority (2018) Artificial intelligence and privacy. Norwegian Data Protection Authority, Oslo, p.20. Available at: https://iapp.org/media/pdf/resource_center/ai-and-privacy.pdf (accessed 28 May 2020). ↑
4Denham, Elizabeth, UK Information Commissioner, Combatting COVID-19 through data: some considerations for privacy, at: https://ico.org.uk/about-the-ico/news-and-events/news-and-blogs/2020/04/combatting-covid-19-through-data-some-considerations-for-privacy/ ↑
5EDPB, 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 ↑
6This 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/ ↑