Article 20 GDPR gives individuals a qualified right to receive certain personal data in a reusable electronic format and transmit them to another controller. It can also require direct transmission between controllers where technically feasible. The right is narrower than access under Article 15, but it is not limited to information someone typed into a form.
The legal source is Article 20 in the official GDPR on EUR-Lex. The Article 29 Working Party’s final portability guidelines, WP242 rev.01, revised on 5 April 2017, explain its interpretation. This guide uses those rules to distinguish eligible data, choose a useful export and handle the request without confusing portability with account closure or erasure.
What the four paragraphs of Article 20 do
Article 20(1) establishes the right to receive personal data concerning the individual that they have provided to a controller, in a structured, commonly used and machine-readable format. It also protects their ability to transmit those data to another controller without hindrance. The processing must be automated and based on the specified consent provisions or contractual necessity under Article 6(1)(b).
Article 20(2) adds the right to direct controller-to-controller transmission where technically feasible. That qualification concerns the direct transfer route. It does not make the individual’s right to receive qualifying data dependent on whether a competing service can import them automatically.
Article 20(3) preserves the relationship with Article 17 erasure and excludes processing necessary for a public-interest task or the exercise of official authority. Article 20(4) protects the rights and freedoms of others. A complete assessment must consider these limits together rather than stopping at the observation that the controller has an electronic file.
Check the processing purpose and legal basis
An organisation may process the same person’s information for several purposes under different legal bases. Article 20 does not apply automatically to everything in the account. Identify the relevant operations and check whether the applicable basis meets its conditions.
The qualifying consent provisions are Article 6(1)(a) and Article 9(2)(a), and the contractual ground is Article 6(1)(b). Contractual necessity requires the relevant relationship with the data subject; a contract between two businesses does not automatically qualify every employee’s contact details. The existence of an employment contract likewise does not make all personnel processing contractual for this purpose.
Processing based only on a legal obligation or legitimate interests does not satisfy Article 20’s legal-basis condition. That does not mean the individual has no rights over those data. Access, rectification, objection or another right may still be relevant under their own conditions.
The automated-processing condition also matters. Article 20 is not a general requirement to digitise every paper archive for portability. A process using both electronic and paper material needs a reasoned assessment of the relevant operations, rather than an assumption that any paper element excludes the whole request.
Provided data include qualifying observed activity
The guidelines interpret data provided by the individual broadly. Account information and uploaded material can qualify, as can data observed through use of a service or device. Examples include a person’s transaction history, listening activity or raw measurements from a connected device, where the remaining Article 20 conditions are met.
The important qualifications remain: the information must concern the requester, constitute personal data and relate to qualifying processing. It is inaccurate to say that every technical log is automatically portable merely because a sensor produced it. Some records may not concern that person; others may belong to processing with a different legal basis.
A controller should examine what a field represents rather than infer its status from a database name. A table called “analytics” might contain both raw events observed from the user’s activity and a score generated by analysing those events. The two categories can require different treatment.
An example is a music service that keeps a user’s playlists, listening history and a prediction of their musical preferences. Subject to the statutory conditions, the playlists and observed history can fall within portability. The prediction is a separate inferred result. This illustration explains the distinction; it is not a claim that a particular company’s enforcement decision established an Article 20 breach.
Inferred data and access are different questions
The guidelines distinguish provided and observed data from inferences or derived information created by the controller, such as a risk score or recommendation profile. Such outputs are not treated as data provided by the individual for Article 20. The underlying qualifying inputs may still need to be included.
Exclusion from portability does not make a personal inference exempt from the right of access. Article 15 has a different scope and includes information about the processing. Any applicable limits, including the rights of others, must be assessed under that right rather than inferred from Article 20’s provided-data condition.
This distinction matters when a request asks for “all my data in a reusable file”. The controller should identify what the person is asking for and explain which rights are being addressed. It should not use a narrow portability decision to avoid dealing with an access request, or silently replace a valid portability response with an ordinary access report.
A coordinated data subject request procedure can handle overlapping rights while retaining separate scope decisions. An accessible explanation of a profile might satisfy part of an access response but does not by itself export the qualifying underlying records. Conversely, a large machine-readable download may fail to provide the explanatory information required for access.
Mixed records require safeguards, not automatic deletion
Personal records often involve other people. An account holder’s transaction history can name counterparties; messages and contact lists can contain third-party details. The fact that a record concerns more than one person does not automatically remove it from the requester’s portability right.
Article 20(4) requires an assessment of adverse effects on others’ rights and freedoms. Consider what the record reveals, to whom it will be supplied and whether safeguards can address the identified concern. Automatically removing every reference to another person can make a record unusable while failing to explain what harm the removal prevents.
Direct transfer to another service raises additional questions about the receiving controller’s use. A contact directory transferred to help the user manage personal communications does not give the recipient unrestricted permission to market to everyone in that directory. The recipient must establish the appropriate basis for its processing and respect purpose limitation and other applicable obligations.
Trade secrets and intellectual property can also require protection. They are not a blanket reason to withhold every item. The guidelines favour providing qualifying personal data in a way that protects legitimate rights, where possible. A commercial concern about making it easier for a customer to leave is not, by itself, a lawful obstacle.
Choose a format that supports meaningful reuse
Article 20 does not prescribe a single extension such as CSV or JSON. It requires structured, commonly used and machine-readable information. The format should allow software to identify and extract meaningful data, rather than merely display a picture of a report.
For a simple transaction list, a tabular format may be suitable. A more complex set of relationships may require a format that preserves structure. Established formats can be useful for contacts, calendar entries or messages. The decision should follow the information and likely reuse, not a company’s preference for its own proprietary export.
A PDF is not automatically disqualified solely by its name. However, an image-only PDF or a flattened printout of an inbox is unlikely to preserve the structure needed for effective reuse. The guidelines specifically question an inbox export that loses useful message metadata. The substantive properties of the output matter more than the label on the file.
Metadata can be essential. A timestamp without a time zone, an unexplained code or an amount without its currency can be difficult to use correctly. Include the existing context needed to interpret qualifying records, with a concise explanation of fields and relationships. This does not create a general licence to collect additional personal information merely because someone might request an export later.
A practical export review
Before delivery, check that the export corresponds to the scope decision. A sample can reveal missing date ranges, duplicated transactions or identifiers that no longer connect related records. The review should also confirm that another person’s unrelated records have not been included by mistake.
Consider an account containing orders, saved addresses and a preference score. The team should document which processing meets Article 20 and why, export the qualifying data with intelligible relationships, and separately consider any access request concerning the score. It should not delete an entire order history because individual orders mention recipients other than the account holder.
Explain the contents to the requester in plain language. If part of the request is outside Article 20, identify the category and reason rather than delivering a mysterious partial file. Where the person can choose between useful formats or subsets, explain what those choices preserve or omit without using extra choices to delay the response.
Direct transmission depends on the actual systems
Technical feasibility must be assessed for the proposed transfer. Can the receiving controller accept the information through a secure available method? Can the sending controller verify the destination and the person’s instruction? The existence or absence of a particular branded integration does not alone answer these questions.
Article 20 does not require controllers to build or maintain technically compatible systems. An API can be an effective mechanism, especially for repeated requests, but it is not the universally mandated solution. Other secure means may allow a direct transfer where the circumstances support it.
If direct transmission is not technically feasible, explain the impediment and address the individual’s entitlement to receive qualifying data. A refusal to transfer directly should not leave the person without a usable response to the underlying portability request. The relevant Article 12 duties still apply.
Nor does Article 20 generally compel a receiving business to accept the dataset or open an account for the person. A recipient that does accept it becomes responsible for its own processing, including lawful basis, information, minimisation and security. Sector-specific rights may add obligations, but those should be identified separately rather than attributed to Article 20.
Identity and secure delivery
The controller needs confidence that it is sending information to the correct person or authorised recipient. Article 12(6) permits additional information where there are reasonable doubts about identity. Verification should be proportionate; it should not become an automatic demand for a passport when existing account controls sufficiently establish the link.
A person using a pseudonymous service may be able to demonstrate control of the relevant account without disclosing a civil identity that the controller never needed. Where the controller cannot identify the person, Articles 11 and 12 require attention to any additional information the person provides to enable identification.
Delivery can expose a substantial collection of personal information. Assess the sensitivity of the file, destination verification, access controls and the period for which an export link remains available. The appropriate safeguards should protect the transfer without creating unjustified obstacles or additional charges.
The requester should also understand that a downloaded copy needs protection. Practical advice about storing the file can be useful. It does not replace the controller’s responsibility for its own extraction and transmission, and it should not be used to pressure the person into abandoning the request.
The deadline is a legal limit, not a service target
Article 12 requires action without undue delay and information on action taken within one month of receipt. An extension of up to two further months is possible where necessary because of the complexity and number of requests. The controller must inform the person of the extension and reasons within the first month.
The ordinary cost of creating a compliant export process is not a reason to charge each requester. Requests are generally free. For a manifestly unfounded or excessive request, the controller may charge a reasonable fee based on administrative costs or refuse to act, but it bears the burden of demonstrating that condition.
A request is not automatically excessive because the dataset is large or because many other people have made requests. Assess the particular request and the statutory conditions. Design limitations and repeated manual effort may reveal a need to improve the process rather than establish a lawful refusal.
If the controller does not act, Article 12(4) requires reasons without delay and at the latest within one month, together with information about complaining to a supervisory authority and seeking a judicial remedy. Silence, an unexplained error message or an indefinite referral to a technical team is not an adequate substitute.
Portability does not itself erase or extend retention
A person can request portability while continuing to use the service. Providing the copy does not automatically close the account or delete the original records. Article 20 expressly preserves the relationship with the right to erasure, whose grounds and exceptions require separate consideration.
Likewise, the export should not be used to postpone a valid erasure request unnecessarily. If a person requests both rights, coordinate them and clarify the sequence where needed. Do not make the exercise of one right conditional on abandoning the other.
There is no general requirement to keep data longer solely in case a future portability request arrives, or to recreate information that was already lawfully erased before the request. Existing backups and archives do not create a blanket exemption either. Assess the actual data and request within the applicable rules, while keeping storage limitation in view.
Prepare the scope before the next request
A record of processing activities can help locate relevant processing, but the legal basis and export classification are useful additional fields rather than separately prescribed Article 30 fields. Connect the legal assessment with the system inventory so that the team knows where qualifying data and relevant context are held.
Document the format, secure route, responsible staff and treatment of mixed records. Review these arrangements when systems or purposes change. Article 20 does not impose a universal annual audit date, but an obsolete extraction process can produce incomplete or misleading responses.
A failure of access is not automatically a failure of portability, and the reverse is also true. When considering GDPR enforcement and fines, check the precise obligations and findings in the actual decision. For day-to-day work, the useful evidence is a clear scope assessment, a usable response, appropriate safeguards and compliance with the applicable deadline.