ARTICLE 29 DATA PROTECTION WORKING PARTY

16/EN WP 242 rev.01

Guidelines on the right to data portability

Adopted on 13 December 2016

As last Revised and adopted on 5 April 2017

This Working Party was set up under Article 29 of Directive 95/46/EC. It is an independent European advisory body ondata protection and privacy. Its tasks are described in Article 30 of Directive 95/46/EC and Article 15 of Directive2002/58/EC.

The secretariat is provided by Directorate C (Fundamental rights and rule of law) of the European Commission,Directorate General Justice and Consumers, B-1049 Brussels, Belgium, Office No MO59 05/35

I. Introduction.......................................................................................................3II. What are the main elements of data portability? ..........................................4III. When does data portability apply? .................................................................8IV. How do the general rules governing the exercise of data subject rights apply to data portability? ...............................................................................13V. How must the portable data be provided? ...................................................15

2Executive summary

Article 20 of the GDPR creates a new right to data portability, which is closely related tothe right of access but differs from it in many ways. It allows for data subjects to receivethe personal data that they have provided to a controller, in a structured, commonly usedand machine-readable format, and to transmit those data to another data controller. Thepurpose of this new right is to empower the data subject and give him/her more controlover the personal data concerning him or her.

Since it allows the direct transmission of personal data from one data controller toanother, the right to data portability is also an important tool that will support the freeflow of personal data in the EU and foster competition between controllers. It willfacilitate switching between different service providers, and will therefore foster thedevelopment of new services in the context of the digital single market strategy.

This opinion provides guidance on the way to interpret and implement the right to dataportability as introduced by the GDPR. It aims at discussing the right to data portabilityand its scope. It clarifies the conditions under which this new right applies taking intoaccount the legal basis of the data processing (either the data subject’s consent or thenecessity to perform a contract) and the fact that this right is limited to personal dataprovided by the data subject. The opinion also provides concrete examples and criteria toexplain the circumstances in which this right applies. In this regard, WP29 considers thatthe right to data portability covers data provided knowingly and actively by the datasubject as well as the personal data generated by his or her activity. This new right cannotbe undermined and limited to the personal information directly communicated by the datasubject, for example, on an online form.

As a good practice, data controllers should start developing the means that will contributeto answer data portability requests, such as download tools and Application ProgrammingInterfaces. They should guarantee that personal data are transmitted in a structured,commonly used and machine-readable format, and they should be encouraged to ensurethe interoperability of the data format provided in the exercise of a data portabilityrequest.

The opinion also helps data controllers to clearly understand their respective obligationsand recommends best practices and tools that support compliance with the right to dataportability. Finally, the opinion recommends that industry stakeholders and tradeassociations work together on a common set of interoperable standards and formats todeliver the requirements of the right to data portability.

I. Introduction

Article 20 of the General Data Protection Regulation (GDPR) introduces a new right of dataportability. This right allows for data subjects to receive the personal data that they haveprovided to a data controller, in a structured, commonly used and machine-readable format,and to transmit those data to another data controller without hindrance. This right, whichapplies subject to certain conditions, supports user choice, user control and userempowerment.

3Individuals making use of their right of access under the Data Protection Directive 95/46/ECwere constrained by the format chosen by the data controller when providing the requestedinformation. The new right to data portability aims to empower data subjects regardingtheir own personal data, as it facilitates their ability to move, copy or transmit personaldata easily from one IT environment to another (whether to their own systems, the systemsof trusted third parties or those of new data controllers).

By affirming individuals’ personal rights and control over the personal data concerning them,data portability also represents an opportunity to “re-balance” the relationship between datasubjects and data controllers1.

Whilst the right to personal data portability may also enhance competition between services(by facilitating service switching), the GDPR is regulating personal data and not competition.In particular, article 20 does not limit portable data to those which are necessary or useful forswitching services2.

Although data portability is a new right, other types of portability already exist or are beingdiscussed in other areas of legislation (e.g. in the contexts of contract termination,communication services roaming and trans-border access to services3). Some synergies andeven benefits to individuals may emerge between the different types of portability if they areprovided in a combined approach, even though analogies should be treated cautiously.

This Opinion provides guidance to data controllers so that they can update their practices,processes and policies, and clarifies the meaning of data portability in order to enable datasubjects to efficiently use their new right.

II. What are the main elements of data portability?

The GDPR defines the right of data portability in Article 20 (1) as follows:

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 data have been provided […]

- A right to receive personal data

Firstly, data portability is a right of the data subject to receive a subset of the personaldata processed by a data controller concerning him or her, and to store those data for furtherpersonal use. Such storage can be on a private device or on a private cloud, withoutnecessarily transmitting the data to another data controller.

1 The primary aim of data portability is enhancing individual’s control over their personal data and making surethey play an active role in the data ecosystem.2 For example, this right may allow banks to provide additional services, under the user’s control, using personaldata initially collected as part of an energy supply service.3 See European Commission agenda for a digital single market: https://ec.europa.eu/digital-agenda/en/digital-single-market, in particular, the first policy pillar “Better online access to digital goods and services”.

