Cloud-Switching und Exit nach dem Data Act (Art. 23-31)

Problem in der Praxis

In vielen Organisationen ist der Cloud-Einstieg gut dokumentiert und der Ausstieg gar nicht. Es gibt einen Migrationsplan in die Plattform, aber keinen belastbaren heraus: Daten liegen in proprietären Formaten, Konfigurationen sind anbieterspezifisch, und ein realistischer Zeit- und Kostenrahmen für einen Wechsel wurde nie ermittelt.

Das fällt erst auf, wenn Druck entsteht: eine Preiserhöhung, eine Neuausrichtung, ein Sicherheitsvorfall beim Anbieter oder eine aufsichtsrechtliche Anforderung. Dann scheitert der Wechsel an Datenexport-Hürden, undokumentierten Abhängigkeiten und langen Kündigungsfristen. Der Data Act adressiert diese künstlichen Hürden, ersetzt aber nicht die fehlende eigene Vorbereitung. Hinzu kommt die Geltungsfrage: Die meisten Bestimmungen sind seit 12.09.2025 anwendbar, das Verbot von Wechselentgelten greift jedoch erst ab 12.01.2027 - viele Bestandsverträge bilden diesen Rahmen noch nicht ab.

CISO-Einordnung

Der Data Act ist Marktregulierung, kein Cybersecurity-Managementrahmen und kein Zertifizierungsschema. Er beschreibt, was an Wechsel- und Exit-Fähigkeit geschuldet ist; das Wie bleibt Aufgabe des eigenen Steuerungsmodells. Der CISO sollte die Wechselrechte als Anforderung an das eigene Lieferanten- und Kontinuitätsmanagement lesen.

Inhaltlich kommt es auf drei Bausteine an. Erstens die vertraglichen Mindest- und Übergangsregeln (Art. 25): begrenzte Kündigungsfristen und ein definierter Übergangszeitraum für einen geordneten Wechsel. Zweitens die funktionale Äquivalenz bei IaaS (Art. 30): die Zielumgebung soll nach dem Wechsel ein Mindestmaß an gleichwertiger Funktionalität bieten, und exportierbare Daten sowie digitale Assets sollen portierbar sein. Drittens offene Schnittstellen und strukturierte, gängige, maschinenlesbare Exportformate (Art. 30/31). Die funktionale Äquivalenz ist dabei ein Maßstab für IaaS und bedeutet nicht, dass jeder PaaS- oder SaaS-Dienst nach dem Wechsel identisch weiterläuft.

Umsetzungsperspektive

Sinnvoll ist ein Exit-Fähigkeits-Programm, das an das bestehende Lieferanten- und Kontinuitätsmanagement andockt statt als Sonderprojekt zu laufen. Ein tragfähiger Kern umfasst:

• Bestandsaufnahme der Datenverarbeitungsdienste mit Dienstmodell (IaaS/PaaS/SaaS), Kritikalität und Datenarten.
• Exit-Strategie je kritischem Dienst: Zielszenario, Datenformate, Schnittstellen, Verantwortliche, grobe Zeit- und Aufwandsschätzung.
• Vertragsprüfung gegen die Wechselpflichten: Kündigungsfristen, Übergangszeitraum, Mitwirkung des Anbieters, Entgeltregelungen mit Blick auf den 12.01.2027.
• Technische Portabilitätsprüfung: Exportierbarkeit in gängigen Formaten, Vollständigkeit von Daten und Metadaten, gesicherte Löschung beim Altanbieter.
• Nachweisführung: Exit-Tests für die kritischsten Dienste, damit Wechselfähigkeit belegbar und nicht nur behauptet ist.

Diese Schritte lassen sich über etablierte ISMS-Controls operationalisieren (Lieferanten-/Cloud-Beziehungen, Vertragsmanagement, Zugriffskontrolle, Kryptografie, Datenlöschung). Der BSI-Kriterienkatalog C5 dient als Nachweisraster für die Anbieterbewertung, ist aber kein Rechtsnachweis.

