Right to Data Portability, i.e. How to Transfer Data from One Controller to Another (Article 20 GDPR) (Chapter 2, Section 8) — Guide to the GDPR

The right to data portability is a new right that has never existed before in personal data protection laws. It was implemented into the legal system in GDPR. This is a right that had to be granted to data subjects due to the rapid development of services based on new technologies, in particular those that use automated personal data processing.

The right to data portability is intended to prevent technological dependence on the services of a particular provider by reducing the cost of discontinuing one service in order to move data to another service or receive transferred data (so-called vendor lock-in). It is aiming to be practical in nature from the point of view of those who make use of everyday services, as it helps when changing service providers. Instead of rewriting data into a new system, it will be sufficient to submit a request to the current service provider (controller) to transfer the personal data to another, specified, service provider. This was, in fact, the aim of EU lawmakers, who wished to increase competitiveness on the market by introducing the right to data portability. This is a consumer-friendly right, and there are rights similar in nature and purpose in other industry regulations, whether they are payment services, where accounts can be transferred between banks, or telecommunications services, where telephone numbers can be moved between various providers.

Executing the right of data portability entails a number of practical issues.

There are two elements to the right to data portability:

This means that the data subject can not only request that they be provided with data that they provided previously, which can be demanded in connection with the right to copies of data, but also request that the data be transferred directly to another specified controller.

The difference between the right to copies of data and the right of data portability is that the right of data portability includes the right to receive the data in a format that can be uploaded, i.e. automatic insertion into the new provider’s system or the organisation’s IT system.

The right of data portability is not a general right and does not apply in each case or to each method of processing personal data. The data subject can exercise this right where personal data are processed upon prior consent or on the basis of a contract. Also, the data must be processed in an automated fashion. This means that where personal data are processed on paper or on a basis other than consent or contract (e.g., based directly on law – legal obligation, public duty, public authority), the data subject is not entitled to request that the controller move the data to another controller. Automatic personal data processing also occurs where data are sent on paper and then digitally converted and saved in the form of files (though a structure of such digitalised data strictly depends on a degree of automation of their processing).

Under Article 20(1) GDPR, an individual is entitled to be provided with ‘data concerning him or her, which he or she has provided to a controller’.

‘Data provided by the data subject’ include data provided by an individual directly, such as contact details and identifying data, or their CV, and content concerning that person (even if including data of other persons), which the person placed in the controller’s resources in performance of an agreement with the controller or on the basis of consent granted to the controller for the processing of that information.

As the author (Maciej Gawronski) intended, inclusion of the right of data portability in personal data protection laws was not aimed at limiting the scope to data that are stricte personal data. It was intended to apply to all data placed in the controller’s system (and systems of the controller’s subcontractors) by the individual. This is the way EU lawmakers interpret and defined this right in the GDPR.

The Article 29 Working Party’s view is that the right of data portability also includes data with which the controller is provided through the actions (behaviour) of the data subject, for example electricity consumption history (meter readings), or readings of smart wearable fitness bands – say ‘data observed/data registered’. The guidelines on the right of data portability state that the data provided should also include ‘personal data resulting from observation of activities of users, such as raw data processed by a smart meters or other types of connected objects, activity logs, history of website usage or search activities’. This concept is in line with the EC’s intentions behind the introduction of the right of data portability.

Execution of the right of data portability should, therefore, include data generated by the data subject’s actions, for example loan repayment history, account history, electricity consumption history, and information placed in a customer relationship management system.

In this situation, a right that is apparently quite clear and simple to execute becomes a challenge for the controller, as the controller has to collect and then transfer a much broader range of data.

The scope of data transferred in machine-readable form does not have to include data generated by the controller as a result of its own analyses, for example a certain profile or internal rating attributed to a customer. This may be deceptive, however. An individual can obtain data of this kind through the right to copies of data (for which there is no limitation to data provided solely by the data subject). Moreover, in case of profiling resulting in material consequences for the data subject (legal effects or similarly significantly affecting the data subject – Article 22 GDPR), the controller is obliged by Article 13(2)(f) and Article 14(2)(g) GDPR) to provide to the data subject meaningful information about the logic involved in such automated processes. Those GDPR provisions create the ‘right to know why’ which corresponds to a recently articulated right to understand the logic underlying artificial intelligence decisions.

Meanwhile, the issue of the mandatory scope of data subject to transfer is not entirely clear. The EC is experimenting by introducing Article 20 GDPR and is well aware of this.

Another task faced by a controller when executing the data portability right is the manner and form in which it should happen. Article 20 GDPR states as follows:

The data subject shall have the right to receive the personal data concerning him or her in a structured, commonly used and machine-readable format.

The Article 29 Working Party has also formulated guidelines on this provision, stating that in addition to formats usually used in a particular sector, ‘controllers should provide personal data using commonly used formats (e.g. XML, JSON, CSV) along with useful metadata at the best possible level of granularity’. This means that this right cannot be executed using the popular PDF format. It will be sufficient however to save data in XML format and transfer the data to the specified controller. One can imagine various scenarios for the procedure: starting with the now somewhat old school method of saving data on a CD or other type of data carrier and then sending them by courier service to the specified recipient, through sending an encoded file by email, to using an application programming interface (API). The choice of the manner in which the right of data portability is executed will depend on the industry sector in which the controller operates and the scale of requests from customers (data subjects). Sometimes a regulator may enforce full automating of data portability (i.e., creating proper APIs) like in case of account information services and payment initiation services introduced by the so-called second EU Payment Services Directive requiring banks to open their systems to providers of such services.

