Responding to Data Portability Requests in Practice

Most EU agency operators and small business owners could handle a standard data access or deletion request with a bit of internal scrambling. You pull the files, package them up, and send them off. But the right to data portability is widely considered the least understood and most technically challenging obligation under the General Data Protection Regulation (GDPR).

If a data portability request arrives in your inbox tomorrow, your standard response playbook will not work. You cannot satisfy the legal requirements by sending a PDF, taking screenshots of a client’s profile, or printing out an internal spreadsheet. Data portability requires exporting isolated user datasets into structured, machine-readable formats that can be seamlessly imported into competing services. Because portability is rarely invoked compared to standard access requests, the vast majority of small businesses have never tested their systems to see if they can actually comply.

This guide translates the technical and legal requirements of data portability into a concrete, practical framework. You will learn exactly what data is covered, what formats are legally acceptable, and the specific steps your agency must take to prepare before a request arrives.

1. What Data Portability Actually Means

Enshrined in Article 20 of the GDPR, the right to data portability is designed to foster digital competition, prevent vendor lock-in, and enhance individual data sovereignty.

The regulation states that individuals have the right to receive the personal data they have provided to an organization in a structured, commonly used, and machine-readable format. Crucially, the law also gives individuals the right to transmit that data to another controller—or to request that your agency transmit it directly to a competitor, provided it is technically feasible to do so.

This "technically feasible" caveat provides legitimate cover: if direct transmission isn't natively supported by your systems, you are not legally obligated to build custom API integrations to comply. You simply provide the structured file directly to the individual instead.

