Article 20 GDPR right to data portability: evidence

What GDPR Article 20 data portability asks systems to do

Article 20 asks two things of the system that holds personal data. First, when a person asks, the controller must hand them the personal data they provided in a structured, commonly used and machine-readable format, so they can keep it or pass it on. Second, where the person asks and it is technically feasible, the controller must transmit that data directly to another controller. The right applies only when the processing rests on consent or on a contract with the person, and when it is carried out by automated means. A paper file or a manually maintained spreadsheet falls outside it, while an account database feeding an app usually falls inside it. For the engineer, the first step is to confirm, per data flow, which legal basis applies and whether the processing is automated. Those two answers decide whether the export feature is required at all.

The hard part is deciding what counts as data the person provided. The Article 29 Working Party guidance treats data supplied knowingly by the person, such as profile fields and uploaded files, as in scope, and it also includes data observed from the person's use of the service, such as activity logs or usage records. Inferred and derived data, such as a credit score, a risk category or a recommendation profile the controller computed, is generally excluded. Your team should map each field in each store to one of these three categories and record the reasoning, because an export that omits observed data or wrongly includes derived data will be hard to defend. Confirm the exact interpretation with your privacy or legal team and against the current guidance, since the position on edge cases is still debated.

The right exists to prevent lock-in and loss of control over one's own data. A person who can take a complete, usable copy of their information to a competing service is not trapped by the first one. Plan for that purpose in the design: a documented export schema, a stable identifier for each person, a way to verify the requester before releasing data, and a secure delivery path. Ask whether your platform can produce the export in a format another controller can ingest without manual rework, and whether it can push data to a named recipient when that is technically feasible. Where direct transfer is not feasible, record the reason, since that decision is itself something you may need to justify.

Which systems and data fall under the portability right

Article 20 applies only when several conditions line up: the lawful basis, the way the processing runs, and where the data came from. Each card below is a scoping decision that changes which systems you must export from and what the export must contain.

Consent or contract as the lawful basis

The right applies only where processing rests on consent or on a contract with the person. Processing based on legitimate interests or legal obligation falls outside it. Map each data set in your systems to its Article 6 basis before building export jobs, because a single customer record may feed both a contract-based service and a marketing process based on consent or interest. Confirm the basis with your records of processing rather than assuming it from the product.

Automated processing only

The right covers data processed by automated means. Paper files and manually kept spreadsheets are generally out of scope, though an organization may still choose to offer them. Check which systems hold the relevant data in structured form, such as databases, CRM tables and application stores, and which records exist only as scans or free text. This decision determines which systems feed the export pipeline and which need a separate manual procedure.

Data provided directly by the person

The right covers personal data the person provided, including data they entered in forms, uploaded, or generated through their own use of the service. Account details, submitted documents and order history typically qualify. Map every intake point, including web forms, API calls, mobile apps and imports from partners where the person supplied the data, so no provided data set is left out of the export.

Observed data from service use

The Article 29 Working Party guidelines treat data observed from the person's use of a service, such as activity logs, device readings or usage history, as provided by the person. These records are often stored in logging, analytics or telemetry tools that engineers do not treat as customer data. Inventory these sources and decide which observed fields to include, since omitting them is a common gap in portability work.

Inferred and derived data excluded

Scores, risk ratings, segments and other conclusions the controller creates from provided or observed data are generally excluded from portability. Keeping them out of the export requires a clear data model that separates raw inputs from computed outputs. Tag derived fields at the schema level and document the boundary, because a mixed table can pull inferred values into an export by mistake.

Third-party data and public-task processing

Two limits narrow the export. Processing needed for a public task or official authority is outside the right, and an export must not adversely affect the rights and freedoms of others. A record of a customer's call that includes a colleague's personal details, for example, needs redaction review before release. Confirm with legal counsel how public-task processing and third-party content are handled in each system, since these checks are judgment calls rather than database filters.

Which data count as provided, observed and derived

