Data Act: Portability and Exit Capability Become Mandatory from September 2025

TL;DR

• The Data Act comes into effect on September 12, 2025, making data portability, cloud switching, and interoperability mandatory requirements – with clear rights for users and obligations for providers.
• The six core objectives range from IoT data access rights to B2B/B2G data access, cloud switching, interoperability, and protection against third-country access – aiming for fair competition instead of vendor lock-in.
• For cloud switching, open APIs, transparent egress rules, and functional equivalence are mandatory. Organizations need exit strategies with clear runbooks, responsibilities, and tested processes.
• Interoperability standards like ISO/IEC 19941 and the EU Cloud Rulebook offer a technical compass for multi-cloud architectures and prevent isolated solutions.
• ayedo supports you with API-first platform design, standardized exit runbooks, and multi-cloud architectures to pragmatically implement Data Act requirements and leverage portability as a competitive advantage.

Data Act: Portability and Exit Capability Become Plannable

The Data Act (Regulation (EU) 2023/2854) is more than just another compliance project. It is an infrastructure law for the European data and cloud market.

On September 12, 2025, the regulation begins to apply. From this point, harmonized rules apply to:

• Access to data from connected products (IoT),
• Fair B2B and B2G data access,
• Cloud switching and interoperability,
• Protection against unlawful third-country access.

For you as a technical leader, this means: Exit capability, portability, and interoperability are no longer “nice to have” but a manageable obligation – and thus an opportunity to make architectures more robust and negotiation-strong.

Overview of the Six Core Objectives of the Data Act

1. IoT Data Access Rights

Users of connected products and services – whether companies or consumers – receive a clear right to access the data generated through use.

Key points:

• Data from IoT products must be provided promptly, free of charge, and in common, machine-readable formats.
• In addition to raw data, pre-processed data and relevant metadata must also be delivered.
• Manufacturers and service providers must consider these access rights “by design,” i.e., plan them into product and platform architectures.

For engineering leaders, this means: Telemetry and event streams no longer belong exclusively to the platform – the ability to make them externally accessible and portable becomes a legal obligation.

2. B2B Data Access According to FRAND Principles

Data holders must provide data to third parties at the user’s request – under fair, reasonable, and non-discriminatory (FRAND) conditions.

Important aspects:

• The quality and scope of the provided data must match those used by the data holder themselves (quality parity).
• Clear purpose limitation: Data may only be used for the purpose defined by the user.
• No dark patterns or hidden restrictions that effectively undermine data access.

This shifts the focus from exclusive data silos to data ecosystems, where interoperability and clean interfaces also become economically relevant.

3. B2G Data Access in Cases of “Exceptional Need”

Public authorities, the EU, and certain Union bodies receive access to data from private actors in exceptional cases, such as:

• Natural disasters,
• Large-scale cyber incidents,
• Pandemics or other exceptional need situations.

This access is strictly purpose-bound, time-limited, and subject to requirements for anonymization, documentation, and deletion.

Organizationally, this means: You should be able to provide data access for authorities in a traceable, controlled, and audit-proof manner – without having to rebuild your entire infrastructure ad hoc.

4. Cloud Switching Without Artificial Barriers

A core area of the Data Act is the systematic reduction of vendor lock-in in cloud and edge services.

Provider obligations:

• Enabling a switch to other cloud or edge providers (or back on-prem) including data, applications, and configurations.
• Open, documented interfaces and machine-readable formats.
• Transparent information on switching processes, risks, and costs already before contract conclusion.

This creates a legally secured right to switch for customers – including the gradual reduction of egress fees.

5. Interoperability & Standards

The EU Commission can define harmonized standards and common specifications for data spaces and cloud interoperability. Relevant references include:

• ISO/IEC 19941 (Interoperability and portability for cloud computing services)
• EU Cloud Rulebook as a guide for uniform interoperability and security requirements.

The goal is that multi-cloud and multi-vendor scenarios do not rely on individual contracts and integrations but on standardized interfaces and formats.

6. Protection Against Unlawful Third-Country Access

Providers must protect non-personal data from unlawful access by third countries.

This includes:

• Technical measures such as encryption and key management,
• Contractual commitments and audits,
• Processes to challenge unlawful requests and inform customers.

Again, compliance is an architectural issue. Those who think early about data location, tenant separation, and encryption not only meet the Data Act but also improve the overall security posture.

Cloud Switching in Detail: Open APIs, Egress Fee Regulation, Functional Equivalence

