Right to data portability

At a glance

• The right to data portability allows individuals to obtain and reuse their personal data for their own purposes across different services.
• It allows them to move, copy or transfer personal data easily from one IT environment to another in a safe and secure way, without affecting its usability.
• Doing this enables individuals to take advantage of applications and services that can use this data to find them a better deal or help them understand their spending habits.
• The right only applies to information an individual has provided to a controller.
• Some organisations in the UK already offer data portability through midata and similar initiatives which allow individuals to view, access and use their personal consumption and transaction data in a way that is portable and safe.

Checklists

In brief

• What is the right to data portability?
• When does the right apply?
• What does the right apply to?
• What does ‘provided to a controller’ mean?
• Does the right apply to anonymous or pseudonymous data?
• What happens if the personal data includes information about others?
• What is an individual entitled to?
• What are the limits when transmitting personal data to another controller?
• Do we have responsibility for the personal data we transmit to others?
• How should we provide the data?
• What does ‘structured’ mean?
• What does ‘commonly used’ mean?
• What does ‘machine-readable’ mean?
• Should we use an ‘interoperable’ format?
• What formats can we use?
• What is CSV?
• What is XML?
• What is JSON?
• Are these the only formats we can use?
• What responsibilities do we have when we receive personal data because of a data portability request?
• When can we refuse to comply with a request for data portability?
• What does manifestly unfounded mean?
• What does excessive mean?
• What should we do if we refuse to comply with a request for data portability?
• How do we recognise a request?
• Can we charge a fee?
• How long do we have to comply?
• Can we extend the time for a response?
• Can we ask an individual for ID?

What is the right to data portability?

The right to data portability gives individuals the right to receive personal data they have provided to a controller in a structured, commonly used and machine readable format. It also gives them the right to request that a controller transmits this data directly to another controller.

When does the right apply?

The right to data portability only applies when:

• your lawful basis for processing this information is consent or for the performance of a contract; and
• you are carrying out the processing by automated means (ie excluding paper files).

What does the right apply to?

Information is only within the scope of the right to data portability if it is personal data of the individual that they have provided to you.

What does ‘provided to a controller’ mean?

Sometimes the personal data an individual has provided to you will be easy to identify (eg their mailing address, username, age). However, the meaning of data ‘provided to’ you is not limited to this. It is also personal data resulting from observation of an individual’s activities (eg 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 that you have created based on the data an individual has provided to you. For example, if you use the data they have provided to create a user profile then this data would not be in scope of data portability.

You should however note that if this ‘inferred’ or ‘derived’ data is personal data, you still need to provide it to an individual if they make a subject access request. Bearing this in mind, if it is clear that the individual is seeking access to the inferred/derived data, as part of a wider portability request, you must include this data in your response.

Does the right apply to anonymous or pseudonymous data?

The right to data portability only applies to personal data. This means that it does not apply to genuinely anonymous data. However, pseudonymous data that can be clearly linked back to an individual (eg where that individual provides the respective identifier) is within scope of the right.

What happens if the personal data includes information about others?

If the requested information includes information about others (eg third party data) you need 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 to you within their information in the first place. However, you should always consider whether there will be an adverse effect on the rights and freedoms of third parties, in particular when you are transmitting data directly to another controller.

If the requested data has been provided to you by multiple data subjects (eg a joint bank account) you need to be satisfied that all parties agree to the portability request. This means that you may have to seek agreement from all the parties involved.

What is an individual entitled to?

The right to data portability entitles an individual to:

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

Individuals have the right to receive their personal data and store it for further personal use. This allows the individual 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.

You 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 you to allow individuals more general and routine access to your systems – only for the extraction of their data following a portability request.

You may have a preferred method of providing the information requested depending on the amount and complexity of the data requested. In either case, you need to ensure that the method is secure.

What are the limits when transmitting personal data to another controller?

Individuals have the right to ask you to transmit their personal data directly to another controller without hindrance. If it is technically feasible, you should do this.

You should consider the technical feasibility of a transmission on a request by request basis. The right to data portability does not create an obligation for you to adopt or maintain processing systems which are technically compatible with those of other organisations (UK GDPR Recital 68). However, you should take a reasonable approach, and this should not generally create a barrier to transmission.

Without hindrance means that you should not put in place any legal, technical or financial obstacles which slow down or prevent the transmission of the personal data to the individual, or to another organisation.

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

Do we have responsibility for the personal data we transmit to others?

If you provide information directly to an individual or to another organisation in response to a data portability request, you are not responsible for any subsequent processing carried out by the individual or the other organisation. However, you are responsible for the transmission of the data and need to take appropriate measures to ensure that it is transmitted securely and to the right destination.

If you provide data to an individual, it is possible that they will store the information in a system with less security than your own. Therefore, you should make individuals aware of this so that they can take steps to protect the information they have received. 

You also need to ensure that you comply with the other provisions in the UK GDPR. For example, whilst there is no specific obligation under the right to data portability to check and verify the quality of the data you transmit, you should already have taken reasonable steps to ensure the accuracy of this data in order to comply with the requirements of the accuracy principle of the UK GDPR.

How should we provide the data?

You should provide the personal data in a format that is:

• structured;
• commonly used; and
• machine-readable.

Although these terms are not defined in the UK GDPR these three characteristics can help you decide whether the format you intend to use is appropriate.

You can also find relevant information in the ‘Open Data Handbook’, published by Open Knowledge International. The handbook is a guide to ‘open data’, information that is free to access and can be re-used for any purpose – particularly information held by the public sector. The handbook contains a number of definitions that are relevant to the right to data portability, and this guidance includes some of these below.  

What does ‘structured’ mean?

Structured data allows for easier transfer and increased 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, ie it is ‘structured’. In practice, some of the personal data you process will already be in structured form.

In many cases, if a format is structured it is also machine-readable.

What does ‘commonly used’ mean?

This simply means that the format you choose must be widely-used and well-established.

However, just because a format is ‘commonly used’ does not mean it is appropriate for data portability. You have to consider whether it is ‘structured’, and ‘machine-readable’ as well. Although you may be using common software applications, which save data in commonly-used formats, these may not be sufficient to meet the requirements of data portability.

What does ‘machine-readable’ mean?

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.’

Furthermore, Regulation 2 of the Re-use of Public Sector Information Regulations 2015 defines ‘machine-readable format’ as:

‘A file format structured so that software applications can easily identify, recognise and extract specific data, including individual statements of fact, and their internal structure.’

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”).

