EU Data Act: What Businesses and DevOps Teams Need to Know

The EU Data Act has been legally binding since September 2025, and most companies are still in the early stages of coming to terms with it. That's not a criticism — it's a reality check. The law is complex, its impact varies widely depending on company size and cloud setup, and many of the concrete technical consequences are buried in the fine print.

This article explains what the EU Data Act actually demands of businesses — without legalese, but without downplaying the rigor of the requirements either. If you operate, use, or develop cloud services, you should understand what's changing.

What the EU Data Act Is and Why It Matters Now

The Data Act is an EU regulation that entered into force in June 2023 and has been fully applicable since September 2025. It complements the Data Governance Act and pursues a clear goal: data should be more accessible, shareable, and portable — between companies, between providers, and between users.

The core idea: whoever generates or holds data shouldn't automatically have exclusive access to it. Whoever uses data should be able to switch providers or take their data with them.

That sounds like data policy. But the specific requirements are deeply technical — and that's exactly why they end up on DevOps teams' desks sooner or later.

What the Data Governance Act Is

The Data Governance Act (DGA) is the "predecessor/framework law" in the European data package. It has been in force since 2022 and primarily establishes rules and structures for how data may be shared — trust, roles, and mechanisms.

In simple terms:

• The DGA creates the framework so that data sharing can work properly (who can mediate, how is trust organized, how are data spaces enabled?).
• The Data Act then specifically requires data to be accessible and portable, and reduces lock-in, particularly with cloud services.

Key building blocks of the DGA:

• Data intermediary services: Neutral "data trustees" that enable data sharing without exploiting the data themselves.
• Data altruism: Rules for how data can be voluntarily made available for public interest purposes (e.g., research).
• European data spaces: A legal/organizational framework for sector-specific data spaces (health, mobility, industry, etc.).

For businesses, the DGA is often less of a "DevOps backlog item" than the Data Act, but it's the strategic umbrella: it shows that the EU is institutionalizing data sharing, which means more requirements (and opportunities) around interoperability, governance, and portability in the long run. In our dedicated guide to the Data Governance Act, we cover what the DGA means for DevOps teams. Our article on cloud sovereignty governance covers the broader governance implications.

Scope: Who Does the Data Act Affect?

The Data Act affects three groups:

1. Manufacturers of connected products — IoT devices, machines, vehicles, any device that generates data
2. Cloud and data service providers — SaaS, PaaS, IaaS
3. Data holders in B2B contexts — companies that hold data from connected products or services and must make it available to others

If none of these apply to you, the core regulation affects you less directly. But: almost every company that uses cloud services is indirectly affected as a customer, because the provider must meet the switching requirements.

The Three Core Obligations Businesses Need to Know

The Data Act can be broken down into three central requirements:

1. Data access: Users of connected products and services must have access to the data they generate — in real time, without disproportionate barriers.

2. Data portability: Data must be exportable in a structured, machine-readable format. This applies not only to personal data under GDPR, but also to usage, operational, and machine data.

3. Provider switching: Cloud providers must actively enable customers to switch to another provider — both technically and contractually.

Provider Switching Must Be Technically Possible

The Data Act requires cloud providers to facilitate switching to another provider. That sounds abstract, but the implications are very concrete:

• Export interfaces must exist and be documented
• Data formats must be portable — no exclusive proprietary formats without a migration path
• Contractual lock-in clauses that hinder switching must be limited
• The switching process itself must be technically supported

For DevOps teams, this means: if you offer or operate cloud services, you need to ensure that customer data is exportable. Not as a workaround, but as a documented, testable process.

The End of Egress Fees

One point that's particularly relevant in practice: the Data Act provides for data export fees (so-called egress fees) to be phased out gradually. By September 2027, they should be eliminated entirely. In our article on cloud egress fees, we took a deeper look at this topic.

This is a direct response to a common practice: hyperscalers have historically made data exports expensive — not because it's technically necessary, but because it discourages customers from switching. AWS, for example, charges per GB of outgoing traffic. If you hold large amounts of data in the cloud, you pay when switching — or with every data use outside the provider.

From 2027 onwards, this is no longer tenable under EU regulation.

EU Data Act and DevOps: What Changes in Practice

Compliance requirements are often stated abstractly. That's why it makes sense to translate them into concrete technical decisions.

API design: If you develop services that hold or process data, check whether your export APIs are documented, stable, and machine-readable. Not as an afterthought, but as part of the service design.

Infrastructure as Code: When infrastructure is described through IaC tools like Terraform or Helm, switching is fundamentally easier — provided you don't rely on provider-specific resource types without alternatives. Kubernetes-native workloads have an advantage here.

Data pipelines: Where is data stored, in what format, and how can it be extracted? These are questions that will be asked in a Data Act audit — and ones you should have answered during the design phase.

Documentation: Compliance doesn't just mean being technically compliant — it means being able to prove it. Which data is stored where, who has access, and how does the export process work? This must be documented and verifiable.

Interoperability as a Technical Requirement

The Data Act explicitly requires data services to be interoperable. In concrete terms: interfaces should be based on open standards — no proprietary protocols without a documented alternative.

For the cloud world, this is an interesting signal. If you use Kubernetes, S3-compatible storage APIs, and avoid proprietary managed services, you're in a better regulatory position — not because you had regulation in mind, but because open standards simply make more technical sense.

Gaia-X-compliant platforms and Kubernetes-based solutions have structural advantages here over solutions that rely heavily on proprietary APIs.

Hyperscalers vs. Open Platforms: Who Has the Upper Hand?

This is one of the more interesting questions around the Data Act — and the answer isn't straightforward.

Hyperscalers like AWS, Azure, and GCP have the resources to implement compliance requirements. They will. But their starting position is complicated: their architecture is historically designed for customer retention. Proprietary services, deep integrations, egress fees — that's not an accident, it's strategically designed vendor lock-in.

The Data Act forces them to dismantle some of these barriers. Whether this actually leads to more portability or whether lock-in mechanisms simply shift elsewhere remains to be seen.

Open platforms — those built on Kubernetes, open storage standards, and documented APIs — have a different starting point. They aren't designed for lock-in by default. That makes compliance easier because the technical foundation is a better fit.

For companies choosing or switching providers, this is a real decision factor: with which provider is Data Act-compliant infrastructure easier to implement?

What Companies Should Do Now

No company needs to restructure everything immediately. But some things should be addressed now:

Audit your data holdings: What data is stored where, in what format, and who has access? This is the foundation for everything else.

Check export capability: Can customer data be exported from your systems in a format that can be reused? If not: that's a concrete risk.

Contract review: Cloud contracts should be checked for lock-in clauses. Existing contracts may need to be adjusted before deadlines expire.

API documentation: If you offer services, make sure export and interoperability APIs are documented and testable.

Clarify internal responsibilities: Data Act compliance isn't purely a legal task. It has a strong technical component. DevOps teams should be involved in the assessment.

The Data Act isn't GDPR 2.0. It's more technical, more focused on cloud and connected systems, and it hits companies at a different point in their infrastructure. Those who understand this early can approach compliance as a design challenge rather than a box-ticking exercise.

lowcloud is a Kubernetes DevOps-as-a-Service platform built on open standards — no proprietary dependencies, with S3-compatible storage and documented APIs. For companies looking to run Data Act-compliant infrastructure, it's a solid starting point.