Art.20 GDPR

GDPR Art.20: Right to Data Portability

What This Control Requires

The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided, where: (a) the processing is based on consent pursuant to point (a) of Article 6(1) or point (a) of Article 9(2) or on a contract pursuant to point (b) of Article 6(1); and (b) the processing is carried out by automated means.

In Plain Language

People should be able to take their data and move it to a competing service without friction. That's the core idea behind data portability - it reduces vendor lock-in and gives individuals real control over their information.

The scope is narrower than you might expect, though. Portability only covers data the individual has provided to you (including both active submissions like form entries and observed data like usage history), where your legal basis is consent or contract performance, and where the processing is automated. Data you've inferred or derived - credit scores, profiles, analytics outputs - is not in scope. Neither is data processed under legitimate interests, legal obligation, or other bases.

You need to deliver the data in a structured, commonly used, machine-readable format. JSON, XML, and CSV are all standard choices. If the individual asks and it's technically feasible, you should transmit the data directly to another controller. The right can't be used to undermine other people's rights or your trade secrets, so there are sensible boundaries around what gets included.

How to Implement

Map out which personal data qualifies for portability. Go through your data inventory and identify everything that was provided by the data subject (actively or through observed behaviour) and is processed on the basis of consent or contract via automated means. Draw a clear line between provided/observed data (in scope) and inferred or derived data like analytics outputs and profiles (out of scope).

Build the technical capability to export data in structured, machine-readable formats. Support at least one of JSON, XML, or CSV - ideally offer multiple options. Include meaningful metadata in the export: field labels, data types, and relationships between data elements, so the exported file is actually useful to a receiving controller.

Look into direct transmission. If another controller asks to receive the data directly, you should support that where technically feasible - through APIs, industry-standard portability protocols, or platform-specific transfer tools. If direct transmission genuinely isn't possible, document why and provide the data to the individual in a portable format they can transfer manually.

Set up a handling procedure that covers identity verification, scope assessment (working out which data qualifies), extraction and formatting, quality checks on the export, and delivery. Keep the whole process within the one-month response deadline.

Be careful about third-party rights. If exported data contains other people's personal data, redact or filter it appropriately. Make sure proprietary analytics, algorithms, or derived insights don't accidentally end up in portability exports. Document clearly what's included and what's excluded, and why.

Evidence Your Auditor Will Request

Data mapping identifying data within scope of portability right (provided data, consent/contract basis, automated processing)
Technical capability for data export in structured, machine-readable formats (JSON, XML, CSV)
Documented portability request handling procedure
Portability request log showing requests handled and formats provided
Assessment of direct transmission feasibility and, where applicable, API documentation

Common Mistakes

Providing data in non-machine-readable formats (e.g., PDF scans) that do not meet the portability requirement
Including derived or inferred data (such as credit scores or profiles) that falls outside the scope of portability
Creating technical barriers to portability, such as proprietary formats or excessive complexity in data structures
Confusing the right to portability with the right of access and providing more or less data than required
No technical capability for direct transmission to other controllers when requested

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.5.34	Related

Frequently Asked Questions

What formats satisfy the 'structured, commonly used and machine-readable' requirement?

The GDPR doesn't mandate a specific format, but JSON, XML, and CSV are all widely accepted. The key is that the format is structured (organised with defined fields), commonly used (supported by standard software), and machine-readable (processable by automated systems). PDFs generally don't cut it because they're not easily machine-readable, even if they're technically digital.

Does observed data fall within the scope of portability?

Yes, according to the Article 29 Working Party (now EDPB). 'Provided' data covers both what someone actively submits (form inputs, uploaded files) and what's generated by their activity (search history, location data, raw sensor readings from wearables). What's excluded is anything you've inferred or derived from that data - analytics results, profiles, risk scores, and the like.

Can we charge for portability requests?

Not for the first request. Like other data subject rights, portability must be provided free of charge. You can only charge a reasonable fee for requests that are manifestly unfounded or excessive - typically meaning someone is making repeated identical requests.

Track GDPR compliance in one place

AuditFront helps you manage every GDPR control, collect evidence, and stay audit-ready.

Start Free Assessment