Der Data Act und das DADG: Überblick und Zuständigkeit der BNetzA

Problem in der Praxis

Viele Organisationen ordnen den Data Act vorschnell dem Datenschutz oder der klassischen Cybersecurity-Regulatorik zu. Beides greift zu kurz: Der Data Act ist horizontal und sektorübergreifend und gilt nicht nur für KRITIS- oder NIS2-Sektoren. Adressaten sind unter anderem Hersteller vernetzter Produkte, Anbieter verbundener Dienste, Dateninhaber, Nutzer und vor allem Anbieter von Datenverarbeitungsdiensten (Cloud- und Edge-Dienste).

Daraus entstehen typische Lücken: Cloud-Verträge werden ohne die neuen Wechsel- und Exit-Anforderungen verhandelt; Exit-Strategien existieren auf dem Papier, sind aber technisch nie erprobt. Häufig wird zudem die horizontale Data-Act-Zuständigkeit der BNetzA mit ihrer sektoralen Aufsichtsrolle für Energie, Telekommunikation und Post verwechselt.

CISO-Einordnung

Der CISO sollte den Data Act entlang weniger steuerungsrelevanter Fragen einordnen:

• In welchen Rollen treten wir auf: Anbieter von Datenverarbeitungsdiensten, Dateninhaber, Hersteller vernetzter Produkte oder vor allem Nutzer und Kunde?
• Wie realistisch ist ein Anbieterwechsel oder Exit unserer Cloud- und Edge-Dienste heute tatsächlich?
• Welche nicht-personenbezogenen Datenbestände sind einem möglichen Drittland-Behördenzugriff ausgesetzt?

Zwei Themen sind unmittelbar sicherheitsnah. Die Cloud-Switching- und Exit-Pflichten (Art. 23 ff.) verlangen die Beseitigung vertraglicher, technischer und organisatorischer Wechselhindernisse, vertragliche Mindestinhalte mit Kündigungs- und Übergangsregeln (Art. 25), funktionale Äquivalenz bei IaaS und Portabilität über offene, maschinenlesbare Exportformate (Art. 30/31); ein Verbot von Wechselentgelten gilt ab dem 12.01.2027. Art. 32 verpflichtet Anbieter, alle angemessenen Maßnahmen gegen staatlichen Drittland-Zugriff zu treffen, der gegen Unions- oder mitgliedstaatliches Recht verstößt, das Pendant zur DSGVO-Drittlandlogik für nicht-personenbezogene Daten.

Umsetzungsperspektive

Der Data Act lässt sich weitgehend über vorhandene ISMS-Mechanik operationalisieren, statt ein paralleles Programm aufzubauen:

• Betroffenheits- und Rollenklärung, getrennt nach Produkten, Diensten und Geschäftsbereichen.
• Vertrags- und Lieferanteninventar: Cloud- und Datenverarbeitungsverträge gegen Wechsel-, Exit- und Mindestinhaltsanforderungen prüfen und Anpassungsbedarf priorisieren.
• Erprobte Exit-Fähigkeit: Portabilität und Exportformate technisch testen, inklusive funktionaler Äquivalenz bei Infrastrukturdiensten.
• Schutz nicht-personenbezogener Daten nach Art. 32 in Architektur, Verträge und Betrieb verankern.
• Behörden- und Eskalationslandkarte: BNetzA als zentrale Anlaufstelle und Beschwerdeinstanz (Art. 38), BfDI für personenbezogene Aspekte.

Bestehende Bausteine helfen: ISO/IEC 27001 liefert über Lieferanten- und Vertragsmanagement sowie Zugriffskontrolle passende Controls; der BSI-Kriterienkatalog C5 bietet ein Strukturraster für Portabilität und Exit-Management. Für Finanzunternehmen wirken DORA-Exit-Anforderungen und Data-Act-Switching-Rechte nebeneinander; die Finanzaufsicht liegt dort bei BaFin und Bundesbank, nicht bei der BNetzA.

Typische Fehler