Article 20 covers only data the person provided, and the Article 29 Working Party guidance (WP242 rev.01) reads "provided" in two tiers. Data actively supplied by the individual, such as details typed into a form or uploaded files, are in scope. Data observed from the person's use of a service, such as activity logs, device readings or transaction history captured by the system, also fall within scope because the person generated them by using the service. Inferred and derived data, meaning values the controller calculates or concludes about the person, such as risk scores, segment labels or profiles, are excluded. The guidance is the reference point assessors and regulators use, so the classification should be settled before the export feature is built, not when the first request arrives. The guidance is available from the Article 29 Working Party guidelines on the right to data portability.

*Illustrative example:* a customer profile holds three kinds of data. The preferred_delivery_address field was typed by the customer, so it is provided and portable. A table of login timestamps and page views recorded by the platform is observed data and is portable. A churn_risk_score computed nightly by a model is derived data and is outside Article 20, although it may still be disclosed under Article 15 access. Teams should record this in the data inventory or record of processing with one classification column per field or dataset, a source attribute (user input, system observation, or controller-generated), the lawful basis, the storage location and the owning system. Where a field's category is unclear, the owner should document the reasoning and confirm it with the privacy function or data protection officer.

The inventory is also what makes the export complete and repeatable. An export job should draw only from fields marked as provided or observed, and the job's query or configuration should be reviewed whenever a schema changes, because a new derived column added to a shared table can silently leak into a portability file or, in the other direction, a new user-entered field can be left out. Ask the team to confirm how observed data is collected in each platform, including application logs, audit trails and third-party integrations, since these often sit outside the main database. Operator-set exclusions for security or fraud logs and for the rights of others should be documented alongside the classification, so the decision can be explained to a complainant.

How an assessor tests portability in practice

This table walks through the steps an assessor typically follows when testing Article 20, from confirming that the right is triggered to checking exclusions. Read each row as a test step with the evidence it produces and the findings that most often come up.

Test step	What the assessor checks	Evidence requested and common findings
Confirm the trigger	Processing is based on consent or contract and carried out by automated means. Processing for a public task or official authority falls outside the right.	Records of processing and lawful basis entries for each in-scope system. Finding: a team records consent as the basis but the data is actually processed under legitimate interests, so the right is misapplied.
Define data provided by the person	Which fields the person supplied directly, and which data were observed from use of the service. Inferred and derived data are excluded.	A data map that labels each field as provided, observed or derived. Finding: observed data such as activity logs or usage history is left out of the export.
Sample requests	A set of completed portability requests, chosen to cover different systems, request channels and time periods. The sample size is set by the assessor, not by a fixed count.	Request tickets with dates, identity verification notes and delivery records. Finding: requests are closed without a record of what was exported.
Trace data to the export	For each sampled request, the assessor follows the data from the source systems to the file the person received.	System queries, export job logs and the file hash or version used. Finding: a secondary store such as a CRM or support tool is missed because it is not in the export procedure.
Check format and completeness	Whether the output is structured, commonly used and machine-readable, and whether it covers all in-scope data for the person.	Sample export files and a field comparison against the source. Finding: exports in proprietary or image-based formats, or PDFs that cannot be re-imported.
Check direct transmission	Where the person asks for transfer to another controller and it is technically feasible, whether the organization can send the data directly, and how it decides feasibility.	A documented feasibility assessment, interface or API specification, and transfer logs. Finding: no stated reason for refusing direct transfer when the receiving controller could accept the format.
Check secure delivery	How the export reaches the person or the receiving controller, and whether access is protected in transit and at rest.	Transfer method records, encryption settings and access controls on download links. Finding: export files sent by unencrypted email or left on shared storage without expiry.
Check exclusions and third-party effects	Whether the export wrongly includes data that would adversely affect the rights of others, or wrongly omits data that should be exported.	Redaction or review notes for each sampled export. Finding: another person's data appears in a shared record and is released without review.

How to implement a portability export step by step

This sequence turns Article 20 into a repeatable export capability: it identifies which data qualifies, which processing triggers the right, and how the export is built, delivered, tested and documented so each request can be answered the same way.

