Data Act & Cloud-Dienste: Mehr Freiheit für Nutzer, neue Pflichten für Anbieter

Das umfasst vertragliche Exit‑Regeln (Kündigungs‑, Übergangs‑ und Abruffristen), technische Unterstützungsleistungen, offene Schnittstellen und Dokumentation – sowie die schrittweise Abschaffung von Wechselentgelten. Für Kunden stärkt das die Verhandlungsposition; Anbieter müssen Exit‑Pläne und Schnittstellen‑Governance professionell aufsetzen.

Wer ist erfasst – und wer (teilweise) ausgenommen?

Erfasst sind Cloud- und Datenverarbeitungsdienste, die Zugang zu einem gemeinsam genutzten Pool konfigurierbarer, skalierbarer und elastischer Rechenressourcen bieten. Dazu zählen insbesondere Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS) sowie ergänzend Edge-Computing, Speicherlösungen und "Data-as-a-Service".

Teilweise Erleichterungen gelten für kundenspezifisch entwickelte Lösungen, die nicht breit vermarktet werden, sowie für Test- und Evaluierungsdienste. Diese Angebote sind jedoch nicht vollständig ausgenommen: Mindestpflichten – etwa die Bereitstellung offener Schnittstellen und der Export in strukturierte, gängige, maschinenlesbare Formate – bleiben bestehen. Auch Nutzerinnen und Nutzer von kostenlosen Einstiegstarifen ("Free-Tier") haben Anspruch auf Wechselrechte.

Kernpflichten beim Anbieterwechsel

Anbieter müssen den Wechsel zu einem anderen Dienstleister oder in eine On-Premises-Umgebung sowohl vertraglich als auch technisch unterstützen. Wechselhindernisse – ob kommerzieller, technischer oder organisatorischer Natur – sind zu vermeiden.

Vorgesehen sind:

• eine Kündigungsfrist von maximal zwei Monaten,
• ein Übergangszeitraum von grundsätzlich 30 Tagen; nur wenn der Anbieter innerhalb von 14 Tagen nach Kündigung nachweist, dass ein Wechsel in dieser Zeit technisch nicht möglich ist, darf der Zeitraum auf bis zu sieben Monate verlängert werden.
• eine Abrufphase von mindestens 30 Tagen nach Ende des Übergangs.

Nach Ablauf der Kündigungsfrist kann der Kunde entweder zu einem anderen Anbieter wechseln, die Daten lokal übernehmen oder deren Löschung verlangen. Während des gesamten Wechsels sind Sicherheit und Geschäftskontinuität zu gewährleisten.

Wechselentgelte: Abschaffung bis 12.01.2027

Wechselentgelte sind schrittweise zu reduzieren und ab dem 12. Januar 2027 vollständig untersagt. Bis dahin dürfen nur tatsächlich angefallene, nachweisbare Kosten verrechnet werden. Größere Migrationen lassen sich – wo möglich – wirtschaftlich entlang dieser Entgelt-Timeline planen.

Interoperabilität & Funktionsäquivalenz

Anbieter von Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS) müssen offene Schnittstellen bereitstellen, die einen Wechsel ohne Informationsverlust ermöglichen. Diese Schnittstellen müssen mit offenen Interoperabilitätsspezifikationen und -standards kompatibel sein, wie sie im Unions-Repository veröffentlicht werden. Die Umsetzungsfrist beträgt 12 Monate ab Veröffentlichung der jeweiligen Spezifikation.

Infrastructure-as-a-Service (IaaS)-Anbieter sind darüber hinaus verpflichtet, Werkzeuge und Unterstützung bereitzustellen, die beim Wechsel vergleichbare Ergebnisse ermöglichen ("Funktionsäquivalenz"). Diese Pflicht bezieht sich ausschließlich auf die eigene Umgebung des Quell-Anbieters – ein Nachbau des Dienstes im Zielumfeld ist nicht erforderlich.

Ergänzend gelten für alle Anbieter Dokumentations-, Informations- und Supportpflichten zur Unterstützung des Wechsels.

Transparenz & Dokumentation

Vor Vertragsschluss und laufend sind Verfahren, Formate/Schnittstellen, Limitierungen, Sicherheits‑ und Kontinuitätsmaßnahmen offenzulegen. Empfehlenswert sind Online‑Register mit Angaben zu Datenstrukturen, Exportformaten, Standards/Specs, Gerichtsbarkeit der Infrastruktur und staatlichen Zugriffsmöglichkeiten ("Government Access").

Praktische Auswirkungen auf Cloud-Verträge

Cloud-Verträge müssen künftig verbindliche Exit-Bausteine enthalten: Kündigungs- und Ankündigungsfristen, Übergangs- und Abrufphasen, Exportformate (strukturiert, gängig, maschinenlesbar), Sicherheitsniveau, Rollen und Zuständigkeiten, Support- und Kooperationspflichten, Dokumentations- und Offenlegungspflichten (z.B. Online-Register/Non-Dispersion) sowie Regelungen zu De-/Re-Provisioning und Datenlöschung. Auch On- Premises-Optionen sind ausdrücklich zu adressieren. Als Begriffsanker dienen "Exportierbare Daten" (Input/Output + Metadaten) sowie "Digitale Assets" (z.B. Konfigurationen, Rechteprofile, VMs/Container), die zur Nutzbarkeit im Zielumfeld erforderlich sind.

