Data Act: Portabilität und Exit-Fähigkeit werden Pflicht ab September 2025

TL;DR

• Der Data Act tritt am 12. September 2025 in Kraft und macht Datenportabilität, Cloud-Switching und Interoperabilität zu verbindlichen Anforderungen – mit klaren Rechten für Nutzer und Pflichten für Provider.
• Die sechs Kernziele reichen von IoT-Datenzugangsrechten über B2B/B2G-Datenzugang bis hin zu Cloud-Switching, Interoperabilität und Schutz vor Drittlandszugriffen – und zielen auf fairen Wettbewerb statt Vendor-Lock-in.
• Für Cloud-Switching werden offene APIs, transparente Egress-Regeln und funktionale Äquivalenz Pflicht. Organisationen brauchen Exit-Strategien mit klaren Runbooks, Verantwortlichkeiten und getesteten Prozessen.
• Interoperabilitätsstandards wie ISO/IEC 19941 und das EU Cloud Rulebook bieten einen technischen Kompass für Multi-Cloud-Architekturen und verhindern Insellösungen.
• ayedo unterstützt Sie mit API-first-Plattformdesign, standardisierten Exit-Runbooks und Multi-Cloud-Architekturen dabei, Data-Act-Anforderungen pragmatisch umzusetzen und Portabilität als Wettbewerbsvorteil zu nutzen.

---

Data Act: Portabilität und Exit-Fähigkeit werden planbar

Der Data Act (Verordnung (EU) 2023/2854) ist mehr als ein weiteres Compliance-Projekt. Er ist ein Infrastrukturgesetz für den europäischen Daten- und Cloud-Markt.

Am 12. September 2025 beginnt die Anwendung der Verordnung. Ab diesem Zeitpunkt gelten harmonisierte Regeln für:

• Zugang zu Daten aus verbundenen Produkten (IoT),
• fairen B2B- und B2G-Datenzugang,
• Cloud-Switching und Interoperabilität,
• Schutz vor unrechtmäßigem Drittlandszugriff.

Für Sie als technisch verantwortliche Person bedeutet das: Exit-Fähigkeit, Portabilität und Interoperabilität sind nicht mehr „nice to have“, sondern eine gestaltbare Pflicht – und damit eine Chance, Architekturen robuster und verhandlungsstärker zu machen.

---

Die sechs Kernziele des Data Act im Überblick

1. IoT-Datenzugangsrechte

Nutzer von verbundenen Produkten und Services – egal ob Unternehmen oder Verbraucher – erhalten ein klares Recht auf Zugang zu den durch Nutzung entstehenden Daten.

Kernpunkte:

• Daten aus IoT-Produkten müssen zeitnah, kostenfrei und in gängigen, maschinenlesbaren Formaten bereitgestellt werden.
• Neben Rohdaten sind auch vorverarbeitete Daten und relevante Metadaten zu liefern.
• Hersteller und Serviceprovider müssen diese Zugangsrechte „by design“ berücksichtigen, also schon in Produkt- und Plattformarchitekturen einplanen.

Für Engineering-Verantwortliche heißt das: Telemetrie- und Event-Ströme gehören nicht mehr exklusiv der Plattform – die Fähigkeit, sie extern zugänglich und portabel zu machen, wird rechtliche Pflicht.

2. B2B-Datenzugang nach FRAND-Prinzipien

Datenhalter müssen auf Wunsch des Nutzers Daten an Dritte weitergeben – unter fairen, angemessenen und nichtdiskriminierenden (FRAND) Bedingungen.

Wichtige Aspekte:

• Qualität und Umfang der bereitgestellten Daten müssen denen entsprechen, die der Datenhalter selbst nutzt (Qualitätsparität).
• Klare Zweckbindung: Daten dürfen nur für den vom Nutzer definierten Zweck verwendet werden.
• Keine Dark Patterns oder versteckte Einschränkungen, die den Datenzugang praktisch aushebeln.

Damit verschiebt sich der Fokus von exklusiven Daten-Silos hin zu Datenökosystemen, in denen Interoperabilität und saubere Schnittstellen auch wirtschaftlich relevant werden.

