Right to Data Portability: What It Means and How to Comply

Your Customer Wants to Take Their Data Somewhere Else

The right to data portability gives individuals the ability to receive their personal data in a format they can reuse -- and, where technically feasible, to have it sent directly to another organization. It is one of the newer rights introduced by the GDPR, and it is one of the most misunderstood.

Unlike the right of access, which is about transparency (letting people see what you hold), portability is about control and mobility. It is designed to prevent vendor lock-in and give individuals real power over their data by making it easy to move between services.

This guide explains when data portability applies, what format you need to use, how it differs from the right of access, and the practical steps for responding to a portability request.

What the Right to Data Portability Actually Means

GDPR Article 20 creates two distinct entitlements:

1. The right to receive personal data "in a structured, commonly used and machine-readable format"
2. The right to transmit that data to another controller without hindrance from the original controller

There is also a third element: where technically feasible, the individual can ask you to transmit the data directly to another controller on their behalf. You are not required to build new technical infrastructure to make this possible, but if you already have the capability (for example, through an API), you should offer it.

The key phrase is "machine-readable." This is not about sending someone a PDF of their account history. It is about giving them data in a format that another system can actually ingest and use -- think CSV, JSON, or XML.

The Two Conditions That Must Be Met

Data portability under GDPR Article 20 only applies when both of the following conditions are true:

1. The processing is based on consent (Article 6(1)(a) or Article 9(2)(a)) or on a contract (Article 6(1)(b))
2. The processing is carried out by automated means

If either condition is not met, the right to portability does not apply. The individual may still have the right of access under Article 15, but that is a different right with different rules.

This is an important distinction. Many businesses process personal data under legitimate interests (Article 6(1)(f)) or legal obligation (Article 6(1)(c)). Data processed under those bases is not subject to the portability right, even though it is subject to the right of access.

How Data Portability Differs From the Right of Access

The right of access (Article 15) and the right to data portability (Article 20) are related but serve different purposes. Businesses frequently confuse them, which leads to either under-delivering or over-delivering on portability requests.

What Counts as "Provided by" the Individual?

This is one of the trickier aspects of portability. The Article 29 Working Party (now the European Data Protection Board) provided guidance distinguishing three categories of data:

1. Data actively and knowingly provided -- form entries, uploaded photos, messages, profile information. This is clearly in scope for portability.
2. Observed data -- data generated by the individual's use of the service, such as search history, location data, usage logs, and activity records. The EDPB considers this in scope for portability, because the individual "provided" it through their behavior.
3. Inferred or derived data -- data created by the controller through analysis, such as credit scores, health risk assessments, customer segments, or algorithmic profiles. This is not in scope for portability, because the controller created it, not the individual.

For the right of access, all three categories are in scope. For portability, only the first two apply.

What Format Should You Use?

The GDPR says "structured, commonly used and machine-readable." It does not prescribe a specific format, but the intent is clear: the data needs to be usable by another system without requiring manual re-entry.

Acceptable Formats

• CSV -- the most universally compatible option. Almost every system can import CSV files. This is a safe default for most data types.
• JSON -- well-suited for structured data with nested relationships. Common in API-based data exports.
• XML -- another machine-readable option, though increasingly less common than JSON.
• Proprietary but open formats -- some industry-specific formats may be appropriate if they are widely supported (for example, vCard for contact data, iCalendar for calendar events).

Unacceptable Formats

• PDF -- not machine-readable. A PDF of someone's account history is fine for an access request, but it does not satisfy a portability request.
• Paper printouts -- obviously not machine-readable.
• Screenshots or images -- same problem as PDFs.
• Proprietary formats that require specific software -- defeats the purpose of portability.

Practical Tip

If you are unsure which format to use, CSV is almost always a reasonable choice. It is simple, widely supported, and does not require specialized software to open. For more complex data structures with nested relationships, JSON is the better option.

If the individual or the receiving controller requests a specific format, you should accommodate it if you reasonably can, but Article 20 does not require you to convert data into any format the requester demands.

When Data Portability Does NOT Apply

The right to data portability is narrower than many people realize. It does not apply in the following situations:

Processing Not Based on Consent or Contract

If your legal basis for processing is legitimate interests (Article 6(1)(f)), legal obligation (Article 6(1)(c)), public interest (Article 6(1)(e)), or vital interests (Article 6(1)(d)), portability does not apply to that data.

Example: An employer processes an employee's payroll data to comply with tax law (legal obligation). The employee requests portability of their payroll records. Portability does not apply because the legal basis is legal obligation, not consent or contract. However, the employee can still request a copy under the right of access.

Manually Processed Data

If personal data is processed entirely by manual means -- paper files, handwritten notes, physical records with no automated component -- the portability right does not apply. The GDPR specifies that portability only covers processing "carried out by automated means."

Would Adversely Affect Rights of Others

Article 20(4) states that the right to data portability "shall not adversely affect the rights and freedoms of others." If providing the data in portable format would necessarily include another person's personal data (for example, a joint account), you need to consider whether you can separate it or whether an exemption applies.

Public Authority Processing

Article 20(3) specifies that portability does not apply when processing is necessary for a task carried out in the public interest or in the exercise of official authority.

CCPA and Data Portability

The California Consumer Privacy Act does not have a standalone "right to data portability" with the same name, but the concept is embedded within the right to know.

Under Cal. Civ. Code Section 1798.100, consumers have the right to request that a business disclose the specific pieces of personal information it has collected. When the request is submitted electronically, the business must provide the information "in a portable and, to the extent technically feasible, readily useable format that allows the consumer to transmit this information to another entity without hindrance."

Key Differences From GDPR Portability

• No legal basis restriction -- the CCPA does not limit portability to data processed under specific legal bases. If you collected it, the consumer can request it.
• Broader data scope -- the CCPA's definition of "personal information" is broad and includes inferred data and profiles, unlike GDPR portability which excludes inferred data.
• No right to direct transfer -- the CCPA does not require businesses to transmit data directly to another controller, though providing data in a portable format serves a similar purpose.
• 12-month lookback -- the CCPA right to know generally covers the preceding 12 months, unless the business can provide data beyond that period.
• Timeline -- 45 calendar days (extendable to 90), compared to GDPR's one calendar month (extendable to three months).

PIPEDA and UK GDPR

UK GDPR

The UK GDPR retains the right to data portability in substantially the same form as the EU GDPR (Article 20). The same conditions apply: consent or contract basis, automated processing, machine-readable format. The ICO's guidance aligns with the EDPB's interpretation on what data is in scope.

PIPEDA (Canada)

PIPEDA does not include a standalone right to data portability equivalent to GDPR Article 20. However, under Principle 4.9 (Individual Access), individuals have the right to access their personal information, and organizations should provide it in a form that is "generally understandable." Some Canadian provinces have introduced or proposed portability-specific provisions, and the proposed Consumer Privacy Protection Act (CPPA, Bill C-27) would introduce a more explicit portability right in Canada. As of the date of publication, the CPPA has not yet been enacted.

Practical Steps for Responding to a Portability Request

Step 1: Confirm This Is a Portability Request

Not every request for data is a portability request. If the individual simply asks for "a copy of my data," that is likely an access request under Article 15. If they specifically ask for their data in a machine-readable format, or say they want to transfer their data to another provider, treat it as a portability request under Article 20.

If it is unclear, respond to both: provide the data in a human-readable format (access) and a machine-readable format (portability). This covers both rights without creating additional back-and-forth.

Step 2: Verify Identity

Use the same identity verification process you would use for any DSAR. The level of verification should be proportionate to the sensitivity of the data.

Step 3: Identify Qualifying Data

Review your data holdings and identify which personal data meets the portability criteria:

1. Was it provided by the individual (actively or through observed behavior)?
2. Is it processed on the basis of consent or contract?
3. Is the processing automated?

Data that meets all three criteria is in scope for portability. Data that does not can still be provided under the right of access if the individual also made an access request.

Step 4: Extract the Data

Export the qualifying data in a structured, machine-readable format. Common approaches:

• Database export -- run a query to extract the individual's records and export as CSV or JSON
• API export -- if your system has an API, use it to pull the individual's data programmatically
• Application export -- many SaaS platforms have built-in data export tools that produce machine-readable output

