Article 20: Right to data portability

GDPR Article 20 requires you to provide individuals with the personal data they “provided” to you in a structured, commonly used, machine-readable format, and to enable transfer to another controller without hindrance when the conditions apply. Operationalize it by scoping eligible processing, defining an export data set and format, and running a tested request workflow with auditable evidence. (Regulation (EU) 2016/679, Article 20)

Key takeaways:

• Build a clear scope: only certain data and processing situations trigger portability, so map where it applies before you automate.
• Treat portability as an engineering-backed DSAR lane: defined export schema, identity checks, logging, and secure delivery.
• Keep defensible evidence: request decisions, exported fields, format choice, and delivery records are what auditors ask for.

Article 20 (right to data portability) is often confused with “right of access.” Access is broader; portability is narrower and more operationally specific. Article 20 focuses on data the individual has provided to you, and it requires that you deliver it in a structured, commonly used, machine-readable format, with the ability for the individual to transmit it to another controller without being blocked. (Regulation (EU) 2016/679, Article 20)

For a Compliance Officer, CCO, or GRC lead, the fastest path to execution is to treat portability like a product requirement with compliance guardrails: define the eligible systems, define the exportable fields, choose formats, implement a repeatable request runbook, and prove it works with test cases and retained evidence. The common failure mode is policy-only compliance: you publish DSAR language but cannot reliably produce a portability export across systems, or you export the wrong data set (too much, too little, or the wrong categories). (Regulation (EU) 2016/679, Article 20)

This page gives requirement-level implementation guidance you can hand to privacy operations, engineering, support, and security teams to stand up a working portability program and defend it in an audit.

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)

What the text means for operators

You must be able to:

1. Identify the “personal data … provided” by the individual that your organization holds as a controller in scope for portability. (Regulation (EU) 2016/679, Article 20)
2. Export that data in a structured, commonly used, machine-readable format (for example, CSV or JSON are common choices, but the requirement is about meeting the standard, not naming a specific file type). (Regulation (EU) 2016/679, Article 20)
3. Deliver it to the individual in a way that allows them to transmit it onward, and do so without hindrance (no unreasonable blockers, friction, or “we only do screenshots” behavior). (Regulation (EU) 2016/679, Article 20)

Operationally, the requirement lives at the intersection of privacy intake (DSAR), data mapping, identity assurance, secure delivery, and platform engineering. If any one of those is missing, you will struggle to execute consistently.

Plain-English interpretation of the requirement

If a person asks for their data “in a portable form,” you need to give them a download (or equivalent) containing the personal data they provided to you, in a format that common software can read, so they can take it to another company. You cannot make them jump through unnecessary hoops that effectively prevent transfer. (Regulation (EU) 2016/679, Article 20)

Portability is not “send everything you know.” It is a defined export of a defined data set. Your job is to predefine the rules, implement them, and document decisions for edge cases.

Who it applies to (entity and operational context)

Entities / roles

• Controllers: Article 20 is framed as a right the individual exercises against a controller. If you determine you are a controller for the processing at issue, you need an operational capability to fulfill portability requests. (Regulation (EU) 2016/679, Article 20)
• Processors: Even if Article 20 is not directed at processors in the same way, processors are usually operationally involved because the data lives in processor-managed systems. If you are a processor, expect controller customers to flow down requirements and timelines contractually; design your systems so you can support controller portability exports quickly and safely. (Regulation (EU) 2016/679)

Where this shows up in real operations

• Consumer apps and SaaS products with user accounts (profile data, preferences, content uploads)
• Financial services and fintech data sets (account holder-submitted information)
• HR platforms where individuals submit information directly
• IoT / device ecosystems where a user configures settings and provides identifiers

Scoping decision you must make early

Maintain a role-and-scope register for portability that answers, per product/process:

• Are we controller, joint controller, or processor for this data set?
• What categories of “provided by the data subject” do we store here?
• What systems are authoritative sources?
• What export format is supported and tested?
  This is one of the highest ROI governance steps because it prevents “we didn’t think it applied to that product” surprises. (Regulation (EU) 2016/679, Article 20)

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

Step 1: Define your portability scope and eligibility rules

Create a written decision record that your teams can follow consistently:

