Consent is the most traditional legal basis for data processing. Furthermore, the draft of the ePrivacy Regulation[1] considers consent as the main basis for lawful data processing in the context of electronic communications, a circumstance that applies, for instance, in the case of IoT devices connected to the web. Consent, however, will only apply if some conditions are met. If consent is used as the legal basis for data processing, developers should ensure that the device they are creating includes the need to require the users’ prior consent for processing in a specific, informed and granular way and ensure the adequate documentation of such consent.
According to the EDPB, granularity means that “a service may involve multiple processing operations for more than one purpose. In such cases, the data subjects should be free to choose which purpose they accept, rather than having to consent to a bundle of processing purposes. In a given case, several consents may be warranted to start offering a service, pursuant to the GDPR.”[2]
The granularity “should not only concern the categories of collected data, but also the time and frequency at which data are captured, as well as the different purposes those data will be processed for. Similarly to the “do not disturb” feature on smartphones, IoT devices should offer a “do not collect” option to schedule or quickly disable sensors.”[3]
It must be crystal clear that consent by the data subject cannot be obtained freely through mandatory acceptance of general terms and conditions, nor through opt-out possibilities.[4] Thus, devices should be designed in a way that ensure that consent is granular and users hold the possibility to renounce certain services or features of an IoT. Users should not be penalized or have degraded access to the capabilities of the system if they decide not to use it (when interacting with another system) or if they decide not to use a specific service incorporated in the system.
Devices and applications should always be designed to inform users and non-user data subjects about the processing of data, for instance via the device physical interface or by broadcasting a signal on a wireless channel. Irrespective of the existence of any contractual relationship and even the legal basis for the processing, any data subject, no matter if they are a user or a non-user must be informed and in a capacity to exercise their rights, (the only exception is the right to object, which is not applicable if the legal basis for processing is consent). [5] The possibility to withdraw consent shall be guaranteed from the moment when the data are collected and data subjects must be informed of such possibility.
Consent management needs prior compliance with the data protection by design and by default principles. As Wachter stated, it is highly recommendable that IoT developers set access permissions “not only for users, but also for ‘things’ seeking to access or process a user’s data on the user’s or a third party’s behalf. These access permissions must respect user’s privacy preferences. Identity management combined with role-based access control, for example, enables identity verification coupled with authorization of users’ actions requests or devices according to their system-assigned role, ensuring that only actions authorized to a specific role (e.g. collecting, transmitting, or processing data) can be taken in a session. Administrators or users can define these permissions, offering different approaches to protect user’s subjective privacy preferences.”[6]
| Box 3: Sticky Policies and Privacy Proxies
A better control on data processing might be guaranteed by the use of an approach based on the so-called sticky policies can support compliance with the data protection framework by embedding information on conditions and limits to the use of data with the data itself. Thus, those policies could establish the context of use of the data, the purposes, policies on third party access and a list of trusted users An alternative/complementary way to offer a data subject real control on how data must be processed when interacting with sensors by being able to express preferences, including getting and revoking consent and purpose limitation choices could be based on the use of privacy proxies. Supported by a device, data requests are confronted with predefined policies governing access to data under the control of the data subject. By defining sensor and policy pairs, third parties requests for collection or access to sensor data would be authorized, limited or simply rejected. Source: Art 29 Data Protection Working Party (2014) Opinion 8/2014 on the on Recent Developments on the Internet of Things (SEP 16, 2014) https://www.dataprotection.ro/servlet/ViewDocument?id=1088 |
In order to prevent the risks of secret monitoring, the former Article 29 Working Party considers it essential that the device warns that the data sharing feature is ‘ON’, for example through a permanently visible icon.[7] Indeed, envisaging appropriate signposting that would be actually visible to the data subjects could be particularly important when we are dealing with wearables. All IoT devices should inform non-user data subjects whose data are collected of such processing, including all relevant information about it. Controllers should make their best to ensure that such information is provided, even though in practice this might be hard. Adequate tools shall be implemented to ensure that the non-user data subjects’ preference not to have their data collected by the device are respected.
If the IoT device incorporates tools provided by third parties, and consent is the most appropriate lawful basis, the IoT developers should be aware of the fact that these tools should be installed on an opt-in basis (even when that is not a widely followed practice in some sectors). Therefore, the Article 29 Working Party stated that “as such access is subjected to the requirement of obtaining the user’s prior consent, this consent needs to be clearly given, specific, and informed. Practice shows, however, that often authorization requests made by third-party application developers do not display sufficient information for the user’s consent to be considered as specific and sufficiently informed, hence valid under EU law”.[8]
Finally, yet importantly, the Article 29 Working Party recommended that providers of applications or services seek to renew individual consent (even where there is no change in the nature of processing) after an appropriate period of time. For instance, it may not be valid to continue to process personal data where an individual had not actively used the service within the previous 12 months. Even where a person has used the service they should be reminded at least once a year (ideally more often, especially where the nature of the processing warrants it) of the nature of the processing of their personal data. Thus, the developer could consider the possibility to incorporate in the device or system a tool able to send a request to the user and re-gain (or not) their consent to continue with the processing. However, this is more a recommendation that a hard law requisite. In any event, data subject must have at their disposal an easy way to withdraw consent, at any time, with no retroactive effects.
Broad consent might be acceptable, but only if some concrete circumstances apply, such as: it is difficult or improbable to foresee how this data will be processed in the future; broad consent used for processing of special categories of data is compatible with national regulations; where broad consent is used, 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. Furthermore, some safeguards must be implemented (see box 4).
| Box 4: Broad consent and additional safeguards
The German DPA has listed some additional safeguards to be implemented in the case of broad consent in the context of research projects.[9] These, which can be appropriately adapted to other circumstances, are: 1. Safeguards to ensure transparency:
2. Safeguards to build trust:
3. Security safeguards:
|
Importantly enough, if the processing of the data is necessary for the processing, in such a way that the processing cannot take place without the data, or that a certain service cannot be offered without the processing, consent may not be the most effective lawful basis. This is true as data subjects may always have a right to withdraw consent at any time. In cases where the activity is dependent on the data, the withdrawal of consent may trigger the incapability to satisfy the service. Depending on all the other circumstances surrounding the processing activity, in these cases other lawful bases may be more appropriate, such as the necessity to execute a contract.
Furthermore, data subjects must have a possibility to withdraw any prior consent given to a specific data processing and to object to the processing of data relating to them. The exercise of such right must be possible without any technical or organizational constraints and the tools provided to register this withdrawal should be accessible, visible and efficient.
According to the Article 29 WP, “withdrawal schemes should be fine grained and should cover:
(1) Any data collected by a specific thing (e.g. requesting that the weather station stops collecting humidity, temperature and sounds);
(2) A specific type of data collected by anything (e.g. a user should be able to interrupt the collection of data by any devices recording sound, whether a sleep tracker or a weather station);
(3) A specific data processing (e.g. users could require that both their pedometer and their watch stop counting their steps). Furthermore, since wearable “connected things” are likely to replace existing items that provide usual functionalities, data controllers should offer an option to disable the “connected” feature of the thing and allow it to work as the original, unconnected item (i.e. disable the smart watch or glasses connected functionality).
The Working Party has already specified that data subjects should have the possibility to “continuously withdraw (their) consent, without having to exit the service provided”[10] .
| Checklist: consent
☐ 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. ☐ Where broad consent is used for the processing of special categories of data is compatible with national regulations. ☐ Where broad consent is used, the controller is particularly the data subjects are given the opportunity to withdraw their consent and to choose whether to participate in certain projects and parts of it. ☐ The power imbalance between controllers and data subjects does not impede free consent. This is particularly important in context 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 what types of data they want, why they want it, 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 or 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 in their access to the service. ☐ The controllers avoid making consent a precondition of a contract to provide a service if the data is not necessary for the performance of such service. |
References
1https://data.consilium.europa.eu/doc/document/ST-6087-2021-INIT/en/pdf ↑
2EDPB, Guidelines 05/2020 on consent under Regulation 2016/679, Adopted on 4 May 2020, at: https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf ↑
3Art 29 Data Protection Working Party Opinion 8/2014 on the on Recent Developments on the Internet of Things (SEP 16, 2014) https://www.dataprotection.ro/servlet/ViewDocument?id=1088. ↑
4Article 29 Working Party (2011) Opinion 13/2011 on Geolocation services on smart mobile devices Adopted on 16 May 2011. 881/11/EN WP 185, P. 13, at: https://www.apda.ad/sites/default/files/2018-10/wp185_en.pdf ↑
5Art 29 Data Protection Working Party (2014) Opinion 8/2014 on the on Recent Developments on the Internet of Things (SEP 16, 2014) https://www.dataprotection.ro/servlet/ViewDocument?id=1088 ↑
6Wachter, Sandra, Normative challenges of identification in the Internet of Things: Privacy, profiling, discrimination, and the GDPR, Computer Law & Security Review, Volume 34, Issue 3, 2018, pages 436-449. ↑
7Article 29 Working Party (2011) Opinion 13/2011 on Geolocation services on smart mobile devices Adopted on 16 May 2011. 881/11/EN WP 185, P. 13, at: https://www.apda.ad/sites/default/files/2018-10/wp185_en.pdf. See the LaLiga case, at: https://asociaciondpd.com/wp-content/uploads/2019/07/PS-00326-2018_ORI.pdf. An English summary is available at: https://iapp.org/news/a/spanish-dpa-fines-la-liga-250k-euros-for-alleged-gdpr-violations/ ↑
8Art 29 Data Protection Working Party Opinion 8/2014 on the on Recent Developments on the Internet of Things (SEP 16, 2014) https://www.dataprotection.ro/servlet/ViewDocument?id=1088. ↑
9DSK, Beschluss der 97. Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder zu Auslegung des Begriffs „bestimmte Bereiche wissenschaftlicher Forschung“ im Erwägungsgrund 33 der DS-GVO 3. April 2019, at: www.datenschutzkonferenz-online.de/media/dskb/20190405_auslegung_bestimmte_bereiche_wiss_forschung.pdf (accessed 20 May 2020). The English translation comes from a nice summary of the measures that can be consulted here: www.technologylawdispatch.com/2019/04/privacy-data-protection/german-dpas-publish-resolution-on-concept-of-broad-consent-and-the-interpretation-of-certain-areas-of-scientific-research/ ↑
10Art 29 Data Protection Working Party Opinion 8/2014 on the on Recent Developments on the Internet of Things (SEP 16, 2014), p. 20, at: https://www.dataprotection.ro/servlet/ViewDocument?id=1088 ↑