Typische Fehler

1. Exit wird als Vertragsklausel abgehakt, aber technisch nie getestet.
2. Funktionale Äquivalenz wird pauschal auf alle Dienstmodelle übertragen, obwohl sie auf IaaS zielt.
3. Der Stichtag 12.01.2027 für das Wechselentgelt-Verbot wird mit der allgemeinen Geltung ab 12.09.2025 verwechselt.
4. Datenexport wird geprüft, die gesicherte Löschung beim Altanbieter aber vergessen.
5. Personenbezogene Daten werden im Wechsel mitgedacht, ohne die vorrangige Datenschutzlogik von der Data-Act-Portabilität zu trennen.

Risiken und Trade-offs

Wechselfähigkeit ist nicht kostenlos. Portabilität über offene Formate kann Funktionsumfang oder Performance eines tief integrierten Dienstes einschränken. Der CISO balanciert zwischen Souveränität und Funktionalität und sollte diese Abwägung bewusst und dokumentiert treffen.

Ein zweiter Trade-off liegt im Aufwand: Regelmäßige Exit-Tests binden Ressourcen und lassen sich nicht für jeden Dienst rechtfertigen. Eine Priorisierung nach Kritikalität ist notwendig, schafft aber blinde Flecken bei vermeintlich unkritischen Diensten, die über Datenflüsse relevant sein können.

Entscheidungspunkte

• Welche Datenverarbeitungsdienste sind so kritisch, dass eine getestete Exit-Fähigkeit zwingend ist?
• Bei welchen Bestandsverträgen müssen Kündigungs-, Übergangs- und Entgeltregelungen mit Blick auf den 12.01.2027 nachverhandelt werden?
• Welches Maß an funktionaler Äquivalenz ist je Dienstmodell realistisch erreichbar, und wo wird ein Funktionsverlust bewusst akzeptiert?
• Wer trägt im Unternehmen die Verantwortung für Exit-Tests und deren Nachweisführung?

Praktische Empfehlungen

1. Führen Sie ein Register der Datenverarbeitungsdienste mit Kritikalität, Dienstmodell und Datenarten und leiten Sie daraus Exit-Prioritäten ab.
2. Prüfen Sie Bestands- und Neuverträge gegen die Wechselpflichten und planen Sie Nachverhandlungen mit Blick auf den 12.01.2027.
3. Verlangen Sie strukturierte, gängige, maschinenlesbare Exportformate und offene Schnittstellen als Beschaffungskriterium.
4. Testen Sie Exit für die kritischsten Dienste praktisch und dokumentieren Sie Datenvollständigkeit und gesicherte Löschung beim Altanbieter.
5. Nutzen Sie ISMS-Controls und C5 als Nachweisraster; bei Finanzunternehmen stimmen Sie die Wechselrechte mit den DORA-Exit-Anforderungen ab.

Relevante Normreferenzen

• Verordnung (EU) 2023/2854 (Data Act), Art. 23-31: Wechsel zwischen Datenverarbeitungsdiensten, Vertrags-/Übergangsregeln (Art. 25), funktionale Äquivalenz (Art. 30), Exportformate/Schnittstellen (Art. 30/31), Wechselentgelt-Verbot ab 12.01.2027.
• DADG: deutsches Durchführungsrecht; in Kraft seit 30.05.2026, zuständige Behörde ist die Bundesnetzagentur. Detailfristen und das Verhältnis zur Datenschutzaufsicht (BfDI) sind am finalen Gesetzestext zu prüfen.
• DORA (Verordnung (EU) 2022/2554), Art. 28 ff.: Exit und IKT-Drittparteienrisiko für Finanzunternehmen; Aufsicht BaFin/Bundesbank.
• BSI C5: Kriterienkatalog zu Portabilität/Interoperabilität/Exit; Nachweisraster, kein Rechtsnachweis. ISO/IEC 27001:2022: Referenz für ISMS-Controls; keine Data-Act-Zertifizierung.