Article 20: Right to data portability

To meet the article 20: right to data portability requirement, you need an end-to-end process that (1) identifies in-scope “provided” personal data, (2) exports it in a structured, commonly used, machine-readable format, and (3) transmits it to another controller without hindrance when the legal conditions are met. Your fastest path is a DSAR playbook plus system-ready export mappings tied to clear ownership. (Regulation (EU) 2016/679, Article 20)

Key takeaways:

• Scope it precisely: “provided” data, specific lawful bases, and feasible direct transmission routes. (Regulation (EU) 2016/679, Article 20)
• Operationalize with a repeatable workflow: intake, identity verification, data mapping, export, secure delivery, and logging. (Regulation (EU) 2016/679, Article 20)
• Keep an evidence packet per request: decisioning, exports, exceptions, and communications, or you will struggle in audits and customer diligence. (Regulation (EU) 2016/679, Article 20)

Article 20 creates a specific, operational obligation: when a data subject asks, you must be able to hand back certain personal data in a portable format and allow transfer to another controller without friction, if the Article 20 conditions are met. (Regulation (EU) 2016/679, Article 20) This is not the same as a general “right of access” export. Portability focuses on data the person has provided to you and on delivering it in a format another system can ingest.

For a Compliance Officer, CCO, or GRC lead, the fastest way to make this real is to treat portability as a productized output of your DSAR program. That means you define the portability dataset, build a reliable export for it, and stand up a secure delivery mechanism that your support and privacy teams can run without engineering heroics.

If you rely on ad hoc engineering pulls, the failure mode is predictable: missed timelines, incomplete datasets, inconsistent formats across products, and weak evidence. The rest of this page is requirement-level guidance you can assign to owners and validate through testing.

Regulatory text

Excerpt (provided): “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:” (Regulation (EU) 2016/679, Article 20)

Operator meaning (what you must be able to do):

1. Receive request and determine eligibility. Article 20 applies when the personal data is data the individual “has provided” to you and the processing context meets the Article 20 conditions (the excerpt you provided ends before listing them, so treat eligibility as a required decision step and document the criteria you apply). (Regulation (EU) 2016/679, Article 20)
2. Provide a portable export. You must deliver the in-scope data in a structured, commonly used, machine-readable format (think CSV/JSON/XML depending on the dataset and interoperability). (Regulation (EU) 2016/679, Article 20)
3. Enable transmission without hindrance. The individual must be able to transmit the exported data to another controller, and where you support direct controller-to-controller transmission, you must not obstruct it. Operationally this means you avoid unnecessary friction, proprietary formats, or intentional delays. (Regulation (EU) 2016/679, Article 20)

Primary sources: (Regulation (EU) 2016/679, Article 20); (Regulation (EU) 2016/679)

Plain-English interpretation (what a regulator expects you can do)

• If a person asks for their data “in a portable form,” you can’t respond with a PDF screenshot dump. You need a machine-readable export that another service can ingest. (Regulation (EU) 2016/679, Article 20)
• You need a defensible definition of what counts as “provided” data for each product line (account profile fields, uploads, form submissions, event data the user actively submits, etc.). You also need a clear exclusion/limitation story for data that is not “provided” under your interpretation. (Regulation (EU) 2016/679, Article 20)
• You must avoid operational “hindrance”: unnecessary identity hoops, manual-only processes when automation is reasonable, inconsistent formats across products, or blocking transmission to competitors as a business tactic. (Regulation (EU) 2016/679, Article 20)

Who it applies to (entity + operational context)

Applies to you when:

• You act as a controller for the personal data subject to the portability request, because Article 20 is framed as obligations on controllers to provide and enable transfer. (Regulation (EU) 2016/679, Article 20)
• You act as a processor supporting a controller: you are not the party responding to the data subject directly in most operating models, but you still need contractually-aligned capabilities to assist the controller with exports and secure transmission. Build this into your third party due diligence and DPA schedules. (Regulation (EU) 2016/679)

Operational contexts where portability commonly breaks:

• Multi-product companies with separate identity stores and inconsistent schemas.
• SaaS platforms where “customer” is the controller and you are a processor, but end users still contact you directly.
• Consumer apps that can export account profile data but not user-generated content, messages, or uploads in a structured export.

What you actually need to do (step-by-step)

1) Establish scope and decision criteria (privacy + legal + product)

Create a role-and-scope register specific to Article 20:

• Controller vs. processor role per product/processing activity.
• Categories of “provided” data per system.
• Export format per category (CSV/JSON, etc.).
• Delivery options (download link, encrypted file, API transfer where feasible).
• Known exclusions and rationale. (Regulation (EU) 2016/679, Article 20)

