The Right to Data Portability: What It Means for Your SaaS Product

GDPR Article 20 grants every data subject the right to receive their personal data in a structured, commonly used, and machine-readable format - and to transmit that data to another controller without hindrance. For SaaS providers, this is not an abstract legal concept. It is a concrete technical and operational obligation that shapes how you store data, build export tools, and structure customer contracts.

Since the regulation took effect in 2018, enforcement of data subject rights has intensified year on year. The CMS GDPR Enforcement Tracker recorded over 2,245 fines by March 2025, totalling approximately EUR 5.65 billion. And with the EU Data Act becoming fully applicable on 12 September 2025, the portability landscape for SaaS companies has shifted dramatically - introducing mandatory switching rights, interoperability obligations, and a phased ban on exit fees.

What Article 20 Actually Requires

The text of Article 20(1) is deceptively short. It says the data subject has the right to receive personal data they have provided to a controller, in a structured, commonly used, and machine-readable format. Two conditions must be met: the processing is based on consent (Article 6(1)(a)) or a contract (Article 6(1)(b)), and the processing is carried out by automated means.

For most SaaS products, both conditions are met by default. Your users sign up (contract), and virtually everything runs on servers (automated means). The right applies.

Article 20(2) goes further. Where technically feasible, the data subject can request that personal data be transmitted directly from one controller to another. This means controller-to-controller transfer - not just a download link for the user. If a customer asks you to send their data straight to a competing platform, and it is technically possible, you must comply.

There are limits. The right does not extend to data processed for public interest tasks. It must not adversely affect the rights and freedoms of others - so if a data export would expose another user's personal data, you can redact or exclude that information. And critically, it only covers data provided by the data subject, not data you have derived or inferred from their behaviour.

Provided Data vs. Derived Data: Where the Line Falls

The distinction between "provided" and "derived" data is one of the trickiest aspects of data portability for SaaS products. The Article 29 Working Party (now endorsed by the EDPB) interpreted "provided by" broadly in its 2017 Guidelines on the Right to Data Portability. Under this reading, it covers not only data the user actively submitted (form fields, uploaded files, messages) but also data generated through their use of the service - browsing history within the app, transaction logs, activity timestamps.

What it does not cover is data you created about the user through analysis or profiling. A lead score your algorithm assigned, a risk category derived from usage patterns, or an internal tag applied by your support team - these are not portable under Article 20.

Some legal scholars argue the EDPB's broad reading stretches beyond what the GDPR's drafters intended. An IAPP analysis noted that the original legislative intent was to help consumers move data between social networks and cloud storage, not to mandate wholesale migration of complex SaaS datasets. Regardless of the academic debate, the practical advice is clear: if a user typed it, uploaded it, or directly caused it to be recorded, treat it as portable.

The EU Data Act: A Second Layer of Portability for SaaS

GDPR Article 20 was the starting point. The EU Data Act (Regulation (EU) 2023/2854) is the escalation.

Applicable from 12 September 2025, the Data Act introduced mandatory switching rights for providers of "data processing services" - a definition broad enough to capture IaaS, PaaS, and SaaS providers serving EU customers. Unlike Article 20, which focuses on personal data and individual rights, the Data Act addresses the entire customer relationship, including non-personal data, and targets vendor lock-in directly.

The key obligations are significant. Customers can initiate a switch to another provider at any time, with a maximum notice period of two months. SaaS providers must complete the data migration within a 30-day transitional period (extendable to seven months only where technical complexity justifies it). All exportable data and digital assets must be transferred in machine-readable formats. From January 2027, switching and data egress charges must be eliminated entirely.

The extraterritorial reach mirrors the GDPR. A US-based SaaS company serving EU customers falls within scope, even without a European office. And unlike the GDPR's portability right, which depends on individual requests, the Data Act imposes structural obligations - you must build the switching infrastructure regardless of whether anyone has asked to leave yet.

What This Means for Contracts

Fixed-term SaaS agreements are not banned, but they are weakened. The Data Act effectively gives every customer a termination-for-convenience right with two months' notice, triggered through a switching request. Early termination fees are permitted but must be proportionate and transparent. Law firms such as Addleshaw Goddard and Latham & Watkins have described the impact as a "gamechanger" for SaaS contract structures.