(It is also worth noting that the EU Data Act, fully applicable since September 2025, broadens portability obligations even further beyond the GDPR's scope to cover all data—including non-personal data—generated by connected products and services.)

Data portability is fundamentally about interoperability. It is not simply about letting a user see what information you hold about them; it is about giving them the technical power to extract their data and reuse it for their own purposes across different IT environments without hindrance.

2. How Portability Differs from a Standard Access Request

A common and dangerous mistake small businesses make is treating a portability request identically to a standard Subject Access Request (SAR). While both rights belong to the Data Subject Access Request (DSAR) family, they have distinct legal boundaries and technical requirements.

Under an Article 15 access request, the goal is transparency. Individuals have the right to obtain a copy of all personal data your organization holds about them in any intelligible, human-readable format, such as a secure PDF or a flat text document. It covers every piece of data associated with them, regardless of how you obtained it or what lawful basis you rely upon to process it.

Data portability under Article 20 is a much narrower right with strict preconditions. A data portability request only applies if:

• The Lawful Basis: You are processing the data based strictly on the individual’s consent or for the performance of a contract. If you process the data based on your legitimate interests or a legal obligation, the right to portability does not apply.
• The Method: The processing is carried out by automated means. Paper files and manual filing systems are excluded from portability.
• The Source: It only covers data that the individual has "provided to" your organization. It does not cover everything in your databases.

If an individual wants to know everything you know about them, they exercise their right of access. If they want to switch to a different agency and take their raw assets with them, they exercise their right to data portability.

3. The Scope Limitation: What Data Qualifies

Understanding what data was "provided by" the individual is the key to executing a compliant portability export. The GDPR splits this into two specific operational categories while strictly excluding a third.

In-Scope: Actively Provided Data

This includes any information the individual explicitly submitted to your agency. Examples include account registration forms, contact details, billing information, and any raw creative assets, images, or documents they uploaded directly to your platform.

In-Scope: Observed Data

Portability also covers data generated passively by the user’s activity and behavior while using your services. This includes raw usage logs, click histories, transaction timestamps, and website interaction data.

Out-of-Scope: Inferred and Derived Data

You do not have to provide data that your agency has created, inferred, or derived through your own analysis of the user. For a typical marketing or consulting agency, this boundary is critical.

Imagine a client exercises their right to data portability as they transition to a competing firm. You are legally required to export their raw onboarding details, the original target audience spreadsheets they uploaded, and the raw performance metrics from their client dashboard. However, you are not required to export your agency's proprietary strategy notes, internal client health scores, inferred predictive conversion models, or the custom SWOT analysis your team drafted. Knowing this distinction prevents the accidental disclosure of your agency's proprietary intellectual property.

4. The Format Question: What "Machine-Readable" Means

The technical core of a portability request lies in the output format. Handing over a printed spreadsheet or a static PDF profile fails the regulatory requirement because those formats require a human to manually re-enter the data into a new system.

To comply, the data must be "structured, commonly used, and machine-readable". The GDPR does not mandate one specific file extension, but regulatory consensus points to three standard formats:

• CSV (Comma-Separated Values): A highly compatible, flat text file where data rows are separated by line breaks. CSV is ideal for simple tabular data, basic transaction logs, and contact lists.
• JSON (JavaScript Object Notation): A lightweight, hierarchical format that is independent of programming languages. JSON is considered the modern industry standard for system-to-system portability because it easily handles complex, nested client profiles and relational interaction histories.
• XML (Extensible Markup Language): A markup structure utilizing tags to define relationships. It is often used in legacy enterprise systems where strict metadata validation is necessary.

The goal is to provide a file that a competing software service can automatically parse, ingest, and deploy without manual formatting adjustments.

5. The One-Month Deadline and No-Fee Rule

Data portability requests are governed by the same strict timelines that dictate all other data subject rights. You must respond to a portability request without undue delay and at the latest within one calendar month of receipt.

You cannot charge the data subject a fee to process their first request. The GDPR only allows you to charge a reasonable administrative fee—or refuse to act on the request entirely—if the request is "manifestly unfounded or excessive". However, the regulatory bar for proving a request is excessive is incredibly high. You must be able to demonstrate that the request is purely malicious or completely repetitive.

Interaction with the Right to Erasure

It is highly common for a portability request to arrive simultaneously with a deletion request, especially when a user is leaving your service. However, exercising the right to portability does not automatically trigger erasure. A user has the right to extract a machine-readable copy of their data while keeping their active account open. When these requests do overlap, it is critical to understand the operational limits of deletion; read our guide on understanding the right to erasure vs retention obligations to ensure you do not illegally purge financial records that must be archived.

6. Practical Steps for Agencies

Achieving compliance with data portability requires proactive engineering and documentation. If you wait for a request to arrive before figuring out how your systems export data, you will likely miss the 30-day deadline. Take these practical steps today:

• 1. Identify Qualifying Systems: Map your entire software ecosystem to identify which databases, cloud applications, and tools hold user-provided personal data based on consent or contract.
• 2. Test Single-User Exports: Do not assume your SaaS vendors support portability out of the box. You must actively test whether your core tools can isolate and export a single user's data into a CSV or JSON file. You will likely find a massive divergence in capabilities. For example, robust CRM systems like HubSpot feature dedicated GDPR tools that allow administrators to export a specific contact’s entire history into a structured JSON file with a single click. Conversely, many project management and collaboration tools limit single-user exports to basic profile data, strip out metadata like timestamps and activity history, or require enterprise plans and custom API work to extract complete records in a structured format. You must figure out these technical limitations in advance.
• 3. Build a Documented Process: Draft a Standard Operating Procedure (SOP) that outlines exactly how your agency will respond when a request hits. This playbook should define how you verify the individual's identity, who is responsible for running the database extraction scripts, how third-party data is filtered out of the export, and how you will securely transmit the final JSON or CSV file to the requester. To understand how this fits into your broader organizational governance and third-party contract structures, consult our GDPR compliance guide for agencies.

If you need a complete breakdown of managing intake channels, verification steps, and communication workflows across all data subject rights, review our comprehensive DSAR handling guide.

Conclusion

Data portability is a powerful legal right that demands precise technical execution. By understanding the narrow scope of what data qualifies, committing to open formats like JSON or CSV, and proactively testing the export capabilities of your agency's software stack, you can transform a daunting compliance challenge into a routine operational workflow.

To eliminate the manual friction of switching between platforms to fulfill these obligations, Custodia's DSAR module handles portability exports alongside access and deletion requests in a unified workflow. Discover your technical gaps and ensure your agency is fully prepared to execute compliant data exports by taking our free assessment.