Overview

The EU Data Act treats interoperability as both exchanging and using data, so a complete cloud exit must test more than file movement. This chapter separates transport, syntax, semantics, behaviour, policy, data portability, and application portability, then connects those layers to open specifications, harmonised standards, and the Union standards repository. It also distinguishes one-off switching from in-parallel use, where continuous data flow, coordination, and cost remain. Standards can reduce known mismatches, but they do not decide business meaning, transfer protected technology, or prove a destination works.

Learning outcomes

A destination can parse every exported byte and still fail because fields, behaviour, access rules, or application instructions mean or operate differently.
Interoperability has layered evidence: transport and syntax precede semantics, behaviour, policy, and relevant application portability.
In-parallel use is not a completed switch: it can support resilience, but continuous transfer, coordination, and egress costs create an ongoing dependency.

Keywords

EU Data Actinteroperabilitystandardssemanticsbehaviouregress

Standards Are Part of the Exit Path

This chapter examines the EU Data Act's idea of interoperability and its effect on cloud exit. It asks why a structured export can still fail in a destination, how the Union standards repository is meant to improve that situation, and why using two clouds at once is not the same as switching. The practical result is an interoperability test matrix that follows meaning, behaviour, policy, and cost—not just the movement of files.

A file can match while the service still fails

The Data Act treats interoperability as the ability of systems, applications, data-processing services, or components to exchange and use data in order to perform their functions. That definition has two verbs. Exchange is necessary, but use is the outcome that matters. A destination can receive every byte and still be unable to perform the function for which the customer moved the workload.

Article 35 reflects that distinction by describing several layers of interoperability and portability. At the infrastructure and service boundary, transport asks whether data can travel between environments. Syntactic interoperability asks whether the receiving system can parse the structure. Semantic interoperability asks whether the same fields, codes, units, and relationships carry the same meaning. Behavioural interoperability asks whether the systems respond in a compatible way. Policy interoperability asks whether the rules governing access, use, and other constraints can operate across the boundary.

The layers are sequential but not interchangeable. If data cannot be transported, later tests cannot begin. If it can be transported but not parsed, the destination cannot inspect it. If it can be parsed but the status codes or timestamps mean something different, a technically successful import can produce a business error. If the data mean the same thing but retries, ordering, or failure responses differ, the application may behave differently under load or during recovery. If the service works but its access and use policies do not transfer, the customer may have preserved data while losing the required control model.

The Regulation also separates cloud data portability from cloud application portability. Data portability includes syntactic, semantic, and policy dimensions. Application portability adds syntax, instructions, metadata, behaviour, and policy. This is why an export format is only one component of an exit path. The application may depend on instructions that describe how to use a service, metadata that describes its configuration, behaviour that users experience, and policies that determine who may act on the result.

flowchart LR T["Transport: can the material move?"] --> S["Syntax: can the destination parse it?"] S --> M["Data semantics: does it mean the same thing?"] M --> B["Behaviour: do shared inputs produce comparable results?"] B --> P["Policy: do access and use rules still work?"] P --> A["Application portability: instructions, metadata, behaviour"] R["Union standards repository"] --> V["Customer acceptance tests"] A --> V M --> V B --> V P --> V

Consider a managed order service. A customer may export order records in a format that the destination can parse.

Published by DeepMox

FAQ

What does interoperability mean for cloud exit under the EU Data Act?

Under the EU Data Act, interoperability means that systems, applications, services, or components can exchange and use data to perform their functions, not merely transfer files. The relevant evidence can include transport, syntax, semantics, behaviour, policy, and application portability.

What is the Union standards repository used for in cloud interoperability?

The Union standards repository publishes references to applicable harmonised standards and common specifications for data-processing-service interoperability, making expectations discoverable by service type. Its contents can evolve, so customers should record the reference and publication date rather than assume a desired standard already governs the service.

How do switching charges differ from in-parallel cloud egress costs?

Switching charges concern the one-off process of leaving, while in-parallel use can carry egress charges limited to the provider's incurred egress costs. Until 12 January 2027, reduced switching charges are capped at directly incurred costs; from that date, switching charges for switching may not be imposed.

Previous11 minEU Data Act IaaS, PaaS, and SaaS Switching

Next14 minEU Data Act Operational Exit Readiness

EU Data Act Interoperability and Standards

Standards Are Part of the Exit Path

A file can match while the service still fails

FAQ