For contracts signed on or after 12 September 2025, these rules apply immediately. For pre-existing contracts, compliance is required by 12 September 2027 if the contract is renewed, amended, or is open-ended. Member states are setting their own penalties: France's SREN Law (enforced by the CNIL) allows fines of up to 3% of global annual turnover (5% for repeat offences), while Germany's draft implementation act (under DSGVO enforcement) permits fines of up to 4%.

CCPA/CPRA: Data Portability Across the Atlantic

California's privacy framework includes its own portability provisions, though they work differently from the GDPR model. Under CCPA Section 1798.100(d), a business that receives a verifiable consumer request must deliver personal information free of charge, in a portable and - to the extent technically feasible - readily usable format that allows the consumer to transmit the data to another entity.

The CPRA (which amended the CCPA, effective 2023) strengthened this by explicitly granting consumers the right to request that their personal information be transmitted directly to another business. The practical difference from GDPR is subtle but real: the CCPA treats portability as an extension of the right of access, while the GDPR treats it as a standalone right with its own conditions.

Enforcement in California is accelerating. The California Privacy Protection Agency (CPPA) issued its first significant fine of USD 1.35 million against Tractor Supply in September 2025, and per-violation penalties now stand at USD 2,663 for non-intentional breaches and USD 7,988 for intentional ones (inflation-adjusted as of late 2024). With over 15 US states now having enacted comprehensive privacy laws - many modelled on the CCPA - SaaS providers cannot treat data portability as a Europe-only concern.

Choosing the Right Export Format

Both the GDPR and the CCPA require data to be provided in a "structured, commonly used, and machine-readable format." None of the regulations mandate a specific file type, but the ICO's guidance names three formats as appropriate examples: CSV, JSON, and XML.

The choice depends on the complexity of your data model. CSV works well for flat, tabular data - user lists, transaction histories, simple records. JSON handles nested and relational structures better, making it a natural fit for SaaS products with complex object hierarchies (think project management tools, CRMs, or analytics platforms). XML offers similar structural flexibility but with more verbose syntax and stronger schema validation.

A pragmatic approach for most SaaS products is to offer CSV for simple datasets and JSON for anything with relationships or hierarchy. Avoid proprietary formats entirely - if your export requires a specific application to open, it fails the "commonly used" test. PDF exports, while useful for human reading, do not satisfy the machine-readable requirement on their own.

What About APIs?

The EU Data Act pushes SaaS providers toward offering open, well-documented interfaces (APIs) for data export and interoperability. This goes beyond a "Download My Data" button in settings. If you build a REST API that outputs user data in JSON, you are simultaneously serving portability requests, satisfying the Data Act's interoperability requirements, and making it easier for customers to integrate with other tools.

The Data Transfer Project - an open-source initiative backed by Apple, Google, Meta, and Microsoft - offers a model for how controller-to-controller transfers might work at scale. While adoption among smaller SaaS providers remains limited, the architectural pattern (standardised adapters per data type) is worth studying if you anticipate cross-platform migration requests.

Handling Portability Requests: Timelines and Process

Under GDPR Article 12(3), you must respond to a portability request without undue delay and within one month. Extensions up to three months are permitted for complex requests, but you must inform the data subject of the delay and the reasons within the first month. No fee can be charged for the first request; for manifestly unfounded or excessive requests, a reasonable administrative fee is permissible.

Under the EU Data Act, switching timelines are tighter and more prescriptive. Once a switching request is received, the migration must begin within two months and be completed within 30 days. During this transitional period, you must maintain business continuity and security for the customer's data.

Build a clear internal workflow. Identity verification comes first - confirm the requester is who they claim to be. Then assess the scope: which data falls under Article 20, and which falls outside it? Extract the portable data, format it appropriately, and deliver it securely. Log everything. Article 12(4) requires you to inform the data subject of your reasons if you refuse a request, along with their right to lodge a complaint with a supervisory authority.

The Cookie and Consent Connection

Data portability intersects with cookie compliance in ways that SaaS providers often overlook. If your product collects personal data through cookies - analytics identifiers like _ga, session tokens, or advertising pixels like _fbp - that cookie-derived data may fall within scope of a portability request, depending on how it is processed and on what lawful basis.