Practical note: most disputes start with scope. Write the scope down, get buy-in, and freeze it as a versioned spec so support teams don’t improvise.

2) Build a request intake path that tags “portability” explicitly

In your DSAR intake form and ticketing:

• Add request type: Data portability (Art. 20).
• Require the requester to specify the account identifier(s) and preferred delivery method.
• Route to a privacy queue with an SLA clock and escalation rules. (Regulation (EU) 2016/679, Article 20)

3) Verify identity (and authority) with minimal friction

Define identity checks proportionate to risk:

• If the request is authenticated in-app, treat that as the default path.
• If email-only, require verification steps that you can explain and log.
• For agents, require proof of authority and record it.

“Hindrance” risk: identity checks that are excessive for low-risk data or that force offline steps without justification. Document why your checks are necessary and how you keep them consistent. (Regulation (EU) 2016/679, Article 20)

4) Determine eligibility and document the decision

For each request, record:

• Whether the data is “provided” under your scope definition.
• Whether the processing context meets your Article 20 eligibility criteria (your team should codify this in the SOP; the excerpt provided indicates conditions exist even though they are not included). (Regulation (EU) 2016/679, Article 20)
• Whether you can support direct transmission to another controller, and if not, how you provide the data “to receive” and “to transmit” without hindrance. (Regulation (EU) 2016/679, Article 20)

5) Execute the export from source systems using repeatable mappings

Create an export mapping per system:

• Source tables/objects and filters for the data subject.
• Field definitions and transformations.
• Redaction logic (avoid exporting other people’s data embedded in the subject’s records unless you have a defined approach; log any exclusions).
• Output format specification and sample output.

Engineering anti-pattern: “one SQL query per request.” Replace with scripted jobs or productized exports so results are consistent and testable.

6) Deliver the export securely in a “commonly used” format

Delivery patterns:

• Secure download link (time-bound link, authenticated access).
• Encrypted archive (password out-of-band).
• Direct transmission to another controller when technically feasible and authenticated to the data subject’s instruction. (Regulation (EU) 2016/679, Article 20)

Avoid “hindrance” in practice:

• Don’t require the user to install proprietary software to read the export.
• Don’t split the export into obscure fragments without a manifest.
• Provide a data dictionary/README to make the file usable.

7) Close the loop: communications, logging, and exceptions

Your SOP should require:

• A completion notice describing what was provided, what was excluded, and why.
• A standard exception path (systems unavailable, identity unresolved, conflicting legal holds).
• Ticket closure criteria and QA sampling.

8) Extend to third parties and processors

If third parties store in-scope data (CRM, analytics, support tooling, cloud storage):

• Confirm you can export “provided” data from them in your required formats.
• Add portability-assistance language in contracts or operational runbooks.
• Test at least one end-to-end export that pulls from third parties so your portability promise matches reality. (Regulation (EU) 2016/679)

Where Daydream fits (earned mention): teams lose time reconciling system scope, owners, and evidence across products and third parties. Daydream is a practical place to maintain the Article 20 role-and-scope register, assign owners per system, and store the evidence packet per request so you can answer audits without chasing screenshots.

Required evidence and artifacts to retain

Keep an “evidence packet” per portability request:

• Intake record (request type tagged as portability).
• Identity verification record (method, outcome).
• Eligibility decision record (in-scope data categories, exclusions).
• Export job logs (system names, timestamps, version of mapping used).
• Copy/hash of export file or reproducible export reference, plus manifest/README.
• Delivery record (method, access logs, confirmation).
• Communications to the requester.
• Exception approvals and remediation notes. (Regulation (EU) 2016/679, Article 20)

Also retain standing artifacts:

• Article 20 SOP with named owners and escalation.
• Role-and-scope register across products/systems and key third parties.
• Export format specifications and sample outputs.
• Test results from periodic portability drills. (Regulation (EU) 2016/679, Article 20)

Common exam/audit questions and hangups

Expect reviewers (regulators, customers, or internal audit) to ask:

• Show your definition of “data provided” and how it maps to systems. (Regulation (EU) 2016/679, Article 20)
• Demonstrate a completed portability request end-to-end, with evidence. (Regulation (EU) 2016/679, Article 20)
• What formats do you export, and why are they “commonly used” and machine-readable? (Regulation (EU) 2016/679, Article 20)
• How do you avoid hindrance, especially for direct transmission requests? (Regulation (EU) 2016/679, Article 20)
• How do you handle portability when you are a processor and the controller owns the relationship with the data subject? (Regulation (EU) 2016/679)