3. B2G-Datenzugang bei „Exceptional Need“

Öffentliche Stellen, die EU und bestimmte Unionsorgane erhalten in Ausnahmefällen Zugang zu Daten privater Akteure, etwa bei:

• Naturkatastrophen,
• großflächigen Cyber-Incidents,
• Pandemien oder anderen außergewöhnlichen Bedarfssituationen.

Dieser Zugang ist streng zweckgebunden, zeitlich limitiert und an Vorgaben zu Anonymisierung, Dokumentation und Löschung geknüpft.

Organisatorisch bedeutet das: Sie sollten in der Lage sein, Datenzugriffe für Behörden nachvollziehbar, kontrolliert und revisionssicher bereitzustellen – ohne Ihre gesamte Infrastruktur ad hoc umbauen zu müssen.

4. Cloud-Switching ohne künstliche Hürden

Ein Kernbereich des Data Act ist die systematische Reduktion von Vendor-Lock-in bei Cloud- und Edge-Services.

Pflichten für Provider:

• Ermöglichung eines Wechsels zu anderen Cloud- oder Edge-Providern (oder zurück On-Prem) inklusive Daten, Anwendungen und Konfigurationen.
• Offene, dokumentierte Schnittstellen und maschinenlesbare Formate.
• Transparente Informationen zu Switching-Prozessen, Risiken und Kosten bereits vor Vertragsschluss.

Für Kunden wird damit ein rechtlich abgesichertes Wechselrecht geschaffen – inkl. schrittweisem Abbau von Egress-Gebühren.

5. Interoperabilität & Standards

Die EU-Kommission kann harmonisierte Normen und Common Specifications für Datenräume und Cloud-Interoperabilität definieren. Relevante Referenzen sind unter anderem:

• ISO/IEC 19941 (Interoperability and portability for cloud computing services)
• EU Cloud Rulebook als Orientierung für einheitliche Interoperabilitäts- und Sicherheitsanforderungen.

Ziel ist, dass Multi-Cloud- und Multi-Vendor-Szenarien nicht auf Einzelverträgen und individuellen Integrationen beruhen, sondern auf standardisierten Schnittstellen und Formaten.

6. Schutz vor unrechtmäßigem Drittlandszugriff

Provider müssen nicht-personenbezogene Daten vor unrechtmäßigen Zugriffen aus Drittstaaten schützen.

Dazu gehören:

• technische Maßnahmen wie Verschlüsselung und Schlüsselverwaltung,
• vertragliche Zusagen und Audits,
• Prozesse, um unrechtmäßige Anfragen anzufechten und Kunden zu informieren.

Auch hier gilt: Compliance ist ein Architekturthema. Wer früh über Datenlokation, Mandantentrennung und Verschlüsselung nachdenkt, erfüllt nicht nur den Data Act, sondern verbessert die Sicherheitsposition insgesamt.

---

Cloud-Switching im Detail: Offene APIs, Egress-Fee-Regelung, funktionale Äquivalenz

Cloud-Switching ist einer der unmittelbar spürbaren Bereiche für Ihre Infrastruktur. Der Data Act konkretisiert hier mehrere technische und organisatorische Anforderungen.

Offene und dokumentierte APIs

Provider müssen offene, gut dokumentierte Schnittstellen anbieten, die:

• Export von Daten, Metadaten, Konfigurationen und – soweit möglich – Applikationen automatisierbar machen,
• sich an etablierten offenen Spezifikationen orientieren (z. B. für Object Storage, Container-Images, Netzwerk- und Storage-Interfaces, API-Definitionen),
• nicht primär auf proprietäre Formate setzen, die nur in einem Anbieterökosystem funktionieren.

Für Sie heißt das: Bei der Bewertung von Cloud- oder Plattformangeboten sollten API-Design, Dokumentation und die Orientierung an Standards explizit in den Auswahlprozess einfließen – nicht nur Preis und Feature-Liste.

Egress-Fee-Regelung

Der Data Act verpflichtet Provider, Gebühren für Datenausgang (Egress) schrittweise abzubauen:

