The right to data portability under EU data protection law

Lydia F de la Torre
Feb 22 · 12 min read
Storing the harvester — : Gift of Australian Consolidated Press under the Taxation Incentives for the Arts Scheme, 1985 — Powerhouse Museum

Key points:

The right to data portability allows data subjects to obtain and reuse personal data about them for their own purposes across different services.

It allows data subjects to move, copy or transfer personal data easily from one IT environment to another in a safe and secure way without affecting its usability.

This enables data subjects to take advantage of different applications and services that can use their data to find them a better deal or help them understand their spending habits.

The right only applies to information a data subject provided to a controller.

What is the right to data portability and why is it important?

The right to data portability gives data subjects the right to receive back the personal data they provided to a controller in a structured, commonly used and machine readable format. The right to data portability entitles the data subject to:

  • receive a copy of their personal data; and/or
  • have their personal data transmitted from one controller to another controller.

Data subjects have the right to receive their personal data and store it for further personal use. This allows the data subjects to manage and reuse their personal data. For example, an individual wants to retrieve their contact list from a webmail application to build a wedding list or to store their data in a personal data store.

Article 20 of GDPR specifies:

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.

The right to data portability does not apply to genuinely anonymous data. However, pseudonymous data that can clearly be linked back to a data subject (e.g. where that individual provides the respective identifier) is within scope of the right.

The right to data portability is not an absolute right. It only applies when:

  • The lawful basis under which the controller is processing the information is either the consent of the data subject or for performance of a contract;
  • The data processing is automated (i.e. excluding paper files); and
  • The personal data in question has been ‘provided to’ the controller by the data subject.

‘Provided to a controller’:

  • Includes both the data proactively shared by the data subject (e.g. mailing address, username, age) and personal data gathered by observation of an individual’s activities (e.g. where using a device or service). This may include:
  • history of website usage or search activities;
  • traffic and location data; or
  • ‘raw’ data processed by connected objects such as smart meters and wearable devices.