• Trigger: a DSAR explicitly asking for portability, “machine-readable,” “download my data,” or “transfer to another provider.”
• Eligible data: “personal data … provided” by the individual. Document what you interpret as “provided” in your context and how you handle derived/observed data. Keep this consistent across products. (Regulation (EU) 2016/679, Article 20)
• Eligible systems: systems containing in-scope fields, plus logs needed to prove fulfillment.

Output: a portability data dictionary and system list owned by Privacy with Engineering sign-off.

Step 2: Build a request intake lane that routes correctly

You need an intake mechanism (web form, email workflow, ticketing) that:

• Tags the request as Portability (Art. 20) versus Access (Art. 15) to avoid mixing outputs.
• Captures enough context: account identifiers, jurisdiction, product(s), desired delivery method.
• Forces an identity verification step before release.

Output: a workflow diagram and SOP with named owners and escalation paths. (Regulation (EU) 2016/679, Article 20)

Step 3: Implement identity verification and authority checks

Before exporting:

• Verify the requester’s identity to an assurance level appropriate to the sensitivity of the data.
• Handle authorized agents and guardians via documented proof requirements.
• If you cannot identify the data subject reliably, document the decision and next steps.

Output: verification checklist embedded in the ticket, plus a record of verification outcome.

Step 4: Produce the export in a structured, commonly used, machine-readable format

Engineering deliverables:

• A repeatable export job (API endpoint, background job, or admin tool).
• Deterministic field selection aligned to the portability data dictionary.
• A format that is structured and machine-readable, with clear schemas and field descriptions. (Regulation (EU) 2016/679, Article 20)

Practical packaging guidance:

• Prefer a single archive with one or more files plus a README that explains files, date ranges, and field meanings.
• Include metadata that helps portability: export timestamp, product version, and identifiers needed to import elsewhere (where appropriate and secure).

Output: export specification, sample export files, and a runbook for regenerating.

Step 5: Deliver “without hindrance,” securely

Delivery options commonly used in practice:

• Secure download link with short-lived access.
• Encrypted file transfer with separate key delivery.
• Delivery inside the authenticated account portal.

Avoid “hindrance” patterns:

• Requiring phone calls when your normal DSAR flow is online.
• Providing only PDFs or screenshots for portability requests.
• Delaying due to internal routing confusion rather than genuine identity/security needs. (Regulation (EU) 2016/679, Article 20)

Output: delivery log (who, when, how), plus confirmation of completion.

Step 6: Track, log, and close with a defensible record

Every portability request should end with an evidence packet:

• Request details and classification decision (why it was treated as Art. 20).
• Identity verification result.
• Systems queried and export job ID/hash.
• Export contents summary (field list version).
• Delivery method and completion confirmation.
• Exceptions and remediation (if any).

This is where many teams fail. They can do the work once, but cannot prove they did it correctly later.

Step 7: Test the workflow and keep it evergreen

Run test cases whenever:

• You add a new data store with in-scope fields.
• You change schema.
• You launch a new product line that collects user-submitted data.

Daydream (as a system of record) fits naturally here: use it to maintain the role-and-scope register, store the operating procedure, and attach evidence packets per request so audits do not turn into a file hunt.

Required evidence and artifacts to retain

Keep these artifacts in a single, searchable location (ticketing system, GRC repository, or DSAR platform export):

Artifact	What it proves	Owner
Role-and-scope register for Article 20	You know where portability applies and why	Privacy / GRC
Portability SOP (intake → verify → export → deliver)	Repeatable execution with named responsibilities	Privacy Ops
Portability data dictionary + schema/versioning	Consistent field inclusion and format	Engineering + Privacy
Export job logs (timestamps, systems, success/failure)	Control operation, traceability	Engineering
Identity verification record	Lawful release to the right person	Support / Privacy Ops
Delivery record (link created, expiry, access confirmation)	Completion “without hindrance,” securely	Support / Security
Exception/denial decision record	Consistent handling of edge cases	Privacy / Legal

All of the above map directly to an auditor’s main question: “Show me you can do this reliably, not once.”

Common exam/audit questions and hangups

Expect auditors, regulators, and enterprise customers to ask:

• “Which products and systems are in scope for portability, and who signed off?” (Regulation (EU) 2016/679, Article 20)
• “Show a sample export. Is it structured and machine-readable?” (Regulation (EU) 2016/679, Article 20)
• “How do you prevent over-disclosure (exporting other people’s data)?”
• “How do you verify identity before releasing a portable file?”
• “How do you ensure support teams do not send PDFs for portability requests?”
• “How do you handle data stored at third parties (processors/subprocessors) and still meet portability expectations?” (Regulation (EU) 2016/679)