Ensure the exported data is complete and accurate. Include clear field names or headers so the data is self-explanatory.

Step 5: Consider Direct Transfer

If the individual has asked you to transmit their data directly to another controller, assess whether this is technically feasible:

• Do you have an API or standard data transfer mechanism?
• Can you establish a secure connection to the receiving controller?
• Is the receiving controller set up to accept inbound data transfers?

If direct transfer is technically feasible, proceed with it. If it is not, explain this to the individual and provide the data to them directly so they can forward it themselves.

Step 6: Respond Within the Deadline

The deadline is the same as for access requests:

• GDPR/UK GDPR: One calendar month from receipt, extendable by up to two additional months for complex requests
• CCPA: 45 calendar days, extendable by an additional 45 days

Provide the data securely. If sending electronically, use encryption or a secure download link rather than attaching unencrypted data to an email.

Common Scenarios

Customer Switching SaaS Providers

A customer using your project management tool wants to move to a competitor. They request portability of their data so they can import it into the new platform.

In scope: Their project data, task lists, uploaded files, comments, profile information, and activity logs (all provided by them or observed through their use, processed under the service contract).

Not in scope: Internal analytics you generated about their usage patterns, customer health scores, or churn predictions (inferred/derived data).

Format: JSON or CSV export of their workspace data. If you have an API that the receiving platform can connect to, offer the direct transfer option.

Employee Leaving the Company

A departing employee requests portability of their personal data.

In scope: Data they provided (contact details, bank information submitted for payroll under their employment contract) and observed data processed under the contract (badge access logs, work email metadata).

Not in scope: Performance reviews written by managers (these are the controller's own assessments, not data provided by the employee). Payroll records processed under legal obligation (wrong legal basis for portability). However, the employee can access all of this under Article 15.

Practical note: Employee data portability requests are less common than customer requests, but they can be more complex because employee data is often processed under multiple legal bases simultaneously.

User Transferring Social Media Data

A user wants to move their photos, posts, and messages from one social network to another. This is the classic portability scenario that Article 20 was designed for.

In scope: All content the user uploaded or created (photos, posts, messages, profile data, friend lists), plus observed data (like and reaction history, viewed content logs).

Not in scope: Algorithmic recommendations, ad targeting profiles, or engagement scores generated by the platform.

Frequently Asked Questions

Do I need to build an API for portability requests? No. Article 20 requires you to provide data in a machine-readable format and, where technically feasible, to transmit it directly to another controller. If you do not have an API or automated transfer mechanism, you are not required to build one. Providing a CSV or JSON file to the individual satisfies the requirement.

Can I charge for a portability request? No. Unlike the right of access, where you can charge a reasonable fee for further copies (Article 15(3)), there is no fee provision for portability requests under Article 20.

What if the individual asks for data in a format I cannot provide? You are required to provide data in "a structured, commonly used and machine-readable format." You are not required to provide it in any specific format the individual demands. If they ask for something unusual, offer CSV or JSON as alternatives and explain that these are widely supported machine-readable formats.

Does portability apply to data I hold about the individual from third-party sources? Under GDPR, portability only applies to data the individual "provided to" the controller. Data obtained from third-party sources was not provided by the individual and is therefore not in scope for portability (though it is in scope for access). Under CCPA, the scope is broader and includes all personal information the business has collected, regardless of source.

Can I refuse a portability request? You can refuse if the conditions for portability are not met -- for example, if the processing is based on legitimate interests rather than consent or contract, or if the processing is not automated. You must inform the individual of your reasons for refusal and their right to complain to the supervisory authority.

References

• GDPR Article 20: Right to data portability. Article 20
• GDPR Article 15: Right of access by the data subject. Article 15
• GDPR Article 12: Transparent information, communication, and modalities. Article 12
• EDPB (formerly Article 29 Working Party): Guidelines on the right to data portability (WP 242 rev.01). EDPB Guidelines
• ICO: Right to data portability guidance. ICO guidance
• California Consumer Privacy Act (CCPA): Cal. Civ. Code Section 1798.100. Full text