4In this regard, data portability complements the right of access. One specificity of dataportability lies in the fact that it offers an easy way for data subjects to manage and reusepersonal data themselves. These data should be received “in a structured, commonly used andmachine-readable format”. For example, a data subject might be interested in retrieving hiscurrent playlist (or a history of listened tracks) from a music streaming service, to find outhow many times he listened to specific tracks, or to check which music he wants to purchaseor listen to on another platform. Similarly, he may also want to retrieve his contact list fromhis webmail application, for example, to build a wedding list, or get information aboutpurchases using different loyalty cards, or to assess his or her carbon footprint4.

- A right to transmit personal data from one data controller to another data controller

Secondly, Article 20(1) provides data subjects with the right to transmit personal data fromone data controller to another data controller “without hindrance”. Data can also betransmitted directly from one data controller to another on request of the data subject andwhere it is technically feasible (Article 20(2)). In this respect, recital 68 encourages datacontrollers to develop interoperable formats that enable data portability5 but without creatingan obligation for controllers to adopt or maintain processing systems which are technicallycompatible6. The GDPR does, however, prohibit controllers from establishing barriers to thetransmission.

In essence, this element of data portability provides the ability for data subjects not just toobtain and reuse, but also to transmit the data they have provided to another service provider(either within the same business sector or in a different one). In addition to providingconsumer empowerment by preventing “lock-in”, the right to data portability is expected tofoster opportunities for innovation and sharing of personal data between data controllers in asafe and secure manner, under the data subject’s control7. Data portability can promote thecontrolled and limited sharing by users of personal data between organisations and thus enrichservices and customer experiences8. Data portability may facilitate transmission and reuse ofpersonal data concerning users among the various services they are interested in.

4 In these cases, the processing performed on the data by the data subject can either fall within the scope ofhousehold activities, when all the processing is performed under the sole control of the data subject, or it can behandled by another party, on the data subject’s behalf. In the latter case, the other party should be considered asdata controller, even for the sole purpose of personal data storage, and must comply with the principles andobligations laid down in the GDPR.5 See also section V.6 As a consequence, special attention should be paid to the format of the transmitted data, so as to guarantee thatthe data can be re-used, with little effort, by the data subject or another data controller. See also section V.7 See several experimental applications in Europe, for example MiData in the United Kingdom, MesInfos /SelfData by FING in France.8 The so-called quantified self and IoT industries have shown the benefit (and risks) of linking personal datafrom different aspects of an individual’s life such as fitness, activity and calorie intake to deliver a morecomplete picture of an individual’s life in a single file.

5 - Controllership

Data portability guarantees the right to receive personal data and to process them, accordingto the data subject’s wishes9.

Data controllers answering data portability requests, under the conditions set forth in Article20, are not responsible for the processing handled by the data subject or by another companyreceiving personal data. They act on behalf of the data subject, including when the personaldata are directly transmitted to another data controller. In this respect, the data controller isnot 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. At the sametime the controller should set safeguards to ensure they genuinely act on the data subject’sbehalf. For example, they can establish procedures to ensure that the type of personal datatransmitted are indeed those that the data subject wants to transmit. This could be done byobtaining confirmation from the data subject either before transmission or earlier on when theoriginal consent for processing is given or the contract is finalised.

Data controllers answering a data portability request have no specific obligation to check andverify the quality of the data before transmitting it. Of course, these data should already beaccurate, and up to date, according to the principles stated in Art 5(1) of the GDPR.Moreover, data portability does not impose an obligation on the data controller to retainpersonal data for longer than is necessary or beyond any specified retention period10.Importantly, there is no additional requirement to retain data beyond the otherwise applicableretention periods, simply to serve any potential future data portability request.

Where the personal data requested are processed by a data processor, the contract concludedin accordance with Article 28 of the GDPR must include the obligation to assist “thecontroller by appropriate technical and organisational measures, (…) to respond to requestsfor exercising the data subject's rights”. The data controller should therefore implementspecific procedures in cooperation with its data processors to answer data portability requests.In case of a joint controllership, a contract should allocate clearly the responsibilities betweeneach data controller regarding the processing of data portability requests.

In addition, a receiving data controller11 is responsible for ensuring that the portable dataprovided are relevant and not excessive with regard to the new data processing. For example,in the case of a data portability request made to a webmail service, where the request is usedby the data subject to obtain emails and send them to a secured archive platform, the new datacontroller does not need to process the contact details of the data subject’s correspondents. Ifthis information is not relevant with regard to the purpose of the new processing, it should notbe kept and processed. In any case, receiving data controllers are not obliged to accept andprocess personal data transmitted following a data portability request. Similarly, where a datasubject requests the transmission of details of his or her bank transactions to a service thatassists in managing his or her budget, the receiving data controller does not need to accept allthe data, or to retain all the details of the transactions once they have been labelled for the

9 The right to data portability is not limited to personal data that are useful and relevant for similar servicesprovided by competitors of the data controller.10 In the example above, if the data controller does not retain a record of songs played by a user then thispersonal data cannot be included within a data portability request.11 i.e. that receives personal data following a data portability request made by the data subject to another datacontroller.

6purposes of the new service. In other words, the data accepted and retained should only bethat which is necessary and relevant to the service being provided by the receiving datacontroller.