Hangups that slow audits:

• No consistent export spec, so every sample looks different.
• Incomplete third-party coverage (support tickets in a third party platform omitted).
• Weak decision records for partial denials or exclusions.

Frequent implementation mistakes and how to avoid them

1. Treating access exports as portability exports. Fix: define a portability dataset and output format separately from access responses, even if they share components. (Regulation (EU) 2016/679, Article 20)

2. No documented scope for “provided” data. Fix: maintain a living register with system owners and data categories; review it when products ship new data collection fields. (Regulation (EU) 2016/679, Article 20)

3. Manual-only exports that don’t scale. Fix: build scripted exports with version control and standard manifests; run a periodic drill to catch schema drift.

4. Excessive identity friction that looks like “hindrance.” Fix: publish verification rules, keep them consistent, and default to authenticated in-product requests where possible. (Regulation (EU) 2016/679, Article 20)

5. Ignoring processor reality. Fix: confirm processor tooling can produce exports fast enough for the controller’s DSAR clock; bake assistance into operational runbooks and contracts. (Regulation (EU) 2016/679)

Enforcement context and risk implications

No public enforcement case sources were provided in the source catalog for this page, so don’t assume a low enforcement risk. Treat portability as a credibility issue: failed exports and obstructive workflows trigger complaints, increase regulator scrutiny across your DSAR program, and create customer trust issues in competitive markets. (Regulation (EU) 2016/679, Article 20)

Practical execution plan (30/60/90-day)

You asked for speed; the plan below is anchored in deliverables, not calendar promises.

First 30 days (foundation and scoping)

• Name a single Article 20 owner (privacy operations) and system owners per data store.
• Publish the Article 20 SOP: intake, verification, decisioning, export, delivery, exception handling, and evidence retention. (Regulation (EU) 2016/679, Article 20)
• Build the role-and-scope register: controller/processor role, “provided” data categories, and systems of record. (Regulation (EU) 2016/679, Article 20)
• Choose standard output formats (CSV/JSON) and define a manifest/README template.

Days 31–60 (build and test the export)

• Implement export mappings for top systems (identity/profile, primary product database, user uploads).
• Implement secure delivery (authenticated download or encrypted archive) with logging. (Regulation (EU) 2016/679, Article 20)
• Run a tabletop plus one live-fire drill on a test account: produce the export, verify readability, and verify evidence packet completeness.
• Update third-party due diligence: confirm portability support from critical third parties that store in-scope data.

Days 61–90 (operational hardening)

• Add QA sampling: review completed requests for completeness and format consistency.
• Add monitoring: backlog aging, exception rate, and recurring failure points (schema drift, third-party delays).
• Train support teams on intake triage and “no hindrance” behaviors, with canned responses approved by privacy/legal.
• Formalize processor support: if you are a processor, publish an internal playbook for assisting controllers with exports and secure transfers. (Regulation (EU) 2016/679)

Frequently Asked Questions

What counts as “data the data subject has provided” for portability?

You need a documented definition and mapping per system, focused on data the individual submitted or supplied through your service. Record that definition in your Article 20 scope register and apply it consistently per request. (Regulation (EU) 2016/679, Article 20)

Can we respond with a PDF export?

Article 20 requires a “structured, commonly used and machine-readable format,” so a PDF usually fails the machine-readable expectation for portability. Use formats like CSV or JSON and include a manifest to make the export usable. (Regulation (EU) 2016/679, Article 20)

Do we have to transmit the data directly to another controller?

Article 20 includes the right to transmit to another controller “without hindrance,” and your process should support direct transmission where feasible and authenticated to the data subject’s instruction. If you cannot do direct transmission, provide a portable export that the data subject can transmit. (Regulation (EU) 2016/679, Article 20)

How should a processor handle portability requests received from end users?

Route the request to the controller (your customer) under your DPA and provide assistance to generate exports as agreed. Maintain evidence of the handoff and your support actions. (Regulation (EU) 2016/679)

What evidence do auditors want for Article 20?

Auditors typically want the intake record, identity verification, eligibility decision, export logs/spec version, delivery proof, and communications, packaged per request. Keep standing artifacts like the SOP and system export mappings to show repeatability. (Regulation (EU) 2016/679, Article 20)

How do we avoid “hindrance” without weakening identity verification?

Make verification rules explicit, proportionate, and consistent, and default to authenticated in-app requests where possible. Log the rationale for any enhanced checks and keep exception approvals in the evidence packet. (Regulation (EU) 2016/679, Article 20)