Cloud switching is one of the most immediately noticeable areas for your infrastructure. The Data Act specifies several technical and organizational requirements here.

Open and Documented APIs

Providers must offer open, well-documented interfaces that:

• Automate the export of data, metadata, configurations, and – where possible – applications,
• Adhere to established open specifications (e.g., for object storage, container images, network and storage interfaces, API definitions),
• Do not primarily rely on proprietary formats that only work within a provider ecosystem.

For you, this means: When evaluating cloud or platform offerings, API design, documentation, and adherence to standards should explicitly be part of the selection process – not just price and feature list.

Egress Fee Regulation

The Data Act requires providers to gradually reduce fees for data egress:

• During a transition phase, egress fees are only allowed to a limited extent and must be transparent.
• No later than three years after the Data Act comes into effect, egress fees for switching scenarios must be reduced to 0 euros.

This removes a central economic lever from the hands of providers and strengthens your negotiating position. At the same time, it is worthwhile for you to prepare switching capability not only legally but also technically so that a switch is practical.

Functional Equivalence, Especially for IaaS

Providers must support “functional equivalence” when switching between cloud infrastructures – at least at the IaaS level.

Specifically, this means:

• Infrastructure functionalities such as compute, network, storage, and basic security mechanisms should be usable in a target environment with reasonable effort.
• Providers must not effectively bind customers to a provider through proprietary dependencies in platform or SaaS components.
• Test or parallel operation scenarios must be possible so that you can verify the target environment before the final cut-over occurs.

For your architectural decisions, this is a strong argument to consistently rely on portable base components and consciously frame provider-specific “magic.”

Exit Strategies in Practice: Runbooks and Switching Processes

Exit capability does not arise automatically just because the legislator demands it. It is the result of architectural decisions, processes, and lived governance.

Principles of a Robust Exit Strategy

A viable exit strategy should cover at least these points:

• Clearly defined triggers for a switch (e.g., cost, quality, risk, compliance).
• Technical prerequisites (data formats, API availability, infrastructure abstraction).
• Organizational responsibilities and decision paths.
• Timely and phased processes with test stages.

Runbooks as a Central Working Tool

Runbooks translate the strategy into concrete, repeatable steps. For Data Act-compliant exits, the following are particularly important:

• Runbooks for data export: Which data domains, in which formats, with which tools?
• Runbooks for application migration: Container images, artifacts, dependencies, secrets, and policies.
• Runbooks for configuration and infrastructure portability: IaC artifacts, network layouts, identity, and access structures.
• Runbooks for rollback and parallel operation if the switch occurs in stages.

It is essential that these runbooks not only exist but are regularly practiced – for example, in the form of “exit drills” similar to disaster recovery tests.

Phases of a Switching Process

In practice, multi-stage switching processes have proven effective:

1. Assessment
   Inventory of workloads, data, dependencies, and regulatory requirements.

2. Design & Prototyping
   Define target architecture, migrate pilot workloads, verify functional equivalence.

3. Parallel Operation & Data Reconciliation
   Synchronize data streams, validate performance, security, and compliance in the target environment.

4. Cut-over & Stabilization
   Switch over production loads, closely monitor, iteratively improve runbooks.

5. Decommissioning & Final Documentation
   Shut down the old environment, fulfill contractual and regulatory requirements (e.g., data deletion, evidence).

With such a structured approach, cloud switching becomes a manageable standard process rather than a risk.

Interoperability Standards: ISO/IEC 19941 and EU Cloud Rulebook

Standards are the bridge between legal requirements and technical implementation.

ISO/IEC 19941: Interoperability and Portability for Cloud Services

The ISO/IEC 19941 standard addresses interoperability and portability of cloud services along several dimensions:

• Data Portability: Formats, metadata, semantics.
• Application Portability: Runtime environments, dependencies, deployment models.
• Service Interoperability: APIs, interfaces, identity, and access models.

For you, the standard is primarily a reference framework: It shows where interoperability must be systematically considered to sustainably meet Data Act requirements.

EU Cloud Rulebook: Guidance for the European Market

The EU Cloud Rulebook consolidates requirements and best practices around:

• Security and compliance requirements,
• Interoperability and data portability,
• Contractual and transparency obligations.

It is less a technical specification than an interpretative framework that providers and customers can orient themselves by. Those who align their platform strategy with it reduce the risk of having to make fundamental changes again in a few years.

Technical Implementation with ayedo: API-First, Exit Runbooks, Multi-Cloud

How these requirements become an actionable operation