This series provides more detailed insight into the General Data Protection Regulation, which was published on 4 May 2016 and must be complied with by 25 May 2018.

This issue focuses on the new right to data portability, including the Guidelines and FAQs recently issued by the Article 29 Working Party ("Article 29 WP"). These documents are of particular importance as they provide guidance on how to interpret the GDPR requirements for the right to data portability. It should be noted, however, that we have serious concerns about the application of these requirements in practice.

The Article 29 Working Party Guidelines are not yet final and stakeholders can submit comments through January 2017 to JUST-ARTICLE29WP-SEC@ec.europa.eu and presidenceg29@cnil.fr.

Skip to the end for a brief overview of the main takeaways and to do's as well as our concerns.

Basic principle: right of the data subject to be given his or her personal data and to pass them on to another controller

Article 20 of the GDPR provides for the new right to data portability. Pursuant to this right, data subjects are entitled to (i) receive in a structured, commonly used and machine-readable format the personal data they previously provided to the data controller and (ii) (if they wish) transmit the data to another controller without hindrance. The rationale behind this right is to ensure that data subjects have more control over their personal data and are able to easily switch providers or reuse their personal data to obtain other services.

Clarification by the Article 29 WP: provisional guidelines on the right to data portability

By means of a set of provisional guidelines adopted on 13 December 2016 (the "Guidelines"), the Article 29 Working Party has provided welcome clarification on the new right to data portability.

Scope of application of the right

The right to data portability applies to the extent the following three cumulative conditions are met:

  1. The requested personal data are processed by automatic means (i.e. excluding paper files) on the basis of the data subject’s prior consent or in the context of the performance of a contract to which the data subject is a party.

  2. The requested personal data relate to the data subject and are provided by him or her. The wording "relate to the data subject" should not be interpreted too restrictively by data controllers, meaning they should also honour data portability requests even when personal data of third parties are contained in the data set relating to and provided by the data subject (e.g. telephone records). The new wording "provided by" should be interpreted quite broadly to include both personal data that are knowingly and actively provided by the data subject (e.g. age, date of birth and contact details) as well as data indirectly "provided" by the data subject through use of a service or device (e.g. search history and location data) but not personal data inferred or derived by the data controller from data provided by the data subject (e.g. a credit rating or health score resulting from the application of algorithms to the data subject's personal data).

  3. The rights and freedoms of third parties are not adversely affected by exercise of the right to data portability. In this regard, there are two possible situations:

    (1) The requested personal data contain data pertaining to other data subjects. In this case, the new data controller to whom the requested personal data are transmitted can only process the personal data of other data subjects if there is an appropriate legal ground for doing so.

    (2) The requested personal data contain or reveal data covered by intellectual property rights (e.g. software copyright) and/or trade secrets of the data controller. The Guidelines note that although such rights and the potential business risks should be taken into account, this alone is not a sufficient ground to refuse to grant a portability request since the data controller can transfer the requested personal data in a way so as not to release protected information.

Responsibility

The data controller is responsible for honouring the data subject's right to data portability but not for any subsequent processing handled by the data subject or another company that receives the personal data (the receiving data controller). The receiving data controller is responsible, for instance for ensuring that the data provided are relevant and not excessive for the purposes of the new processing.

Information to be provided to and identification of the data subject

Data controllers should inform data subjects of the existence of the right to data portability in a clear and comprehensive yet concise manner. In this regard, the Article 29 WP recommends clearly explaining the differences between the types of data a data subject can receive by exercising the right to data portability versus the right of access, specifically informing the data subject of the right to data portability before any account closure. Furthermore, the Guidelines recommend that the receiving data controller inform the data subject of the nature of personal data relevant to performance of the services. Lastly, data controllers should put in place appropriate procedures enabling data subjects to make data portability requests, including an authentication procedure to verify the identity of the requesting data subject.

Practicalities

A data portability request must be honoured or refused without undue delay and in any case within one month from receipt of the request or within a maximum period of three months for complex cases, provided the data subject is informed of the reasons for the delay within one month from the original request. In terms of cost, data portability requests should be honoured free of charge unless the data controller can demonstrate that the requests are manifestly unfounded or excessive, in particular due to their repetitive character. Such exceptions should however be interpreted very restrictively, with excessiveness analysed with reference to a specific request rather than overall data portability implementation costs.

Expected data format

As expressly stated in the GDPR, the requested personal data must be provided in a structured, commonly used and machine-readable format. This is considered a minimum standard to facilitate the desired outcome of interoperability, not compatibility, of the data formats provided by data controllers. Furthermore, data controllers should provide as much metadata as possible with the data, at the best possible level of granularity, in order to preserve the precise meaning of the information exchanged (e.g. providing the data subject with a pdf version of emails would hinder the ability to re-use the data). The GDPR and the Guidelines do not however provide specific recommendations regarding the format in which personal data should be provided. The most appropriate format will thus vary from one sector to another; while adequate formats may already exist, a format should always be chosen to achieve the purpose of interoperability. In this context, the Guidelines strongly encourage cooperation between industry stakeholders and trade associations to agree on a common set of interoperable standards and formats that meet the requirements of the right to data portability.

Recommended data portability tools

The data controller should offer data subjects the possibility of direct download and allow them to directly transmit the data to another data controller, for instance by making available an application programming interface (API).

Our concerns

  • Strict requirements yet lack of clear instructions and a hands-on approach: The Guidelines impose strict requirements on data controllers but without providing them with clear instructions on how to comply with the right to data portability. It is particularly unfortunate that the Article 29 WP did not examine the data portability mechanisms currently used by IT service providers to meet these requirements under other legislation, such as mobile and utilities contract termination.

    Furthermore, the Guidelines do not contain instructions on encryption requirements when transferring or storing personal data even though a lack of encryption can pose serious security and privacy risks.

    Instructions on logging and monitoring access to personal data during the transfer process are also missing. Nonetheless, it is important that logging and monitoring occur.

  • Security risks associated with an API or direct download possibility: The Guidelines mention that the data controller must allow data subjects to directly transmit their data to another data controller, for instance by making available an application programming interface (API). It should be noted, however, that an API could undermine the obligation to have appropriate security measures to protect personal data from, amongst other things, unauthorised processing and access (Article 32 of the GDPR). Indeed, an API provides an additional gateway for hackers to obtain access to data from all connected systems.

Takeaways and to do's

Please click here to view table

Relevant provisions

Recital 68

Articles 13.2(b), 14.2(c) and 20