• Während einer Übergangsphase sind Egress-Gebühren nur noch begrenzt zulässig und müssen transparent sein.
• Spätestens drei Jahre nach Anwendungsbeginn des Data Act müssen Egress-Gebühren für Switching-Szenarien auf 0 Euro reduziert werden.

Das nimmt einen zentralen wirtschaftlichen Hebel aus der Hand der Provider und stärkt Ihre Verhandlungsposition. Gleichzeitig lohnt sich für Sie, Switching-Fähigkeit nicht nur juristisch, sondern technisch so vorzubereiten, dass ein Wechsel praktikabel ist.

Funktionale Äquivalenz, insbesondere für IaaS

Provider müssen „funktionale Äquivalenz“ beim Wechsel zwischen Cloud-Infrastrukturen unterstützen – mindestens auf IaaS-Ebene.

Konkret bedeutet das:

• Infrastruktur-Funktionalitäten wie Compute, Network, Storage und grundlegende Security-Mechanismen sollen mit vertretbarem Aufwand in einer Zielumgebung nutzbar sein.
• Provider dürfen Kunden nicht durch proprietäre Abhängigkeiten in Plattform- oder SaaS-Komponenten faktisch an einen Anbieter binden.
• Test- bzw. Parallelbetriebs-Szenarien müssen möglich sein, damit Sie die Zielumgebung verifizieren können, bevor der endgültige Cut-over erfolgt.

Für Ihre Architekturentscheidungen ist das ein starkes Argument, konsequent auf portierbare Basiskomponenten zu setzen und Provider-spezifische „Magie“ bewusst einzurahmen.

---

Exit-Strategien in der Praxis: Runbooks und Switching-Prozesse

Exit-Fähigkeit entsteht nicht automatisch, nur weil der Gesetzgeber sie verlangt. Sie ist das Ergebnis von Architekturentscheidungen, Prozessen und gelebter Governance.

Prinzipien einer belastbaren Exit-Strategie

Eine tragfähige Exit-Strategie sollte mindestens diese Punkte abdecken:

• Klar definierte Trigger für einen Wechsel (z. B. Kosten, Qualität, Risiko, Compliance).
• Technische Voraussetzungen (Datenformate, API-Verfügbarkeit, Infrastrukturabstraktion).
• Organisatorische Zuständigkeiten und Entscheidungswege.
• Zeitlich und in Phasen planbare Abläufe mit Teststufen.

Runbooks als zentrales Arbeitsinstrument

Runbooks übersetzen die Strategie in konkrete, wiederholbare Schritte. Für Data-Act-konforme Exits sind insbesondere wichtig:

• Runbooks für Datenexport: Welche Datendomänen, in welchen Formaten, mit welchen Tools?
• Runbooks für Applikations-Migration: Container-Images, Artefakte, Abhängigkeiten, Secrets und Policies.
• Runbooks für Konfigurations- und Infrastrukturportabilität: IaC-Artefakte, Netzwerk-Layouts, Identitäts- und Zugriffsstrukturen.
• Runbooks für Rollback und Parallelbetrieb, falls der Wechsel gestaffelt erfolgt.

Wesentlich ist, dass diese Runbooks nicht nur existieren, sondern regelmäßig geübt werden – etwa in Form von „Exit-Drills“ ähnlich zu Disaster-Recovery-Tests.

Phasen eines Switching-Prozesses

Praktisch haben sich mehrstufige Switching-Prozesse bewährt:

1. Assessment
   Bestandsaufnahme von Workloads, Daten, Abhängigkeiten und regulatorischen Anforderungen.

2. Design & Prototyping
   Zielarchitektur definieren, Pilot-Workloads migrieren, funktionale Äquivalenz verifizieren.

3. Parallelbetrieb & Datenabgleich
   Synchronisation von Datenströmen, Validierung von Performance, Security und Compliance in der Zielumgebung.

4. Cut-over & Stabilisierung
   Umschalten von Produktivlasten, Monitoring eng verfolgen, Runbooks iterativ verbessern.

5. Decommissioning & Abschlussdokumentation
   Abschaltung der Altumgebung, vertragliche und regulatorische Anforderungen (z. B. Datenlöschung, Nachweise) erfüllen.

