GDPR Right to Data Portability: How to Handle Article 20 Requests

Short answer: The GDPR right to data portability (Article 20) lets a person receive the personal data they provided to you in a structured, commonly used, machine-readable format, and have it sent to another controller where technically feasible. It applies only when processing is automated and based on consent or a contract. Answer within one month, usually free.

Related guides:

• The 8 mandatory GDPR data subject rights, broken down
• GDPR right of access: how to respond to a DSAR under Article 15
• Data controller vs data processor: differences explained

Key takeaways

• Article 20 has two gates: the lawful basis must be consent or contract, and the processing must be automated. Fail either gate and the right does not apply, although the right of access still does.
• Scope covers data the person provided, which regulators read to include data observed from their use of your service. Data you infer or derive, such as a risk score, is out of scope.
• The output must be structured, commonly used and machine-readable. Think JSON or CSV with field names and metadata, not a PDF.
• Direct controller-to-controller transfer is required only where technically feasible. You do not have to build systems compatible with every competitor.
• A self-serve export and an authenticated API turn most portability requests into a routine support task.

When does the GDPR right to data portability apply?

It applies when you process the person's data by automated means on the basis of consent or a contract with them. Those conditions sit in Article 20(1) of the GDPR: consent under Article 6(1)(a), explicit consent under Article 9(2)(a) for special category data, or a contract under Article 6(1)(b). Article 20(3) adds that the right does not apply to processing necessary for a task carried out in the public interest or in the exercise of official authority.

The Article 29 Working Party Guidelines on the right to data portability (WP242 rev.01), which the EDPB endorsed on 25 May 2018 and which remain the main EU guidance on this right as of October 2026, confirm that processing based on legal obligation, public interest or legitimate interests does not trigger portability.

Use this scope decision table for each processing activity in your record of processing:

Lawful basis	Automated processing?	Article 20 applies?	Example in a SaaS or HealthTech product
Contract (Art. 6(1)(b))	Yes	Yes	Account profile, uploaded files, settings in a B2C app the person signed up for
Consent (Art. 6(1)(a))	Yes	Yes	Optional wearable sync or newsletter preferences collected with consent
Explicit consent (Art. 9(2)(a))	Yes	Yes	Symptom diary or health readings shared with explicit consent
Legitimate interests (Art. 6(1)(f))	Yes	No	Fraud detection logs, product analytics run on legitimate interests
Legal obligation (Art. 6(1)(c))	Yes	No	Invoices kept for tax law
Any basis	No (paper records only)	No	Signed paper intake forms that were never digitised

A "no" here does not end the conversation. The person may still be entitled to a copy under the right of access.

Which data is in scope for a data portability request?

Data "provided by" the person is in scope, and that includes data observed from their activity, but not data you create about them. The WP242 guidelines split personal data into three groups, and the ICO's guidance on the right to data portability uses the same approach under the UK GDPR:

Category	In scope?	What it means	SaaS and HealthTech examples
Actively provided	Yes	Data the person knowingly gave you	Name, email, profile fields, messages, uploaded documents, symptom entries
Observed	Yes	Data generated by their use of the service or device	Activity and search history, location data, readings from a connected device
Inferred or derived	No	Data you create from what they provided	Risk scores, health assessment outcomes, segments, recommendations, model outputs

The WP242 guidelines give a credit score and the outcome of an assessment of a user's health as typical inferred data, and a fitness tracker's heartbeat readings as observed data. For a HealthTech product that usually means raw readings and patient-entered data go in the export, while your algorithm's interpretation of them does not.

Two more scope rules from the guidelines:

• Pseudonymised data that you can link to the requester is in scope. Truly anonymous data is not.
• No new retention duty. You need not keep data longer than your retention policy says, and portability does not trigger erasure. Article 20(3) keeps erasure under Article 17 separate.

How is Article 20 different from the right of access?

Access is about transparency, while portability is about reuse. Many requests mention both, so your team needs to know which rules apply to which part of the answer.

	Right of access (Art. 15)	Right to data portability (Art. 20)
Lawful basis	Any	Consent or contract only
Processing	Any, including paper filing systems	Automated only
Data covered	All personal data you process about the person	Data provided by the person, including observed data
Inferred data	Included	Excluded
Supplementary information	Purposes, recipients, retention and more	Not required
Format	Commonly used electronic form for electronic requests	Structured, commonly used, machine-readable
Sending to another controller	Not part of the right	Direct transfer where technically feasible

When a request is unclear, ask which the person wants, or answer both in one response.

What format and transfer method does Article 20 require?

Provide the data in a structured, commonly used and machine-readable format, and send it straight to another controller if the person asks and it is technically feasible. Article 20 does not name a format. Guidance fills the gap:

• Open formats. The ICO suggests formats such as CSV, XML and JSON. WP242 says formats with costly licensing constraints are not adequate.
• Metadata matters. WP242 asks controllers to include as much metadata as possible and notes that PDF copies of an email inbox would not be structured enough. Include field names, timestamps, units and an explanation of internal codes.
• Technically feasible, not universal. Recital 68 encourages interoperable formats but says the right should not oblige controllers to adopt or maintain processing systems that are technically compatible. The ICO adds that you must not create legal, technical or financial obstacles that slow the transfer down.
• Secure transmission. WP242 makes the sending controller responsible for security measures, such as encryption, to get the data to the right destination, but those measures must not obstruct the right.