Where cookie data is processed based on consent (Article 6(1)(a)), and it qualifies as data "provided by" the user (the EDPB's broad interpretation includes observed data), a portability request could theoretically extend to it. More commonly, the practical overlap is in your consent management setup: the consent preferences a user has recorded - which cookie categories they accepted or rejected, when they gave consent, and whether they later withdrew it - are personal data provided by the user and are squarely portable. For a deeper look at how different cookie categories work, see the Kukie.io blog.

This matters for SaaS products that manage consent on behalf of other websites. If you run a consent management platform, your clients' end users could exercise portability rights over their stored consent logs. Maintaining clean, exportable consent records is both a compliance safeguard and a practical necessity.

Practical Steps for SaaS Providers

Compliance is not a single checkbox. It is a set of architectural and operational decisions that need to be embedded in your product from the start.

Audit your data model. Map every category of personal data your product stores. Classify each as "provided," "observed," or "derived." This mapping drives everything else - what gets exported, what gets excluded, and how you explain the distinction to users who ask why their lead score was not included.

Build self-service export tools. A "Download My Data" feature in your product settings is the minimum. Offer exports in at least two machine-readable formats (JSON and CSV cover most cases). For B2B SaaS with complex data, consider offering a documented export API. The EU Data Act's interoperability requirements make this increasingly necessary, not optional.

Review your contracts. If you serve EU customers, your terms of service need to reflect the Data Act's switching obligations. This includes clear language on the switching process, timelines, data formats, and any known technical limitations. The European Commission is preparing non-binding standard contractual clauses under Article 41 of the Data Act - monitor these and assess how they interact with your existing agreements.

Plan for controller-to-controller transfers. Article 20(2) and the Data Act both anticipate direct transfers between providers. You do not need to build compatible systems with every competitor, but you do need a process for handling transfer requests when they arrive. An API-based export endpoint makes this significantly easier than manual file extraction.

Train your support team. The ICO notes that portability requests can arrive verbally or in writing, to any part of your organisation, and do not need to reference "Article 20" or "data portability" by name. Your frontline staff need to recognise these requests and route them correctly. A user saying "I want to move my data to [competitor]" is a portability request, even if they do not use the legal terminology.

What Happens If You Get It Wrong

Failing to honour a data portability request is a violation of data subject rights under the GDPR, which falls under the higher tier of GDPR penalties: up to EUR 20 million or 4% of global annual turnover, whichever is greater. The CMS Enforcement Tracker Report notes that insufficient fulfilment of data subject rights is among the top five reasons for fines.

The enforcement landscape in 2024 and 2025 has been punishing for technology companies in particular. The Irish DPC fined LinkedIn EUR 310 million for consent violations, Meta received an additional EUR 251 million penalty for a 2018 breach, and the Dutch DPA imposed a EUR 290 million fine on Uber for improper cross-border data transfers. While none of these fines related specifically to data portability, they signal that DPAs are actively scrutinising how technology companies handle data subject rights.

The Dutch DPA has gone further, warning that company leadership could face personal liability for known compliance failures. This aligns with the NIS-2 Directive's emphasis on executive accountability - a trend that SaaS founders and CTOs should take seriously.

Under the EU Data Act, non-compliance with switching obligations carries penalties set at Member State level, but they must be "effective, proportionate and dissuasive." Where personal data is involved, GDPR-level fines can apply in parallel. A SaaS provider that blocks a switching request could face enforcement under both regimes simultaneously.

Portability as a Competitive Advantage

The instinctive reaction to portability obligations is defensive: how do we comply without losing customers? But the smarter SaaS companies are treating portability as a trust signal.

Enterprise buyers increasingly require proof of GDPR and Data Act compliance before signing contracts. A well-documented data export API, transparent switching procedures, and clear contractual terms around portability can accelerate procurement cycles rather than stalling them. DLA Piper's 2025 GDPR survey found that compliance maturity is becoming a competitive differentiator, particularly in sectors where data sensitivity is high.

Portability also reduces the pressure on customer success teams. When users know they can leave easily, they stay because your product is good - not because migration is painful. That shift in dynamic tends to produce healthier retention metrics and more honest product feedback.

Frequently Asked Questions