Classify data by provenance
Start by listing the personal data sets your systems hold for each service and tagging each field by origin: data the person provided directly, data observed from their use of the service, and data inferred or derived by your systems. The owner is usually the product or data owner with input from the DPO, since they know where fields are created. Under the Article 29 Working Party guidelines on portability (WP242 rev.01), provided and observed data fall in scope, while inferred and derived data do not. The output is a provenance register that names each data set, its source and its scope decision, reviewed and signed off before any export code is written.
Map the lawful basis and processing method
For each in-scope data set, record whether the processing rests on consent or on a contract and whether it is carried out by automated means. Article 20 applies only when both conditions hold, so a set processed under a legal obligation or a public task falls outside the right. The privacy and records teams should confirm these bases against the record of processing and privacy notices. The output is a portability map that shows which processing activities trigger the right, with the reason recorded for each exclusion, so an assessor can trace every decision back to the source.
Define the export schema
Specify the export format for each in-scope data set. Article 20 asks for a structured, commonly used and machine-readable format, so schemas should use widely supported formats such as JSON or CSV with a documented field dictionary, units, date formats and character encoding. Engineering and the DPO agree the schema, and the output is a versioned schema specification stored with the procedure. Where your platform uses a proprietary internal format, the schema should translate it into the standard export format rather than exposing internal structures. Keep the schema under change control so that later releases do not silently break exports.
Build the export and secure delivery path
Implement the job that selects the requesting person's records from the in-scope sets, applies the schema and packages the result. The export must include only that person's data and must not expose the data of others, as Article 20(4) requires. Deliver the file through an authenticated channel, such as a time-limited download behind verified login, and never by unprotected email. Engineering owns the build, and security reviews the delivery path. The output is a working export for a test account that contains only the expected fields, can be opened by a standard parser and is delivered only to the verified requester.
Add direct transfer where technically feasible
Article 20(2) gives the person the right to have data transmitted directly from one controller to another where technically feasible. Decide whether a receiving controller can accept your format through an API or a secure file exchange, and document the technical limit if it cannot. Where direct transfer is built, authenticate both ends, encrypt the channel and log each transfer. The guidelines encourage industry stakeholders to agree interoperable formats, so record any standards you adopt. The output is either a tested transfer interface with its security controls documented, or a written feasibility assessment explaining why direct transfer is not technically feasible for that data set.
Test with sample requests
Run the procedure against sample requests using test accounts with known data. Check that the export contains every in-scope field, excludes inferred and derived data, leaves out other people's data, parses cleanly in the chosen format and reaches only the verified requester. Include edge cases such as deleted records, multiple services and accounts with mixed consent and contract bases. Quality assurance and the DPO should review the results, and failures should go into a tracked remediation list. The output is a dated test report with pass or fail results per check, retained as evidence that the capability works as designed.
Document the procedure and maintain it
Write a portability procedure that covers intake and identity verification, the scope rules from the provenance register, the lawful basis map, schema versions, delivery methods, direct transfer conditions, logging and exceptions. Assign owners for each step and review the document when systems, formats or processing bases change. The output is an approved procedure, a change history and a link from each portability request to the test evidence and log entries that prove it was handled. Ask your implementation partner and your independent assessor to confirm which of these records they will expect to see before you finalize the format.

Evidence that satisfies a portability assessment

An assessor testing Article 20 will look for proof that the organization knows which data fall in scope, can export them in a usable format, and can show the export working on real requests. The artifacts below connect those points, and each one needs a named owner and a review date so it stays accurate between assessments.

Data classification register

A register that lists each data field or dataset and labels it as provided by the person, observed from use of the service, or inferred or derived by the controller. This register decides what goes into an export. Check that every field in the export schema traces back to a register entry, and that the label reflects how the data was actually collected, not how the team wishes to describe it. Review it whenever a new feature adds fields.

Export schema specification

A versioned document that defines each exported field, its data type, its meaning and the structured format used, such as JSON or CSV. Article 20 requires a structured, commonly used and machine-readable format, so the specification is the proof that the format was chosen deliberately. Record who approved each version and which release it belongs to, so a request answered in 2025 can be matched to the schema that produced it.

Sample export files and validation

Retained sample exports, generated from test or consenting accounts, along with the results of automated checks that confirm each file parses and matches the schema. Keep the validation script and its output together, so an assessor can rerun it. Include a sample for each processing activity that falls under consent or contract, because those are the only activities Article 20 reaches. Regenerate samples after each schema change.

Request logs with timestamps