Once the data arrives, the receiving service becomes a controller for it in its own right.

How to respond to a data portability request, step by step

Use the same deadline and fee rules as other rights requests, with a few portability-specific checks. Under Article 12(3) and 12(5), you must respond without undue delay and within one month of receipt, extendable by two further months for complex or numerous requests if you tell the person why within the first month. Responses are free unless a request is manifestly unfounded or excessive.

1. Log the request and calculate the due date.
2. Confirm your role. If you only process the data for a business customer, forward the request to them.
3. Verify identity proportionately. WP242 expects an authentication procedure. For a logged-in user, the existing login is usually enough. Ask for more only where you have reasonable doubts, as Article 12(6) allows.
4. Run the scope decision table to separate processing activities on consent or contract from the rest.
5. Collect provided and observed data from every in-scope system.
6. Check the rights of others. Article 20(4) says portability must not adversely affect the rights and freedoms of others. WP242 allows third-party data, such as contacts in a message history, to be ported when it stays in the same personal use, while the receiving controller may not use it for its own purposes, such as marketing. For joint accounts, the ICO advises getting the agreement of all account holders.
7. Package and deliver in JSON or CSV with a data dictionary, through an expiring authenticated download link or, if requested, a direct transfer.
8. Record what you exported, how you verified identity, and any exclusions.

If you refuse any part, Article 12(4) requires you to tell the person why, and of their right to complain to a supervisory authority, within one month of receipt. The ICO notes that whether a request is manifestly unfounded or excessive must be decided case by case.

What should engineering build for portability exports?

Build a self-serve export once, keyed to a single user ID, so requests stop needing ad hoc database queries. Work through this checklist with your engineering lead:

• Data inventory tags. Every table, bucket and SaaS tool that holds user data is tagged with lawful basis and data category (provided, observed, inferred).
• Stable subject ID. One internal ID links the account to every pseudonymous identifier, device ID and analytics ID.
• Export job per system. Each in-scope store has a tested export function that excludes inferred fields by default.
• Open, documented schema. JSON or CSV with timestamps, units, original file attachments and a versioned data dictionary.
• In-app download. Logged-in users can trigger an export from settings, which handles identity checks and creates an audit record.
• Authenticated API. A documented, secured API, which WP242 points to as a good practice, lets a person or an authorised receiving service pull the data.
• Secure delivery. Encryption, expiring links and download logging.
• Third-party filter. Other users' data in shared workspaces or threads is excluded or limited to what the requester legitimately uses.
• Health data handling. Stronger authentication, and never plain email attachments.
• Annual test. Run an end-to-end export on a staff account and keep the output as evidence.

What if you are the processor, not the controller?

If you hold the data on behalf of a business customer, the customer is the controller and answers the request, and your job is to help them. Under Article 28(3)(e), your processor contract must require you to assist the controller with data subject requests through appropriate technical and organisational measures. Your data processing agreement should describe how.

For a B2B HealthTech platform, the clinic or employer is often the controller. In practice:

• Forward, do not fulfil. If an end user writes to you directly, pass the request to the customer promptly, as your DPA specifies.
• Give customers the tooling. Admin-level bulk export and per-user export in open formats let the customer meet the deadline without raising a ticket.
• Flow requirements down. Your own subprocessors that hold the data need matching assistance clauses.

How SecureSlate helps

SecureSlate helps you build the evidence behind a working portability process. GDPR is built in, so Article 20 obligations sit in the same control library as your SOC 2, ISO 27001 and HIPAA controls through multi-framework control mapping. You can add custom controls for your export runbook and annual export test, track subprocessors and their assistance clauses with vendor risk management, record portability-related risks in risk management, and use agentless read-only cloud integrations to keep an eye on the systems that hold user data. Audit management and the trust center help you share that evidence.

Start your free SecureSlate trial

FAQ

Does the right to data portability apply to B2B SaaS?

It applies to individuals, not companies. For end-user data you usually act as processor, so your customer answers with your help. For data you control, such as admin user accounts, Article 20 may apply where processing rests on contract or consent.

Can we charge for a data portability request?

Usually not. Article 12(5) makes responses free unless a request is manifestly unfounded or excessive, in particular because it is repetitive. Then you may charge a reasonable fee or refuse, and you must be able to show why.

Do we have to send data directly to a competitor?

Only where technically feasible. Recital 68 says controllers are not obliged to adopt or maintain technically compatible systems. If direct transfer is not feasible, give the person the export so they can upload it themselves, and do not create obstacles to that move.

Does a portability request mean we must delete the data?

No. Portability does not trigger erasure on its own. If the person also wants their account deleted, treat that as a separate erasure request under Article 17.

Are risk scores or AI model outputs included?

Generally no. Inferred and derived data, such as scores, assessment outcomes and model outputs, fall outside Article 20, though they may still be disclosable under the right of access.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.