Mit einem solchen strukturierten Vorgehen wird Cloud-Switching von einem Risiko zu einem gestaltbaren Standardprozess.

---

Interoperabilitätsstandards: ISO/IEC 19941 und EU Cloud Rulebook

Standards sind die Brücke zwischen rechtlichen Anforderungen und technischer Umsetzung.

ISO/IEC 19941: Interoperability and portability for cloud services

Die Norm ISO/IEC 19941 adressiert Interoperabilität und Portabilität von Cloud-Services entlang mehrerer Dimensionen:

• Datenportabilität: Formate, Metadaten, Semantik.
• Anwendungsportabilität: Laufzeitumgebungen, Abhängigkeiten, Deployment-Modelle.
• Service-Interoperabilität: APIs, Schnittstellen, Identitäts- und Zugriffsmodelle.

Für Sie ist die Norm vor allem ein Referenzrahmen: Sie zeigt, an welchen Stellen Interoperabilität systematisch bedacht werden muss, um Data-Act-Anforderungen nachhaltig zu erfüllen.

EU Cloud Rulebook: Orientierung für den europäischen Markt

Das EU Cloud Rulebook bündelt Anforderungen und Best Practices rund um:

• Sicherheits- und Compliance-Anforderungen,
• Interoperabilität und Datenportabilität,
• Vertrags- und Transparenzpflichten.

Es ist weniger eine technische Spezifikation als ein Interpretationsrahmen, an dem sich Anbieter und Kunden orientieren können. Wer seine Plattformstrategie daran ausrichtet, reduziert das Risiko, in ein paar Jahren erneut grundlegende Umbauten vornehmen zu müssen.

---

Technische Umsetzung mit ayedo: API-First, Exit-Runbooks, Multi-Cloud

Wie wird aus diesen Anforderungen ein umsetzbares Betriebsmodell? Drei technische Prinzipien haben sich in Projekten mit ayedo bewährt.

API-First über die gesamte Plattform

API-First bedeutet:

• Jede zentrale Funktionalität der Plattform – von Provisionierung über Observability bis hin zu Datenexporten – ist über klare, dokumentierte APIs zugänglich.
• Diese APIs orientieren sich, wo möglich, an offenen Standards und verbreiteten Ökosystemen (z. B. CNCF-Stack, offene Storage- und Netzwerkinterfaces).
• Export- und Importpfade werden von Anfang an mitgedacht, statt erst im Exit-Fall improvisiert.

Damit entsteht die Basis, um Data-Act-konforme Switching-Prozesse nicht nur theoretisch zu beschreiben, sondern automatisiert auszuführen.

Multi-Cloud-Architektur als Normalfall

Anstatt eine einzelne Zielplattform zu privilegieren, setzt ayedo auf Architekturen, die:

• Workloads auf mehreren Infrastrukturen (Hyperscaler, europäische Provider, On-Prem) betreiben können,
• zentrale Funktionen (CI/CD, Observability, Policy-Management) so abstrahieren, dass sie providerunabhängig nutzbar bleiben,
• Datenlokation und -flüsse transparent machen, um Anforderungen aus Data Act, DSGVO und branchenspezifischen Regelungen gleichzeitig zu adressieren.

Multi-Cloud wird damit nicht zum Selbstzweck, sondern zum Mittel, Portabilität und Resilienz greifbar zu machen.

Standardisierte Exit-Runbooks und Governance

Auf Basis dieser Architektur erstellt ayedo mit Kunden:

• standardisierte Exit-Runbooks für unterschiedliche Szenarien (Providerwechsel, Repatriierung, Carve-outs),
• Governance-Modelle, in denen Verantwortlichkeiten, Entscheidungswege und Testzyklen für Exits klar verankert sind,
• Metriken und SLOs, die nicht nur Verfügbarkeit und Performance, sondern auch Exit-Fähigkeit und Portabilität messbar machen.

So wird der Data Act zu einem Treiber für professionelles Plattform-Engineering – und nicht zu einer bloß juristischen Checkliste.

---

Häufige Fragen

Gilt der Data Act für meine bestehende Cloud-Infrastruktur oder nur für neue Verträge?

