GDPR Article 20 gives individuals the right to receive personal data they have provided to a controller in a structured, commonly used, machine-readable format, and to have it transmitted directly to another controller — but only where processing is based on consent or contract, and only for data the individual actually provided (not data the controller derived or inferred from it).
Key takeaways
- The right applies only to two legal bases: consent (Article 6(1)(a)) and contract (Article 6(1)(b)). Data processed under legitimate interests, legal obligation, vital interests, or public task is explicitly excluded.
- "Data the data subject has provided" covers both actively submitted data (form fields, uploaded files, account preferences) and observed data generated through use of a service (location history, transaction logs, app usage data). It does not cover inferred or derived data — algorithmic outputs, credit scores, behavioral segments, or any data the controller created by analyzing the provided data.
- "Structured, commonly used, machine-readable format" is not defined in the regulation. The ICO and EDPB guidance converges on JSON, CSV, and XML as acceptable formats. The format must allow the data to be processed by another system without manual conversion.
- The direct transmission right (Article 20(2)) — having data sent from one controller to another without the individual downloading it first — applies "where technically feasible." Controllers cannot refuse this on grounds of inconvenience; it must be technically impossible.
- The EU Data Act (applicable from September 12, 2025) extends portability obligations for IoT-generated and cloud-held data beyond what Article 20 covers, and imposes specific switching obligations on cloud and SaaS providers. These are separate obligations but frequently arise in the same compliance conversation.
- Response deadline: one month from receipt of the request, extendable by two further months for complex or numerous requests (with notification to the data subject within the first month explaining why).
What Article 20 actually covers
Article 20(1) states the right applies to personal data the data subject has provided to a controller. Two categories of data qualify:
Actively provided data: Information the individual consciously submitted — registration form data, typed preferences, uploaded documents, payment details entered, contact information provided. The individual took an affirmative action to supply this data.
Observed data: Information generated automatically through the individual's use of a service — GPS location data collected while the app runs, search queries, purchase history, listening history, click and browsing logs, device information collected during normal use. The individual "provided" this through their behavior, even though they did not consciously type it in.
What does not qualify:
- Inferred data: conclusions drawn from observed data — a recommendation engine's output, a risk score, a behavioral segment, a churn probability score. The controller created this through analysis; the data subject did not provide it.
- Derived data: data generated entirely by the controller's processing — an aggregated analytics summary, a customer lifetime value calculation, a fraud risk flag. These are controller-generated and not portable.
- Data processed under legal bases other than consent or contract: HR records held under legal obligation, data processed for public task or vital interests, data processed under legitimate interests. None of this is subject to Article 20 regardless of format.
Practical example: A fitness app user requests their data under Article 20. In scope: their account details (name, email, date of birth — actively provided), their recorded workout sessions (GPS coordinates and timestamps — observed), their app preferences (units, goals — actively provided). Not in scope: the app's analysis that classified them as a "high-risk for churn" user, or the aggregate statistics the app generates for its own analytics.
The format requirement
Article 20(1) requires the data be provided in a "structured, commonly used, and machine-readable format." The regulation does not specify which formats qualify. EDPB guidance indicates:
- Structured: organized in a defined schema, not free-form text or a PDF scan
- Commonly used: a format in widespread use in the relevant context — not a proprietary format requiring specialized software to open
- Machine-readable: processable by software without manual extraction — binary or XML-based formats where the structure is programmatically interpretable
In practice:
- JSON is the most appropriate format for complex data with nested relationships (user profiles, activity logs with multiple attributes per entry). Preserves structure and relationships.
- CSV is appropriate for flat tabular data (transaction lists, contact lists). Easy to open in spreadsheet tools but loses hierarchy.
- XML is appropriate where strict validation and metadata are required, particularly in enterprise or regulated-sector contexts.
- PDF does not qualify as machine-readable. A PDF of a table is structured and commonly used, but the data cannot be processed by another system without extraction.
- Proprietary formats (.xlsx, Apple Health XML) may qualify if they are in widespread use in the sector and can be imported by competing services.
The ICO guidance specifically states that where no specific format is in common use in your industry, you should use open formats such as CSV, JSON, or XML. The goal is interoperability: another controller should be able to import the file directly.
The direct transmission right
Article 20(2) adds that where technically feasible, the individual has the right to have data transmitted directly from one controller to another — not downloaded as a file and then re-uploaded manually.
"Technically feasible" does not mean convenient or straightforward. It means technically possible given existing infrastructure. If the receiving controller exposes an API that can accept the data, and the sending controller can connect to that API, direct transmission is generally considered feasible. Controllers cannot claim it is not technically feasible simply because they have not built an API or because the implementation would require engineering work.
In practice, direct transmission is most commonly implemented through:
- A data export API that the individual can point at a competing service's import endpoint
- OAuth-connected data sharing where both controllers have agreed integration protocols
- Industry-standard data portability frameworks (banking's open banking APIs, healthcare's FHIR standard for health records)
The EDPB has noted that the direct transmission right strengthens competition and reduces lock-in effects — the legislative intent behind this provision. Controllers in sectors with established data portability frameworks (banking, energy, telecommunications) face stronger scrutiny on "technically feasible" claims.
Relationship to Data Subject Access Requests (DSARs)
Article 20 portability requests are distinct from Article 15 DSARs, though they often arrive together. The key differences:
| DSAR (Article 15) | Portability (Article 20) | |
|---|---|---|
| Scope of data | All personal data held | Only data subject "provided," only under consent/contract |
| Format | No format requirement (readable, yes; machine-readable, no) | Structured, machine-readable |
| Purpose | Verify lawfulness of processing | Enable switching or reuse |
| Direct transmission | No | Yes (where technically feasible) |
| Legal bases covered | All | Consent and contract only |
Operationally, many organizations process these together when a request arrives that cites both rights. The EDPB has confirmed that a controller can provide a portability response as part of a broader DSAR response, but the portability-specific format obligation still applies to the Article 20-qualifying data within that response.
See the GDPR data subject access request response guide for the DSAR process; this guide focuses on the additional portability-specific requirements.
The EU Data Act: what changes from September 2025
The EU Data Act (Regulation (EU) 2023/2854) became fully applicable on September 12, 2025. It extends portability obligations significantly beyond GDPR Article 20 in two ways.
Scope expansion: Where Article 20 covers only personal data processed under consent or contract, the Data Act covers all data — personal and non-personal — generated by connected products and related services (IoT devices, connected vehicles, smart home systems, industrial equipment, wearables). A manufacturing company's IoT sensor data, which includes no personal data, is subject to Data Act portability obligations but not Article 20.
Cloud and SaaS switching obligations: The Data Act imposes specific obligations on cloud service providers (IaaS, PaaS, SaaS) to facilitate customer switching. Providers must:
- Remove contractual barriers to switching (no exit fees or penalties for migration)
- Enable data and workload export in interoperable formats
- Provide a maximum 30-day transitional period to complete migration
- Eliminate egress fees for data export by September 2027
These cloud switching obligations are separate from Article 20 but frequently arise in the same vendor review or procurement process. For DPOs reviewing SaaS vendor contracts: both Article 28 DPA obligations and Data Act switching clauses should be verified in vendor agreements from 2025 forward.
Implementation: how to respond to a portability request
Step 1 — Verify the request is valid
Confirm: (a) the data subject's identity, (b) the request is for Article 20 portability (not just a general data request), and (c) the data requested falls within Article 20's scope — processed under consent or contract, and data the subject provided.
Step 2 — Map the in-scope data
Identify every system holding personal data for this individual that was collected under consent or contract. This is where a current data mapping exercise pays off — you cannot fulfill a portability request from systems you have not mapped.
Common in-scope systems: CRM (contact and account data), e-commerce platforms (order and preference history), analytics systems if using consent as the basis, email marketing tools (preference and engagement data held under consent), app usage logs collected under consent.
Step 3 — Extract and format the data
Export all in-scope data for the individual in JSON, CSV, or XML. If your systems use different formats internally, the export for the individual must be consolidated and normalized — delivering a dozen separate exports in proprietary formats is not compliant.
Step 4 — Exclude derived and inferred data
Review the export before sending. Remove any fields that represent controller-generated conclusions: risk scores, segments, classification outputs, analytics-derived attributes.
Step 5 — Respond within one month
The one-month clock starts from receipt of the request, not from verification. If verification takes two weeks, that comes out of the same month. If you need more time (genuine complexity or numerous concurrent requests), notify the data subject within the first month of the extension and the reason.
Step 6 — Handle direct transmission requests
If the individual asks for data to be sent directly to another controller: identify whether direct transmission is technically feasible. If the receiving controller has a publicly documented import API, it generally is. Build a process to execute this rather than treating it as a novel case each time.
Step 7 — Record the request and response
Log the request, the data provided, the format used, the response date, and any exclusions with justification. This record is your evidence if the response is challenged before a DPA.
Frequently asked questions
Does Article 20 apply to B2B data — data about employees or business contacts?
Yes. Article 20 applies to any natural person whose data is processed under consent or contract. An employee whose employment contract is the legal basis for data processing, and whose data was "provided" by them (CV submitted, contact details provided, bank details entered), can exercise the Article 20 right. The right does not apply to legal persons (companies) — only natural persons.
A customer has asked us to send their order history directly to a competitor. Do we have to?
Only if direct transmission is technically feasible. If the competitor exposes an API that can accept the data, and you can connect to it, the answer is generally yes. You cannot require the customer to download and re-upload the data themselves if direct transmission is feasible. You can, however, require the customer to authenticate the receiving controller's import endpoint and confirm the transmission target before you send.
Can we charge a fee for portability requests?
No. Article 20 requests must be handled free of charge. The only exception is where requests are manifestly unfounded or excessive (e.g., repeated identical requests in bad faith), in which case you may charge a reasonable fee or refuse — but you must be able to demonstrate the request was manifestly unfounded or excessive.
Our analytics platform holds data processed under legitimate interests, not consent. Is that subject to Article 20?
No. Only data processed under consent (Article 6(1)(a)) or contract (Article 6(1)(b)) is subject to the portability right. If you rely on legitimate interests for analytics, that data is not in scope for Article 20 — though it may be subject to a DSAR under Article 15.
How does this interact with our data retention policy? Can we delete data before honoring a portability request?
No. A pending portability request creates an obligation to preserve the data until the request is fulfilled, even if your standard retention period would otherwise trigger deletion during the response window. Once the request is received, deletion should be paused for the data in scope until the response is sent.
What happens if we cannot technically separate portable data from non-portable data in our systems?
This is a data mapping problem that Article 20 compliance makes visible. Controllers whose systems cannot isolate consent-basis personal data from legitimately-interest-basis data face a genuine compliance gap. The practical solution is to tag data by legal basis at collection — a capability that a consent management platform can provide for web-collected data, and that your CRM or data warehouse should be configured to record.
