Definition. The right to data portability (GDPR Article 20) allows individuals to receive their personal data in a structured, commonly used, and machine-readable format (e.g., JSON, CSV, XML) and to transmit it to another controller without hindrance. It applies only to data processed by automated means on the legal basis of consent (Article 6(1)(a)) or contract (Article 6(1)(b)), and only to data the data subject has provided to the controller — not to derived or inferred data. The controller must respond within one month, extendable by two months for complex requests.
The right to data portability under GDPR allows individuals to receive their personal data in a structured, commonly used, and machine-readable format — and to transmit that data to another controller without hindrance. Enshrined in Art. 20 GDPR, this right has specific conditions that distinguish it from the broader right of access: it applies only to data processed by automated means, only on the legal basis of consent or contract, and only to data “provided by” the data subject. Understanding these boundaries is essential for organisations implementing the right to data portability GDPR.
Key Takeaways
- Art. 20 GDPR grants the right to receive personal data in a structured, commonly used, and machine-readable format (JSON, CSV, XML are common choices).
- The right applies only when processing is based on consent (Art. 6(1)(a) or Art. 9(2)(a)) or contract performance (Art. 6(1)(b)), and carried out by automated means.
- It covers data “provided by” the data subject — both actively provided data (form submissions) and observed data (usage history, activity logs), but not inferred or derived data (credit scores, analytics profiles).
- The data subject can request direct transmission from one controller to another “where technically feasible” (Art. 20(2)).
- The right to data portability does not override the rights and freedoms of others (Art. 20(4)) and does not apply when processing is based on legitimate interests or legal obligation.
Art. 20 GDPR: What the Right to Data Portability Requires
Art. 20 GDPR contains four paragraphs that define the scope and limits of the right (see our Article 20 paragraph guide):
Art. 20(1) — The data subject has the right to receive personal data concerning them, which they have provided to a controller, in a structured, commonly used, and machine-readable format, and has the right to transmit that data to another controller without hindrance, where:
- (a) processing is based on consent or on a contract; and
- (b) processing is carried out by automated means.
Art. 20(2) — The data subject has the right to have personal data transmitted directly from one controller to another, where technically feasible.
Art. 20(3) also excludes processing necessary for a public-interest task or official authority. Exercise of the right to data portability is “without prejudice to Art. 17” — meaning it does not automatically trigger the right to erasure, nor does it prevent the data subject from also exercising that right.
Art. 20(4) — The right shall not adversely affect the rights and freedoms of others. This limits portability where the data includes information about third parties (e.g., email conversations, shared photos).
When Data Portability Applies — and When It Does Not
The right to data portability GDPR has narrower scope than the right of access (Art. 15). Understanding the boundaries prevents both over-compliance and under-compliance.
Portability Applies When:
| Condition | Requirement |
|---|---|
| Legal basis | Consent (Art. 6(1)(a) / Art. 9(2)(a)) or contract (Art. 6(1)(b)) — see the six lawful bases under Article 6 |
| Processing method | Automated means (not paper files) |
| Data type | Data “provided by” the data subject |
Portability Does NOT Apply When:
| Scenario | Why Not |
|---|---|
| Processing based on legitimate interests (Art. 6(1)(f)) | Art. 20(1)(a) limits scope to consent and contract |
| Processing based on legal obligation (Art. 6(1)©) | Same — not covered by Art. 20 |
| Processing for public interest (Art. 6(1)(e)) | Same |
| Inferred or derived data (credit scores, risk profiles) | Not “provided by” the data subject |
| Manual (paper) processing | Art. 20(1)(b) requires automated means |
| Export containing other people’s data | Assess their rights; mixed records are not automatically excluded |
What Does “Provided By” the Data Subject Mean?
The EDPB’s Guidelines on the right to data portability (WP 242 rev.01) distinguish three categories:
- Actively provided data — form submissions, uploaded content, entered preferences. Clearly covered.
- Observed data — usage logs, activity history, location data generated by using a service, transaction records. Also covered — the data subject “provided” this data through their use of the service.
- Inferred or derived data — algorithmic outputs, credit scores, segmentation profiles, analytics results. Not covered — the controller created this data, the data subject did not provide it.
Hypothetical example, assuming Article 20’s conditions apply: A music streaming service must port a user’s playlist data (actively provided), listening history (observed data), and uploaded profile information. It does not need to port its algorithmic taste profile or recommendation model outputs (inferred data).
Comparison: Right to Data Portability vs Right of Access
These two rights are frequently confused. They serve different purposes and have different scopes:
| Right of Access (Art. 15) | Right to Data Portability (Art. 20) | |
|---|---|---|
| Legal basis restriction | None — applies to all legal bases | Only consent or contract |
| Data scope | All personal data about the data subject | Only data “provided by” the data subject |
| Format | Any intelligible form | Structured, commonly used, machine-readable |
| Purpose | Transparency — let the data subject know what is processed | Reuse — let the data subject move data elsewhere |
| Includes inferred data? | Yes | No |
| Direct transmission to another controller? | No | Yes, where technically feasible |
| Response time | One month (Art. 12(3)) | One month (Art. 12(3)) |
A data subject who wants to know everything an organisation holds about them should exercise the right of access under Article 15. A data subject who wants to switch services and bring their data should exercise data portability.
For a comprehensive understanding of what constitutes personal data under GDPR, see our dedicated guide.
Machine-Readable Format Requirements
Art. 20(1) requires data to be provided in a “structured, commonly used, and machine-readable format.” The GDPR does not mandate a specific format, but the EDPB guidelines and practical consensus point to:
| Format | Best For | Notes |
|---|---|---|
| JSON | Structured data, API integrations | Widely supported, preserves data structure |
| CSV | Tabular data (contacts, transactions) | Simple, universally readable |
| XML | Complex hierarchical data | More verbose, but highly structured |
Key requirements:
- The format must be machine-readable — a PDF scan of printed records does not comply.
- The format must be commonly used — proprietary formats that require specific software do not comply.
- The data must be structured — a plain text dump without field labels does not meet the requirement.
Practical implementation: Build export functionality into your application. A user dashboard with a “Download my data” button that generates a JSON or CSV file is the most common approach. For direct controller-to-controller transfers (Art. 20(2)), APIs are the standard mechanism — though “where technically feasible” acknowledges that not all controllers have compatible systems.
Practical Implementation for Organisations
Step 1: Identify Portable Data
Map which data falls within Art. 20 scope:
- Which processing activities are based on consent or contract?
- Which data was “provided by” the data subject (actively or through observed behaviour)?
- Exclude inferred/derived data and data processed under other legal bases.
Step 2: Build Export Capability
- Implement automated data export in at least one machine-readable format (JSON or CSV minimum)
- Include all qualifying data: profile information, content, preferences, usage history, transaction records
- Ensure exports can be generated within the Art. 12(3) one-month deadline
Step 3: Enable Direct Transfers
Where technically feasible, provide direct transmission to the recipient controller the individual identifies. An API is one possible method, not a legal requirement for every organisation. Verify the destination and protect the transfer; an unverified email address should not receive a complete export merely because it appears in a request.
Step 4: Handle Third-Party Data
An export can contain data relating to several people, such as a shared transaction or correspondence. Article 20(4) protects others’ rights but does not justify refusing the whole request automatically. Assess the context and the receiving controller’s proposed use. Record any necessary safeguards or limited exclusions and explain them to the requester.
Step 5: Document and Track
Record receipt, identity checks where justified, the eligibility decision, datasets searched, format selected, destination verification and the actual delivery date. A reminder is useful only if someone owns the next action. Keep evidence proportionate; do not retain a second complete export indefinitely as proof that the request was handled.
Article 20 text: how to use the official provision
For the authoritative wording, open Article 20 in the official GDPR publication. The paragraph explanations above are a guide, not a substitute for the full text. Read paragraph 1 for eligibility, paragraph 2 for direct transmission, paragraph 3 for its relationship with erasure and public tasks, and paragraph 4 for other people’s rights. Read Article 12 alongside it for timing and communication.
Do not confuse the right with a promise that two services must offer identical functions. A reusable export needs intelligible fields and relationships, but the GDPR does not require controllers to build technically compatible systems. Nor does choosing CSV make an incomplete dataset compliant.
Hypothetical export acceptance check
A customer asks a subscription service to transfer account details and usage history to another provider. The service first confirms which records were processed under the subscription contract and which were produced through the customer’s use. Its separately inferred marketing segment is outside the portability scope, although an access request may reach personal data of that kind.
The export contains an account table, a usage table and a short dictionary explaining identifiers, timestamps, units and empty values. A reviewer checks that every usage row points to the correct account, that dates are interpreted consistently and that a test import does not lose special characters. They also confirm that unrelated household members’ records have not been included by mistake.
If direct transmission is not technically feasible, the team records the actual reason and provides the qualifying data securely to the individual. If a requested category is excluded, the response identifies that category and explains the applicable limit. The individual’s request for transfer does not itself authorise deletion of records still lawfully needed for another purpose. Review that separately under storage limitation.
FAQ
What is the right to data portability under GDPR?
Art. 20 GDPR gives individuals the right to receive their personal data in a structured, commonly used, and machine-readable format, and to transmit it to another controller without hindrance. It applies only to data processed by automated means, based on consent or contract performance, and limited to data “provided by” the data subject.
Does the right to data portability apply to all personal data?
No. It applies only to data provided by the individual (actively submitted or observed through use of the service), processed based on consent (Art. 6(1)(a)) or contract (Art. 6(1)(b)), and processed by automated means. Inferred data (credit scores, algorithmic profiles) and data processed under legitimate interests or legal obligation are excluded.
How does data portability differ from the right of access?
The right of access (Art. 15) covers all personal data about the data subject, under any legal basis, in any intelligible format. Data portability (Art. 20) is narrower: only consent/contract-based data, only data provided by the data subject, and it must be in a machine-readable format. Portability also includes the right to direct controller-to-controller transfer, which access does not.
Within what timeframe must organisations respond to data portability requests?
One month from receipt of the request, per Art. 12(3). This can be extended by a further two months for complex or numerous requests, but the controller must inform the data subject of the extension and the reasons within the first month. Failure to respond within the deadline is an independent infringement.
Conclusion
Article 20 gives individuals a defined route to reuse qualifying personal data. A reliable response combines the eligibility assessment with a usable export, secure delivery and an explanation of any limits. Build those steps into the same operational process used for other rights, without treating portability as an unrestricted copy of every internal record.