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?
Template: Request Register
Keep track of every request in a register: who, when, what was asked, and how it was handled.
View the template arrow_forwardStep 2: Check whether portability applies
This is where portability gets specific. It only applies when all three conditions are met:
-
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.
-
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.
-
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
GDPRWise generates response templates and helps you keep a register of all received requests.