Right to Data Portability: What You Need to Provide

Recognising a data portability request

A data portability request is when someone says: “Give me my data so I can take it to another provider.” It is different from a regular access request. The goal is not just to see the data, but to reuse it elsewhere.

The request does not need to use the words “data portability.” If a customer writes “I want to export my data” or “send my data to [other company]”, that counts as a portability request.

Step 1: Register the request

As with any data subject request, log it immediately:

• Who is making the request
• When you received it (the one-month deadline starts now)
• Through which channel it came in
• What exactly is being asked - do they want the data themselves, or do they want you to send it directly to another controller?

Step 2: Check whether portability applies

This is where portability gets specific. It only applies when all three conditions are met:

1. The data was provided by the data subject. This includes data they actively gave you (name, email, uploaded files) and data generated by their activity (purchase history, usage logs, location data). It does not include data you created yourself, such as internal notes, risk assessments, or analysis.

2. Processing is based on consent or contract. If you process the data on the basis of legitimate interest, legal obligation, or public interest, portability does not apply to that data.

3. Processing is carried out by automated means. Paper-only files are excluded, but in practice almost all processing today is automated.

If these conditions are not met, you do not need to comply with a portability request. You may still need to handle it as a regular access request instead.

Step 3: Determine what to include and exclude

This is where most businesses get confused. Use this table as a guide:

Data type	Include in portability?	Why?
Name, email, address provided by the customer	Yes	Provided by the data subject
Purchase history, order data	Yes	Generated by the data subject’s activity
Uploaded photos or documents	Yes	Provided by the data subject
Usage logs, click behaviour	Yes	Observed data from their activity
Your internal notes about the customer	No	Created by you, not provided by them
Credit score or risk profile you calculated	No	Derived/inferred data
Data processed under legitimate interest only	No	Wrong legal basis for portability
Employee data processed for legal obligations	No	Wrong legal basis for portability

When in doubt, ask yourself: did this data come from the person, or did we create it? If you created it, it stays out of the portability response.

Step 4: Prepare the data in the right format

The format is what sets portability apart from an access request. The GDPR requires the data to be:

• Structured - organised in a logical way, not a raw database dump
• Commonly used - a format that other businesses and software can handle
• Machine-readable - software can process it automatically

Acceptable formats:

• CSV (simplest and most widely supported)
• JSON (good for structured, nested data)
• XML (more verbose, but acceptable)

Not acceptable:

• PDF (not machine-readable)
• Scanned documents
• Screenshots

For most small and medium businesses, a CSV file is the best choice. It can be opened in Excel, imported into other systems, and is easy to generate.

Step 5: Check for direct transfer requests

The data subject may ask you to send the data directly to another controller - for example, a competitor. Under Article 20(2), you must do this where technically feasible.

In practice, “technically feasible” means:

• There is a standard API or data exchange protocol available
• The receiving controller has a system that can accept the transfer

If no standard interface exists, you are not required to build one. Inform the data subject that direct transfer is not technically feasible and provide the data to them directly instead.

Step 6: Send the response

• Deadline - within one month of receiving the request
• Extension - for complex requests, you may extend by two months, but inform the requester within the first month
• Cost - providing the data is free
• Secure delivery - use a secure channel, especially if the data contains sensitive information

Portability vs. access request - key differences

	Access request (Art. 15)	Portability request (Art. 20)
Scope	All personal data you hold	Only data provided by the data subject
Legal basis	Applies regardless of legal basis	Only consent or contract
Format	Any readable format (PDF is fine)	Must be machine-readable (CSV, JSON)
Direct transfer	Not applicable	Yes, if technically feasible
Derived data	Must include	Must not include

If you receive a portability request, check whether the person might also want a broader access request. Sometimes customers use the wrong term but actually want to see everything you hold about them.

Common pitfalls

• Providing a PDF - this does not meet the machine-readable requirement for portability
• Including too much - adding your internal notes or analysis to a portability response goes beyond what is required
• Including too little - forgetting usage data or transaction history that the person generated through their activity
• Confusing legal bases - check per data category whether processing is based on consent or contract before excluding data