Records of every portability request showing receipt date, identity verification steps, the one-month response clock, the date the export was produced and the date it was delivered. Timestamps should come from a synchronized clock and be kept in an append-only store. An assessor will compare these dates against the Article 12 deadline, so gaps or edited entries will draw questions. Run a periodic sample check to confirm the log is complete.

Secure delivery and direct transfer records

Evidence of how each export reached the person, such as an authenticated download or encrypted delivery, and, where direct transmission to another controller is offered, the test records showing the transfer succeeded and the receiving system accepted the data. Direct transfer applies only where technically feasible, so document the feasibility decision and the reasons behind it. Keep transfer logs free of the exported content itself.

Documented exclusions with reasons

A written list of data excluded from portability, with the reason for each exclusion. Typical reasons include inferred or derived data, processing based on a public task or legal obligation, and data whose disclosure would adversely affect the rights of others. Each entry should cite the rule relied on and carry an approval record. Review the list when processing purposes change, because an exclusion that no longer fits becomes a finding.

What meeting Article 20 costs in money and effort

This table breaks down the cost components of building Article 20 portability into who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to shape a written scope and to ask vendors and partners which items are included in a quote. The main takeaway is that most of the cost sits in data mapping, format design and ongoing upkeep rather than in the export function itself.

Cost component	Who is paid or who does the work	One-time or recurring	What drives the cost
Legal review of scope	Counsel or privacy team, sometimes an external DPO	One-time, revisited when processing changes	Number of processing purposes that rely on consent or contract, and edge cases such as observed data
Data classification and mapping	Internal data owners with engineering support	One-time, then recurring as systems change	Number of systems holding user-provided data and how many tables or fields are involved
Export and schema engineering	Internal developers or an implementation partner under a written scope	One-time build	Number of data models, need for a common schema, and inconsistent legacy formats
Machine-readable format testing	QA engineers and the data owner who checks the output	One-time, repeated on each format change	Number of formats offered and how complete the test data set is
Direct transfer to another controller	Engineering and the receiving controller's technical team	One-time per receiving party, plus upkeep	Whether a common interoperable format exists, and the authentication and transport design agreed with each receiver
Identity verification and access control for exports	Security engineering and the team running request handling	One-time build, recurring operation	Volume of requests and how sensitive the exported data is
Ongoing schema upkeep	Internal platform team or a retainer partner	Recurring	Frequency of application releases and new fields added to user-facing features
Software licences for self-hosted open source	Typically none for the core platform, though support contracts may apply	Recurring only if a support contract is chosen	Choice of open-source components and whether vendor support is bought

Who does what: your team, a partner and the auditor

Your organization remains the controller and owns every decision that defines the right. Your legal or privacy function must establish whether the processing rests on consent or contract and is carried out by automated means, because only then does Article 20 apply at all. Your team also decides which processing falls under the public task exclusion, how the right interacts with erasure under Article 17, and how third-party rights are protected when an export contains other people's data. These are accountable judgments that cannot be transferred to a vendor or consultant.

Lawful basis and scope: Record which processing activities are consent or contract based and document why others are excluded.
Data provided versus derived: Decide which fields count as provided, observed or inferred, using the Article 29 Working Party guidance as your reference point.
Third-party data: Set the rule for redacting or withholding information about other individuals.
Policy and procedure: Approve the request workflow, response format and retention of exports.
Ownership of evidence: Keep the register of decisions that an assessor or supervisory authority will ask to see.

Confirm these decisions in writing before any engineering starts, because scope errors are the most expensive to correct later.

Where portability programs usually fall short

Most portability problems are not legal disputes about the right itself. They come from exports that quietly drop data, formats nobody can reuse, and transfers that were never designed or documented. Each card below names one gap, what it looks like in a system, and the fix an assessor or data subject would expect to see.

Exports omit observed data

Teams often export only the fields users typed into a form and leave out activity logs, device signals, usage history and call records. Under Article 20 and the Article 29 Working Party guidelines, data observed from the use of a service counts as provided by the data subject, while inferred and derived data do not. Map each data store to one of these three categories, then include the observed group in the export and document why each excluded field is inferred or derived.

Proprietary or unreadable formats

An export delivered as a PDF, a screenshot or a vendor-specific binary cannot be reused by the person or a receiving controller. Article 20 requires a structured, commonly used and machine-readable format. Confirm that each export produces formats such as CSV or JSON with a documented schema, field names and encoding, and test the output by importing it into a second tool before you call the route complete.