It does not include any additional data extrapolated by the controller based on the data an individual provided. For example, if a controller used data to create a user profile, such a profile is not be in scope of data portability (although it would be within the scope if the data subject were to request access.

Handling a request for data portability

EU data protection law does not specify how to make a valid request. Therefore, an individual can make a request for rectification verbally or in writing. It can also be made to any department of the organisation — the request does not have to be directed to a specific person or contact point. A request to rectify personal data does not need to mention the phrase ‘request for rectification’ or a specific legal provision to be valid. As long as the individual clearly challenged the accuracy of their data and asked for it to be corrected, or has asked that the controller take steps to complete data, the request is valid.

Because any employee could potentially receive a valid request, it is important to train staff who regularly interact with data subjects to identify a request. Additionally, it is good practice to:

  • have a policy for recording details of the requests received, particularly those made by telephone or in person;
  • check with the requester to make sure the request is clearly understood, which can help avoid later disputes about how the controller interpreted the request; and
  • keep a log of verbal requests.

Where there are doubts about the identity of the person that made the request it is possible to ask for more information. However, it is important that only the information that is necessary to confirm who they are is requested. The key to this is proportionality. The period for responding to the request begins when the additional information is received. The controller must inform the data subject without undue delay about:

  • the reasons the controller is requesting additional information;
  • their right to make a complaint to supervisory authority; and
  • their ability to seek to enforce this right through a judicial remedy.

If a valid request for data portability is received, all steps to ensure compliance must be taken. Controllers can achieve this by either:

  • directly transmitting the requested data to the individual; or
  • providing access to an automated tool that allows the individual to extract the requested data themselves (this does not create an obligation for controllers to allow data subjects a more general and routine access to their systems — only for the extraction of their data following a portability request).

Where data subjects request controllers to transmit their personal data directly to another controller, controllers must comply if it is ‘technically feasible’.

  • The technical feasibility must be considered on a request by request basis;
  • The right to data portability does not create an obligation for controllers to adopt or maintain processing systems which are technically compatible with those of other organizations (see, GDPR Recital 68);
  • Controllers should take a reasonable approach, and this should not generally create a barrier to transmission.

Controllers must comply with requests for data portability ‘without hindrance’. This means:

  • controllers should not erect any legal, technical or financial obstacles which slow down or prevent the requested transmission of personal data to the data subject or to another organization.

The controller is responsible for transmitting the data and must to take appropriate measures to ensure that it is transmitted securely and to the right destination.

The controller should provide the personal data in a format that is ‘structured’, ‘commonly used’ and ‘machine readable’. These terms are not defined in the GDPR. As a general rule :

  • Structured: Structured data facilitates efficient transfers and increases usability. The Open Data Handbook defines ‘structured data’ as: ‘data where the structural relation between elements is explicit in the way the data is stored on a computer disk.’ This means that software must be able to extract specific elements of the data. An example of a structured format is a spreadsheet, where the data is organised into rows and columns, i.e. it is ‘structured’. If a format is structured it is generally also machine-readable.
  • Commonly used: This simply means the format must be widely-used and well-established. However, just because a format is ‘commonly used’ does not mean it is appropriate for data portability. Controllers must consider whether it is ‘structured’ and ‘machine-readable’ as well.
  • Machine-readable: The Open Data Handbook states that ‘machine readable’ data is: ‘Data in a data format that can be automatically read and processed by a computer.’ Machine-readable data can be made directly available to applications that request that data over the web. This is undertaken by means of an application programming interface (“API”). Controllers that are able to implement such a system can facilitate data exchanges with data subjects and easily respond to data portability requests.

Controllers must consider the format to be used. In particular:

  • ‘Interoperable’ format: the GDPR encourages but does not require controllers to use an interoperable format. Recital 68 provides: ‘Data controllers should be encouraged to develop interoperable formats that enable data portability.’ Interoperability allows different systems to share information and resources. An ‘interoperable format’ is a type of format that allows data to be exchanged between different systems and be understandable by both. Data portability is intended to produce interoperable systems, not compatible ones.
  • ‘Appropriate’ format: Controllers may already use an appropriate format within their networks and systems, and/or may be required to use a particular format due to the particular industry or sector where they operate. Provided the format meets the requirements of being structured, commonly-used and machine readable, then it could be appropriately utilized for a data portability request.
  • ‘Proprietary’ formats: EU data protection law does not require controllers to use open formats internally. Controller’s processing systems may indeed use proprietary formats which individuals may not be able to access. In such cases, controllers need to perform some additional processing on the personal data in order to convert it into the type of format required by EU data protection law.
  • ‘Open’ formats (CVS, XML and JSON): Where no specific format is commonly used within the industry or sector where the controller operates, controllers can provide the personal data using open formats such as CSV, XML and JSON.
  • CSV stands for ‘Comma Separated Values’: It is defined by the Open Data Handbook as: ‘a standard format for spreadsheet data. Data is represented in a plain text file, with each data row on a new line and commas separating the values on each row. As a very simple open format it is easy to consume and is widely used for publishing open data.’ CSV is used to exchange data and is widely supported by software applications. Although CSV is not standardised it is nevertheless structured, commonly used and machine-readable. Therefore, CSV is an appropriate format to respond to a data portability request.
  • XML stands for ‘Extensible Markup Language’: It is defined by the Open Data Handbook as: ‘a simple and powerful standard for representing structured data.’ It is a file format intended to be both human and machine-readable. Unlike CSV, XML is defined by a set of open standards maintained by the World Wide Web Consortium (“W3C”). It is widely used for documents but can also be used to represent data structures such as those used in web services. This means XML can be processed by APIs, facilitating data exchange. For example, you may develop or implement an API to exchange personal data in XML format with another organisation. In the context of data portability, this can allow you to transmit personal data to an individual’s personal data store, or to another organisation if the individual requests.
  • JSON stands for ‘JavaScript Object Notation’: The Open Data Handbook defines JSON as: ‘a simple but powerful format for data. It can describe complex data structures, is highly machine-readable as well as reasonably human-readable, and is independent of platform and programming language, and is therefore a popular format for data interchange between programs and systems.’ It is a file format based on the JavaScript language that many websites use primarily as a data interchange format. As with XML it can be read by humans or machines. It is also a standardised and open format maintained by the W3C.

CSV, XML and JSON are three examples of structured, commonly used and machine-readable formats that are appropriate for data portability. However, this does not mean controllers are required to use them. Other formats exist that also meet the requirements of data portability.

Example

The RDF or ‘Resource Description Framework’ format is also a structured, commonly-used, machine-readable format. It is an open standard published by the W3C and is intended to provide interoperability between applications exchanging information.

Controllers should, however, consider the nature of the portability request. If the individual cannot make use of the format, even if it is structured, commonly-used and machine-readable then the data will be of no use to them.

Responsibility for complying with requests lies with the controller. Controllers must ensure that they have contractual arrangements in place to guarantee requests are dealt with properly, irrespective of whether they are sent to the processor. The time to comply with a request cannot be extended on the basis that the controller has to rely on a processor to provide the information.

What happens if the personal data includes information about others?

If the requested information includes information about others (eg third party data) the controller needs to consider whether transmitting that data would adversely affect the rights and freedoms of those third parties.

Generally speaking, providing third party data to the individual making the portability request should not be a problem, assuming that the requestor provided this data in the first place. However, the controller should always consider whether there will be an adverse effect on the rights and freedoms of third parties, in particular when transmitting data directly to another controller.

If the requested data was provided to you by multiple data subjects (e.g. a joint bank account), the controller needs to be satisfied that all parties agree to the portability request. This may require agreement from all the parties involved.

Time to comply, extensions, refusals and charging fees

Time to comply and extensions

See, Data Subject Rights under EU data protection law

Refusing to comply with a request

There may be legitimate reasons why a controller cannot undertake a transmission. For example, if the transmission would adversely affect the rights and freedoms of others. It is however the responsibility of the controller to justify that these reasons are legitimate and not a ‘hindrance’ to the transmission.

In addition, the right to data portability can also be restricted under Member State law in certain circumstances (see, the section on “Restrictions on the rights of individuals” here)

Finally, if the controller considers that the request is manifestly unfounded or excessive, it can:

  • request a “reasonable fee” to deal with the request; or
  • refuse to deal with the request.

If the request is refused, the controller must inform the data subject without undue delay and within one month of receipt of the request about:

  • the reasons the controller is refusing to restrict the processing of the data;
  • their right to make a complaint to supervisory authority; and
  • their ability to seek to enforce this right through a judicial remedy.

There can be additional bases to refuse a request under Member State law.

Charging a fee

See, Data Subject Rights under EU data protection law

Responsibility for personal data after it is transmitted to others

The controller is responsible for the transmission of the data and must take appropriate measures to ensure that it is transmitted securely and to the right destination. However, once the information is provided directly to an individual or to another organization, the controller is not responsible for any subsequent processing carried out by the individual or the other organization.

It is a good practice to make data subjects aware of the sensitivity of the data so that they can take steps to protect the information they receive.

Responsibilities of a controller that receives personal data from a data portability request

When a controller receives personal data as part of a data portability request, it needs to process this data in line with data protection requirements.

In deciding whether to accept and retain personal data, the controller should consider whether the data is relevant and not excessive in relation to the purposes for which it will be processed. The controller must also consider whether the data contains any third party information.

New controllers must ensure that they has one or more lawful bases for processing any third party data, and that this processing does not adversely affect the rights and freedoms of those third parties. If a controller receives personal data which it has no reason to keep, it should delete the data as soon as possible.

Example

An individual entered into a contract with a controller for the provision of a service. The controller relies on Article 6(1)(b) to process the individual’s personal data. The controller receives information from a data portability request that includes information about third parties. The controller has a legitimate interest to process the third party data under Article 6(1)(f) so that it can provide a service to the individual. However, the controller should not then use this data to send direct marketing to the third parties.

ICO’s Checklist

Available at the UK Information Commissioner’s Website https://ico.org.uk/

RELEVANT PROVISIONS

Relevant provisions in the GDPR — See Articles 13, 20 and Recital 68.

ADDITIONAL RESOURCES

The European Data Protection Board has published guidelines and FAQs on data portability for organizations.

Further reading on formats:

Future of Privacy Forum CPDP 2019 Panel: Understanding the limits and benefits of data portability

Golden Data

Legal blog about data laws

Lydia F de la Torre

Written by

Teacher. Counsel. Author. Queen bee.

Golden Data

Legal blog about data laws

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade