Data portability is the most misunderstood of the eight rights, because teams assume it is a subject access request in a different file format. It is not. Article 20 is narrower than access on two axes at once: it only applies where your lawful basis is consent or contract, and only to data the person provided rather than data you worked out about them. Get either axis wrong and you either over-disclose or refuse a valid request.
This article covers the three conditions that have to be met before the right exists at all, the difference between provided, observed and inferred data, what "structured, commonly used and machine-readable" rules out, the direct-transmission right and its limits, and how to build one export that serves both portability and access without conflating them.
The Three Conditions
Article 20(1) gives a person the right to receive the personal data concerning them which they have provided to a controller, in a structured, commonly used and machine-readable format, and to transmit that data to another controller without hindrance. But it only applies where two further things are true, set out in the same paragraph: the processing is based on consent or on a contract, and it is carried out by automated means.
That basis condition is the one that surprises people. If you process on legitimate interests, there is no portability right. If you process to meet a legal obligation, there is no portability right. A bank running anti-money-laundering checks processes a great deal of personal data on a legal obligation basis and owes no portability duty on any of it, however clearly the data concerns the person asking.
For most B2B SaaS the practical answer is that account data, profile information and content the customer created sit under contract, so they are portable. Fraud signals, security logs and anything you retain for a legal obligation generally are not.
Two further limits sit in the same article. Article 20(3) says the right does not apply to processing necessary for a task in the public interest or in the exercise of official authority, and that it is without prejudice to the right to erasure. Article 20(4) says exercising portability must not adversely affect the rights and freedoms of others — which matters more than it sounds, and comes up below.
Provided, Observed, Inferred
"Provided by the data subject" is the phrase that decides the scope of your export, and it does not mean what a literal reading suggests.
The Article 29 Working Party's guidelines on the right to data portability read the phrase broadly and split the data into three categories.
Provided data is what the person actively and knowingly gave you: their name, their email address, everything they typed into a form, the content they uploaded.
Observed data is what you collected by watching them use the service — search history, traffic data, location data, activity logs, raw readings from a device. The Working Party is explicit that this is in scope. Teams that export only the profile form and call it done have under-delivered.
Inferred and derived data is what you created by analysing the first two: a credit score, a health assessment, an analytics profile, an evaluation report, a churn-risk rating. This is not in scope and you do not have to hand it over. Your model outputs about a customer stay yours.
Two boundary points worth knowing. Anonymous data is out of scope because it is not personal data at all. Pseudonymous data that can be clearly linked to the person — including where they supply the identifier themselves — is in scope.
What "Machine-Readable" Rules Out
The format requirement is three adjectives and each one does work: structured, commonly used, and machine-readable.
CSV, JSON and XML all qualify comfortably. A PDF does not, because it is not machine-readable in any useful sense — the point of the right is that the person can take the file elsewhere and have a second service ingest it. A screenshot certainly does not. A proprietary format that only your product can open fails the "commonly used" limb.
Beyond format, the export should be intelligible. A JSON dump of internal column names with no key is technically machine-readable and practically useless, and the transparency principle in Article 5(1)(a) applies to the response as much as to the notice. Include field descriptions.
Where an export actually lives varies by product and it is worth knowing yours before a request arrives — our piece on Notion records where one vendor's workspace export sits, which is the sort of detail that turns a month-long scramble into an afternoon.
There is no obligation to invent interoperability. Recital 68 says the right does not create an obligation for controllers to adopt or maintain processing systems that are technically compatible with one another. You have to produce a good file. You do not have to match a competitor's schema.
Direct Transmission, And The Third-Party Problem
Article 20(2) adds that where technically feasible, the person can require the data to be transmitted directly from one controller to another. "Where technically feasible" is a real qualifier, not a formality, and combined with Recital 68 it means you are not obliged to build integrations with every competitor who asks. If you have an API that can do it, the argument that it is infeasible gets weak.
Article 20(4) is the constraint people forget. An export frequently contains other people's personal data: a shared workspace shows collaborators, a messaging history shows the other participants, an address book is entirely third parties. You cannot refuse the whole request on that basis, but you also cannot disclose freely.
The workable approach is to scope the export to the requester's own data, include third-party data only where it is genuinely inseparable from theirs, and avoid exporting other users' contact details, content and identifiers as a convenience. Where third-party data does travel, the Working Party's position is that the receiving controller may only process it under the requester's sole control and for their own purposes.
Timelines, And Building It Once
The mechanics are the same as any data subject right. Article 12(3): one month from receipt, extendable by two further months for complex or numerous requests, with the person told about the extension and why within the first month. Article 12(5): free of charge, unless the request is manifestly unfounded or excessive.
Because the timing and identity-verification steps are shared with access requests, the sensible build is one export pipeline with two scopes. The access scope is wider — it covers everything you hold about the person regardless of lawful basis, plus the supplementary information Article 15 requires. The portability scope is narrower and cleaner: consent and contract processing only, provided and observed data only, in a structured file. The DSAR machinery around both — intake, identity checks, deadline tracking, redaction — is covered in our complete DSAR guide, and this article does not repeat it.
One thing that surfaces during the build: observed data usually lives in logs and event streams rather than in the application database, so knowing what your logging actually captures is a prerequisite for scoping a portability export correctly.
Common Mistakes With Data Portability Requests
Treating portability as access with a different file extension. The lawful-basis condition alone excludes a great deal of what an access request would cover. Running one query for both means either over-disclosing or missing the supplementary information Article 15 requires.
Exporting only actively submitted data. Observed data — activity logs, search and usage history, location — is in scope. An export containing just the signup form is incomplete.
Handing over inferred data by default. Scores, segments, risk ratings and analytics profiles are outside Article 20. Exporting them anyway gives away proprietary work nobody asked for.
Providing a PDF. It fails the machine-readable limb, and it defeats the purpose of a right designed to let people move between services.
Ignoring Article 20(4). Exports that sweep in collaborators, message counterparties or an entire address book disclose other people's personal data to satisfy one person's request.
FAQ
Is data portability the same as a subject access request?
No, and conflating them causes most portability errors. Access covers everything you hold about the person on any lawful basis, plus context about your processing. Portability covers only consent- and contract-based processing, only automated processing, and only data the person provided or you observed — but it must arrive in a structured, machine-readable file.
Does portability apply if we rely on legitimate interests?
No. Article 20 lists consent and contract only. Processing on legitimate interests, legal obligation, vital interests or public task carries no portability obligation. That said, the same data is usually still within scope of an access request, so refusing portability is rarely the end of the conversation.
What format do we have to provide?
Something structured, commonly used and machine-readable — CSV, JSON and XML are the safe answers. PDFs and screenshots do not qualify. There is no obligation to match another provider's schema, but there is a practical obligation to make the file intelligible, which usually means shipping a short key alongside it.
Do we have to send the data directly to a competitor?
Only where it is technically feasible. Article 20(2) creates the right, and Recital 68 confirms you need not build or maintain systems that are technically compatible with anyone else's. If you already have an API that could do it, feasibility becomes harder to dispute than if you would have to build one.
Closing Thought
Portability was written to break lock-in, and the uncomfortable implication is that a well-built export is a switching aid you are legally required to hand your customers. Most teams respond by building the minimum and hoping nobody asks.
The teams that do better tend to notice something else: the export you build for Article 20 is the same export that lets a customer leave gracefully, migrate between your own plans, or run their own analysis. A right you resent is often a feature you have not recognised yet.
ComplyDog handles the request side of this — a self-serve intake form for data subject requests, on a portal hosted on your own domain, with the records of processing that tell you which lawful basis applies to which data in the first place. That last part is what decides what belongs in a portability export. You can try it free for 14 days, no credit card required.
