Article 20 — Right to data portability

Article 20(1) is the core provision establishing the right to data portability. Unlike other data subject rights that focus primarily on transparency or correcting unlawful processing, Article 20(1) gives individuals a practical ability to recover and reuse their personal data. It enables data subjects to obtain a copy of qualifying personal data in a format that facilitates further use and, where they choose, transfer those data to another controller.

This right is deliberately limited by several cumulative conditions. A controller is obliged to comply only where all of the following requirements are met:

1. the request concerns personal data concerning the data subject;

2. the data were provided by the data subject;

3. the processing is based on consent orcontract;

4. the processing is carried out by automated means.

Each requirement has generated extensive legal debate and practical guidance, particularly in the Article 29 Working Party (WP29) Guidelines on the Right to Data Portability (WP242 rev.01), which continue to be endorsed by the European Data Protection Board (EDPB).

I. The Nature of the Right to Receive Personal Data

The opening words of Article 20(1) provide that:

"The data subject shall have the right to receive the personal data concerning him or her…"

The expression "receive" is significant. Unlike Article 15, which grants access to information about processing, Article 20 requires the controller to provide the actual dataset in a reusable format.

This reflects a shift from informational transparency todata mobility.

The controller must therefore provide:

• the underlying personal data,

• in digital form,

• capable of being reused,

• without unnecessary barriers.

The objective is not merely that the data subject can read the information but that they can meaningfully reuse it.

Example

providing a customer's transaction history as an image or scanned PDF may technically disclose the information but would frustrate the objective of portability because the data cannot easily be imported into another system.

Accordingly, controllers should provide formats that preserve the utility of the data.

II. Relationship with the Right of Access under Article 15

One of the most common misconceptions is that Article 20 merely duplicates Article 15.

Although both rights involve receiving personal data, they differ fundamentally.

Article 15	Article 20
Transparency right	Mobility right
Applies to almost all processing	Limited to consent or contract
Covers all personal data undergoing processing	Covers only qualifying portable data
Copy may be human-readable	Copy must be machine-readable
Purpose is verification of legality	Purpose is reuse and transfer

For example:

A bank customer requesting:

• copies of internal fraud assessments,

• compliance records,

• AML investigations,

would generally rely upon Article 15.

However,

requesting:

• transaction history,

• beneficiary lists,

• standing orders,

• payment instructions,

would potentially fall under Article 20.

Thus, portability complements, not replaces, the right of access.

III. "Personal Data Concerning Him or Her"

Article 20 only applies to personal data concerning the requesting data subject.

The meaning of personal data remains that provided by Article 4(1):

any information relating to an identified or identifiable natural person.

Consequently, portability extends to:

• names,

• addresses,

• email accounts,

• uploaded photographs,

• messages,

• playlists,

• banking transactions,

• GPS records,

• cloud files,

• fitness records,

• purchase history,

• customer preferences.

The provision also applies to pseudonymised data, provided that the controller can still identify the individual.

Data Concerning Multiple Individuals

Many datasets concern more than one individual.

Examples

include:

• email conversations,
• messaging histories,
• shared calendars,
• bank transfers,
• family accounts,
• joint photographs. These datasets simultaneously constitute personal data relating to multiple persons. The WP29 Guidelines acknowledge that portability generally still applies. For instance, a WhatsApp conversation belongs simultaneously to:
• the requesting individual,
• every participant. The requesting individual should ordinarily receive the complete conversation because it also concerns them. However, the receiving controller must subsequently process those third-party data lawfully.

IV. Meaning of "Provided by the Data Subject"

This phrase has generated perhaps the greatest controversy surrounding Article 20.

At first glance, it appears to include only information actively entered by users.

However, both WP29 and the EDPB adopt a considerably broader interpretation.

They distinguish three categories of personal data.

Category 1: Actively Provided Data

These include information consciously submitted by the individual.

Examples

include:

• name,
• address,
• telephone number,
• email,
• uploaded files,
• photographs,
• CVs,
• payment details,
• customer preferences entered manually. These unquestionably fall within Article 20.

Category 2: Observed Data

The WP29 Guidelines also include observed data.

Observed data arise through an individual's use of a service.

Examples

include:

• browsing history,
• search history,
• location history,
• GPS routes,
• fitness tracker recordings,
• smartwatch activity,
• electricity consumption,
• mobile phone usage,
• purchase history,
• clickstream data. Although users do not manually type these data, they are generated directly through their activities. WP29 therefore considers them "provided." This interpretation significantly broadens portability.

Practical Example

A fitness application records:

• daily steps,
• running routes,
• heart rate,
• exercise sessions. Although the user never manually entered each step count,

the information results directly from the user's activity.

Therefore,

the user should ordinarily be able to export these records.

Category 3: Inferred or Derived Data

This category is excluded.

Derived data are created through the controller's own analysis.

Examples

include:

• credit scores,
• behavioural profiles,
• fraud risk assessments,
• marketing segmentation,
• AI-generated personality profiles,
• insurance risk calculations,
• recommendation scores,
• predictive analytics. These are not regarded as data "provided by" the individual. Instead, they constitute intellectual outputs created by the controller.

Example

A bank analyses:

• transaction history,
• repayment behaviour,
• employment records, to calculate a credit score. Although the underlying transactions are portable,

the calculated credit score itself generally is not.

The same reasoning applies to:

• fraud probabilities,

• customer lifetime value,

• churn predictions,

• internal marketing scores.

V. Why Derived Data Are Excluded

Several policy reasons justify excluding inferred data.

First,

derived information often reflects the controller's expertise and investment.

Second,

it may incorporate proprietary algorithms.

Third,

mandatory disclosure could undermine trade secrets.

Fourth,

many derived datasets consist of predictions rather than objective facts.

For example,

an AI system may predict:

• likelihood of depression,

• purchasing behaviour,

• political preferences,

• creditworthiness.

These predictions belong to the controller's analytical process rather than constituting data supplied by the individual.

VI. Ongoing Academic Debate

Not all scholars agree with WP29's distinction.

Some argue that behavioural observations should also be excluded because individuals never actively "provided" them.

Others contend that excluding inferred data significantly weakens portability because modern AI systems increasingly rely upon inferred information rather than raw inputs.

For example,

recommendation engines primarily operate through inferred preferences.

If only raw data are portable,

switching providers may remain commercially unattractive.

This debate has become increasingly important in the age of generative AI.

VII. Structured, Commonly Used and Machine-Readable Format

Perhaps the most practical requirement concerns the format.

The GDPR deliberately avoids prescribing particular file types.

Instead,

it establishes three qualitative requirements.

(A) Structured

The data must possess an organised structure.

Information should not appear as random text.

Instead,

relationships between data fields should remain identifiable.

Examples

include:

• rows and columns,
• JSON objects,
• XML trees,
• CSV tables.

(B) Commonly Used

Controllers should employ formats widely recognised across industries.

Common examples include:

• CSV

• XML

• JSON

These formats enable straightforward import into many systems.

Controllers should avoid:

• obscure proprietary formats,

• encrypted vendor-specific structures,

• undocumented database exports.

(C) Machine-Readable

Machine-readable means software can automatically process the information.

This excludes:

• scanned documents,

• photographs of tables,

• printed pages.

A PDF may satisfy Article 15,

but it often fails Article 20 because software cannot reliably reuse the underlying data.

VIII. Interoperability

Recital 68 introduces the broader concept of interoperability.

Interoperability means different systems should communicate effectively.

However,

controllers are not required to redesign their systems merely to achieve perfect compatibility.

Instead,

they should:

• avoid unnecessary technical barriers,

• adopt open standards where reasonable,

• facilitate reuse.

APIs and Portability

Modern controllers increasingly satisfy portability through:

• secure APIs,

• downloadable archives,

• cloud export functions,

• synchronisation tools.

For example,

many cloud providers allow users to export all stored files directly.

Similarly,

major technology companies provide downloadable data archives.

These practices align closely with Article 20.

IX. "Without Hindrance"

The controller must not obstruct portability.

WP29 identifies several examples of prohibited hindrances:

• charging unjustified fees;

• excessive administrative procedures;

• unreasonable delays;

• deliberately poor export formats;

• unnecessary authentication requirements;

• proprietary file structures;

• technical incompatibility deliberately maintained.

Controllers must actively facilitate portability under Article 12.

Merely avoiding obstruction is insufficient.

X. Legal Basis Requirement

Article 20 only applies where processing is based upon:

• Article 6(1)(a) (consent),

• Article 9(2)(a) (explicit consent for special categories),

• Article 6(1)(b) (contract).

Consent

Typical examples include:

• social media,

• cloud storage,

• health apps,

• fitness platforms,

• photo-sharing services.

Contract

Examples

include:

• online banking,
• e-commerce,
• telecommunications,
• streaming subscriptions,
• software-as-a-service,
• airline loyalty programmes.

Mixed Legal Bases

Controllers often rely on multiple legal bases simultaneously.

For example,

an online retailer may process:

• customer purchases under contract;

• marketing analytics under legitimate interests;

• promotional emails based on consent.

Only the processing falling within consent or contract qualifies for portability.

XI. Automated Processing

The second condition requires processing by automated means.

Manual paper files fall outside Article 20.

Examples

covered include:

• cloud databases;
• online platforms;
• CRM systems;
• mobile applications;
• wearable devices;
• IoT platforms;
• AI services. The rationale is practical. Portability seeks digital mobility. Controllers are not expected to digitise purely paper archives solely for portability purposes.

XII. Practical Examples

Example 1

Music Streaming A subscriber requests:

• playlists,
• favourite songs,
• listening history. These are portable because:

• they were provided or observed,

• processing is contractual,

• processing is automated.

Example 2

Smartwatch The user requests:

• step counts,
• heart rate,
• sleep history. Portable.

However,

the provider's internally generated health risk score generally is not.

Example 3

Social Media A user requests:

• uploaded photographs,
• posts,
• messages,
• comments,

• friend list.

These are generally portable.

However,

the platform's internal engagement ranking or advertising profile may fall outside Article 20 because it consists of inferred data.