Right to Data Portability under GDPR Article 20

Updated: July 2026

The right to data portability under GDPR Article 20 lets people get the personal data they gave to a controller in a structured, commonly used, and machine-readable format. They can then move that data between services without being blocked. Meeting this right takes both technical setup and clear compliance steps, which any organisation handling requests from people in the EU needs to plan for.

Key Takeaways:

• Data portability applies only to automated processing based on consent or contract. It covers data people provided, not data the controller inferred or derived.

• Organisations must provide the data in structured, common, machine-readable formats such as CSV, JSON, or XML, within one month of a valid request.

• Where it is technically feasible, controllers should support direct transfer between services, with security measures to protect user privacy.

What is the right to data portability?

Data portability is the right of people to get their personal data from one controller and reuse it with other services or platforms. It lets people move the information they gave to an organisation. This supports competition in the digital economy and reduces vendor lock-in, which used to limit consumer choice.

The right gives users more control over their data across platforms and supports interoperability between systems. It helps consumers by making sure they can get their data in formats that software can process automatically.

How does data portability differ from the right of access?

Data portability is different from the right of access under Article 15, though both give personal data to the individual.

Data portability is about reuse. It needs structured formats that other systems can process without human input. Access requests can include inferred data and explanations of processing. Portability covers only the data the person provided, in a machine-readable format suited to automated processing.

How does it relate to other GDPR rights?

Data portability works alongside other rights, including rectification, erasure, and the right to withdraw consent. Using the portability right does not delete data from the original controller. Erasure is a separate request the person must make.

Data portability rests on consent under Article 6(1)(a) or contract under Article 6(1)(b). It supports data protection by design, because organisations must build in technical measures that let data move between services from the start.

What is the legal framework and scope?

The legal basis for data portability is GDPR Article 20 and the supporting guidance from the European Data Protection Board. Together they set out when organisations must respond to a portability request and what data they must provide.

When does the right apply?

Data portability applies when processing is based on consent under Article 6(1)(a) or contract under Article 6(1)(b), and when the data is processed by automated means. Organisations that process data for a legal obligation or a public-interest task do not have to provide portability for those activities.

The right must not harm the rights and freedoms of others. Controllers should check whether sending the data would put a third party’s privacy or security at risk. Where direct transfer is not technically feasible, organisations can record the limits while still providing the data where possible.

What data does it cover?

Portability covers personal data the person gave directly, such as account details, preferences, and uploaded content. It also covers observed data from how a person uses a system, including location history, search queries, and recorded behaviour.

Controllers must leave out inferred or derived data made through analysis, profiling, or algorithms. Raw data from device use qualifies for portability. Predictive scores or recommendations created by the organisation do not.

What are the technical requirements?

Structured formats let both people and software organise and read the data easily. The data must be in common formats that are widely supported across platforms.

Machine-readable means the receiving system can process the data automatically, without manual work or format conversion. Organisations should choose an interoperable format that supports smooth data exchange while keeping data accurate and secure during transfer.

How does the compliance process work?

Organisations need set procedures for portability requests. These should meet the one-month response time and keep data secure throughout.

What are the steps to handle a request?

Use these steps when responding to a portability request under Article 20, whether the person wants to move their data to another service or get it for reuse.

1. Verify identity and request scope. Confirm the person’s identity with your usual authentication methods, and clarify which data and processing activities the request covers.

2. Assess legal conditions. Check whether the processing is based on consent or contract and whether it is automated. Record any cases where portability does not apply.

3. Extract the relevant data. Find and retrieve the data the person provided from your systems. Leave out inferred data, and make sure you cover all portable information.

4. Format the data. Convert it into a structured, common, machine-readable format: CSV for simple datasets, JSON for complex nested data, or XML for enterprise systems that need metadata.

5. Transmit securely. Send the formatted data to the person, or to another controller where technically feasible. Use encryption and secure authentication to protect the data during transfer.

Which data format should you use?

Feature	CSV	JSON	XML
Ease of Use	Simple tabular structure, widely supported by spreadsheet software	Modern web standard with intuitive key-value pairs	Complex hierarchical structure requiring technical expertise
Technical Compatibility	Universal support across platforms and applications	High compatibility with web services and APIs	Strong enterprise system integration and metadata support
Data Complexity Support	Limited to flat, tabular data structures	Supports nested objects and complex relationships	Handles highly structured data with extensive validation capabilities
Industry Adoption	Ubiquitous for basic data exchange and analysis	Preferred for modern web applications and mobile services	Standard for enterprise document management and data interchange

Choose CSV for simple tabular data that users can view and analyse easily. Choose JSON for complex user-generated content that needs its relationships kept intact. Choose XML for enterprise settings where strict validation and detailed metadata matter.

Conclusion

Data portability is both a legal duty under the GDPR and a chance for organisations to show they take user privacy seriously. Doing it well needs the right technical setup, clear procedures, and ongoing investment in systems that move data securely between services.

Organisations that support portability early do well in markets where consumers value data control and easy transfers between services. Handled this way, compliance can build user trust and improve interoperability, which sets a business apart from competitors.

Frequently Asked Questions

Does data portability apply to all personal data an organisation holds about an individual?

No. It applies only to data the person provided through direct input or observed interactions with automated systems. Organisations must leave out inferred data made through profiling, analysis, or algorithms.

Can organisations charge fees for providing data in portable formats?

No fee applies to the first request. Controllers may charge a reasonable admin fee for extra copies or excessive requests that put a heavy load on resources, as long as the charge is clear and proportionate.

What happens if technical feasibility prevents direct data transmission between controllers?

When direct transfer is not feasible, the organisation must give the data to the person in a structured, common, machine-readable format. The person can then move it to other services themselves, and the organisation should record the technical limits it ran into.