EU-Musterklauseln für Daten- und Cloud-Verträge

Zur praktischen Umsetzung des Data Act hat die Europäische Kommission freiwillige Muster veröffentlicht: die Model Contractual Terms (MCTs) für Verträge rund um Datenzugang und -nutzung sowie die Standard Contractual Clauses (SCCs) als modulare Bausteine für Cloud-Verträge. Die MCTs decken typische Szenarien ab – vom Verhältnis Dateninhaber–Nutzer über Nutzer–Datenempfänger bis zu Dateninhaber–Datenempfänger (auf Nutzeranweisung) sowie freiwilliges B2B-Datenteilen – und enthalten Best-Practice-Regelungen zu Datenbeschreibung, Nutzungsrechten, FRAND, Geschäftsgeheimnisschutz, Haftung und Streitlösung. Die SCC-Module fokussieren auf Cloud-Kernfragen wie Switching & Exit, Termination, Security & Business Continuity, Transparenz/Non-Dispersion, Haftung und Änderungssperren und helfen, die neuen Wechsel- und Interoperabilitätspflichten konsistent in Verträge zu übersetzen (einschließlich Ankündigungs-, Übergangs- und Abruffristen).

Wichtig: Diese Vorlagen sind nicht bindend und auch nicht mit den bekannten DSGVO-SCCs für internationale Datentransfers zu verwechseln – sie dienen als Referenzrahmen und können je nach Geschäftsmodell und Risikoprofil maßgeschneidert werden.

Cloud‑Playbook: operative Bausteine für Einkauf, IT & Legal
(inkl. Hinweise, welche MCT/SCC‑Module typischerweise passen)

Der Data Act verlangt nicht nur neue Vertragsklauseln, sondern auch technische und organisatorische Exit-Vorbereitungen. Unser Cloud-Playbook bietet praxisnahe Bausteine für Einkauf, IT und Legal – abgestimmt auf die Anforderungen des Data Act und geeignet für Ausschreibungen, Verträge und Migrationsprojekte. 

1.        Für Einkauf (Procurement)

• Exit‑Readiness im RfP: Nach Exportformaten, API‑Spezifikationen, Konfigurations‑/Metadaten‑Export, Test‑Migrationen und Rollen fragen; Bewertungsmatrix Muss/Nice‑to‑ (SCC: Switching & Exit; Security & BC)
• Kostenklarheit & Anti‑Umgehung: Bis 2027 Kostenaufschlüsselung (direkt/indirekt); Anti‑Umgehungsklausel gegen versteckte Exit‑Fees (z.B. Export‑API‑Aufpreise). (SCC: Liability; Non‑Amendment)
• Service‑Credits & Meilensteine: Pönalen/Service‑Credits bei Verzug; objektive Abnahmekriterien (Vollständigkeit, Integrität, Funktionsfähigkeit). (SCC: Switching & Exit; Termination)
• Lieferantensegmentierung: Standard‑ kundenspezifische Dienste trennen; Charakter vorab offenlegen, sonst greifen Erleichterungen nicht. (Art. 31 Data Act; FAQs)
• Referenzen & Nachweise: Use‑Case‑nahe Migrationsreferenzen, Runbooks/SOPs, benannte Rollen anfordern. (SCC: Security & BC)
   

2.        Für IT (Architektur, Betrieb, Sicherheit)

• Export‑Inventar & Mapping: Exportierbare Daten/"digitale Assets" (Metadaten, Workflows, Rechteprofile) je Dienst erfassen; Zielformat‑Mapping; Datenqualität (Checksums). (SCC: General; Security & BC)
• Probedurchlauf (Dry‑Run): Test‑Export in Zielumgebung; Fehlerlog/"Lessons Learned" zurück ins Playbook. (SCC: Switching & Exit)
• Schnittstellen‑Governance: API‑Katalog (Versionen, Limits, Auth, Durchsatz), Fehler‑Handling/Retry, Fallback‑ (SCC: Security & BC; Art. 26/30 Data Act – Repository & 12‑Monats‑Frist)
• Business Continuity: Read‑only/Read‑write‑Fenster, Change‑Freeze, Rollback‑Plan, Monitoring/Alerting (SLOs). (SCC: Security & BC; Switching & Exit)
• Security‑Invarianten: E2E‑Verschlüsselung, KMS/BYOK, Least‑Privilege für Migrationsrollen, Audit‑ (SCC: Security & BC)
• "Brownfield" & Schatten‑IT: Parallel‑Systeme/Abhängigkeiten (ERP/CRM/SCM) inventarisieren; Migrationsfenster abstimmen. (SCC: General)
   

3.        Für Legal (Vertragsrahmen & Compliance)

