Data Portability Under the EU Data Act: What SaaS Must Support

The EU Data Act creates data portability requirements for cloud service providers that go significantly further than GDPR Article 20. Where GDPR portability applies only to personal data provided by the data subject, the Data Act covers all customer data stored in a cloud service — and adds functional equivalence documentation requirements that have no GDPR equivalent.

Data Act Portability vs GDPR Portability

For SaaS companies: if you already comply with GDPR portability for personal data, the Data Act adds requirements for the full data scope (not just personal data) and for the switching ecosystem.

What Data Must Be Portable Under the Data Act

Cloud service providers must support portability for all customer data — data the customer has stored in or generated through use of the cloud service.

This includes:

• Data explicitly uploaded or entered by the customer
• Configurations, settings, and metadata created through use of the service
• Records and logs generated by the customer's use of the platform
• Outputs produced by the service based on customer inputs

Not in scope for portability:

• Data about the customer held by the provider for its own purposes (analytics, billing data beyond what the customer created)
• Aggregated or derived data that constitutes the provider's proprietary output
• Data protected by trade secret (though trade secret claims must be specific)

Format Requirements

Customer data must be provided in a format that enables re-use on another platform. The Data Act requires:

Commonly used and open format: Where an open standard exists for the type of data (e.g., open database formats, standard API schemas, industry-standard exchange formats), the provider should use it.

Interoperable format: Where no open standard exists, the format must be sufficiently documented and standard enough that another provider can import and use the data without needing a proprietary tool.

Not acceptable: Proprietary binary formats without public documentation, formats that require the exporting provider's own software to read, PDFs or other rendered formats for structured data.

For SaaS companies assessing their formats: the test is whether a reasonably competent software team at a competing provider could implement an import of your exported data. If yes, your format likely qualifies.

Functional Equivalence Documentation

This is the requirement most SaaS companies are least prepared for. The Data Act requires cloud providers to maintain documentation that enables customers to understand what is needed to replicate the service's functionality on another platform.

What this means in practice:

For a simple SaaS platform: documentation of the data model, API schema, integration points, and configuration options — sufficient for a new provider to build a compatible import and re-implement the customer's workflows.

For a complex platform with custom logic: documentation of what custom processing the platform applies, what the service's architecture looks like from the customer's perspective, and what technical capabilities a replacement service would need to provide.

This is not about open-sourcing your product. The documentation does not need to reveal your proprietary algorithms or implementation details. It needs to give a customer enough information to evaluate alternative providers and plan a migration.

Switching Process Requirements

When a customer wants to switch cloud providers, the Data Act sets a framework:

Initiation: The customer can initiate a switch through the provider's standard process. The provider cannot require unusual formalities or approval processes that create a barrier.

Transition period: Default is 30 days from the date the switch is initiated. This can be extended by mutual agreement up to a maximum of 180 days for complex migrations.

Continuous service: The provider must maintain the customer's service during the transition period at the contracted service level. Degrading service to discourage switching is prohibited.

Direct transfer: Where technically feasible, the provider must support direct data transfer to the new provider — not requiring the customer to download and re-upload data themselves.

Egress Fee Practical Implications

Egress fees directly affect the cost of portability:

Before September 2027: Providers can charge for the actual cost of data transmission (bandwidth, processing costs at cost-plus-zero margin). They cannot apply a commercial margin to switching egress.

From September 2027: No egress fees for switching data downloads.

For SaaS companies where egress fees are meaningful: this change affects revenue and cost models. Assess the cost of providing full data exports at scale, and ensure this is sustainable before the 2027 deadline. The alternative — continuing to charge profit-margin egress fees after September 2027 — creates direct enforcement exposure.

Implementation Checklist for SaaS Portability

• Identify all data held for customers — not just what they explicitly uploaded, but all customer-associated data
• Assess current export format: does it qualify as "commonly used and open" or "interoperable"?
• Build or confirm full data export capability covering the complete customer dataset
• Assess whether direct provider-to-provider transfer is technically feasible and build if so
• Create functional equivalence documentation: data model, API schema, configuration options
• Review current egress fee policy — adjust to cost-only before September 2025
• Build a switching support process: who handles migration requests, what the steps are, how long it takes
• Update contracts to include switching provisions and remove void lock-in terms