A “receiving” organization becomes a new data controller regarding these personal data andmust respect the principles stated in Article 5 of the GDPR. Therefore, the ”new” receivingdata controller must clearly and directly state the purpose of the new processing before anyrequest for transmission of the portable data in accordance with the transparency requirementsset out in Article 1412. As for any other data processing performed under its responsibility, thedata controller should apply the principles laid down in Article 5, such as lawfulness, fairnessand transparency, purpose limitation, data minimization, accuracy, integrity andconfidentiality, storage limitation and accountability13.

Data controllers holding personal data should be prepared to facilitate their data subject’sright to data portability. Data controllers can also choose to accept data from a data subject,but are not obliged to.

- Data portability vs. other rights of data subjects

When an individual exercises his or her right to data portability he or she does sowithout prejudice to any other right (as is the case with any other rights in the GDPR).A data subject can continue to use and benefit from the data controller’s service even after adata portability operation. Data portability does not automatically trigger the erasure of thedata14 from the systems of the data controller, and does not affect the original retention periodapplying to the data which have been transmitted. The data subject can exercise his or herrights as long as the data controller is still processing the data.

Equally, if the data subject wants to exercise his or her right to erasure (“right to be forgotten”under Article 17), data portability cannot be used by a data controller as a way of delaying orrefusing such erasure.

Should a data subject discover that personal data requested under the right to data portabilitydoes not fully address his or her request, any further request for personal data under a right ofaccess should be fully complied with, in accordance with Article 15 of the GDPR.

Furthermore, where a specific European or Member State law in another field also providesfor some form of portability of the data concerned, the conditions laid down in these specificlaws must also be taken into account when satisfying a data portability request under theGDPR. First, if it is clear from the request made by the data subject that his or her intention isnot to exercise rights under the GDPR, but rather, to exercise rights under sectorial legislation

12 In addition, the new data controller should not process personal data, which are not relevant, and theprocessing must be limited to what is necessary for the new purposes, even if the personal data are part of a moreglobal data-set transmitted through a portability process. Personal data, which are not necessary to achieve thepurpose of the new processing, should be deleted as soon as possible.13 Once received by the data controller, the personal data sent as part of the right to data portability can beconsidered as “provided by” the data subject and be re-transmitted according to the right to data portability, tothe extent that the other conditions applicable to this right (ie. the legal basis of the processing, …) are met.14 as stated in Article 17 of the GDPR

7only, then the GDPR’s data portability provisions will not apply to this request15. If, on theother hand, the request is aimed at portability under the GDPR, the existence of such specificlegislation does not override the general application of the data portability principle to anydata controller, as provided by the GDPR. Instead, it must be assessed, on a case by casebasis, how, if at all, such specific legislation may affect the right to data portability.

III. When does data portability apply?

- Which processing operations are covered by the right to data portability?

Compliance with the GDPR requires data controllers to have a clear legal basis for theprocessing of personal data.

In accordance with Article 20(1)(a) of the GDPR, in order to fall under the scope of dataportability, processing operations must be based:

- either on the data subject’s consent (pursuant to Article 6(1)(a), or pursuant to Article 9(2)(a) when it comes to special categories of personal data);

- or, on a contract to which the data subject is a party pursuant to Article 6(1)(b).

As an example, the titles of books purchased by an individual from an online bookstore, or thesongs listened to via a music streaming service are examples of personal data that aregenerally within the scope of data portability, because they are processed on the basis of theperformance of a contract to which the data subject is a party.

The GDPR does not establish a general right to data portability for cases where the processingof personal data is not based on consent or contract16. For example, there is no obligation forfinancial institutions to answer a data portability request concerning personal data processedas part of their obligations obligation to prevent and detect money laundering and otherfinancial crimes; equally, data portability does not cover professional contact detailsprocessed in a business to business relationship in cases where the processing is neither basedon the consent of the data subject nor on a contract to which he or she is a party.

When it comes to employees’ data, the right to data portability typically applies only if theprocessing is based on a contract to which the data subject is a party. In many cases, consentwill not be considered freely given in this context, due to the imbalance of power between the

15 For example, if the data subject’s request aims specifically at providing access to his banking account historyto an account information service provider, for the purposes stated in the Payment Services Directive 2 (PSD2)such access should be granted according to the provisions of this directive.16 See recital 68 and Article 20(3) of the GDPR. Article 20(3) and Recital 68 provide that data portability doesnot apply when the data processing is necessary for the performance of a task carried out in the public interest orin the exercise of official authority vested in the data controller, or when a data controller is exercising its publicduties or complying with a legal obligation. Therefore, there is no obligation for data controllers to provide forportability in these cases. However, it is a good practice to develop processes to automatically answer portabilityrequests, by following the principles governing the right to data portability. An example of this would be agovernment service providing easy downloading of past personal income tax filings. For data portability as agood practice in case of processing based on the legal ground of necessity for a legitimate interest and forexisting voluntary schemes, see pages 47 & 48 of WP29 Opinion 6/2014 on legitimate interests (WP217).

8employer and employee17. Some HR processings instead are based on the legal ground oflegitimate interest, or are necessary for compliance with specific legal obligations in the fieldof employment. In practice, the right to data portability in an HR context will undoubtedlyconcern some processing operations (such as pay and compensation services, internalrecruitment) but in many other situations a case by case approach will be needed to verifywhether all conditions applying to the right to data portability are met.

Finally, the right to data portability only applies if the data processing is “carried out byautomated means”, and therefore does not cover most paper files.