If you are able to implement such a system then you can facilitate data exchanges with individuals and respond to data portability requests in an easy manner.

Should we use an ‘interoperable’ format?

Although you are not required to use an interoperable format, this is encouraged by the UK GDPR, which seeks to promote the concept of interoperability. Recital 68 says:

‘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 to both.

At the same time, you are not expected to maintain systems that are technically compatible with those of other organisations. Data portability is intended to produce interoperable systems, not compatible ones.

What formats can we use?

You may already be using an appropriate format within your networks and systems, and/or you may be required to use a particular format due to the particular industry or sector you are part of. Provided it meets the requirements of being structured, commonly-used and machine readable then it could be appropriate for a data portability request.

The UK GDPR does not require you to use open formats internally. Your processing systems may indeed use proprietary formats which individuals may not be able to access if you provide data to them in these formats. In these cases you need to perform some additional processing on the personal data in order to put it into the type of format required by the UK GDPR.

Where no specific format is in common use within your industry or sector, you should provide personal data using open formats such as CSV, XML and JSON. You may also find that these formats are the easiest for you to use when answering data portability requests.

For further information on CSV, XML and JSON, please see below.

What is CSV?

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 and is therefore an appropriate format for you to use when responding to a data portability request.

What is XML?

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 that is intended to be both human readable 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 has asked you to do so.

What is JSON?

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 web sites use and is used as a data interchange format. As with XML, it can be read by humans or machines. It is also a standardised open format maintained by the W3C.

Are these the only formats we can use?

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 you are obliged to use them. Other formats exist that also meet the requirements of data portability.

You 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.

What responsibilities do we have when we receive personal data because of a data portability request?

When you receive personal data that has been transmitted as part of a data portability request, you need to process this data in line with data protection requirements.

In deciding whether to accept and retain personal data, you should consider whether the data is relevant and not excessive in relation to the purposes for which you will process it. You also need to consider whether the data contains any third party information.

As a new controller, you need to ensure that you have an appropriate lawful basis for processing any third party data and that this processing does not adversely affect the rights and freedoms of those third parties. If you have received personal data which you have no reason to keep, you should delete it as soon as possible. When you accept and retain data, it becomes your responsibility to ensure that you comply with the requirements of the UK GDPR.

In particular, if you receive third party data you should not use this for your own purposes. You should keep the third party data under the sole control of the individual who has made the portability request, and only used for their own purposes.

When can we refuse to comply with a request for data portability?

If an exemption applies, you can refuse to comply with a request for data portability (wholly or partly). Not all of the exemptions apply in the same way, and you should look at each exemption carefully to see how it applies to a particular request. For more information, please see our guidance on Exemptions.

You can also refuse to comply with a request if it is:

• manifestly unfounded; or
• excessive.

In order to decide if a request is manifestly unfounded or excessive you must consider each request on a case-by-case basis. You should not have a blanket policy.

You must be able to demonstrate to the individual why you consider the request is manifestly unfounded or excessive and, if asked, explain your reasons to the Information Commissioner.

What does manifestly unfounded mean?

A request may be manifestly unfounded if:

