Skip to main content
Back to Guides
Compliance7 min read

Data Portability Requests: What You Actually Have to Provide

Data portability is the most misunderstood data subject right. It is narrower than access, it only covers certain data, and a scanned PDF does not count. Here is exactly what GDPR Article 20 requires, what to leave out, and how the CCPA version differs.

Data portability is the data subject right people most often get wrong, usually by treating it as a synonym for access. It is not. The right to portability is narrower, it applies to a specific slice of data, and it comes with a format requirement that a screenshot or a scanned PDF will fail. Answer a portability request the way you would answer an access request and you can technically comply with the wrong obligation while breaching the right one.

Here is what GDPR Article 20 actually asks for, what falls outside it, and how the CCPA's portable-format rule compares. For the right it is most confused with, see DSAR handling for website owners.

What portability actually is

Article 20 gives a person the right to receive the personal data they provided to you in a structured, commonly used, and machine-readable format, and to transmit that data to another controller without you obstructing it. Where technically feasible, they can ask you to send it directly to the other controller. The point of the right is switching: moving your data from one service to a competitor, the way you might port a phone number. That framing explains its limits.

The three conditions, all of which must hold

Portability only applies where all three of these are true. Miss one and the right does not attach (though the access right usually still does):

  • The data was provided by the person. This covers data they gave you directly (name, email, uploads) and data observed from their activity (search history, location logs, raw usage events). The Article 29 Working Party guidance (WP242) reads "provided by" broadly to include this observed data.
  • The legal basis is consent or contract. If you process the data under legitimate interests or a legal obligation, portability does not apply. This is the condition teams miss most.
  • The processing is automated. Purely paper records are out of scope.

Because the right is tied to consent and contract, the same withdrawal-of-consent event that can trigger an erasure request can sit next to a portability request. Recognise which one you are answering.

What you leave out: inferred and derived data

This is the line to get right. Portability covers data the person provided or generated. It does not cover data you created about them: a credit score you calculated, a risk segment, a churn probability, a recommendation profile. WP242 is explicit that inferred and derived data are outside the scope of Article 20. You built those with your own analysis, and portability does not require you to hand your models' outputs to a competitor. You still have to disclose the existence of such data under the access right, but you do not have to port it. Drawing this line correctly is what separates a portability export from a full data dump.

The format rule: a PDF is usually not enough

"Structured, commonly used, and machine-readable" means another system can ingest it without manual retyping. In practice that means CSV, JSON, or XML. WP242 makes the point directly: a scanned PDF or a proprietary, unreadable export is not a machine-readable format within the meaning of Article 20. A human-readable PDF can satisfy an access request while failing a portability request, because portability is about machine-to-machine transfer, not human review. Where you can, include field descriptions or a small schema so the receiving controller can interpret the file. The regulation also says the data should be provided free of charge, so do not attach an export fee.

Direct transmission and its limits

The person can ask you to send their data straight to another controller "where technically feasible." You are not required to build or maintain interoperable systems with every competitor, and you are not responsible for whether the receiving controller can actually accept the data. What you cannot do is obstruct the transfer or the person's ability to move. If direct transmission is not feasible, giving the person the machine-readable file to move themselves satisfies the right. And Article 20(4) reminds you that portability must not adversely affect the rights of others, so an export that would reveal a third party's personal data needs the same care as any other disclosure.

How the CCPA version differs

California does not have a standalone "portability" right. It folds a format requirement into the right to know. Civil Code 1798.130(a)(2) says that when a consumer asks for specific pieces of their personal information and the disclosure is made electronically, it must be provided in a portable and, to the extent technically feasible, readily usable format that allows the consumer to transmit it to another entity without hindrance. So the effect is similar (a machine-usable export the consumer can move), but the trigger is the access request, the scope follows the CCPA's broad definition of personal information rather than GDPR's consent-or-contract test, and there is no equivalent to GDPR's direct controller-to-controller transmission. For the wider US framework, see the US state privacy laws guide.

Portability and access are different obligations

An access request asks "what do you have about me?" and is answered in a form a human can read. A portability request asks "give me my data so I can take it elsewhere" and must be answered in a form a machine can ingest. The scope also differs: access covers everything you hold, including inferred data; portability covers only provided and observed data processed on consent or contract. When a request is ambiguous, clarify which one the person wants rather than guessing.

Consent and cookie data in a portability export

When a portability request touches tracking data, the records you already keep can supply a clean, structured export. Consent decisions, per-purpose choices, and the events tied to them are, by design, held as structured data with a consent ID and timestamps, which is exactly the shape Article 20 wants. CookieBeam's privacy portal offers portability as a request type where the visitor's jurisdiction grants it (EU, UK, and Brazil in its regional mapping, not California, which routes the equivalent need through the access right), and logs each request with a status and timestamp so the deadline is tracked from receipt. The portal handles intake, verification, and tracking; assembling the export from your own systems stays your call, because only you know which fields were provided versus inferred. See proof of consent for how those records are structured.

Data portability request checklist

  • Confirm all three conditions apply

    Provided or observed data, processed on consent or contract, by automated means.

  • Include provided and observed data

    Direct inputs plus activity-generated data like usage and location logs.

  • Exclude inferred and derived data

    Scores, segments, and profiles you created are out of portability scope.

  • Export in CSV, JSON, or XML, not a scanned PDF

    The format must be machine-readable so another system can ingest it.

  • Offer direct transmission where technically feasible

    Otherwise give the person the file to move themselves; do not obstruct.

  • Provide it free of charge and within the deadline

    GDPR portability follows the one-month clock; no export fee.

  • Protect third-party data in the export

    Portability must not adversely affect the rights of others.

Draw the provided-versus-inferred line once

The reusable decision in every portability request is which fields the person provided or generated (in scope) versus which you inferred about them (out of scope). Map that once against your data model and portability exports become a repeatable query rather than a case-by-case debate. See DSAR deadlines by law for the clock you are working against.

Data Portability Requests: What You Must Provide | CookieBeam | CookieBeam