• Export‑Scope präzisieren: "Exportierbare Daten & digitale Vermögenswerte" inkl. Metadaten/Konfigurationen/Rechteprofile/Protokolle definieren; Whitelist der Formate/Standards (JSON/CSV/XML/OpenAPI). (SCC: Switching & Exit; General; FAQs)
• Migrationspflichten mit Abnahme: Cooperation‑Clause, Pflichtenheft als Anlage, Abnahme‑KPIs, Mitwirkungspflichten beider Anbieter. (SCC: Switching & Exit; Termination)
• Fristen & Verlängerungslogik: Kündigungs‑/Übergangsfristen (s. oben); 14‑Tage‑Nachweis für Verlängerung auf max. 7 Monate; Stop‑the‑Clock bei Anbieterfehlern. (SCC: Switching & Exit; FAQs)
• Haftung & Rechtsbehelfe: Spezial‑Cap für Migrationsschäden (Datenverlust/Downtime); Eskalation (zertifizierte Stellen/Dispute Board). (SCC: Liability; Termination)
• Anti‑Lock‑in & IP: Keine Exklusiv‑Tools ohne Exportpfad; Lizenz‑Portabilität für kundenseitige Komponenten; Nutzungsrechte an Export‑ (SCC: Non‑Amendment; General)
• Datenschutz & Geheimnisschutz: DPA‑Alignment für die Migrationsphase, NDA‑Layer, gestufte Offenlegung, Logging, Drittlandtransfers dokumentieren; Trade‑Secrets absichern (ggf. MCT‑Annex). (MCTs + SCC: Security & BC)
• Transparenz & Nachweise: Wechselverfahren, Standards/Formate und Online‑Register (Art. 26  b) als Vertragspflicht; Doku‑/Audits für den Exit‑Prozess; Change‑of‑Law‑Klausel. (FAQs/Repository).
   

4.        Gemeinsame Governance (Rollen, Ablauf, Dokumentation)

Rollen & Verantwortlichkeiten (RACI).

Zur eindeutigen Zuständigkeit bietet sich das RACI-Schema an: R = Responsible (führt aus), A = Accountable (trägt die Letztverantwortung), C = Consulted (wird eingebunden/beraten), I = Informed (wird informiert). Typische Zuordnung im Anbieterwechsel: Owner/Accountable bei Programmleitung bzw. Business-Service-Owner; Consulted: IT-Security, Datenschutz, Einkauf, Fachbereiche; Informed: Management.

Ablauf & Zeitplan (Beispiel).

• T–90 bis T–60: Exit-Kick-off, Daten-Inventar, Migrationsdesign.
• T–60 bis T–30: Dry-Run (Probelauf), Fehlerbehebung, Abnahmekriterien finalisieren.
• T–30 bis T–0: Umschaltplan (Cut-over-Plan: Zeitpunkt und Schritte der Umschaltung), Kommunikationsplan (Comms-Plan: wer erhält wann welche Information), Change-Freeze (Änderungsstopp).
• T–0 bis T+30: Übergangszeitraum (Wechsel durchführen), Day-2-Stabilisierung.
• T+30 bis T+60: Abrufphase, Abschluss-Audit, Lösch-/Rückgabebestätigung.
   

Dokumentation (Must-haves).

Exit-Runbook (detaillierter Ablaufplan), API/Format-Katalog, Testprotokolle, Abnahmeberichte, Kostenübersicht, Lösch-/Rückgabebestätigung sowie Lessons Learned sichern Nachvollziehbarkeit und Compliance.

Red Flags (kurz & konkret)

• Vage Exportzusagen ("in üblichen Formaten") ohne Standard‑Nennung
• Entgelte für bloßen Datenzugang oder Pflicht‑Support trotz Art. 29
• Weiche Fristen ohne Abnahme‑/Verlängerungsmechanik (Art. 25)
• Verbot der Kooperation mit Zielanbieter oder von Test‑Migrationen
• Haftungsausschlüsse auch für Migration/Datenverlust

Ausnahmen & Sonderfälle

Für kundenspezifische und Test-/Evaluierungsdienste gelten Erleichterungen (z.B. kein voller Interoperabilitätspflichtenumfang) – aber nur, wenn der Charakter vorab klar offengelegt wurde. Bei späterer Breitvermarktung greifen die Pflichten voll; SaaS ist grundsätzlich erfasst.

Ausblick

Im letzten Teil unserer Serie widmen wir uns unfairen Vertragsklauseln, Behördenzugriffen und Sanktionen – mit praxisnahen Vertrags-"Red Flags" und einer Risikomatrix für Rechts- und Einkaufsabteilungen.

(Hinweis: Die Kommissions‑FAQs sind nicht rechtsverbindlich, bieten aber nützliche Orientierung für Praxis und Auslegung.)

Wenn Sie Fragen zu den Themen in diesem Artikel haben oder Unterstützung im Zusammenhang mit dem Datenschutzrecht benötigen, stehen Mag. Philipp Reinisch, LL.M. und Mag. Veronika Wolfbauer, LL.M. gerne als Ansprechpartner zur Verfügung.