The data must be suitable for import via a different system or application, using a simple ‘open file’ or ‘import data’ option. The controllers exporting data should not impose unnecessary restrictions on the controller importing data or the data subject. Article 20(1) GDPR states clearly that data is transferred ‘without hindrance from the controller’. Hindrance can take various forms, from charging extra fees, implementing an unclear and complicated procedure for execution of the right, imposing discriminatory security requirements, to simply delaying its execution.

Finally referring to the receipt of data (or import of data in the IT meaning), the Article 29 Working Party says that controllers transferring data are not responsible for the processing of data by the data subject or by the controller to which the data are transferred. A controller transferring data is also not required to review and verify the quality of the data before sending them.

There are limitations on the right to portability of data.

Above all, to reiterate, transfer of data can be requested if the data have been made available to the controller on the basis of consent or a contract. Therefore, data portability does not apply to data processed to perform a task carried out in the public interest or in the exercise of official authority vested in the controller, for compliance with a legal obligation, processed to protect a vital interest, and when the controller collects and processes data for the purpose of legitimate interests pursued by the controller or by a third party. These ‘limitations’ follow from the function and envisaged purpose of the right of data portability, which is to enable transfer of data between various service providers – thereby reducing dependence on a particular service provider (often called ‘vendor lock-in’) due to the costs and effort involved in moving (‘exit costs’).

An exception sensu stricto preventing the execution of the right of data portability, under Article 20(4) GDPR, is the adverse effect of transferring data from one controller to another on the rights and freedoms of ‘others’. The same exception is provided for in Article 15(4) GDPR with respect to the right to copies of data. The right to copies of data cannot have an adverse effect on the rights and freedoms of persons or entities other than the data subject. Release of copies of data (including machinereadable) should therefore be refused where they also cover:

data of third parties, if release of the data would be a breach of the law;
court, disciplinary, or criminal proceedings, if release of copies of data would disrupt those proceedings;
information covered by exclusive rights – copyright, related rights, patents – if release of copies of data would breach these rights;
information subject to professional privilege, trade secrets, or other legally protected secrets of a third party, if release of copies of these data would be a breach of those secrets;
data that breach personality rights of persons other than the data subject.

Of course, there is also a question if and when the controller learns of a situation of this kind and how a controller intends to resolve it. A controller is not under an obligation to have information of that kind and in particular is not required to monitor the content of the data (as a rule it should not do this, in fact, to avoid unnecessary liability). If the controller does, in fact, learn in a reliable manner of this problem (potential breach of rights of ‘others’), it should not hand over the data. The situation is similar to the so-called notice and takedown procedure resulting from the EU E-Commerce Directive.

Some authors claim that as a rule a data controller is not allowed to hand over copies of data or transfer data containing third-party personal data (such as lists of contacts in an email system, lists of recipients of bank money transfers). This is incorrect and distorts the very essence of the right to copies of data. When processing data for household purposes, a natural person is not subject to the GDPR and is entitled to do so. Contact details or other data processed by a person exercising the data portability right are ‘theirs’, and as a rule the controller cannot contest this right.

But even if processing (possession) of certain third party personal data by a data subject falls under GDPR (such data subject being a controller or even a processor of such data) there is no reason to reject that data subject’s request to transfer data to another services provider (another controller) simply because the requested data include other people too.

In practice, the data portability right will probably be the most commonly exercised right with respect to providers of online services, for example banks, social networking sites, online stores, providers of electronic payment services, providers of email services and space for data storage, music websites, and other cloud service providers.

The data export service must have the appropriate safeguards, like any other data processing operation. For example, during C2C data transmission, an assessment must be conducted of the need for encryption and, where applicable, other safeguards. The differences in safeguards between one controller and another may be one of the causes preventing the transfer of data not involving the data subject (e.g., the requirement for separate authentication of the individual by the transferring controller and the receiving controller). These processes will definitely be more automated as certification becomes more common – then organisations in a single industry who are signatories to the same code of conduct will have the same security standards. This will still take some time to come about.

A controller is required to transfer data in a ‘structured, commonly used, and machine-readable format’; that is, the controller is required to employ some kind of generally accepted format for a file/data transmission. A controller is not required however to transfer data in an exotic format if the data recipient uses a format of that kind. The data portability right is technologically neutral. The aim is to facilitate the transfer of data between digital service providers, but there is no aspiration to introduce full interoperability standards in a single move.

#8.1 Preliminary Remarks

#8.2 What Exactly Does the Right of Data Portability Entail?

#8.3 When the Right of Data Portability Can Be Exercised?

#8.4 The Scope of Data to Be Transferred

#8.5 How the Right of Data Portability Should Be Executed?

#8.5.1 Exceptions

#8.5.2 Third-Party Rights

#8.5.3 Transfer of Data Concerning at the Same Time the Requesting Person and Another Person

#8.6 Who Is Affected the Most by Data Transfer?

#8.6.1 Security

#8.6.2 Technicalities