No direct transfer or documented reason

Article 20(2) requires direct transmission between controllers where technically feasible. Many programs have no transfer path at all and never record why. Where a direct route is possible, build it with an agreed API or secure file exchange. Where it is not, keep a written feasibility assessment that states the technical barrier, the date it was reviewed and the alternative offered, such as a downloadable export.

Unclear lawful basis for the export

The right applies only when processing rests on consent or contract and runs by automated means. Teams that export data held under legitimate interests or a legal obligation, or that skip the test entirely, cannot show why the request was in or out of scope. Record the lawful basis for each dataset in the record of processing, and add a scope check to the request workflow so the decision and its reason are logged for each request.

Exports delivered insecurely

A complete, well-formed export sent by unencrypted email or posted to a shared link with no expiry can expose more personal data than the original system did. Deliver exports through an authenticated portal with time-limited, single-use access, and verify the requester's identity before release. Set access logs for each download and confirm that any transfer to another controller uses encrypted channels with the recipient authenticated.

How helpdesk tools can track portability requests

A helpdesk ticket gives the team a dated record of how a portability request was received, handled and closed, which is the process evidence an assessor will ask for. Both GLPI and Zammad can hold that record, but neither will show what was exported. Treat the ticket as a log of the workflow, and keep the export file and its checks in the controlled location your team defines.

GLPI's Assistance module (documented at help.glpi-project.org) lets users create, follow and process tickets, with plannings and statistics. A portability request can be opened as a ticket, assigned to a named person, and tracked through follow-ups, with a planning entry showing when the export is scheduled. Recurring tickets and the Kanban view can show open requests across the team. Confirm in your own instance which ticket categories, statuses and fields are configured, and whether closing a ticket requires a linked export reference.

Zammad, described in its documentation, brings email, chat, telephone and social media messages into one ticket system. This matters because a portability request often arrives through an ordinary channel, not a formal form. Confirm that intake from each channel creates a ticket, that identity verification notes are recorded on the ticket rather than in free email threads, and that the final response and transmission reference are attached before closure. A ticket that says an export was sent is not proof that the right data was sent, so pair it with the export log and a check of the file contents.

Questions buyers ask about Article 20 compliance

How much effort and time does Article 20 compliance take?

The effort depends mostly on how many systems hold data the person provided, how many of those systems produce structured machine-readable exports today, and whether a transmission channel to another controller is needed. No fixed duration applies to every organization, so ask for a timeline built from a written scope. Costs have two parts: one-time work to map which data count as provided, build or configure export functions and test them, and recurring work to keep exports current as schemas change and new systems are added. Ask any partner to split its quote into these phases and to state which systems are included.

Can an in-house team handle Article 20 work by itself?

Often yes, if the team has engineers who know the systems that store customer data and someone who can judge legal scope. Article 20 is narrower than access or erasure: it covers data the person provided, processed on the basis of consent or contract, by automated means. The hard parts are legal and technical at once, such as deciding whether observed usage data is in scope while inferred data is not. Many teams keep the legal decision in-house and bring in outside engineering for export tooling, testing and documentation. DeployOpen plans, implements and documents such work inside the client's own infrastructure, but the organization keeps ownership of its decisions.

What does the work need from our staff?

The work needs input from four groups. Privacy or legal staff confirm the lawful basis for each processing activity and the scope of the right. Data owners identify where provided data lives across databases, file stores, SaaS tools and logs. Engineers build or configure exports and check that they are complete and consistent. Security staff verify identity checks before any export leaves the organization, and confirm the delivery channel is protected. Ask your partner to name who on your side signs off each stage, because delays usually come from unclear decision owners rather than from technical complexity.

Is direct transmission to another controller always required?

No. Article 20 requires direct transmission from one controller to another only where it is technically feasible, so the duty is conditional. In practice, the first obligation is to give the person a copy of the data in a structured, commonly used and machine-readable format. Direct transfer becomes a question of feasibility: whether a compatible receiving system exists, whether a common format is available, and whether the transfer can be secured. Article 20 also does not apply to processing necessary for a public task or official authority. The Article 29 Working Party guidelines encourage industry stakeholders to develop interoperable formats, so document why direct transfer is or is not feasible for each system.