• the individual clearly has no intention to exercise their right to data portability. For example an individual makes a request, but then offers to withdraw it in return for some form of benefit from the organisation; or
• the request is malicious in intent and is being used to harass an organisation with no real purposes other than to cause disruption. For example:
  • the individual has explicitly stated, in the request itself or in other communications, that they intend to cause disruption;
  • the request makes unsubstantiated accusations against you or specific employees;
  • the individual is targeting a particular employee against whom they have some personal grudge; or
  • the individual systematically sends different requests to you as part of a campaign, eg once a week, with the intention of causing disruption.

This is not a simple tick list exercise that automatically means a request is manifestly unfounded. You must consider a request in the context in which it is made, and you are responsible for demonstrating that it is manifestly unfounded.

Also, you should not presume that a request is manifestly unfounded because the individual has previously submitted requests which have been manifestly unfounded or excessive or if it includes aggressive or abusive language.

The inclusion of the word “manifestly” means there must be an obvious or clear quality to it being unfounded. You should consider the specific situation and whether the individual genuinely wants to exercise their rights. If this is the case, it is unlikely that the request will be manifestly unfounded.

What does excessive mean?

A request may be excessive if:

• it repeats the substance of previous requests; or
• it overlaps with other requests.

However, it depends on the particular circumstances. It will not necessarily be excessive just because the individual:

• makes a request about the same issue. An individual may have legitimate reasons for making requests that repeat the content of previous requests. For example, if the controller has not handled previous requests properly;
• makes an overlapping request, if it relates to a completely separate set of information; or
• previously submitted requests which have been manifestly unfounded or excessive.

What should we do if we refuse to comply with a request for data portability?

You must inform the individual without undue delay and within one month of receipt of the request.

You should inform the individual about:

• the reasons you are not taking action;
• their right to make a complaint to the ICO or another supervisory authority; and
• their ability to seek to enforce this right through a judicial remedy.

You should also provide this information if you request a reasonable fee or need additional information to identify the individual.

How do we recognise a request?

The UK GDPR does not specify how individuals should make data portability requests. Therefore, requests could be made verbally or in writing. They can also be made to any part of your organisation and do not have to be to a specific person or contact point.

A request does not have to include the phrase 'request for data portability' or a reference to ‘Article 20 of the UK GDPR’, as long as one of the conditions listed above apply.

This presents a challenge as any of your employees could receive a valid request. However, you have a legal responsibility to identify that an individual has made a request to you and handle it accordingly. Therefore you may need to consider which of your staff who regularly interact with individuals may need specific training to identify a request.

Additionally, it is good practice to have a policy for recording details of the requests you receive, particularly those made by telephone or in person. You may wish to check with the requester that you have understood their request, as this can help avoid later disputes about how you have interpreted the request. We also recommend that you keep a log of verbal requests.

In practice, you may already have processes in place to enable your staff to recognise subject access requests, such as training or established procedures. You could consider adapting them to ensure your staff also recognise data portability requests.

Can we charge a fee?

In most cases you cannot charge a fee to comply with a request for data portability.

However, you can charge a “reasonable fee” for the administrative costs of complying with the request if it is manifestly unfounded or excessive. You should base the reasonable fee on the administrative costs of complying with the request.

If you decide to charge a fee you should contact the individual promptly and inform them. You do not need to comply with the request until you have received the fee.

Alternatively, you can refuse to comply with a manifestly unfounded or excessive request.

How long do we have to comply?

You must comply with a request for data portability without undue delay and at the latest within one month of receipt of the request or (if later) within one month of receipt of:

• any information requested to confirm the requester’s identity (see Can we ask an individual for ID?); or
• a fee (only in certain circumstances – see Can we charge a fee?)

You should calculate the time limit from the day you receive the request (whether it is a working day or not) until the corresponding calendar date in the next month

If this is not possible because the following month is shorter (and there is no corresponding calendar date), the date for response is the last day of the following month.

If the corresponding date falls on a weekend or a public holiday, you have until the next working day to respond.

This means that the exact number of days you have to comply with a request varies, depending on the month in which the request was made.

For practical purposes, if a consistent number of days is required (eg for operational or system purposes), it may be helpful to adopt a 28-day period to ensure compliance is always within a calendar month.

Can we extend the time for a response?

You can extend the time to respond by a further two months if the request is complex or you have received a number of requests from the individual. You must let the individual know within one month of receiving their request and explain why the extension is necessary.

Can we ask an individual for ID?

If you have doubts about the identity of the person making the request you can ask for more information. However, it is important that you only request information that is necessary to confirm who they are. The key to this is proportionality. You should take into account what data you hold, the nature of the data, and what you are using it for.

You need to let the individual know as soon as possible that you need more information from them to confirm their identity before responding to their request. The period for responding to the request begins when you receive the additional information.