24# Data Subject Rights – The right to data portability

Thank you, Anna, for all the wonderful insights into the data subjects’ rights. I’m going to continue in your spirit and talk more about some other data subjects’ rights, and today, the right to data portability.

The right to data portability means that you as the controller must give the data subjects the right to:

1. Receive the personal data concerning them, which they have provided to you
2. Transmit personal data concerning them, which they have provided to you, to another controller without hindrance from you.

This right is not an absolute right, meaning that there are derogations and rules on when it applies. The rules of application are as follows: the lawful basis for the processing will have to be either consent or for the performance of a contract. The second rule is that the processing will have to be by automated means. If you recall, the GDPR applies to processing by wholly or partly automated means and processing that form part of a filing system or is intended to form part of a filing system. The second rule excludes the latter.

Looking at the two rights, they both state that it is personal data that they have provided to you. The WP29 have stated that there are at least two categories of personal data that is provided by the data subject:

• Data actively and knowingly provided by the data subject
• Observed data provided by the data subject by virtue of the use of the services or devices

That could be mailing address, username, age, or data from a device or service like the history of website usage or search activities, traffic and location data, and other raw data from connected objects such as smart meters and wearable devices.

The WP29 is very clear that the rights to receive and transmit do not include any additional data that you have created based on the personal data that the data subject has provided to you. It is so-called inferred or derived data, which is, for example, credit scoring, evaluations and assessments based on the provided personal data.

You are supposed to carry out the data subject’s request without hindrance, meaning that you should not put in place any legal, technical, or financial obstacles for the data subject. There might, however, be a legitimate reason why you cannot carry out the request, which is if the request would adversely affect the rights and freedoms of others. Two examples of that are if the request would infringe on intellectual property rights or trade secrets. It is still your responsibility to justify the reasons for not complying with the request and for proving that non-compliance is indeed legitimate.

Any decision to carry out the request or to refuse to act upon the request has to be explainable and justifiable. The data subjects need to be informed about their right to lodge a complaint to the supervisory authority and their ability to seek to enforce their rights through a judicial remedy when a decision is handed to them.

If you grant the data subject’s request, you should provide the personal data to the data subject in a structured, commonly used, and machine-readable format. Here is a brief explanation of the requirements:

• Structured; the 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.
• Commonly used; that the format you choose must be conventional and well-established.
• Machine-readable; the data can be made directly available to applications that request that data.

The aim of these words, according to the WP29, is to provide for an interoperable format to be used by controllers. The interoperable format is something that allows data to be exchanged between different systems and be understandable to both. Examples of formats are CSV, XML, and JSON, but the appropriate format will depend on the circumstances.

If you look at the 2nd right in the list, the data subject may ask you to transmit the data to another controller. That is, however, only if it is technically feasible. This does not create an obligation for controllers to adopt or maintain processing systems that are technically compatible. You will need to take appropriate measures to ensure that the respective personal data is transmitted securely and to the right destination when you transmit.

As a good practice, you should have a system to answer data portability requests and a download tool for personal data, etc. Having tools on your side should guarantee that personal data are transmitted in a structured, commonly used and machine-readable format. They should ensure the interoperability of the data format provided in the exercise of a data portability request. DPOrganizer’s tool makes responding to a right to data portability request easy by having your processing operations mapped, which would be a time-saver in identifying what data are processed, where, how, and why. You can also create a request case and have a case log readily available for responding to the request.

Next week, I’m going to talk a bit about the data subjects’ right to object. If you have any questions about this week’s content, you can reach me via mail on albin.thelin@nulldporganizer.com or other privacy professionals at the community called Watercooler. Until then!