1. Der Data Act wird als Datenschutzthema geführt und damit fälschlich allein dem BfDI zugeordnet.
2. Die horizontale Data-Act-Rolle der BNetzA wird mit ihrer Sektoraufsicht (Energie, Telekommunikation, Post) verwechselt.
3. Exit- und Portabilitätspflichten werden vertraglich abgebildet, aber technisch nie erprobt.
4. Cloud-Neuverträge werden ohne die neuen Wechsel- und Mindestinhaltsanforderungen abgeschlossen.
5. Art. 32 (nicht-personenbezogene Daten) wird übersehen, weil der Fokus allein auf personenbezogenen Daten liegt.

Risiken und Trade-offs

Ein zu enger Blick reduziert den Data Act auf Cloud-Verträge und übersieht IoT-Datenzugangs- und Interoperabilitätspflichten; ein zu breiter, ungesteuerter Ansatz bindet Ressourcen, ohne die wesentlichen Risiken zuerst zu adressieren.

Beim Schutz von Geschäftsgeheimnissen besteht ein echter Trade-off: Datenzugangs- und Weitergabepflichten stehen in Spannung zum Schutz vertraulicher Inhalte; die Verordnung sieht hierfür Schutzmechanismen vor. Bei der Portabilität darf Offenheit nicht zu Lasten der Sicherheit gehen; offene Schnittstellen müssen abgesichert betrieben werden. Bei doppelter Regulierung (z. B. NIS2 und Data Act) sollten Nachweise konsolidiert statt parallel aufgebaut werden.

Entscheidungspunkte

• In welchen Data-Act-Rollen tritt die Organisation auf, und wo liegt der größte Handlungsbedarf?
• Welche Cloud- und Datenverarbeitungsverträge werden zuerst angepasst?
• Bis wann ist die Exit-Fähigkeit für kritische Dienste erprobt, mit Blick auf das Wechselentgelt-Verbot ab 12.01.2027?
• Wie werden Art.-32-Maßnahmen für nicht-personenbezogene Daten in Architektur und Verträge integriert?
• Wie ist die interne Schnittstelle zu BNetzA und BfDI organisiert, inklusive Beschwerde- und Eskalationswegen?

Praktische Empfehlungen

1. Den Data Act als horizontales Datenrecht behandeln, nicht als Anhängsel von Datenschutz oder NIS2.
2. Eine klare Behördenlandkarte führen: BNetzA zentral nach Art. 37, BfDI für personenbezogene Daten.
3. Cloud- und Edge-Verträge gegen Wechsel-, Exit- und Mindestinhaltspflichten prüfen und Neuverträge konform gestalten.
4. Exit und Portabilität technisch testen, nicht nur dokumentieren, und das Ergebnis als Nachweis im ISMS führen.
5. Art.-32-Schutz für nicht-personenbezogene Daten in Risikoanalyse und Architektur verankern.
6. Vorhandene Rahmen wiederverwenden: ISO/IEC 27001-Controls und BSI C5 als Umsetzungs- und Nachweisraster.

Relevante Normreferenzen

• Verordnung (EU) 2023/2854 (Data Act / Datengesetz): EU-Recht, frei zitierbar; sicherheitsnahe Anker u. a. Art. 3 ff. (IoT-Datenzugang; Art. 3 Abs. 1 gilt für vernetzte Produkte, die nach dem 12.09.2026 in Verkehr gebracht werden), Art. 23-31 (Cloud-Wechsel und Exit), Art. 32 (Drittland-Behördenzugriff), Art. 33-36 (Interoperabilität), Art. 37 ff. (Durchsetzung, zuständige Behörden).
• DADG (Datenverordnung-Anwendungs- und Durchsetzungs-Gesetz): DE-Durchführungsrecht, frei zitierbar; regelt Zuständigkeiten, Verfahren und Sanktionsrahmen. Genaue BGBl.-Fundstelle, Bußgeldhöhen und einzelne Detailfristen sind anhand der amtlichen Verkündung zu prüfen.
• ISO/IEC 27001:2022: Referenz für ISMS-Controls zur Operationalisierung; keine Zertifizierung des Data Act über ISO 27001.