- What personal data must be included?

Pursuant to Article 20(1), to be within the scope of the right to data portability, data must be: - personal data concerning him or her, and - which he or she has provided to a data controller.

Article 20(4) also states that compliance with this right shall not adversely affect the rightsand freedoms of others.

First condition: personal data concerning the data subject

Only personal data is in scope of a data portability request. Therefore, any data that isanonymous18 or does not concern the data subject, will not be in scope. However,pseudonymous data that can be clearly linked to a data subject (e.g. by him or her providingthe respective identifier, cf. Article 11 (2)) is within the scope.

In many circumstances, data controllers will process information that contains the personaldata of several data subjects. Where this is the case, data controllers should not take an overlyrestrictive interpretation of the sentence “personal data concerning the data subject”. As anexample, telephone, interpersonal messaging or VoIP records may include (in the subscriber’saccount history) details of third parties involved in incoming and outgoing calls. Althoughrecords will therefore contain personal data concerning multiple people, subscribers should beable to have these records provided to them in response to data portability requests, becausethe records are (also) concerning the data subject. However, where such records are thentransmitted to a new data controller, this new data controller should not process them for anypurpose which would adversely affect the rights and freedoms of the third-parties (see below:third condition).

Second condition: data provided by the data subject

The second condition narrows the scope to data “provided by” the data subject.

There are many examples of personal data, which will be knowingly and actively “providedby” the data subject such as account data (e.g. mailing address, user name, age) submitted viaonline forms. Nevertheless, data “provided by” the data subject also result from theobservation of his activity. As a consequence, the WP29 considers that to give its full value tothis new right, “provided by” should also include the personal data that are observed from the17 As the WP29 outlined in its Opinion 8/2001 of 13 September 2001 (WP48).18 http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf

9activities of users such as raw data processed by a smart meter or other types of connectedobjects19, activity logs, history of website usage or search activities.

This latter category of data does not include data that are created by the data controller (usingthe data observed or directly provided as input) such as a user profile created by analysis ofthe raw smart metering data collected.

A distinction can be made between different categories of data, depending on their origin, todetermine if they are covered by the right to data portability. The following categories can bequalified as “provided by the data subject”: - Data actively and knowingly provided by the data subject (for example, mailing address, user name, age, etc.) - Observed data provided by the data subject by virtue of the use of the service or the device. They may for example include a person’s search history, traffic data and location data. It may also include other raw data such as the heartbeat tracked by a wearable device.

In contrast, inferred data and derived data are created by the data controller on the basis of thedata “provided by the data subject”. For example, the outcome of an assessment regarding thehealth of a user or the profile created in the context of risk management and financialregulations (e.g. to assign a credit score or comply with anti-money laundering rules) cannotin themselves be considered as “provided by” the data subject. Even though such data may bepart of a profile kept by a data controller and are inferred or derived from the analysis of dataprovided by the data subject (through his actions for example), these data will typically not beconsidered as “provided by the data subject” and thus will not be within scope of this newright20.

In general, given the policy objectives of the right to data portability, the term “provided bythe data subject” must be interpreted broadly, and should exclude “inferred data” and “deriveddata”, which include personal data that are created by a service provider (for example,algorithmic results). A data controller can exclude those inferred data but should include allother personal data provided by the data subject through technical means provided by thecontroller21.

Thus, the term “provided by” includes personal data that relate to the data subject activity orresult from the observation of an individual’s behaviour, but does not include data resultingfrom subsequent analysis of that behaviour. By contrast, any personal data which have been

19 By being able to retrieve the data resulting from observation of his or her activity, the data subject will also beable to get a better view of the implementation choices made by data controller as to the scope of observed dataand will be in a better situation to choose what data he or she is willing to provide to get a similar service, and beaware of the extent to which his or her right to privacy is respected.20 Nevertheless, the data subject can still use his or her “right to obtain from the controller confirmation as towhether or not personal data concerning him or her are being processed, and, where that is the case, access to thepersonal data” as well as information about “the existence of automated decision-making, including profiling,referred to in Article 22(1) and (4) and, at least in those cases, meaningful information about the logic involved,as well as the significance and the envisaged consequences of such processing for the data subject”, according toArticle 15 of the GDPR (which refers to the right of access).21 This includes all data observed about the data subject during the activities for the purpose of which the data arecollected, such as a transaction history or access log. Data collected through the tracking and recording of thedata subject (such as an app recording heartbeat or technology used to track browsing behaviour) should also beconsidered as “provided by” him or her even if the data are not actively or consciously transmitted.

10created by the data controller as part of the data processing, e.g. by a personalisation orrecommendation process, by user categorisation or profiling are data which are derived orinferred from the personal data provided by the data subject, and are not covered by the rightto data portability.

Third condition: the right to data portability shall not adversely affect the rights and freedomsof others

With respect to personal data concerning other data subjects:

The third condition is intended to avoid the retrieval and transmission of data containing thepersonal data of other (non-consenting) data subjects to a new data controller in cases wherethese data are likely to be processed in a way that would adversely affect the rights andfreedoms of the other data subjects (Article 20(4) of the GDPR)22.

Such an adverse effect would occur, for instance, if the transmission of data from one datacontroller to another, would prevent third parties from exercising their rights as data subjectsunder the GDPR (such as the rights to information, access, etc.).