Have your evidence packet ready, and keep your field-level definitions crisp.

Frequent implementation mistakes and how to avoid them

1. Treating portability as access.
   Fix: Create a distinct request type, templates, and outputs for Article 20 versus general access. (Regulation (EU) 2016/679, Article 20)

2. No agreed definition of “provided by the data subject.”
   Fix: Write a portability data dictionary with examples and edge-case guidance, then version it.

3. Export formats that are human-readable but not machine-readable.
   Fix: Standardize on structured formats and include schema notes. (Regulation (EU) 2016/679, Article 20)

4. Engineering builds a one-off script.
   Fix: Make portability export a maintained feature with monitoring and ownership.

5. Third-party data silos break fulfillment.
   Fix: Update third-party contracts and integration runbooks so your teams can extract in-scope data quickly when you are the controller. Track which systems are “authoritative sources” in your register. (Regulation (EU) 2016/679)

6. Weak evidence retention.
   Fix: Require an “evidence checklist” before closing tickets; store sample exports and logs with sensitive parts redacted where appropriate.

Enforcement context and risk implications

No public enforcement cases are provided in the supplied sources, so this page does not list case law or fines. Treat the risk as practical and recurring: inability to fulfill portability requests triggers regulator complaints, customer trust issues, and contract friction in enterprise sales. Article 20 is also easy for sophisticated users to test: they can ask for an export and assess whether it is actually portable. (Regulation (EU) 2016/679, Article 20)

Practical 30/60/90-day execution plan

Numeric timelines are not source-backed here, so treat these as phases you can size to your environment.

Immediate phase (stabilize and scope)

• Assign a single owner for Article 20 execution (Privacy Ops lead) and a technical owner (Engineering).
• Build the role-and-scope register: products, systems, controller/processor position, export readiness.
• Draft and approve the portability SOP with intake routing, identity checks, and delivery methods. (Regulation (EU) 2016/679, Article 20)

Near-term phase (build and test)

• Define and version the portability data dictionary and export schema.
• Implement export automation for the highest-volume product first.
• Create a secure delivery mechanism and logging standard.
• Run tabletop tests: “happy path,” wrong-account request, authorized agent, partial data in third-party system.

Operational phase (prove, monitor, improve)

• Add monitoring for export failures and backlog visibility.
• Train support teams with scripts that distinguish portability from access.
• Institute periodic reassessment: new systems, schema changes, acquisitions, and new third-party processors.
• Centralize evidence packets in Daydream (or your GRC system) so you can produce proof on demand.

Frequently Asked Questions

Does Article 20 mean we must send data directly to another company?

Article 20 includes a right to transmit data to another controller “without hindrance,” and it also gives the individual the right to receive the data themselves in a portable format. Your baseline deliverable is a usable export to the individual. (Regulation (EU) 2016/679, Article 20)

What formats count as “structured, commonly used and machine-readable”?

The regulation sets characteristics, not a required file type. Choose formats your users and other controllers can reasonably process (often CSV/JSON), document your rationale, and keep the schema stable and versioned. (Regulation (EU) 2016/679, Article 20)

Is portability the same as “download all my data”?

Portability is limited to personal data “provided” by the data subject under the conditions in Article 20. Build a distinct export data set and do not assume it equals every internal record tied to the account. (Regulation (EU) 2016/679, Article 20)

How should we handle data stored with a third party (processor/subprocessor)?

If you are the controller, you still need the operational ability to produce the export. Make sure your contracts and technical integrations allow timely extraction of the in-scope fields from third-party systems you rely on. (Regulation (EU) 2016/679)

What evidence should we retain to defend a portability response?

Keep the request record, identity verification outcome, export schema/version used, systems queried, export job logs, and delivery confirmation. Auditors typically focus on whether you can reproduce and explain what was delivered. (Regulation (EU) 2016/679, Article 20)

Can we deny a portability request if we can’t verify identity?

You should not release portable data without confidence you are sending it to the correct person. Document what verification you attempted, what failed, and what you asked the requester to provide next. (Regulation (EU) 2016/679, Article 20)