Which data count as data the person provided?

Data the person provided includes data they entered or submitted, and data observed from their use of the service, such as activity logs tied to their account. Inferred and derived data, such as scores or categories a controller calculates from that information, are excluded according to the Article 29 Working Party guidelines (WP242 rev.01). For engineers, this means tagging fields by origin in the data model, not guessing at export time. Ask your team to produce a field-level inventory that records whether each attribute was provided, observed or derived, since an export that includes or omits the wrong category is the most common scoping error.

Does Article 20 compliance come with a certificate?

No. The GDPR requires no audit, attestation or certificate for Article 20 or any other obligation. Article 42 certification is voluntary, issued for at most three years by accredited certification bodies or supervisory authorities, and it does not reduce the controller's or processor's responsibility for compliance. A partner that prepares exports, documentation and test evidence does not issue a certificate or report. Any claim of a portability certificate should prompt you to ask who issued it, under which scheme, and whether it is recognized under Article 42. Your own records of testing and decisions are the evidence regulators will look for.

Which open-source tools help with portability requests?

Ticketing and case management tools can help track each portability request from intake through delivery, which produces the audit trail regulators expect. GLPI's Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics and a Kanban view. Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. Neither tool produces exports itself. Confirm with each vendor how attachments, status history and retention are handled before you rely on them as evidence.

Where to read the regulation and guidance

Start with the official text of Article 20 in the *General Data Protection Regulation*, published on EUR-Lex: Regulation (EU) 2016/679 (GDPR), Article 20. Read paragraphs 1 to 4 together before scoping any export or transfer feature. Paragraph 1 limits the right to data provided by the person and processed by consent, contract or automated means, paragraph 2 covers direct transmission where technically feasible, and paragraphs 3 and 4 set the exclusions for public task processing, erasure under Article 17 and the rights of others. Your engineers and product owner should work from the same copy, and your legal team should confirm which processing activities fall inside those conditions.

For interpretation, read the Article 29 Working Party guidelines on the right to data portability (WP242 rev.01), last revised 5 April 2017. The guidance explains that data observed from use of a service count as provided, while inferred and derived data do not. That distinction decides which fields your export must include, so the data inventory should tag each attribute as provided, observed, inferred or derived before you define the export schema. The EDPB endorsed these guidelines on 25 May 2018, and the EDPB page for the WP29 guidelines is the place to confirm the endorsed version. The guidelines also encourage industry to develop interoperable formats, so check whether your sector has a common standard before choosing one.

Keep in mind that guidelines are not binding law. The regulation is binding, and national supervisory authorities in each Member State enforce it, with the European Data Protection Board issuing guidance and resolving disputes between authorities. A supervisory authority will still expect you to explain your reasoning, so record why you chose a format, how you tested the export and which exclusions you applied. Confirm the authority responsible for each country where you operate, and ask your legal counsel whether any sector-specific guidance from national regulators applies to your data.

How DeployOpen prepares portability for your self-hosted platforms

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the export and transfer paths for data you provided can be scoped, built and tested before a request arrives. We prepare the systems and evidence; your organization owns the controls and any assessment is carried out by independent parties.

How we scope

Map which systems hold data a person provided, observed or derived, and mark each as in or out of portability scope.
Record the processing basis for each dataset, since portability applies only to consent or contract based automated processing.
Agree the scope, deliverables and timelines in writing before work starts, as most engagements are fixed-scope.

How we build

Configure export functions that return provided data in structured, commonly used, machine-readable formats agreed with your team.
Build exports that exclude inferred and derived data unless your written scope says otherwise, and document that boundary.
Set up controlled direct transmission to another controller where technically feasible, with authentication and logging on each transfer.

How we hand over

Test sample exports against the agreed format, field list and scope definition, and record the results for your review.
Document the export procedure, data mappings, format specifications and known limits so your staff can run it.
Deliver the evidence pack to your compliance owners, who decide what to share with an independent assessor or regulator.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer when the platforms change after handover.
Re-test export paths after each platform upgrade or new integration, and update the documentation to match.
Confirm with your legal team how Article 20 interacts with erasure and other rights before changing any export logic.