The data subject initiating the transmission of his or her data to another data controller, eithergives consent to the new data controller for processing or enters into a contract with thatcontroller. Where personal data of third parties are included in the data set another legal basisfor the processing must be identified. For example, a legitimate interest may be pursued bythe data controller under Article 6(1)(f), in particular when the purpose of the data controlleris to provide a service to the data subject that allows the latter to process personal data for apurely personal or household activity. The processing operations initiated by the data subjectin the context of personal activity that concern and potentially impact third parties remainunder his or her responsibility, to the extent that such processing is not, in any manner,decided by the data controller.

For example, a webmail service may allow the creation of a directory of a data subject’scontacts, friends, relatives, family and broader environment. Since these data relate to (and arecreated by) the identifiable individual that wishes to exercise his right to data portability, datacontrollers should transmit the entire directory of incoming and outgoing e-mails to that datasubject.

Similarly, a data subject’s bank account can contain personal data relating to the transactionsnot just of the account holder but also those of other individuals (e.g., if they have transferredmoney to the account holder). The rights and freedoms of those third parties are unlikely to beadversely affected by the transmission of the bank account information to the account holderonce a portability request is made—provided that in both examples the data are used for thesame purpose (i.e., a contact address only used by the data subject or a history of the datasubject’s bank account.

Conversely, the rights and freedoms of third parties will not be respected if the new datacontroller uses the personal data for other purposes, e.g. if the receiving data controller uses

22 Recital 68 provides that “where, in a certain set of personal data, more than one data subject is concerned, theright to receive the personal data should be without prejudice to the rights and freedoms of other data subjects inaccordance with this Regulation.”

11personal data of other individuals within the data subject’s contact directory for marketingpurposes.

Therefore, to prevent adverse effects on the third parties involved, the processing of suchpersonal data by another controller is allowed only to the extent that the data are kept underthe sole control of the requesting user and is only managed for purely personal or householdneeds. A receiving ‘new’ data controller (to whom the data can be transmitted at the requestof the user) may not use the transmitted third party data for his own purposes e.g. to proposemarketing products and services to those other third party data subjects. For example, thisinformation should not be used to enrich the profile of the third party data subject and rebuildhis social environment, without his knowledge and consent23. Neither can it be used toretrieve information about such third parties and create specific profiles, even if their personaldata are already held by the data controller. Otherwise, such processing is likely to beunlawful and unfair, especially if the third parties concerned are not informed and cannotexercise their rights as data subjects.

Furthermore, it is a leading practice for all data controllers (both the “sending” and“receiving” parties) to implement tools to enable data subjects to select the relevant data theywish to receive and transmit and exclude, where relevant, data of other individuals. This willfurther assist in reducing the risks for third parties whose personal data may be ported.

Additionally, the data controllers should implement consent mechanisms for other datasubjects involved, to ease data transmission for those cases where such parties are willing toconsent, e.g. if they also want to move their data to some other data controller. Such asituation might arise, for example, with social networks, but it is up to data controllers todecide on the leading practice to follow.

With respect to data covered by intellectual property and trade secrets:

The rights and freedoms of others are mentioned in Article 20(4). While not directly related toportability, this can be understood as “including trade secrets or intellectual property and inparticular the copyright protecting the software. However, even though these rights should beconsidered before answering a data portability request, “the result of those considerationsshould not be a refusal to provide all information to the data subject”. Furthermore, the datacontroller should not reject a data portability request on the basis of the infringement ofanother contractual right (for example, an outstanding debt, or a trade conflict with the datasubject).

The right to data portability is not a right for an individual to misuse the information in a waythat could be qualified as an unfair practice or that would constitute a violation of intellectualproperty rights.

A potential business risk cannot, however, in and of itself serve as the basis for a refusal toanswer the portability request and data controllers can transmit the personal data provided bydata subjects in a form that does not release information covered by trade secrets orintellectual property rights.

23 A social networking service should not enrich the profile of its members by using personal data transmitted bya data subject as part of his right to data portability, without respecting the principle of transparency and alsomaking sure they rely on an appropriate legal basis regarding this specific processing.

12 IV. How do the general rules governing the exercise of data subject rights apply to data portability?

- What prior information should be provided to the data subject?

In order to comply with the new right to data portability, data controllers must inform datasubjects of the existence of the new right to portability. Where the personal data concernedare directly collected from the data subject, this must happen “at the time where personal dataare obtained”. If the personal data have not been obtained from the data subject, the datacontroller must provide the information as required by Articles 13(2)(b) and 14(2)(c).

“Where the personal data have not been obtained from the data subject”, Article 14(3)requires the information to be provided within a reasonable time not exceeding one monthafter obtaining the data, during first communication with the data subject, or when disclosureis made to third parties24.

When providing the required information data controllers must ensure that they distinguishthe right to data portability from other rights. Therefore, WP29 recommends in particular thatdata controllers clearly explain the difference between the types of data that a data subject canreceive through the rights of subject access and data portability.

In addition, the Working Party recommends that data controllers always include informationabout the right to data portability before data subjects close any account they may have. Thisallows users to take stock of their personal data, and to easily transmit the data to their owndevice or to another provider before a contract is terminated.

Finally, as leading practice for “receiving” data controllers, the WP29 recommends that datasubjects are provided with complete information about the nature of personal data which arerelevant for the performance of their services. In addition to underpinning fair processing, thisallows users to limit the risks for third parties, and also any other unnecessary duplication ofpersonal data even where no other data subjects are involved.

- How can the data controller identify the data subject before answering his request?

There are no prescriptive requirements to be found in the GDPR on how to authenticate thedata subject. Nevertheless, Article 12(2) of the GDPR states that the data controller shall notrefuse to act on request of a data subject for exercising his or her rights (including the right todata portability) unless it is processing personal data for a purpose that does not require theidentification of a data subject and it can demonstrate that it is not able to identify the datasubject. However, as per Article 11(2), in such circumstances the data subject can providemore information to enable his or her identification. Additionally, Article 12(6) provides thatwhere a data controller has reasonable doubts about the identity of a data subject, it canrequest further information to confirm the data subject’s identity. Where a data subjectprovides additional information enabling his or her identification, the data controller shall notrefuse to act on the request. Where information and data collected online is linked topseudonyms or unique identifiers, data controllers can implement appropriate procedures24 Article 12 requires that data controllers provide “any communications […] in a concise, transparent,intelligible, and easily assessable form, using clear and plain language, in particular for any informationaddressed specifically to a child.”

13enabling an individual to make a data portability request and receive the data relating to himor her. In any case, data controllers must implement an authentication procedure in order tostrongly ascertain the identity of the data subject requesting his or her personal data or moregenerally exercising the rights granted by the GDPR.

These procedures often already exist. The data subjects are often already authenticated by thedata controller before entering into a contract or collecting his or her consent to theprocessing. As a consequence, the personal data used to register the individual concerned bythe processing can also be used as evidence to authenticate the data subject for portabilitypurposes25.

While in these cases, the data subjects’ prior identification may require a request for proof oftheir legal identity, such verification may not be relevant to assess the link between the dataand the individual concerned, since such a link is not related with the official or legal identity.In essence, the ability for the data controller to request additional information to assess one’sidentity cannot lead to excessive demands and to the collection of personal data which are notrelevant or necessary to strengthen the link between the individual and the personal datarequested.

In many cases, such authentication procedures are already in place. For example, usernamesand passwords are often used to allow individuals to access their data in their email accounts,social networking accounts, and accounts used for various other services, some of whichindividuals chose to use without revealing their full name and identity.

If the size of data requested by the data subject makes transmission via the internetproblematic, rather than potentially allowing for an extended time period of a maximum ofthree months to comply with the request26, the data controller may also need to consideralternative means of providing the data such as using streaming or saving to a CD, DVD orother physical media or allowing for the personal data to be transmitted directly to anotherdata controller (as per Article 20(2) of the GDPR where technically feasible).

- What is the time limit imposed to answer a portability request?

Article 12(3) requires that the data controller provides “information on action taken” to thedata subject “without undue delay” and in any event “within one month of receipt of therequest”. This one month period can be extended to a maximum of three months for complexcases, provided that the data subject has been informed about the reasons for such delaywithin one month of the original request.

Data controllers operating information society services are likely to be better equipped to beable to comply with requests within a very short time period. To meet user expectations, it is agood practice to define the timeframe in which a data portability request can typically beanswered 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

25 For example, when the data processing is linked to a user account, providing the relevant login and passwordmight be sufficient to identify the data subject.26 Article 12(3): “The controller shall provide information on action taken on a request”.

14complaint with a supervisory authority and seeking a judicial remedy”, no later than onemonth after receiving the request.

Data controllers must respect the obligation to respond within the given terms, even if itconcerns a refusal. In other words, the data controller cannot remain silent when it isasked to answer a data portability request.

- In which cases can a data portability request be rejected or a fee charged?

Article 12 prohibits the data controller from charging a fee for the provision of the personaldata, unless the data controller can demonstrate that the requests are manifestly unfounded orexcessive, “in particular because of their repetitive character”. For information societyservices that specialise in automated processing of personal data, implementing automatedsystems such as Application Programming Interfaces (APIs)27 can facilitate the exchangeswith the data subject, hence lessen the potential burden resulting from repetitive requests.Therefore, there should be very few cases where the data controller would be able to justify arefusal to deliver the requested information, even regarding multiple data portability requests.

In addition, the overall cost of the processes created to answer data portability requests shouldnot be taken into account to determine the excessiveness of a request. In fact, Article 12 of theGDPR focuses on the requests made by one data subject and not on the total number ofrequests received by a data controller. As a result, the overall system implementation costsshould neither be charged to the data subjects, nor be used to justify a refusal to answerportability requests.

V. How must the portable data be provided?

- What are the expected means the data controller should implement for data provision?

Article 20(1) of the GDPR provides that data subjects have the right to transmit the data toanother controller without hindrance from the controller to which the personal data have beenprovided.

Such hindrance can be characterised as any legal, technical or financial obstacles placed bydata controller in order to refrain or slow down access, transmission or reuse by the datasubject or by another data controller. For example, such hindrance could be: fees asked fordelivering data, lack of interoperability or access to a data format or API or the providedformat, excessive delay or complexity to retrieve the full dataset, deliberate obfuscation of thedataset, or specific and undue or excessive sectorial standardization or accreditationdemands28.

Article 20(2) also places obligations on data controllers for transmitting the portable datadirectly to other data controllers “when technically feasible”.

27 Application Programming Interface (API) means the interfaces of applications or web services made availableby data controllers so that other systems or applications can link and work with their systems.28 Some legitimate obstacles might arise, as the ones, which are related to the rights and freedoms of othersmentioned in Article 20(4), or the ones that relate to the security of the controllers’ own systems. It shall be theresponsibility of the data controller to justify why such obstacles would be legitimate and why they do notconstitute a hindrance in the meaning of Article 20(1).

15The technical feasibility of transmission from data controller to data controller, under thecontrol of the data subject, should be assessed on a case by case basis. Recital 68 furtherclarifies the limits of what is “technically feasible”, indicating that “it should not create anobligation for the controllers to adopt or maintain processing systems which are technicallycompatible”.

Data controllers are expected to transmit personal data in an interoperable format, althoughthis does not place obligations on other data controllers to support these formats. Directtransmission from one data controller to another could therefore occur when communicationbetween two systems is possible, in a secured way29, and when the receiving system istechnically in a position to receive the incoming data. If technical impediments prohibit directtransmission, the data controller shall explain those impediments to the data subjects, as hisdecision will otherwise be similar in its effect to a refusal to take action on a data subject’srequest (Article 12(4)).

On a technical level, data controllers should explore and assess two different andcomplimentary paths for making portable data available to the data subjects or to other datacontrollers:

- a direct transmission of the overall dataset of portable data (or several extracts of parts of the global dataset); - an automated tool that allows extraction of relevant data.

The second way may be preferred by data controllers in cases involving of complex and largedata sets, as it allows for the extraction of any part of the data-set that is relevant for the datasubject in the context of his or her request, may help minimising risk, and possibly allows foruse of data synchronisation mechanisms30 (e.g. in the context of a regular communicationbetween data controllers). It may be a better way to ensure compliance for the “new” datacontroller, and would constitute good practice in the reduction of privacy risks on the part ofthe initial data controller.

These two different and possibly complementary ways of providing relevant portable datacould be implemented by making data available through various means such as, for example,secured messaging, an SFTP server, a secured WebAPI or WebPortal. Data subjects should beenabled to make use of a personal data store, personal information management system31 orother kinds of trusted third-parties, to hold and store the personal data and grant permission todata controllers to access and process the personal data as required.

- What is the expected data format?

The GDPR places requirements on data controllers to provide the personal data requested bythe individual in a format, which supports re-use. Specifically, Article 20(1) of the GDPRstates that the personal data must be provided “in a structured, commonly used and machine-

29 Through an authenticated communication with the necessary level of data encryption.30 Synchronisation mechanism can help reaching the general obligations under Article 5obligation of the GDPR,which provides that “personal data shall be (…) accurate and, where necessary, kept up to date”31 On personal information management systems (PIMS), see, for example, EDPS Opinion 9/2016, available athttps://secure.edps.europa.eu/EDPSWEB/webdav/site/mySite/shared/Documents/Consultation/Opinions/2016/16-10-20_PIMS_opinion_EN.pdf

16readable format”. Recital 68 provides a further clarification that this format should beinteroperable, a term that is defined32 in the EU as:

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.

The terms “structured”, “commonly used” and “machine-readable” are a set of minimalrequirements that should facilitate the interoperability of the data format provided by the datacontroller. In that way, “structured, commonly used and machine readable” are specificationsfor the means, whereas interoperability is the desired outcome.

a file format structured so that software applications can easily identify, recognize and extract specific data, including individual statements of fact, and their internal structure. Data encoded in files that are structured in a machine-readable format are machine-readable data. Machine-readable formats can be open or proprietary; they can be formal standards or not. Documents encoded in a file format that limits automatic processing, because the data cannot, or cannot easily, be extracted from them, should not be considered to be in a machine-readable format. Member States should where appropriate encourage the use of open, machine-readable formats.

Given the wide range of potential data types that could be processed by a data controller, theGDPR does not impose specific recommendations on the format of the personal data to beprovided. The most appropriate format will differ across sectors and adequate formats mayalready exist, and should always be chosen to achieve the purpose of being interpretable andaffording the data subject with a large degree of data portability. As such, formats that aresubject to costly licensing constraints would not be considered an adequate approach.

Recital 68 clarifies that “The data subject's right to transmit or receive personal dataconcerning him or her should not create an obligation for the controllers to adopt ormaintain processing systems which are technically compatible.” Thus, portability aims toproduce interoperable systems, not compatible systems35.

Personal data are expected to be provided in formats that have a high level of abstraction fromany internal or proprietary format. As such, data portability implies an additional layer of dataprocessing by data controllers, in order to extract data from the platform and filter outpersonal data outside the scope of portability, such as inferred data or data related to securityof systems. In this way, data controllers are encouraged to identify beforehand data which arewithin the scope of portability in their own systems. This additional data processing will be32 Article 2 of Decision No 922/2009/EC of the European Parliament and of the Council of 16 September 2009on interoperability solutions for European public administrations (ISA) OJ L 260, 03.10.2009, p. 2033 Amending Directive 2003/98/EC on the re-use of public sector information.34 The EU glossary (http://eur-lex.europa.eu/eli-register/glossary.html) provides further clarification onexpectations related to the concepts used in this guideline, such as machine-readable, interoperability, openformat, standard, metadata.35 ISO/IEC 2382-01 defines interoperability as follows: “The capability to communicate, execute programs, ortransfer data among various functional units in a manner that requires the user to have little or no knowledge ofthe unique characteristics of those units.”

17considered as ancillary to the main data processing, since it is not performed to achieve a newpurpose defined by the data controller.

Where no formats are in common use for a given industry or given context, data controllersshould provide personal data using commonly used open formats (e.g. XML, JSON,CSV,…) along with useful metadata at the best possible level of granularity, whilemaintaining a high level of abstraction. As such, suitable metadata should be used in order toaccurately describe the meaning of exchanged information. This metadata should be enoughto make the function and reuse of the data possible but, of course, without revealing tradesecrets. It is unlikely therefore that providing an individual with PDF versions of an emailinbox would be sufficiently structured or descriptive to allow the inbox data to be easily re-used. Instead, the e-mail data should be provided in a format which preserves all the metadata,to allow the effective re-use of the data. As such, when selecting a data format in which toprovide the personal data, the data controller should consider how this format would impact orhinder the individual’s right to re-use the data. In cases where a data controller is able toprovide choices to the data subject regarding the preferred format of the personal data a clearexplanation of the impact of the choice should be provided. However, processing additionalmetadata for the sole purpose that they might be needed or wanted to answer a data portabilityrequest poses no legitimate ground for such processing.

associations to work together on a common set of interoperable standards and formatsto deliver the requirements of the right to data portability. This challenge has also beenaddressed by the European Interoperability Framework (EIF) which has created an agreedapproach to interoperability for organizations that wish to jointly deliver public services.Within its scope of applicability, the framework specifies a set of common elements such asvocabulary, concepts, principles, policies, guidelines, recommendations, standards,specifications and practices36.

- How to deal with a large or complex personal data collection?

The GDPR does not explain how to address the challenge of responding where a large datacollection, a complex data structure or other technical issues arise that might createdifficulties for data controllers or data subjects.

However, in all cases, it is crucial that the individual is in a position to fully understand thedefinition, schema and structure of the personal data that could be provided by the datacontroller. For instance, data could first be provided in a summarised form using dashboardsallowing the data subject to port subsets of the personal data rather than the entirety. The datacontroller should provide an overview “in a concise, transparent, intelligible and easilyaccessible form, using clear and plain language” (see Article 12(1)) of the GDPR) in such away that data subject should always have clear information of what data to download ortransmit to another data controller in relation to a given purpose. For example, data subjectsshould be in a position to use software applications to easily identify, recognize and processspecific data from it.

As referenced above, a practical way by which a data controller can answer requests for dataportability may be by offering an appropriately secured and documented API. This may

36 Source : http://ec.europa.eu/isa/documents/isa_annex_ii_eif_en.pdf

18enable individuals to make requests of the data controller for their personal data via their ownor third-party software or grant permission for others to so do on their behalf (includinganother data controller) as specified in Article 20(2) of the GDPR. By granting access to datavia an externally accessible API, it may also be possible to offer a more sophisticated accesssystem that enables individuals to make subsequent requests for data, either as a fulldownload or as a delta function containing only changes since the last download, withoutthese additional requests being onerous on the data controller.

- How can portable data be secured?

In general, data controllers should guarantee the “appropriate security of the personal data,including protection against unauthorised or unlawful processing and against accidental loss,destruction or damage, using appropriate technical or organisational measures” according toArticle 5(1)(f) of the GDPR.

However, the transmission of personal data to the data subject may also raise some securityissues:

How can data controllers ensure that personal data are securely delivered to the right person?

As data portability aims to get personal data out of the information system of the datacontroller, the transmission may become a possible source of risk regarding those data (inparticular of data breaches during the transmission). The data controller is responsible fortaking all the security measures needed to ensure not only that personal data is securelytransmitted (by the use of end-to-end or data encryption) to the right destination (by the use ofstrong authentication measures), but also continuing to protect the personal data that remainsin their systems, as well as transparent procedures for dealing with possible data breaches37.As such, data controllers should assess the specific risks linked with data portability and takeappropriate risks mitigation measures.

Such risk mitigation measures could include: if the data subject already needs to beauthenticated, using additional authentication information, such as a shared secret, or anotherfactor of authentication, such as a onetime password; suspending or freezing the transmissionif there is suspicion that the account has been compromised; in cases of a direct transmissionfrom a data controller to another data controller, authentication by mandate, such as token-based authentications, should be used.

Such security measures must not be obstructive in nature and must not prevent users fromexercising their rights, e.g. by imposing additional costs.

How to help users in securing the storage of their personal data in their own systems?

By retrieving their personal data from an online service, there is always the risk that usersmay store them in less secured systems than the one provided by the service. The data subjectrequesting the data is responsible for identifying the right measures in order to secure personaldata in his own system. However, he should be made aware of this in order to take steps toprotect the information he has received. As an example of leading practice data controllers

37 In conformance to the Directive (EU) 2016/1148 concerning measures for a high common level of security ofnetwork and information systems across the Union

19may also recommend appropriate format(s), encryption tools and other security measures tohelp the data subject in achieving this goal.