Article 20 GDPR: Difference between revisions
No edit summary |
|||
(21 intermediate revisions by 6 users not shown) | |||
Line 185: | Line 185: | ||
==Legal Text== | ==Legal Text== | ||
'''Article 20 - Right to data portability''' | <br /><center>'''Article 20 - Right to data portability'''</center> | ||
<span id="1">1. The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided, where:</span> | <span id="1">1. The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided, where:</span> | ||
Line 202: | Line 202: | ||
{{Recital/68 GDPR}}{{Recital/73 GDPR}}{{Recital/156 GDPR}} | {{Recital/68 GDPR}}{{Recital/73 GDPR}}{{Recital/156 GDPR}} | ||
==Commentary | ==Commentary== | ||
The purpose of the right to data portability is to give data subjects more control over their personal data by granting them a certain type of "ownership". | The right to data portability empowers data subjects to receive a copy of their data in a structured, commonly used, and machine-readable format. They can then decide what they want to do with this data, and either store it on their computer, send it or have it sent to a third party. The recipients of this data are not limited to providers that offer similar or comparable services, as the right to portability can be exercised with any controller data subjects choose within the conditions specified below.<ref>The purpose of the right to data portability is to give data subjects more control over their personal data by granting them a certain type of "ownership". Regulators’ objective was to increase competition on the market by allowing for the free movement of data between providers. Data portability is especially relevant in cases when one controller offers a higher level of protection of personal data than another within the same industry sector or across sectors.</ref> | ||
===(1) Right to data portability=== | |||
Data subject have the right to request and obtain a copy of any personal data they have provided to the controller and which is being processed based on consent or contract. This information must be structured in an accessible and intelligible manner, so that both the data subject themselves and any controllers who may receive it in the future can understand and make use of it. <blockquote><u>EDPB</u>: Take, for instance, a scenario where a data subject desires to obtain his/her present playlist or a log of listened tracks from a music streaming service. This could be for the purpose of ascertaining the number of times specific tracks were played, or for identifying which music to buy or listen to on an alternate platform. Correspondingly, the data subject may seek to retrieve his/her contact list from a webmail application, perhaps to compile a wedding list, track purchases made with various loyalty cards, or evaluate his/her carbon footprint.<ref>EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, p. 5 (available [https://ec.europa.eu/newsroom/article29/items/611233 here]).</ref> </blockquote> | |||
=== | ==== Right to receive ==== | ||
The request for data portability does not differ much from the request for access, at least in terms of the necessary steps to carry it out.<ref>However, it is always important to keep these two rights distinct. The right of access enables individuals to obtain information about the processing and a copy of the personal data held by the controller, in order to ensure transparency and allow for further actions by the data subject. On the other hand, data portability has a distinct economic feature. It allows for a copy of the data - which is also different and more limited than that under Article 15 - to be obtained, and the possibility to send such a dataset to another controller for similar or different purposes (i.e., essentially a competitor). In any case, a request must be made, even electronically. The controller must facilitate the request, including the authentication of the data subject (Article 12(2) GDPR). Obstructive practices in this area not only unduly limit the requester's subjective right, but also harm the single market and the free movement of personal data, creating real anti-competitive phenomena or "lock-in" effects.</ref> The controller must facilitate the request, including the authentication phase (Article 12(2) GDPR). Obstructive practices in this area will not only unduly limit the requester's subjective right, but also harm the single market and the free movement of personal data, creating anti-competitive phenomena or "lock-in" effects. | |||
As for the rest, the general rules set out in Article 12 apply. Article 12(3) requires that the data controller provides “''information on action taken''” to the data subject “''without undue delay''” and in any event “''within one month of receipt of the request''”. As usual, the one month period can be extended to a maximum of three months for complex cases, provided that the data subject has been informed about the reasons for such delay within one month of the original request.<blockquote><u>EDPB</u>: To meet user expectations, it is a good practice to define the timeframe in which a data portability request can typically be answered and communicate this to data subjects. Data controllers who refuse to answer a portability request shall, pursuant to Article 12(4), inform the data subject “''the reasons for not taking action and on the possibility of lodging a complaint with a supervisory authority and seeking a judicial remedy''”, no later than one month after receiving the request.<ref>EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, p. 14-15 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-right-data-portability-under-regulation-2016679_en here]).</ref></blockquote> | |||
===== Modalities to provide the data ===== | |||
Data controllers should consider two distinct but complementary options for providing portable data to data subjects or other controllers. The first option is a direct transmission of the complete dataset or specific parts of it. The second option is an automated tool that allows for the extraction of relevant data. For complex and large datasets, the second option may be preferred as it minimizes risks and allows for the use of data synchronization mechanisms. Making portable data available through various secure means such as messaging, SFTP servers, or secured WebAPI/WebPortal would enable data subjects to use personal data stores or other trusted third parties to hold and manage their personal data. This would also reduce privacy risks for the initial data controller and promote compliance for the new data controller.<ref>EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, p. 16 (available [https://ec.europa.eu/newsroom/article29/items/611233 here]).</ref> | |||
==== Personal data concerning him or her ==== | |||
A data portability request only applies to personal data concerning the data subject. Pseudonymous data is within the scope if the corresponding identifier is provided by the subject (as per Article 11(2) GDPR). Any data that is anonymous or not related to the data subject is not included. <blockquote><u>EDPB</u>: For instance, call records in a subscriber's account history may include details of third parties, but subscribers should still be able to obtain such records in response to portability requests since they are also concerning the data subject. Nevertheless, new data controllers who receive such records should not process them in any way that would adversely affect the rights and freedoms of the third parties involved.<ref>EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, p. 9 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-right-data-portability-under-regulation-2016679_en here]).</ref></blockquote> | |||
==== Provided to a controller ==== | |||
Article 20 specifies that only personal data "''provided''" by the data subject is covered by the right. This includes data that the user knowingly and actively provides, such as their name and mailing address,<ref>The data "''provided''" is the data that was actively given to the controller (e.g. photos uploaded to the service) or which was "''observed''" by a controller (e.g. activity logs, food preferences). This definition also includes data that has been transferred to the controller in the context of the exercise of the right to data portability. ''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 20 GDPR, margin number 11 (C.H. Beck 2020, 3rd Edition).</ref> as well as, according to the EDPB, data that is "''observed''" from the user's activity, such as their search history or location data. <blockquote><u>EDPB</u>: Inferred data and derived data are created by the data controller on the basis of the data “''provided by the data subject''”. For example, the outcome of an assessment regarding the health of a user or the profile created in the context of risk management and financial regulations (e.g. to assign a credit score or comply with anti-money laundering rules) cannot in themselves be considered as “''provided by''” the data subject. Even though such data may be part of a profile kept by a data controller and are inferred or derived from the analysis of data provided by the data subject (through his actions for example), these data will typically not be considered as “''provided by the data subject''” and thus will not be within scope of this new right.<ref>EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, p. 10 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-right-data-portability-under-regulation-2016679_en here]).</ref></blockquote>However, it should be noted that there is a doctrinal debate regarding whether or not "observed data" should be included within the scope of application of portability. One argument in favor of a restrictive approach aims to limit the provision of data only to the types necessary for offering a comparable service. However, inferred or derived data, which is created by the data controller based on the data provided by the data subject, is not covered by the right to data portability.<ref>''Kamann, Braun'', in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 20 GDPR, margin number 13 (C.H. Beck 2018, 2nd Edition).</ref> This is one of the most remarkable differences between portability and access under Article 15(3) GDPR. | |||
==== In a structured, commonly used and machine-readable format ==== | |||
= | According to Recital 68, the data should be available in an "''interoperable format''", which data controllers "''should be encouraged to develop''". In turn, "''interoperable''" refers to the ability of disparate and diverse organisations to "''interact towards mutually beneficial and agreed common goals, involving the sharing of information and knowledge between the organisations, through the business processes they support, by means of the exchange of data between their respective ICT systems''."<ref>The WP29 defines interoperability as the "''capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units''". EDPB, ‘Guidelines on the right to data portability’, 16/EN WP 242 rev.01, 5 April 2017, 17 (available [http://ec.europa.eu/newsroom/document.cfm?doc_id=44099 here]).</ref> | ||
According to Article 20(1) GDPR the data should be provided to the data subject in a "''structured, commonly used and machine-readable format''". Beyond this requirement, the GDPR does not call for a specific format to be used. The terms “''structured''”, “''commonly used''” and “''machine-readable''” are a set of minimal requirements that should facilitate the "''interoperability''" of the data format provided by the data controller.<ref>In that way, “''structured, commonly used and machine readable''” are specifications for the means, whereas interoperability is the desired outcome.</ref> Formats subject to costly licensing constraints are not considered "''commonly used''". The personal data provided should have a high level of abstraction from any internal or proprietary format, and metadata should be used to describe the exchanged information accurately.<ref>EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, pp. 16-18 (available [https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-right-data-portability-under-regulation-2016679_en here]).</ref> | |||
Industry stakeholders and trade associations are encouraged to work together on a common set of interoperable standards and formats to deliver the requirements of the right to data portability. The Commission has published a Communication on "''ICT Standardisation Priorities for the Digital Single Market''", which may be used as a basis on which to develop standards for the purposes of data portability.<ref>EU Commission Communication on ICT Standardisation Priorities for the Digital Single Market (Available [https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX:52016DC0176 here]).</ref> | |||
The personal data | ==== and the right to transmit (the data to another controller) ==== | ||
The right to data portability, as outlined in Article 20(1), enables data subjects to transmit their personal data from one data controller to another "without hindrance". This goes beyond the ability to simply obtain and reuse personal data and allows individuals to transfer their data to another service provider, regardless of whether it is within the same sector or not. By preventing "lock-in" situations, data portability empowers consumers and is expected to foster innovation and secure sharing of personal data between controllers under the control of the data subject. Additionally, it can enhance customer experiences by facilitating the controlled and limited sharing of personal data between organizations. This feature of data portability has the potential to facilitate the transfer and reuse of personal data among various services of interest to the user. | |||
The data | ==== Without hindrance (from the first controller) ==== | ||
The GDPR's Article 20(1) guarantees that individuals have the right to transfer their data to another controller without facing any obstructions from the initial controller who provided the personal data. Such impediments can be identified as any legal, technical, or financial barriers that the data controller sets up to prevent or hinder the data subject's or another data controller's access, transmission, or reuse of the data. | |||
Examples of such impediments include charges for data delivery, a lack of interoperability or access to a data format or API, excessive delays or complexity in retrieving the complete dataset, the intentional concealment of the dataset, or sector-specific standards or accreditation demands that are undue or excessive. The WP29 recommends that data controllers offer several options to the data subject. They suggest, for instance, that data subjects should be offered an opportunity to directly download the data as well as to transmit it directly to another data controller, and that this could be implemented by making an Application Programme Interface ('API') available.<ref>Cormack expresses doubts regarding the viability of this solution, noting that many organisations will hold their data on internal databases that are securely firewalled from internet access as opposed to APIs. Without standards leading to interoperability, the right to data portability may "''remain more a declaration of principle than a real and effective tool for individual self-determination in the digital environment''". See, ''Lynskey'' in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 20 GDPR, p. 505 (Oxford University Press 2020).</ref> | |||
Simultaneously, the data controller must implement measures to ensure that they are truly representing the interests of the data subject. One way to achieve this is by instituting protocols to verify that only the specific personal data that the data subject wants to transmit is actually being transmitted. This verification process could involve obtaining confirmation from the data subject either prior to transmission, or at an earlier stage such as when they provide initial consent for processing or finalize the contract.<ref>EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, pp. 16-18 (available [https://ec.europa.eu/newsroom/article29/items/611233 here]).</ref> | |||
==== | ==== Where these conditions cumulatively apply ==== | ||
The right to data portability only applies if (i) the individual has either consented to the processing or the information is processed for the execution of a contract between the data subject and controller and, in both cases, (ii) data is processed by automated means.<ref>For example, data which is only available on paper and manually processed falls out of the scope data portability.</ref> | |||
===== (i) Processing is based on either consent or contract ===== | |||
The right to data portability, as per Article 20(1)(a), is only applicable when the processing of personal data by the controller is based on the data subject's consent in accordance with Article 6(1)(a), consent to the processing of special categories of personal data in accordance with Article 9(2)(a), or a contract in accordance with Article 6(1)(b) to which the data subject is a party. Recital 68 specifically highlights that the right to data portability should not be applicable if the processing is carried out on a legal basis other than the data subject's consent or a contract. Consequently, data obtained by the controller by processing personal data to protect its legitimate interests in accordance with Article 6(1)(f) is not covered by the right under Article 20 GDPR.<ref>However, according to the WP29, it is a good practice to address portability requests also in such cases that do not explicitly provide for a general right to data portability, i.e. when processing is based on the legitimate interests or for the performance of a task carried out in the public interest. See, WP29, ‘Guidelines on the right to data portability’, 16/EN WP 242 rev.01, 5 April 2017, p. 8 (available [http://ec.europa.eu/newsroom/document.cfm?doc_id=44099 here]).</ref> | |||
===( | ===== (ii) Processing is carried out by automated means ===== | ||
The right to data portability under Art. 20(1)(b) only applies to processing that is conducted through automated means. This condition is generally met for internet service providers, but not for non-automated processing of personal data, such as data stored on structured index cards or in non-structured files. This limitation alleviates the controller's burden of converting non-machine-readable records into machine-readable data.<ref>''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 20 GDPR, margin number 13 (Beck 2020, 3rd edition).</ref> | |||
Data portability is | ===(2) Right to have personal data directly transmitted to another controller=== | ||
Article 20(2) introduces the right for data subjects to request that their personal data be transmitted directly from the first controller<ref>Controllers that address portability requests ("''sending controllers''") act on behalf of a data subject and are responsible for providing prior information about the right’s existence (e.g. in the privacy notice) and clearly explaining the difference between the right of access and the right to data portability; processing the request without undue delay, within 1 month (up to 3 months); carrying out authentication; setting safeguards to ensure they genuinely act on the data subject’s behalf (e.g. ensure that they transmit the exact type of personal data that the data subject wants to receive); in light of the principles set forth in [https://gdprhub.eu/Article%205%20GDPR Article 5(1) GDPR], ensuring that the data transmitted is accurate and up to date; and, taking all necessary security measures for transmissions. The sending controllers are, however, not responsible for the processing handled by the data subject or by another company receiving personal data. In this respect, "''the data controller is not responsible for compliance of the receiving data controller with data protection law, considering that it is not the sending data controller that chooses the recipient".'' See, WP29, ‘Guidelines on the right to data portability’, 16/EN WP 242 rev.01, 5 April 2017, 6 (available [http://ec.europa.eu/newsroom/document.cfm?doc_id=44099 here]).</ref> to a second one.<ref>Data controllers that receive portability requests ("''receiving controllers''") have an obligation to "''clearly and directly''" state the purpose of the new processing before they accept the request in accordance with the transparency requirements set out in [https://gdprhub.eu/Article%2014%20GDPR Article 14 GDPR]; process the request without undue delay, within 1 month (up to 3 months); ensure that the data they accept is relevant and not excessive for the intended data processing; delete the personal data which are not necessary to achieve the purpose of the new processing as soon as possible. The receiving controllers can decide whether to accept and process data from a portability request.</ref> This request, in line with the principle of facilitation, spares the data subject the burden of receiving the data and then sending it on to the intended controller. The request can be typically fulfilled through automated transmission, such as an application programming interface (API) that allows for data transfer to other systems implementing the same API. Therefore, it suffices if the data subject is given the opportunity to initiate the transfer by selecting a field labeled "''Transfer of data to another provider''" choosing a provider, selecting the data to be transferred, and clicking on a corresponding field to initiate the automated transfer.<ref>''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 20 GDPR, margin number 25 (Beck 2020, 3rd edition).</ref> | |||
==== Where technically feasible ==== | |||
If the provider has not established an automated data transmission, they may be required to comply with Article 20(2) to the extent that it is "''technically feasible''".<ref>It should be noted that the "''where technically feasible''" safeguard clause only applies to the direct transmission from one controller to another under paragraph 2. Therefore, it does not apply to the scenario outlined in paragraph 1 where the data subject directly requests to receive the data. Such requests shall always be fulfilled, regardless of technical reasons.</ref> Recital 68 states that the controller is not required to adopt or maintain technically compatible data processing systems. Therefore, the technical feasibility of direct data transfer is primarily dependent on the existing technical capabilities of the controller. However, according to Article 12(2) GDPR, the controller must facilitate the exercise of data subject rights, including the right to data portability. As such, the data subject may request reasonable cooperation from the controller, such as adapting data transmission formats, to carry out the intended portability.<ref>''Herbst'', in Kühling, Buchner, DS-GVO BDSG, Article 20 GDPR, margin number 27 (Beck 2020, 3rd edition).</ref> <blockquote><u>EDPB</u>: Data controllers are expected to transmit personal data in an interoperable format, although this does not place obligations on other data controllers to support these formats. Direct transmission from one data controller to another could therefore occur when communication between two systems is possible, in a secured way29, and when the receiving system is technically in a position to receive the incoming data. If technical impediments prohibit direct transmission, the data controller shall explain those impediments to the data subjects, as his decision will otherwise be similar in its effect to a refusal to take action on a data subject’s request (Article 12(4)).<ref>WP29, ‘Guidelines on the right to data portability’, 16/EN WP 242 rev.01, 5 April 2017, 6 (available [https://ec.europa.eu/newsroom/article29/items/611233 here]).</ref> </blockquote> | |||
===(3) | ===(3) Other conditions=== | ||
The exercise of the right to data portability | The first sentence of Article 20(3) GDPR clarifies that the exercise of the right to data portability does not preclude the exercise of any other rights under the GDPR. Thus, if data subjects want to delete their data from the controller's system (right to erasure under [[Article 17 GDPR]]), the controller cannot justify its denial to erase such data because of the data portability request. | ||
The rights and freedoms are | The second sentence excludes that the right to data portability apply if the processing is necessary for the controller to perform a task that is in the public interest or carried out in the exercise of official authority. This exception corresponds to the legal basis of Article 6(1)(e) GDPR. In such cases, the public administration operating under public law is not required to provide data portability. | ||
===(4) Rights of third parties=== | |||
In accordance with Paragraph 4, the right to data portability must not infringe upon the rights and freedoms of others, including both individuals and legal entities. When data is transferred with reference to a third party, such as transaction data from a current account agreement or data from the use of a webmail service, the rights and freedoms of others are generally not affected if the new provider uses the data solely under the control of the data subject and for the same purposes as before.<ref>The portability request should not include any third party data if there is a likelihood that the new processing will adversely affect the rights and freedoms of the other data subjects. ''"Such an adverse effect would occur, for instance, if the transmission of data from one data controller to another, would prevent third parties from exercising their rights as data subjects under the GDPR."'' See, WP29, ‘Guidelines on the right to data portability’, 16/EN WP 242 rev.01, 5 April 2017, 11 (available [http://ec.europa.eu/newsroom/document.cfm?doc_id=44099 here]).</ref> However, data transmission may be restricted by trade secrets, business secrets, or copyrights, such as those pertaining to software, if there is a specific risk of harm resulting from the transmission. Controllers cannot refuse to transfer data based solely on the possibility of such legally protected interests being infringed; instead, they must seek ways to transfer the data in a manner that avoids the disclosure of legally protected secrets.<ref>''Dix'', in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 20 GDPR, margin number 18 (C.H. Beck 2019).</ref> | |||
==Relevance of other EU legislation== | |||
It is important to refer to the interplay of the right to data portability with the proposed or adopted legislation under the umbrella of the EU digital strategy<ref>European Commission, 'A Europe fit for the digital age' (available [https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age_en here])</ref>. | |||
The Digital Markets Act (DMA)<ref>Regulation (EU) 2022/1925 of the European Parliament and of the Council of 14 September 2022 on contestable and fair markets in the digital sector and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets Act) (Text with EEA relevance) (available [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R1925 here]).</ref> imposes a new obligation on "gatekeepers" that enhances the right to data portability. According to Article 6(9) DMA, gatekeepers shall provide an end user and third parties authorised by an end user with effective portability of data provided by the end user or generated through their activity through use of the gatekeeper’s core platform services (CPSs), including by the provision of continuous and real-time access to such data. Recital 59 DMA clarifies that this obligation on the gatekeeper complements the right to data portability under the GDPR. | |||
Further, the proposed EU Data Act<ref>Proposal for a Regulation of the European Parliament and of the Council on harmonised rules on fair access to and use of data (Data Act) (available [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM%3A2022%3A68%3AFIN here]).</ref> that is supposed to help users of connected devices to unlock access to data generated by them, reinforces the right to data portability by creating an obligation on "data holders" to make available the data generated by such devices (Article 5). This obligation would empower a user (e.g. a data subject) to request the porting of personal and non-personal data from their Internet of Things devices (IoT) to a third party "''without undue delay, free of charge to the user, of the same quality as is available to the data holder and, where applicable, continuously and in real-time''". The scope of the data to be transmitted is not limited by the legal basis under which the data is processed by the "data holder" (e.g. controller) and therefore has the potential to unlock the portability of more data. Note: at the time of writing of this Commentary, the EU Data Act proposal was still under trialogues between the EU institutions (EU Commission, EU Parliament and the Council of Ministers). | |||
==Decisions== | ==Decisions== |
Latest revision as of 07:05, 1 June 2023
Legal Text
1. The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided, where:
- (a) the processing is based on consent pursuant to point (a) of Article 6(1) or point (a) of Article 9(2) or on a contract pursuant to point (b) of Article 6(1); and
- (b) the processing is carried out by automated means.
2. In exercising his or her right to data portability pursuant to paragraph 1, the data subject shall have the right to have the personal data transmitted directly from one controller to another, where technically feasible.
3. The exercise of the right referred to in paragraph 1 of this Article shall be without prejudice to Article 17. That right shall not apply to processing necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller.
4. The right referred to in paragraph 1 shall not adversely affect the rights and freedoms of others.
Relevant Recitals
Commentary
The right to data portability empowers data subjects to receive a copy of their data in a structured, commonly used, and machine-readable format. They can then decide what they want to do with this data, and either store it on their computer, send it or have it sent to a third party. The recipients of this data are not limited to providers that offer similar or comparable services, as the right to portability can be exercised with any controller data subjects choose within the conditions specified below.[1]
(1) Right to data portability
Data subject have the right to request and obtain a copy of any personal data they have provided to the controller and which is being processed based on consent or contract. This information must be structured in an accessible and intelligible manner, so that both the data subject themselves and any controllers who may receive it in the future can understand and make use of it.
EDPB: Take, for instance, a scenario where a data subject desires to obtain his/her present playlist or a log of listened tracks from a music streaming service. This could be for the purpose of ascertaining the number of times specific tracks were played, or for identifying which music to buy or listen to on an alternate platform. Correspondingly, the data subject may seek to retrieve his/her contact list from a webmail application, perhaps to compile a wedding list, track purchases made with various loyalty cards, or evaluate his/her carbon footprint.[2]
Right to receive
The request for data portability does not differ much from the request for access, at least in terms of the necessary steps to carry it out.[3] The controller must facilitate the request, including the authentication phase (Article 12(2) GDPR). Obstructive practices in this area will not only unduly limit the requester's subjective right, but also harm the single market and the free movement of personal data, creating anti-competitive phenomena or "lock-in" effects.
As for the rest, the general rules set out in Article 12 apply. Article 12(3) requires that the data controller provides “information on action taken” to the data subject “without undue delay” and in any event “within one month of receipt of the request”. As usual, the one month period can be extended to a maximum of three months for complex cases, provided that the data subject has been informed about the reasons for such delay within one month of the original request.
EDPB: To meet user expectations, it is a good practice to define the timeframe in which a data portability request can typically be answered and communicate this to data subjects. Data controllers who refuse to answer a portability request shall, pursuant to Article 12(4), inform the data subject “the reasons for not taking action and on the possibility of lodging a complaint with a supervisory authority and seeking a judicial remedy”, no later than one month after receiving the request.[4]
Modalities to provide the data
Data controllers should consider two distinct but complementary options for providing portable data to data subjects or other controllers. The first option is a direct transmission of the complete dataset or specific parts of it. The second option is an automated tool that allows for the extraction of relevant data. For complex and large datasets, the second option may be preferred as it minimizes risks and allows for the use of data synchronization mechanisms. Making portable data available through various secure means such as messaging, SFTP servers, or secured WebAPI/WebPortal would enable data subjects to use personal data stores or other trusted third parties to hold and manage their personal data. This would also reduce privacy risks for the initial data controller and promote compliance for the new data controller.[5]
Personal data concerning him or her
A data portability request only applies to personal data concerning the data subject. Pseudonymous data is within the scope if the corresponding identifier is provided by the subject (as per Article 11(2) GDPR). Any data that is anonymous or not related to the data subject is not included.
EDPB: For instance, call records in a subscriber's account history may include details of third parties, but subscribers should still be able to obtain such records in response to portability requests since they are also concerning the data subject. Nevertheless, new data controllers who receive such records should not process them in any way that would adversely affect the rights and freedoms of the third parties involved.[6]
Provided to a controller
Article 20 specifies that only personal data "provided" by the data subject is covered by the right. This includes data that the user knowingly and actively provides, such as their name and mailing address,[7] as well as, according to the EDPB, data that is "observed" from the user's activity, such as their search history or location data.
EDPB: Inferred data and derived data are created by the data controller on the basis of the data “provided by the data subject”. For example, the outcome of an assessment regarding the health of a user or the profile created in the context of risk management and financial regulations (e.g. to assign a credit score or comply with anti-money laundering rules) cannot in themselves be considered as “provided by” the data subject. Even though such data may be part of a profile kept by a data controller and are inferred or derived from the analysis of data provided by the data subject (through his actions for example), these data will typically not be considered as “provided by the data subject” and thus will not be within scope of this new right.[8]
However, it should be noted that there is a doctrinal debate regarding whether or not "observed data" should be included within the scope of application of portability. One argument in favor of a restrictive approach aims to limit the provision of data only to the types necessary for offering a comparable service. However, inferred or derived data, which is created by the data controller based on the data provided by the data subject, is not covered by the right to data portability.[9] This is one of the most remarkable differences between portability and access under Article 15(3) GDPR.
In a structured, commonly used and machine-readable format
According to Recital 68, the data should be available in an "interoperable format", which data controllers "should be encouraged to develop". In turn, "interoperable" refers to the ability of disparate and diverse organisations to "interact towards mutually beneficial and agreed common goals, involving the sharing of information and knowledge between the organisations, through the business processes they support, by means of the exchange of data between their respective ICT systems."[10]
According to Article 20(1) GDPR the data should be provided to the data subject in a "structured, commonly used and machine-readable format". Beyond this requirement, the GDPR does not call for a specific format to be used. The terms “structured”, “commonly used” and “machine-readable” are a set of minimal requirements that should facilitate the "interoperability" of the data format provided by the data controller.[11] Formats subject to costly licensing constraints are not considered "commonly used". The personal data provided should have a high level of abstraction from any internal or proprietary format, and metadata should be used to describe the exchanged information accurately.[12]
Industry stakeholders and trade associations are encouraged to work together on a common set of interoperable standards and formats to deliver the requirements of the right to data portability. The Commission has published a Communication on "ICT Standardisation Priorities for the Digital Single Market", which may be used as a basis on which to develop standards for the purposes of data portability.[13]
and the right to transmit (the data to another controller)
The right to data portability, as outlined in Article 20(1), enables data subjects to transmit their personal data from one data controller to another "without hindrance". This goes beyond the ability to simply obtain and reuse personal data and allows individuals to transfer their data to another service provider, regardless of whether it is within the same sector or not. By preventing "lock-in" situations, data portability empowers consumers and is expected to foster innovation and secure sharing of personal data between controllers under the control of the data subject. Additionally, it can enhance customer experiences by facilitating the controlled and limited sharing of personal data between organizations. This feature of data portability has the potential to facilitate the transfer and reuse of personal data among various services of interest to the user.
Without hindrance (from the first controller)
The GDPR's Article 20(1) guarantees that individuals have the right to transfer their data to another controller without facing any obstructions from the initial controller who provided the personal data. Such impediments can be identified as any legal, technical, or financial barriers that the data controller sets up to prevent or hinder the data subject's or another data controller's access, transmission, or reuse of the data.
Examples of such impediments include charges for data delivery, a lack of interoperability or access to a data format or API, excessive delays or complexity in retrieving the complete dataset, the intentional concealment of the dataset, or sector-specific standards or accreditation demands that are undue or excessive. The WP29 recommends that data controllers offer several options to the data subject. They suggest, for instance, that data subjects should be offered an opportunity to directly download the data as well as to transmit it directly to another data controller, and that this could be implemented by making an Application Programme Interface ('API') available.[14]
Simultaneously, the data controller must implement measures to ensure that they are truly representing the interests of the data subject. One way to achieve this is by instituting protocols to verify that only the specific personal data that the data subject wants to transmit is actually being transmitted. This verification process could involve obtaining confirmation from the data subject either prior to transmission, or at an earlier stage such as when they provide initial consent for processing or finalize the contract.[15]
Where these conditions cumulatively apply
The right to data portability only applies if (i) the individual has either consented to the processing or the information is processed for the execution of a contract between the data subject and controller and, in both cases, (ii) data is processed by automated means.[16]
(i) Processing is based on either consent or contract
The right to data portability, as per Article 20(1)(a), is only applicable when the processing of personal data by the controller is based on the data subject's consent in accordance with Article 6(1)(a), consent to the processing of special categories of personal data in accordance with Article 9(2)(a), or a contract in accordance with Article 6(1)(b) to which the data subject is a party. Recital 68 specifically highlights that the right to data portability should not be applicable if the processing is carried out on a legal basis other than the data subject's consent or a contract. Consequently, data obtained by the controller by processing personal data to protect its legitimate interests in accordance with Article 6(1)(f) is not covered by the right under Article 20 GDPR.[17]
(ii) Processing is carried out by automated means
The right to data portability under Art. 20(1)(b) only applies to processing that is conducted through automated means. This condition is generally met for internet service providers, but not for non-automated processing of personal data, such as data stored on structured index cards or in non-structured files. This limitation alleviates the controller's burden of converting non-machine-readable records into machine-readable data.[18]
(2) Right to have personal data directly transmitted to another controller
Article 20(2) introduces the right for data subjects to request that their personal data be transmitted directly from the first controller[19] to a second one.[20] This request, in line with the principle of facilitation, spares the data subject the burden of receiving the data and then sending it on to the intended controller. The request can be typically fulfilled through automated transmission, such as an application programming interface (API) that allows for data transfer to other systems implementing the same API. Therefore, it suffices if the data subject is given the opportunity to initiate the transfer by selecting a field labeled "Transfer of data to another provider" choosing a provider, selecting the data to be transferred, and clicking on a corresponding field to initiate the automated transfer.[21]
Where technically feasible
If the provider has not established an automated data transmission, they may be required to comply with Article 20(2) to the extent that it is "technically feasible".[22] Recital 68 states that the controller is not required to adopt or maintain technically compatible data processing systems. Therefore, the technical feasibility of direct data transfer is primarily dependent on the existing technical capabilities of the controller. However, according to Article 12(2) GDPR, the controller must facilitate the exercise of data subject rights, including the right to data portability. As such, the data subject may request reasonable cooperation from the controller, such as adapting data transmission formats, to carry out the intended portability.[23]
EDPB: Data controllers are expected to transmit personal data in an interoperable format, although this does not place obligations on other data controllers to support these formats. Direct transmission from one data controller to another could therefore occur when communication between two systems is possible, in a secured way29, and when the receiving system is technically in a position to receive the incoming data. If technical impediments prohibit direct transmission, the data controller shall explain those impediments to the data subjects, as his decision will otherwise be similar in its effect to a refusal to take action on a data subject’s request (Article 12(4)).[24]
(3) Other conditions
The first sentence of Article 20(3) GDPR clarifies that the exercise of the right to data portability does not preclude the exercise of any other rights under the GDPR. Thus, if data subjects want to delete their data from the controller's system (right to erasure under Article 17 GDPR), the controller cannot justify its denial to erase such data because of the data portability request.
The second sentence excludes that the right to data portability apply if the processing is necessary for the controller to perform a task that is in the public interest or carried out in the exercise of official authority. This exception corresponds to the legal basis of Article 6(1)(e) GDPR. In such cases, the public administration operating under public law is not required to provide data portability.
(4) Rights of third parties
In accordance with Paragraph 4, the right to data portability must not infringe upon the rights and freedoms of others, including both individuals and legal entities. When data is transferred with reference to a third party, such as transaction data from a current account agreement or data from the use of a webmail service, the rights and freedoms of others are generally not affected if the new provider uses the data solely under the control of the data subject and for the same purposes as before.[25] However, data transmission may be restricted by trade secrets, business secrets, or copyrights, such as those pertaining to software, if there is a specific risk of harm resulting from the transmission. Controllers cannot refuse to transfer data based solely on the possibility of such legally protected interests being infringed; instead, they must seek ways to transfer the data in a manner that avoids the disclosure of legally protected secrets.[26]
Relevance of other EU legislation
It is important to refer to the interplay of the right to data portability with the proposed or adopted legislation under the umbrella of the EU digital strategy[27].
The Digital Markets Act (DMA)[28] imposes a new obligation on "gatekeepers" that enhances the right to data portability. According to Article 6(9) DMA, gatekeepers shall provide an end user and third parties authorised by an end user with effective portability of data provided by the end user or generated through their activity through use of the gatekeeper’s core platform services (CPSs), including by the provision of continuous and real-time access to such data. Recital 59 DMA clarifies that this obligation on the gatekeeper complements the right to data portability under the GDPR.
Further, the proposed EU Data Act[29] that is supposed to help users of connected devices to unlock access to data generated by them, reinforces the right to data portability by creating an obligation on "data holders" to make available the data generated by such devices (Article 5). This obligation would empower a user (e.g. a data subject) to request the porting of personal and non-personal data from their Internet of Things devices (IoT) to a third party "without undue delay, free of charge to the user, of the same quality as is available to the data holder and, where applicable, continuously and in real-time". The scope of the data to be transmitted is not limited by the legal basis under which the data is processed by the "data holder" (e.g. controller) and therefore has the potential to unlock the portability of more data. Note: at the time of writing of this Commentary, the EU Data Act proposal was still under trialogues between the EU institutions (EU Commission, EU Parliament and the Council of Ministers).
Decisions
→ You can find all related decisions in Category:Article 20 GDPR
References
- ↑ The purpose of the right to data portability is to give data subjects more control over their personal data by granting them a certain type of "ownership". Regulators’ objective was to increase competition on the market by allowing for the free movement of data between providers. Data portability is especially relevant in cases when one controller offers a higher level of protection of personal data than another within the same industry sector or across sectors.
- ↑ EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, p. 5 (available here).
- ↑ However, it is always important to keep these two rights distinct. The right of access enables individuals to obtain information about the processing and a copy of the personal data held by the controller, in order to ensure transparency and allow for further actions by the data subject. On the other hand, data portability has a distinct economic feature. It allows for a copy of the data - which is also different and more limited than that under Article 15 - to be obtained, and the possibility to send such a dataset to another controller for similar or different purposes (i.e., essentially a competitor). In any case, a request must be made, even electronically. The controller must facilitate the request, including the authentication of the data subject (Article 12(2) GDPR). Obstructive practices in this area not only unduly limit the requester's subjective right, but also harm the single market and the free movement of personal data, creating real anti-competitive phenomena or "lock-in" effects.
- ↑ EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, p. 14-15 (available here).
- ↑ EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, p. 16 (available here).
- ↑ EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, p. 9 (available here).
- ↑ The data "provided" is the data that was actively given to the controller (e.g. photos uploaded to the service) or which was "observed" by a controller (e.g. activity logs, food preferences). This definition also includes data that has been transferred to the controller in the context of the exercise of the right to data portability. Herbst, in Kühling, Buchner, DS-GVO BDSG, Article 20 GDPR, margin number 11 (C.H. Beck 2020, 3rd Edition).
- ↑ EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, p. 10 (available here).
- ↑ Kamann, Braun, in Ehmann, Selmayr, Datenschutz-Grundverordnung, Article 20 GDPR, margin number 13 (C.H. Beck 2018, 2nd Edition).
- ↑ The WP29 defines interoperability as the "capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units". EDPB, ‘Guidelines on the right to data portability’, 16/EN WP 242 rev.01, 5 April 2017, 17 (available here).
- ↑ In that way, “structured, commonly used and machine readable” are specifications for the means, whereas interoperability is the desired outcome.
- ↑ EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, pp. 16-18 (available here).
- ↑ EU Commission Communication on ICT Standardisation Priorities for the Digital Single Market (Available here).
- ↑ Cormack expresses doubts regarding the viability of this solution, noting that many organisations will hold their data on internal databases that are securely firewalled from internet access as opposed to APIs. Without standards leading to interoperability, the right to data portability may "remain more a declaration of principle than a real and effective tool for individual self-determination in the digital environment". See, Lynskey in Kuner, Bygrave, Docksey, The EU General Data Protection Regulation (GDPR): A Commentary, Article 20 GDPR, p. 505 (Oxford University Press 2020).
- ↑ EDPB, Guidelines on the right to data portability under Regulation 2016/679, WP242 rev.01, pp. 16-18 (available here).
- ↑ For example, data which is only available on paper and manually processed falls out of the scope data portability.
- ↑ However, according to the WP29, it is a good practice to address portability requests also in such cases that do not explicitly provide for a general right to data portability, i.e. when processing is based on the legitimate interests or for the performance of a task carried out in the public interest. See, WP29, ‘Guidelines on the right to data portability’, 16/EN WP 242 rev.01, 5 April 2017, p. 8 (available here).
- ↑ Herbst, in Kühling, Buchner, DS-GVO BDSG, Article 20 GDPR, margin number 13 (Beck 2020, 3rd edition).
- ↑ Controllers that address portability requests ("sending controllers") act on behalf of a data subject and are responsible for providing prior information about the right’s existence (e.g. in the privacy notice) and clearly explaining the difference between the right of access and the right to data portability; processing the request without undue delay, within 1 month (up to 3 months); carrying out authentication; setting safeguards to ensure they genuinely act on the data subject’s behalf (e.g. ensure that they transmit the exact type of personal data that the data subject wants to receive); in light of the principles set forth in Article 5(1) GDPR, ensuring that the data transmitted is accurate and up to date; and, taking all necessary security measures for transmissions. The sending controllers are, however, not responsible for the processing handled by the data subject or by another company receiving personal data. In this respect, "the data controller is not responsible for compliance of the receiving data controller with data protection law, considering that it is not the sending data controller that chooses the recipient". See, WP29, ‘Guidelines on the right to data portability’, 16/EN WP 242 rev.01, 5 April 2017, 6 (available here).
- ↑ Data controllers that receive portability requests ("receiving controllers") have an obligation to "clearly and directly" state the purpose of the new processing before they accept the request in accordance with the transparency requirements set out in Article 14 GDPR; process the request without undue delay, within 1 month (up to 3 months); ensure that the data they accept is relevant and not excessive for the intended data processing; delete the personal data which are not necessary to achieve the purpose of the new processing as soon as possible. The receiving controllers can decide whether to accept and process data from a portability request.
- ↑ Herbst, in Kühling, Buchner, DS-GVO BDSG, Article 20 GDPR, margin number 25 (Beck 2020, 3rd edition).
- ↑ It should be noted that the "where technically feasible" safeguard clause only applies to the direct transmission from one controller to another under paragraph 2. Therefore, it does not apply to the scenario outlined in paragraph 1 where the data subject directly requests to receive the data. Such requests shall always be fulfilled, regardless of technical reasons.
- ↑ Herbst, in Kühling, Buchner, DS-GVO BDSG, Article 20 GDPR, margin number 27 (Beck 2020, 3rd edition).
- ↑ WP29, ‘Guidelines on the right to data portability’, 16/EN WP 242 rev.01, 5 April 2017, 6 (available here).
- ↑ The portability request should not include any third party data if there is a likelihood that the new processing will adversely affect the rights and freedoms of the other data subjects. "Such an adverse effect would occur, for instance, if the transmission of data from one data controller to another, would prevent third parties from exercising their rights as data subjects under the GDPR." See, WP29, ‘Guidelines on the right to data portability’, 16/EN WP 242 rev.01, 5 April 2017, 11 (available here).
- ↑ Dix, in Simitis, Hornung, Spiecker gen. Döhmann, Datenschutzrecht, Article 20 GDPR, margin number 18 (C.H. Beck 2019).
- ↑ European Commission, 'A Europe fit for the digital age' (available here)
- ↑ Regulation (EU) 2022/1925 of the European Parliament and of the Council of 14 September 2022 on contestable and fair markets in the digital sector and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets Act) (Text with EEA relevance) (available here).
- ↑ Proposal for a Regulation of the European Parliament and of the Council on harmonised rules on fair access to and use of data (Data Act) (available here).