Der Data Act gilt grundsätzlich ab dem 12. September 2025 für alle betroffenen Dienste und Vertragsverhältnisse – unabhängig davon, wann diese ursprünglich geschlossen wurden.

Allerdings wird es Übergangsphasen geben, insbesondere bei der vollständigen Abschaffung von Egress-Gebühren für Switching-Szenarien. Für Sie ist entscheidend, frühzeitig zu prüfen:

• Welche bestehenden Verträge enthalten Regelungen, die mit dem Data Act kollidieren könnten?
• Welche technischen Abhängigkeiten erschweren heute einen Wechsel und sollten mittelfristig abgebaut werden?

Je früher Sie diese Analyse starten, desto größer ist Ihr Handlungsspielraum – vertraglich und technisch.

Wie detailliert müssen Exit-Runbooks dokumentiert sein?

Der Data Act schreibt keine bestimmte Seitenzahl vor, fordert aber nachvollziehbare und praktikable Switching-Prozesse. In der Praxis sollten Exit-Runbooks:

• die relevanten Systeme, Datendomänen und Abhängigkeiten klar benennen,
• Schnittstellen, Formate und Tools beschreiben, die für Export und Import genutzt werden,
• Rollen, Verantwortlichkeiten und Kommunikationswege definieren,
• Test- und Validierungsschritte enthalten, um Risiken zu minimieren.

Die Dokumentation muss so konkret sein, dass sie im Ernstfall als Arbeitsgrundlage taugt – nicht nur als formaler Nachweis. Viele Organisationen verbinden Exit-Runbooks daher mit ihren Disaster-Recovery- und Business-Continuity-Prozessen.

Wie unterstützt ayedo konkret bei Data-Act-Compliance im Kontext von Cloud-Switching?

ayedo unterstützt an drei Stellen:

1. Assessment & Architekturdesign
   Analyse Ihrer bestehenden Plattformlandschaft, Identifikation von Lock-in-Risiken und Design einer Zielarchitektur, die Data-Act-Anforderungen (Portabilität, Interoperabilität, Drittlandszugriff) strukturell berücksichtigt.

2. Implementierung von API-first- und Multi-Cloud-Patterns
   Aufbau oder Weiterentwicklung Ihrer Plattform – etwa auf Basis von Kubernetes – mit klaren APIs, standardisierten Deployments und abstrahierten Infrastrukturkomponenten, die Switching technisch ermöglichen.

3. Aufbau und Test von Exit-Runbooks
   Erstellung konkreter Runbooks, Begleitung von Probeläufen und Integration der Exit-Strategie in Ihre Governance-Strukturen, sodass Data-Act-Compliance Teil des Regelbetriebs wird.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Der Data Act macht Portabilität, Interoperabilität und Exit-Fähigkeit zu verbindlichen Standards – und schafft damit den Rahmen für einen Cloud- und Datenmarkt, in dem technologische Qualität, nicht Lock-in, den Ausschlag gibt.

Für Sie als verantwortliche Person bedeutet das, Architekturen und Prozesse so zu gestalten, dass:

• Daten und Workloads zwischen Providern wechselbar sind,
• Interoperabilität auf etablierten Standards statt auf proprietären Sonderwegen beruht,
• Exit-Strategien dokumentiert, getestet und organisatorisch verankert sind.

ayedo versteht Data-Act-Compliance dabei nicht als isoliertes Rechtsprojekt, sondern als Bestandteil moderner Plattform- und Infrastrukturstrategie. Mit API-first-Design, Multi-Cloud-fähigen Architekturen und gelebten Exit-Runbooks unterstützen wir Organisationen dabei, die gesetzlichen Anforderungen nicht nur zu erfüllen, sondern in robuste, verhandlungsstarke und zukunftsfähige Infrastrukturen zu übersetzen.

Wenn Sie Portabilität und Exit-Fähigkeit systematisch angehen möchten, ist unser Data Act Compliance-Guide ein sinnvoller Einstiegspunkt – kompakt, praxisorientiert und auf Ihre Rolle zugeschnitten. Starten Sie den Prozess mit einer unverbindlichen Erstberatung über den Data Act Compliance-Guide.