Autor: Trenchant

UMSETZUNG NIS-2: DEUTSCHLANDS SONDERWEG BLEIBT RECHTLICH RISKANT

Posted on by Trenchant

Umsetzung NIS-2: Deutschlands Sonderweg bleibt rechtlich riskant

Der deutsche Gesetzgeber entlastet Unternehmen von den Anforderungen der NIS-2-Richtlinie in einem Ausmaß, das die Ziele des europäischen Gesetzgebers zu verfehlen droht. Was das für Unternehmen bedeutet.

Stand der Dinge

Mit einer Verzögerung von über einem Jahr ist am 06.12.2025 das deutsche BSIG zur Umsetzung der NIS-2-Richtlinie in Kraft getreten (Network and Information Security). Es ist seither unmittelbar geltendes Recht. Eine weitere Umsetzungsfrist für die Wirtschaft gibt es nicht. Unternehmen, die eine in den Anlagen 1 oder 2 gelistet Tätigkeit ausüben, müssen sich bis zum 06.03.2026 beim BSI registrieren und ein Risikomanagementsystem eingeführt haben. 

Bemerkenswert ist, dass das BSIG trotz erheblicher Kritik aus der Anwaltschaft während des Gesetzgebungsverfahrens in wesentlichen Punkten nicht richtlinienkonform ausgestaltet ist. Es räumt Unternehmen einen unbestimmten Ermessensspielraum bei der Frage ein, ob sie sich als wichtige oder besonders wichtige Einrichtung registrieren. Gut gemeint gehen damit rechtliche Unsicherheiten und Haftungsrisiken einher.

Worum geht es in der Richtlinie

Nach der europäischen NIS-2-Richtlinie liegen Unternehmen benannter Sektoren

➡ Energie, Verkehr, Bankwesen, Finanzmarktinfrastrukturen, Gesundheitswesen, Trinkwasser, Abwasser, Digitale Infrastruktur, Verwaltung von B2B-IKT-Diensten, Weltraum, Post- und Kurierdienste, Abfallwirtschaft, Produktion/Herstellung/Handel mit chemischen Stoffen, Produktion/Verarbeitung/Vertrieb von Lebensmitteln, Verarbeitendes Gewerbe/Herstellung von Waren, Anbieter digitaler Dienste und Forschung mit

a) mindestens 50 Mitarbeitenden oder

b) mehr als 10 Mio. Euro Jahresumsatz und mehr als 10 Mio. Euro Jahresbilanzsumme 

im Anwendungsbereich des Gesetzes.

Nicht relevant ist, ob es sich bei der Tätigkeit um die Haupttätigkeit des Unternehmens handelt oder nur um eine Nebentätigkeit. 

So kann schon der Betrieb einer einzigen Photovoltaik-Anlage für eigene Zwecke die gesetzlichen Pflichten zum Cyber-Risikomanagement auslösen. Über die vorgenannten Schwellenwerte hinaus (Size-Caps) gibt es weitere Ausnahmen für Unternehmen derzeit nur in den Sektoren Trinkwasser, Abwasser und Abfallwirtschaft.

Dass hierdurch eine Vielzahl von Unternehmen erfasst wird, ist bewusst gewollt. Der Regelungsansatz richtet sich nicht mehr allein auf den Schutz des einzelnen Unternehmens, sondern verpflichtet dieses, einen aktiven Beitrag zur Cybersicherheit zu leisten. Ziel ist es, durch das Zusammenwirken der Mitgliedstaaten und ihrer Unternehmen die Cyberresilienz der Gesellschaft insgesamt zu stärken und ein hohes gemeinsames Cybersicherheitsniveau in der Europäischen Union zu gewährleisten. 

Der „deutsche Sonderweg“ im BSIG

Während die Richtlinie also im Sinne eines möglichst umfassenden Zusammenwirkens grundsätzlich auch geringfügige Tätigkeiten in den Blick nimmt, eröffnet das deutsche BSIG demgegenüber die Möglichkeit, bestimmte Geschäftstätigkeiten unberücksichtigt zu lassen, wenn sie 

➡  im Hinblick auf die gesamte Geschäftstätigkeit der Einrichtung vernachlässigbar sind. 

Begründet wird dies mit dem Grundsatz der Verhältnismäßigkeit. Es soll vermieden werden, dass eine lediglich geringfügige Nebentätigkeit zu einer unverhältnismäßigen Einstufung als wichtige oder besonders wichtige Einrichtung führt.

Mögliche Anhaltspunkte für diese Bewertung können, so die Gesetzesbegründung, etwa die Anzahl der in diesem Bereich tätigen Mitarbeiter, der durch diese Geschäftstätigkeit erwirtschaftete Umsatz oder die Bilanzsumme für diesen Bereich sein. Entscheidend sei dabei unter Berücksichtigung aller relevanten Anhaltspunkte das Gesamtbild der betreffenden Geschäftstätigkeit im Lichte der Gesamtgeschäftstätigkeit der Einrichtung.

In der Beratungspraxis zeigt sich, dass viele Unternehmen diese Ausnahme weit auslegen und auf dieser Basis nicht nur von einer Registrierung absehen, sondern auch die Einführung von Risikomanagementsystemen unterlassen möchten.

Dieser Weg ist riskant. 

Was bedeutet das nun:

Der deutsche Sonderweg mag aus Sicht der Wirtschaft äußerst begrüßenswert sein, ändert jedoch nichts daran, dass die Ausnahmeregelung für „vernachlässigbare Tätigkeiten“ nach überwiegender Auffassung der Fachliteratur nicht richtlinienkonform ausgestaltet ist. Sie verkennt die Systematik der NIS-2-Richtlinie. Die Schwellenwerte sind kein Indiz für die Kritikalität der Einrichtung. Sie soll vielmehr eine faire Lastenverteilung gewährleisten und kleine und Kleinstunternehmen mit einem Beitrag zur gemeinschaftlichen Cybersicherheit nicht überfordern.

Geht man von der Richtlinienwidrigkeit aus, führt das zwar nicht zur Unanwendbarkeit des deutsche Rechts. Es ist jedoch – wo möglich – so auszulegen, dass die NIS-2-Richtlinie ihre volle Wirksamkeit erreicht. Hierfür bedarf es einer Bewertung des Einzelfalls. 

Eine größtmögliche Ausdehnung der Ausnahmeregelung, ohne Berücksichtigung der europäischen Vorgaben, kann haftungsrechtlich problematisch sein und sollte vermieden werden.

Was sollten Unternehmen tun:

  • Geschäftsleitungen sind aufgrund der im HGB, GmbHG und AktG verankerten Legalitätspflicht gehalten, bei der Betroffenheitsbewertung rechtlichen Rat einzuholen, sofern eine Betroffenheit nicht offensichtlich ausgeschlossen werden kann. Dies gilt in besonderem Maße bei der Inanspruchnahme des „deutschen Sonderwegs“ in vielen Aspekten des Gesetztes. 
  • Rechtliche Beratung durch andere Personen als Rechtsanwälte enthaftet die Geschäftsleitung nicht. 
  • Wenn die Geschäftsleitung zu dem Ergebnis kommt, eine Tätigkeit unter Berufung auf den deutschen Sonderweg nicht beim BSI zu registrieren, sollte diese dennoch in das Risikomanagement aufgenommen werden. Kippen die Regelungen, sind sie ab dem Moment nicht mehr anwendbar. Darauf sollte das Unternehmen vorbereitet sein.

IT-Sicherheits-Rechtsberatung

Bei der NIS-2-Richtlinie, der NIS-2-Durchführungsverordnung für IKT und dem BSIG handelt es sich um Gesetze, die – anders als internationale Normen wie die ISO/IEC 27001 – in einem komplexen digitalrechtlichen Kontext stehen und an zahlreichen Stellen einer europarechtskonformen Auslegung bedürfen. 

Dabei ist zu beachten, dass sie als Teil des öffentlich-rechtlichen Sicherheitsrechts nicht dem Schutz der Unternehmen vor Bußgeldern oder der Förderung ihrer Marktchancen dienen (so ISO/IEC 27001)

Sie sollen die kontinuierlichen Verfügbarkeit kritischer Dienste und Infrastrukturen und ein hohes allgemeines Cybersicherheitsniveau ermöglichen. 

In den vergangenen Monaten habe ich zahlreiche Unternehmen in der Betroffenheitsbewertung begleitet. Wenn Sie zeitnah eine strukturierte Einordnung benötigen, melden Sie sich gerne. 

EU Data Act: Cloud-Switching und Interoperabilität

Posted on by Trenchant

EU Data Act: Cloud-Switching und Interoperabilität –
Eine erster Einstieg

Seit dem 12. September 2025 finden wesentliche Regelungen des EU Data Act Anwendung.

Interessierte Communities tauschen sich viel zu den Anforderungen an das Produktdesign oder die Bereitstellung von Nutzungsdaten aus. Als Beispiel gern genommen wird das Auto. Eher leise kommen dagegen die Regelungen zum Cloud-Switching daher. Das ist verwunderlich, denn sie haben für Softwarehersteller und Distributoren erhebliche Auswirkungen – Kunden können Nutzen ziehen.

Veröffentlicht am 21.08.2025 – überarbeitet am 05.01.2026

Zwei sehr verschiedene Regelungsbereiche

Am 23. Februar 2022 legte die EU-Kommission ihren ersten Entwurf für den Data Act vor – eine Verordnung über fairen Datenzugang und faire Datennutzung. Über die Pläne berichtete ich bereits im September 2022 in der Sonderbeilage der Fachzeitschrift IT-Business – Cloud & Virtualisierung.

Seither habe ich die Debatten um den Data Act intensiv begleitet, unter anderem in Sitzungen der Verbände BDI und ZVEI, an denen auch Vertreter der EU-Kommission und des Bundesministeriums für Wirtschaft im Bereich Digitalisierung und Industrie 4.0 teilgenommen haben. Dort stand vor allem das Kapitel zum Data-Sharing bei IoT-Produkten im Mittelpunkt: Wem gehören die Daten, die bei der Nutzung eines Autos, eines CT-Geräts oder einer Baumaschine entstehen? Nach dem Willen der EU dürfen Hersteller diese künftig nur mit Zustimmung der Nutzer selbst verwenden. Gleichzeitig müssen sie die Daten und Metadaten Nutzern – und auf Wunsch auch Dritten – zugänglich machen, selbst wenn Geschäftsgeheimnisse betroffen sind.

Die Industrie konnte daran kaum etwas ändern. Der Data Act wurde am 22. Dezember 2023 verabschiedet und gilt in seinen wesentlichen Teilen seit dem 12. September 2025. Viele Unternehmen stehen nun vor der Herausforderung, unklare und komplexe Vorgaben in die Praxis umzusetzen. Aus meiner Beratungspraxis weiß ich: Mit einem pragmatischen Ansatz lassen sich Lösungen finden. In dem Data-Act-Projekt bei einem international ausgerichteten Baumaschinenhersteller haben wir in einem interdisziplinären Team Wege entwickelt, um die gesetzlichen Anforderungen zu erfüllen, ohne Wettbewerbsnachteile zu riskieren.

Deutlich weniger Aufmerksamkeit haben bisher die Vorgaben zu Cloud-Switching und Interoperabilität erhalten. Dabei gehören sie zu den folgenreichsten Kapiteln des Data Act – mit weitreichenden Konsequenzen nicht nur für die großen Softwarehersteller, sondern ebenso für Distributoren, Partner und Dienstleister. 

1. Was bedeutet Cloud-Switching im Kontext des Data Act?

Der Data Act greift gezielt in den Markt für Cloud-Dienste ein. Sein Ziel: Nutzer sollen nicht mehr dauerhaft an einen Anbieter gebunden sein, sondern ihre Daten, Anwendungen und Workloads einfacher zu einem anderen Provider übertragen können. Damit will die EU den „Lock-in-Effekt“ durchbrechen, der heute viele Unternehmen davon abhält, den Anbieter zu wechseln. Erfasst sind Cloud-Angebote in den bekannten Schichten:

  • Infrastructure-as-a-Service (IaaS): Infrastruktur wie Server, Netze und Speicher.
  • Platform-as-a-Service (PaaS): Entwicklungs- und Betriebsumgebungen für Anwendungen.
  • Software-as-a-Service (SaaS): Anwendungen, die der Kunde „fertig“ nutzen kann.

Je höher die Ebene, desto komplexer ist ein Anbieterwechsel. 

Gleiche Dienstart

Der Data Act ermöglicht eine vom Anbieter kostenlos zu unterstützte Portabilität von Daten zwischen Diensten – aber nur, wenn diese Dienste gleichartig sind. Unter „Diensten gleicher Dienstart“ versteht man im Wesentlichen Datenverarbeitungsdienste, die dasselbe Hauptziel, die gleichen Hauptfunktionen und das gleiche Dienstmodell teilen.

Operative Details, wie etwa die zugrunde liegende Infrastruktur oder konkrete technische Umsetzung, spielen keine Rolle. Entscheidend ist, dass alle drei Kriterien gleichzeitig erfüllt sind: Nur wenn Hauptziel, Hauptfunktionen und Dienstmodell übereinstimmen, kann ein Nutzer seine Daten rechtlich und technisch problemlos zu einem anderen Anbieter übertragen.

Bereichsausnahmen

Nicht alle Dienste sind jedoch erfasst. Ausgenommen sind Test- und Proof-of-Concept-Angebote, da hier naturgemäß noch kein Lock-in besteht. Anders verhält es sich mit „On-Top-Angeboten“, die bestehende Kunden binden sollen – sie fallen unter die Wechselpflichten.

2. Interoperabilität: Anforderungen an Schnittstellen

Ein zentrales Element des Data Act sind die Schnittstellen, über die ein Wechsel von einem Cloud-Anbieter zum anderen technisch ermöglicht wird. Der Gesetzgeber schreibt vor, dass Anbieter von Datenverarbeitungsdiensten ihre Schnittstellen so ausgestalten müssen, dass Kunden ihre Daten in ein anderes System übertragen können – ohne übermäßigen Aufwand und ohne technische Hürden.

Offene Schnittstellen mit ausreichenden Informationen

Art. 30 Data Act verpflichtet Anbieter, offene Schnittstellen bereitzustellen. „Offen“ bedeutet hier: Die Schnittstellen sind öffentlich dokumentiert und können von Dritten genutzt werden, etwa für die Entwicklung von Migrationstools.

Diese Schnittstellen müssen mit ausreichenden Informationen angereichert sein – insbesondere mit den Metadaten, die erforderlich sind, um eine Kommunikationsfunktion zwischen Alt- und Neusystem herzustellen. Ein typisches Beispiel: Im Altsystem werden „Vorname“ und „Nachname“ getrennt gespeichert, im neuen System gibt es nur das Feld „Name“. Das Migrationstool muss anhand der bereitgestellten Metadaten in der Lage sein, die beiden Werte zusammenzuführen und korrekt im Zielsystem einzutragen. Ohne solche Informationen wären die exportierten Daten zwar vorhanden, im neuen System aber nicht sinnvoll nutzbar.

Konflikt mit Schutzrechten

Wie schon im vorherigen Kapitel dargestellt, können diese Metadaten tief in geschützte Bereiche wie Geschäftsgeheimnisse oder geistige Eigentumsrechte hineinreichen. Der Data Act stellt jedoch klar: Der Schutz endet dort, wo er den Anbieterwechsel vereiteln würde. Die genaue Abgrenzung, welche Informationen offengelegt werden müssen, bleibt in vielen Fällen eine Frage der Praxis und voraussichtlich auch der Rechtsprechung.

Interessant für SAP Kunden:

Selbstverständlich gilt das alles auch für „RISE with SAP S/4 HANA on Hyperscaler“. Kunden können – jedenfalls in der public cloud – frei wählen, ob sie im Bereich Analytics & Data die SAP Analytics Cloud (SAC) verwenden wollen oder z.B. die Power BI von Microsoft. Die Schnittstellen müssen künftig den Anforderungen des Data Act genügen. Hierzu gab es im Rahmen meines Vortrages bei den Münchner SAP-Tagen am 2. Oktober 2025 interessante Diskussionen: http://sap-tage.de/227.html.

Fazit

Der Data Act ist weit mehr als ein Gesetzestext – er ist ein komplexer Regelungsrahmen, der Unternehmen auf vielen Ebenen betrifft. Die hier angesprochenen Punkte zu Datenportabilität, Metadaten und Schnittstellen sind nur ein Ausschnitt. In der Praxis stellen sich zahlreiche weitere Detailfragen, die jeweils erhebliche rechtliche und technische Herausforderungen mit sich bringen.

Mit einzelnen Aspekten habe ich mich in einer Beitragsreihe von TRENCHANT tiefer auseinandergesetzt:

👉 Link zu Beitrag 1: „Cloud-Wechsel: Warum gute Verträge allein nicht vor Abhängigkeit schützen“
https://trenchant-legal.de/cloud-wechsel-warum-gute-vertraege-allein-nicht-vor-abhaengigkeit-schuetzen/

👉 Link zu Beitrag 2: „Cloud ist nicht gleich Cloud – wie die Abstraktionsebene über den Aufwand des Exits entscheidet“
https://trenchant-legal.de/cloud-ist-nicht-gleich-cloud-wie-die-abstraktionsebene-ueber-den-aufwand-des-exits-entscheidet/

👉 Beitrag 3: Cloud-Wechsel: Offene Schnittstellen, Metadaten, Informationen – Neue Pflichten der Anbieter nach Data Act
https://trenchant-legal.de/cloud-wechsel-offene-schnittstellen-metadaten-informationen/

Eines ist klar: Projekte zur Umsetzung des Data Act sollten unbedingt mit rechtlicher Expertise begleitet werden. Nur so lassen sich Risiken vermeiden und tragfähige Lösungen entwickeln, die den gesetzlichen Anforderungen gerecht werden und gleichzeitig die Wettbewerbsfähigkeit sichern.

Wer tiefer einsteigen möchte: Im Compliance Handbuch EU Data Act (Carl Heymanns Verlag – Wolters Kluwer), an dem ich als Co-Autorin mitgewirkt habe, finden sich umfassende Erläuterungen und Praxishinweise zu allen relevanten Kapiteln.

Wenn Sie konkrete Fragen zu Ihrem Data Act Projekt haben, sprechen Sie mich gerne an.

Cloud-Wechsel: Offene Schnittstellen, Metadaten, Informationen

Posted on by Trenchant

Cloud-Wechsel: Kostenreduktion durch offene Schnittstellen, bereitzustellende Metadaten und Informationen

Seit dem 12.09.2025 ist der Data Act EU-weit unmittelbar anwendbar. Im Fokus steht auch der wirtschaftliche lock-in beim Cloud-Computing durch zu hohe Kosten und Risiken beim Wechsel des Providers. Dafür nimmt das Gesetz jene Faktoren in den Fokus, die schon immer entscheidend waren: Schnittstellen, Metadaten und Informationszugang.

Ein Überblick.

Intro

Der Data Act wird häufig als neues Wechselrecht für Cloud-Nutzer beschrieben. Diese Perspektive greift jedoch zu kurz; der Wechsel des Anbieters war schon immer rechtlich möglich, oft aber unwirtschaftlich und stark risikobehaftet: Die Kosten der Berater für das Migrationsprojekt, die internen Aufwände und die Risikokosten – auch getrieben durch Aspekte aus der Sphäre des bisherigen Anbieters – haben den Business-Case des Wechsels selten getragen.

Bitter, wenn der Nutzer das erst im Laufe des Migrationsprojekts erkennt.

Diese wirtschaftliche Abhängigkeit möchte das Gesetz aufbrechen. Erstmals sind Anbieter verpflichtet, den Wechsel für Nutzer – vertraglich nicht abwendbar – kostenfrei und risikoärmer zu gestalten. Dafür adressiert der Data Act ganz bewusst die technische und informationelle Seite des Cloud-Exits.

Gut gemeint, aber in Teilen unglücklich gestaltet: Zahlreiche Auslegungsfragen sowie Konflikte mit bestehenden Normen erzeugen erhebliche Rechtsunsicherheiten. Besonders heikel wird es dort, wo bereitzustellende Metadaten Rückschlüsse auf Geschäftsgeheimnisse des Anbieters erlauben.

Für Anbieter sollte diese Beratung idealerweise vor Vertragsschluss erfolgen, denn Geschäftsgeheimnisschutz lässt sich vielfach auch technisch rechtssicher gestalten. Nur braucht dieser Weg Zeit und Mittel. Manche Anbieter verweisen statt dessen reflexartig auf die von der Kommission bereitgestellten „Standardvertragsklauseln“ – oft ohne sie im Detail zu kennen oder zu verstehen. Aus verschiedenen Gründen keine gute Idee.

Der Perspektivwechsel des Data Act: Vom Wechselrecht zur Anbieterpflicht

Auf den ersten Blick scheint es sich um recht abstrakte Pflichten zu handeln, die der Data Act vorhält. In zentralen Aspekten mit hohem Interessenwiderstreit wird es aber de facto sehr konkret.

Im Zentrum stehen:

  • die Bereitstellung offener Schnittstellen,
  • die Zurverfügungstellung von Informationen für die Herstellung der Kommunikationsfunktion des Migrationstools,
  • die Herausgabe von Unternehmensdaten und der für ihre sinnvolle Nutzung erforderlichen „Metadaten“.

Das alles adressiert den ETL-Prozess der technischen Migration der Unternehmensdaten des Nutzers in das Zielsystem (Extract-Transform-Load).

Nach meiner Erfahrung einer der kritischsten Prozesse im Projekt überhaupt. Das Migrationstool muss die Unternehmensdaten vollständig aus dem Altsystem extrahieren, sie korrekt interpretieren und dann im neuen System an der richtigen Stelle ablegen. Werden hier entstehende Fehler zu spät erkannt, kann der Schaden erheblich sein – insbesondere dann, wenn das Altsystem nicht mehr für eine Rekonstruktion zur Verfügung steht.

Das ebenso häufige Problem mangelhafter Datenqualität ist damit allerdings nicht gelöst. Das bleibt in der Verantwortung des Nutzers. Einfache Beispiele hierfür sind inkonsistente Nummernangaben als Text- und Zahl, inkonsistente Codes wie „m“, „male“ „Mann“ oder auch Namensvarianten wie „Müller“ „Mueller“.

👉 Im Einzelnen:

Offene Schnittstellen und Informationen: Rechtlich gefordert, technisch nicht eindeutig definiert

Eine zentrale Vorgabe des Data Act ist die Verpflichtung zur Bereitstellung offener Schnittstellen. Dieser Begriff ist jedoch nicht definiert. Klargestellt ist nur, dass Schnittstellen „ausreichende Informationen über den betreffenden Dienst enthalten müssen, damit die Software entwickelt werden kann, die für die Kommunikation mit den Diensten zu Zwecken der Datenübertragbarkeit und der Interoperabilität erforderlich ist.“ – also das Migrationstool.

👉 „Offen“ bedeutet damit nicht, dass die Schnittstelle standardisiert oder universell kompatibel sein muss. 

Der Data Act selbst verweist nicht auf einen konkreten verbindlichen technischen Standard (z. B. ein bestimmtes API-Protokoll). Allerdings arbeiten EU-Institutionen bzw.  Standardisierungsorganisationen bereits an harmonisierten technischen Standards. 

Eine Vorstellung davon, welche Informationen offengelegt werden müssen, kann (stark vereinfacht) ein Vergleich mit der allgemein bekannten E-Mail-Kommunikation geben: Um mit einer anderen Person per E-Mail Daten oder Datenpakete auszutauschen, ist zunächst die Kenntnis der E-Mail-Adresse erforderlich. Sie gibt an, wohin Daten und Datenpakete gesendet werden können. Darüber hinaus muss der Sender die Datenformate für Anhänge kennen, die vom Empfänger verarbeitet und gelesen werden können. Diese Informationen genügen, um Daten und Datenpakete in einen Datenverarbeitungsdienst einzubringen.

Für Anwender bedeutet das: Die Existenz offener Schnittstellen ist ein wichtiger Fortschritt, ersetzt aber nicht die Entwicklung eines Migrationstools.

👉 Die Bereitstellung einer tauglichen Schnittstelle zum Altsystem ist aus Sicht eines „Migrationsberaters“ eine Beistellung des Kunden. Ihm gegenüber ist allein der Kunde verantwortlich, nicht der bisherige Cloud-Provider.

👉 Aus der Praxis: Immer häufiger kommt es vor, dass „Migrationsberater“ das Migrationstool an Kunden gesondert vermieten, damit diese es ihm dann wieder als Beistellung überlassen. Interessante Konstellation mit unschönen rechtlichen Folgen für den Kunden.

Daten und Metadaten – und die Grenze zum Geschäftsgeheimnis

Besondere Brisanz entfaltet der Data Act bei der Pflicht zur Bereitstellung von Metadaten. Hierbei handelt es sich um eine strukturierte Beschreibung der Kundendaten. Sie sind notwendig, um die Kundendaten sinnvoll einzuordnen, zu interpretieren und weiterzuverarbeiten. Ohne sie bleiben Kundendaten formal portabel, aber wirtschaftlich kaum nutzbar.

👉 Metadaten werden u.a. benötigt für das Mapping vom Altsystem zum Zielsystem und für die Entwicklung des Migrationstools.

Gleichzeitig können Metadaten weit mehr sein als neutrale Beschreibungen. Sie können Rückschlüsse auf Systemarchitekturen, Optimierungslogiken oder interne Abläufe des Anbieters zulassen. Diese Interessenkollision hat der Data Act zu Lasten der Cloud-Anbieter gelöst:

Werden Informationen über die interne Funktionsweise des Dienstes durch die Nutzung des Datenverarbeitungsdienstes generiert und sind sie für einen ungehinderten und effizienten Wechsel notwendig, muss der Anbieter sie zum Export bereitstellen, und zwar auch dann, wenn die Gefahr der Verletzung von Geschäftsgeheimnissen besteht.

Soweit Informationen über die interne Funktionsweise des Dienstes nicht durch die Nutzung des Datenverarbeitungsdienstes generiert werden, fallen sie nicht unter die Definition von „exportierbare Daten“. Sind sie für einen ungehinderten und effizienten Wechsel notwendig, muss der Anbieter sie aber offenlegen.

In der Praxis wird es auf eine sorgfältige Abgrenzung ankommen, welche sowohl technisch als auch rechtlich gut begründet und behördentauglich dokumentiert werden muss.  

Was Anwender-Unternehmen daraus realistisch ableiten sollten

Der Data Act verbessert die Ausgangslage von Anwendern spürbar. Er schafft erstmals einen verbindlichen Rahmen für die Mitwirkungspflichten der Anbieter beim Wechsel. Gleichzeitig verlagert er Konflikte in neue Bereiche.

Für Anwender bedeutet das: Die neuen Rechte sind keine Selbstläufer. Sie müssen verstanden, eingeordnet und im konkreten Kontext durchgesetzt werden. Gerade bei komplexen Cloud-Umgebungen wird entscheidend sein, frühzeitig zu klären, welche Informationen, Schnittstellen und Metadaten tatsächlich benötigt werden – und wo legitime Grenzen der Anbieterpflichten verlaufen.

Im Rahmen meines Beitrags zum

👉 Fachbuch „Compliance-Handbuch EU Data Act“ – ISBN 978-3-452-30432-2.

habe ich die technischen Aspekten des Cloud-Switchings ausführlich beschrieben. Diese Kenntnisse sind erforderlich, um qualifiziert anwaltlich beraten zu können. Insbesondere geht es um Geschäftsgeheimnisse und Datenbankrechte, Syntax und Semantik, Daten und Metadaten sowie um weitere Aspekte, die ich in den vorherigen Beiträgen dieser Reihe erläutert habe:

👉 Link zu Beitrag 1: „Cloud-Wechsel: Warum gute Verträge allein nicht vor Abhängigkeit schützen“
https://trenchant-legal.de/cloud-wechsel-warum-gute-vertraege-allein-nicht-vor-abhaengigkeit-schuetzen/

👉 Link zu Beitrag 2: „Cloud ist nicht gleich Cloud – wie die Abstraktionsebene über den Aufwand des Exits entscheidet“
https://trenchant-legal.de/cloud-ist-nicht-gleich-cloud-wie-die-abstraktionsebene-ueber-den-aufwand-des-exits-entscheidet/

Kurzer Abschlussgedanke –

Der Data Act ist kein Befreiungsschlag, aber ein Instrument. Wie wirkungsvoll es ist, entscheidet sich nicht im Gesetzestext, sondern in seiner Anwendung. Genau dort beginnt die eigentliche Arbeit. 

Cloud ist nicht gleich Cloud: Wie die Abstraktionsebene über den Aufwand des Wechsels entscheidet

Posted on by Trenchant

Cloud ist nicht gleich Cloud: Wie die Abstraktionsebene über den Aufwand des Exits entscheidet

Wer über Cloud-Abhängigkeit spricht, spricht häufig abstrakt. In der Praxis entscheidet sich der spätere Aufwand und der Erfolg eines Exit jedoch an einer sehr konkreten Frage: Auf welcher Ebene nutzt das Unternehmen Cloud-Leistungen?

Infrastructure-, Platform- und Software-as-a-Service unterscheiden sich nicht nur im Funktionsumfang, sondern vor allem darin, in welcher Tiefe Teile der IT- und Prozesslandschaft vom Unternehmen gesteuert werden – und welche nicht.

Infrastruktur: Technisch austauschbar – organisatorisch beherrschbar

Infrastructure as a Service beschränkt sich im Kern auf die Bereitstellung technischer Ressourcen wie Rechenleistung, Speicher und Netzwerkinfrastruktur. Die Verantwortung für Applikationen, Datenstrukturen und Geschäftslogiken verbleibt weitgehend beim Unternehmen.

Diese Trennung ist für den Exit entscheidend. Beim Anbieterwechsel müssen zwar Systeme migriert und Betriebsumgebungen neu aufgebaut werden, die grundlegende Struktur der Applikationen bleibt jedoch erhalten. Daten behalten ihre Bedeutung, weil sie nicht durch plattformspezifische Funktionen oder Anwendungskontexte geprägt sind, sondern durch unternehmenseigene Modelle und Prozesse.

Der Wechsel ist damit primär eine technische und organisatorische Aufgabe. Er erfordert Planung, Koordination und Ressourcen, verändert jedoch nicht die Art und Weise, wie das Unternehmen arbeitet. Die Abhängigkeit vom Anbieter betrifft nur den Betrieb, nicht die Logik des Geschäfts. Sie ist daher vergleichsweise gering.

👉 Infrastruktur ermöglicht Skalierung und Flexibilität, ohne die Architektur oder die Prozesse des Unternehmens tiefgreifend zu prägen. Der Exit ist aufwendig, aber strukturell beherrschbar, weil das Unternehmen die Kontrolle über Applikationen und Datenmodelle behält.

Plattform: Wenn technische Entscheidungen strategische Wirkung entfalten

Platform as a Service verschiebt die Verantwortung weiter vom Unternehmen zum Anbieter. Neben der reinen Infrastruktur werden zentrale technische Bausteine genutzt, etwa Datenbankdienste, Laufzeitumgebungen oder Integrationskomponenten. Diese Dienste geben nicht nur technische Möglichkeiten vor, sondern definieren den Rahmen, in dem Softwareanwendungen entwickelt und betrieben werden.

Applikationen werden dadurch nicht „proprietär“ gestaltet. Vielmehr orientieren sich Architektur- und Designentscheidungen an den Funktionen und Standards der jeweiligen Plattform. Datenmodelle, Schnittstellen und Verarbeitungslogiken entstehen innerhalb dieses Rahmens, weil er Effizienz, Skalierbarkeit und Betriebssicherheit verspricht.

Dieses Setting hat Konsequenzen für den Exit. Zwar lassen sich Applikationen grundsätzlich portieren. Funktionen, die innerhalb der Plattform selbstverständlich verfügbar sind – etwa bestimmte Datenbankmechanismen, Event- oder Messaging-Strukturen oder integrierte Sicherheits- und Identitätsdienste – müssen jedoch bei einem Wechsel entweder nachgebildet oder neu konzipiert werden.

Der Wechsel betrifft damit nicht nur den Betrieb, sondern die Struktur der Apps selbst. Was technisch als Plattformwechsel erscheint, wird organisatorisch zu einem Architekturprojekt. Der Aufwand liegt weniger im Transfer von Daten oder Code als in der Wiederherstellung der Funktionslogik unter anderen technischen Voraussetzungen.

👉 Für Unternehmen bedeutet das: Entscheidungen, die auf Plattformebene getroffen werden, wirken strategisch, auch wenn sie operativ motiviert sind. Die Wahl einer Plattform bestimmt nicht nur Effizienz und Geschwindigkeit der Entwicklung, sondern auch die Komplexität eines späteren Wechsels.

Software: Wenn Anwendungen die Organisation strukturieren

Software as a Service unterscheidet sich grundlegend von Infrastruktur- und Plattformdiensten. Das Unternehmen nutzt hier nicht lediglich technische Ressourcen oder Entwicklungsumgebungen, sondern Softwareanwendungen, in denen Geschäftsprozesse, Entscheidungslogiken und Datenstrukturen unmittelbar und zunächst standardisiert abgebildet sind.

Unternehmensdaten werden dabei nicht isoliert gespeichert. Sie sind Teil eines funktionalen Gesamtzusammenhangs. Ihre Bedeutung ergibt sich aus der Art, wie die App sie verarbeitet, miteinander verknüpft und in Prozesse einbettet.

Mit der Zeit werden die Standards konfiguriert, erweitert und an individuelle Abläufe angepasst. Die Software übernimmt zunehmend Funktionen, die zuvor organisatorisch geregelt waren. Die Grenze zwischen IT-System und Organisation wird unscharf. Mit der Zeit bilden Workflows, Berechtigungen, Automatisierungen und Auswertungen die gesamte konkrete Arbeitsweise des Unternehmens ab.

Beim Exit zeigt sich die Konsequenz. Zwar lassen sich Daten regelmäßig exportieren, ihre wirtschaftliche Nutzbarkeit hängt jedoch davon ab, ob ihre Bedeutung außerhalb der Anwendung rekonstruierbar ist. Prozesse, die bislang implizit im System abgebildet waren, müssen nun – weil die gesonderte Dokumentation im Unternehmen selbst regelmäßig fehlt – explizit beschrieben werden. Entscheidungen, die die Software bislang automatisiert getroffen hat, müssen neu verortet werden.

Der Wechsel einer SaaS-Lösung ist daher kein reines Migrationsprojekt. Er betrifft Abläufe, Verantwortlichkeiten und Steuerungsmechanismen. Der Aufwand liegt weniger im technischen Transfer als in der Entflechtung einer über Jahre gewachsenen Struktur, in der Software und Organisation eng miteinander verwoben sind.

👉 Für Unternehmen bedeutet das: SaaS schafft nicht nur Effizienz, sondern strukturiert das Unternehmen mit. Diese Bindungswirkung ist kein Fehlverhalten, sondern die logische Folge intensiver Nutzung. Sie lässt sich nicht vollständig vermeiden – aber sie muss verstanden und gesteuert werden, wenn ein späterer Wechsel realistisch möglich bleiben soll.

Fazit

Cloud ist nicht gleich Cloud. Der Aufwand und das Risiko eines Anbieterwechsels hängen maßgeblich davon ab, auf welcher Ebene Cloud-Leistungen genutzt werden. Während Infrastruktur vor allem den Betrieb betrifft, prägen Plattformen die Architektur und SaaS-Anwendungen zunehmend die Organisation selbst. Mit jeder Abstraktionsebene verändert sich damit auch die Intensität der Abhängigkeit.

Warum diese Abhängigkeiten häufig erst beim Exit sichtbar werden, habe ich im ersten Beitrag dieser Reihe näher erläutert. Der vorliegende Beitrag zeigt, wodurch sie sich bei den jeweiligen Ebenen konkret unterscheiden und warum sie sich nicht allein durch vertragliche Regelungen beherrschen lassen.

Die hier dargestellten Zusammenhänge basieren auf meiner vertieften Auseinandersetzung mit Cloud-Wechseln und Exit-Szenarien im Rahmen meines Beitrags zum

👉 Fachbuch „Compliance-Handbuch EU Data Act“ – ISBN 978-3-452-30432-2

Die Analyse verbindet rechtliche Vorgaben mit der technischen und organisatorischen Realität von Unternehmen – genau an dieser Schnittstelle entstehen in der Praxis die entscheidenden Risiken.

Dies ist der zweite Beitrag einer Reihe –

👉 Link zu Beitrag 1: „Cloud-Wechsel: Warum gute Verträge allein nicht vor Abhängigkeit schützen“
https://trenchant-legal.de/cloud-wechsel-warum-gute-vertraege-allein-nicht-vor-abhaengigkeit-schuetzen/
Hier gehe ich noch näher auf die Aspekte zum Wechsel von SaaS-Anbietern ein.

👉 Beitrag 3: Cloud-Wechsel: Offene Schnittstellen, Metadaten, Informationen – Neue Pflichten der Anbieter nach Data Act
https://trenchant-legal.de/cloud-wechsel-offene-schnittstellen-metadaten-informationen/

Cloud-Wechsel: Warum gute Verträge allein nicht vor Abhängigkeit schützen

Posted on by Trenchant

Cloud-Wechsel: Warum weder der EU Data Act noch gute Verträge allein vor Abhängigkeit schützen – Ein Realitätscheck.

Seit dem 12. September 2025 sind die Regelungen des Data Act über den Wechsel von Cloud-Services anwendbar. Sie sollen Anwender vor Abhängigkeiten und unfairen Verträgen schützten, die diese Abhängigkeit noch verstärken. Was der Data Act übersieht: Abhängigkeiten haben ihre Wurzeln in erheblichem Ausmaß auch im Unternehmen der Anwender.

Was zu beachten ist:

Cloud-Abhängigkeit entsteht nicht beim Einstieg – sondern im Laufe der Zeit

Unternehmen verlagern ihre IT in die Cloud, um flexibler, effizienter und resilienter zu werden. In den meisten Fällen funktioniert das – zumindest am Anfang.

Ernsthafte Probleme zeigen sich Jahre später. Dann, wenn sich Geschäftsmodelle ändern, regulatorische Anforderungen steigen oder ein Anbieterwechsel strategisch sinnvoll erscheint. Plötzlich wird aus einer erfolgreichen Cloud-Nutzung eine unerwartete Abhängigkeit.

Auffällig ist dabei: Diese Abhängigkeit basiert selten nur auf schlechten Verträgen, fehlenden Rechten oder proprietären Datenformaten und Schnittstellen. In der Praxis scheitert der Exit an der Realität – an technischen Verflechtungen, organisatorischem Know-how-Verlust und fehlenden Strukturen für den Ausstieg.

 ☞ Cloud-Abhängigkeit ist in erheblichem Ausmaß das Ergebnis von Entscheidungen, die früh getroffen wurden – oft ohne den Exit mitzudenken.

Die unternehmerische Realität als „Root-Cause“ für die Abhängigkeit 

Die wirtschaftlich und technologisch sinnvolle Entscheidung für die Cloud entfaltet über die Zeit eine Bindungswirkung, die beim Einstieg und über die Laufzeit nicht nur vertraglich, sondern auch organisatorisch berücksichtigt werden muss:

 ☞ Der Kontrollverlust gegenüber dem Anbieter muss so weit wie möglich vermieden werden. 

Ein zentraler Faktor hierbei ist die Kontrolle über die eigenen Daten. Zwar lassen sich diese regelmäßig während und am Ende einer Vertragslaufzeit exportieren. Ihre wirtschaftliche Nutzbarkeit hängt jedoch davon ab, ob ihre Struktur, ihre Bedeutung und ihr Zusammenhang mit Geschäftsprozessen auch außerhalb des bestehenden Systems verständlich bleibt. In der Praxis ist das häufig nicht der Fall. Ein typisches Beispiel: Über Jahre werden die Standardprozesse der Anwendung an kundenspezifische Abläufe angepasst, Felder ergänzt, Verknüpfungen verändert, Automatisierungen aufgebaut. Die Daten und Prozesse „passen“ immer besser zum bestehenden System – verlieren aber gleichzeitig ihre Eigenständigkeit. Daten sind oft nur noch im Rahmen der Prozesse verständlich. Formal sind sie portabel. Faktisch sind sie ohne erheblichen Analyse- und Mapping-Aufwand kaum weiterverwendbar.

Diese technische Entwicklung wird durch organisatorische Effekte verstärkt. Mit der Auslagerung von IT-Leistungen verlagert sich auch Wissen: über Systemlogiken, Abhängigkeiten, Schnittstellen und Sonderfälle. Was im Unternehmen nicht mehr täglich benötigt wird, wird nicht weiter gepflegt.

☞ Dokumentationen veralten, interne Expertise schrumpft, Verantwortung diffundiert zwischen Anbieter, Dienstleistern und internen Teams.

Die Folge ist eine schleichende Verschiebung der Steuerungsfähigkeit. Das Unternehmen bleibt rechtlich handlungsfähig, verliert aber faktisch an Überblick. Entscheidungen über Anpassungen, Erweiterungen oder einen späteren Wechsel können nur noch auf Basis der Informationen getroffen werden, die der bestehende Anbieter bereitstellt. Genau hier entsteht der eigentliche Lock-in-Effekt: nicht als bewusste Bindung, sondern als Nebenfolge effizienter Zusammenarbeit. Verträge bilden diese Entwicklung i.d.R. nur unvollständig ab. Sie bleiben – bedauerlicherweise – meist statisch, während sich Technik, Prozesse und Organisation dynamisch weiterentwickeln.

Aus unternehmerischer Sicht ist das kein Versagen, sondern ein realistisches Szenario. Problematisch wird es erst dann, wenn diese Realität beim Exit auf eine Erwartung trifft, die von formaler Austauschbarkeit ausgeht. Der Aufwand, die gewachsene Struktur zu entflechten, wird dann regelmäßig unterschätzt – in Zeit, Kosten und Managementaufmerksamkeit.

Warum der Exit der teuerste Moment eines Cloud-Vertrags ist

Der Exit aus einem Cloud-Vertrag ist selten ein ausreichend langfristig vorbereitetes Projekt. Erfahrungsgemäß erfolgt er nicht aus einer Position der Ruhe, sondern unter Zeit- und Entscheidungsdruck. Dann zeigt sich, dass auch vom bisherigen Anbieter bereitgestellte Daten samt Metadaten nicht ausreichen, um das Projekt erfolgreich abzuschließen. Der tatsächliche Aufwand beginnt erst dann – im Migrationsprojekt mit dem neuen Anbieter.

Die Daten müssen bereinigt, analysiert und neu zugeordnet werden. Die neue Zuordnung übernehmen oft so genannte „Migrationsroutinen“ automatisch. Aber nicht nur die vorher erforderliche Bereinigung der Daten, sondern auch die Dokumentation bestehender Geschäftsprozesse und damit der Anforderungen an die neue Software überfordern viele Unternehmen.

Geschäftslogiken, die über Jahre in der Anwendung abgebildet wurden, lassen sich nicht ohne Weiteres in eine neue Umgebung übertragen. Was technisch möglich ist, erweist sich organisatorisch und wirtschaftlich als hochkomplex.

Der Aufwand hierfür wird häufig unterschätzt – insbesondere, wenn internes Know-how in den Jahren zuvor abgebaut wurde.

Der regulatorische Rahmen verschärft diese Situation sogar. 

Nach dem Data Act muss der Wechsel zwischen Cloud-Anbietern grundsätzlich innerhalb eines klar begrenzten Zeitraums von bis zu 7 Monaten vollzogen sein. Für komplexe, historisch gewachsene Cloud-Umgebungen ist diese Frist kaum einzuhalten, wenn der Exit bzw. der Anbieterwechsel nicht frühzeitig vorbereitet wurde. Was als Schutz vor Lock-in gedacht ist, kann sich dann in einen erheblichen zusätzlichen Zeit- und Steuerungsdruck verwandeln.

Hinzu kommt, dass der bestehende Anbieter in dieser Phase faktisch zum Engpass wird. Selbst bei kooperativer Unterstützung bleibt das Unternehmen auf Informationen angewiesen, die nur dort verfügbar sind. Der Handlungsspielraum ist formal vorhanden, praktisch aber eingeschränkt. Kosten entstehen nicht nur durch technische Leistungen, sondern auch durch verlängerte Vertragslaufzeiten, Parallelbetrieb oder kurzfristige Übergangslösungen.

Der Exit wird damit zum teuersten Moment des Cloud-Vertrags – nicht, weil er überraschend ist, sondern weil seine Voraussetzungen lange nicht aktiv gestaltet wurden.

Für Geschäfts- IT-Leitungen ist das eine kritische Erkenntnis. Denn in dieser Phase geht es nicht mehr um Optimierung, sondern um Schadensbegrenzung.

Der Data Act ändert die Rechtslage – aber nicht die Ausgangssituation

Der Data Act macht den Anbieterwechsel rechtlich erzwingbar. Er setzt allerdings voraus, dass Unternehmen ihre Daten, Prozesse und Systemzusammenhänge in einer Form beherrschen, die einen strukturierten Übergang erlaubt. Wo diese Voraussetzungen fehlen, entsteht kein rechtliches Hindernis, sondern ein praktisches.

Der Data Act schützt vor formaler Blockade, nicht vor gewachsener Komplexität. Er erleichtert den Wechsel dort, wo er vorbereitet ist – und erhöht den Druck dort, wo er es nicht ist.

☞ Für Unternehmen bedeutet das: Regulierung ersetzt keine Exit-Strategie.

Was Geschäfts- und IT-Leitungen daraus ableiten sollten

Cloud-Nutzung ist heute eine strategische Notwendigkeit. Entscheidend ist jedoch, ob sie als dauerhaftes Abhängigkeitsverhältnis oder als steuerbares Geschäftsmodell verstanden wird. Der Unterschied liegt nicht im Vertrag, sondern in der Art, wie Entscheidungen über Technik, Organisation und Verantwortung getroffen werden.

Für Geschäfts- und IT-Leitungen bedeutet das vor allem eines: Der Exit ist kein Randthema, sondern Teil der Cloud-Strategie. Wer ihn erst am Vertragsende betrachtet, reagiert auf Entwicklungen, die längst stattgefunden haben. Wer ihn früh mitdenkt, behält Handlungsfähigkeit – auch unter regulatorischem und wirtschaftlichem Druck.

Der Data Act kann diese Handlungsfähigkeit unterstützen. Er ersetzt sie nicht. Unternehmen, die ihre Abhängigkeiten kennen und steuern, werden von neuen Wechselrechten profitieren. Unternehmen, die den Exit der Technik überlassen, werden auch durch Regulierung nicht beweglicher.

Fazit:

Abhängigkeit entsteht nicht durch einzelne Entscheidungen, sondern durch deren Zusammenspiel über Zeit. Sie lässt sich nicht vollständig vermeiden – aber sie lässt sich gestalten. Dafür braucht es keinen radikalen Kurswechsel, sondern einen nüchternen Blick auf die eigene Realität.

Verträge allein helfen hier wenig. Sie können Rechte, Pflichten und Risikokosten regeln. Aber auch eine wirksame Exit-Strategie ist rechtlich gebotene Governance-Aufgabe, die nach zahlreichen Gesetzen über Unternehmensführung und EU-Digitalrecht gestaltet werden muss.

Abschließend

Die hier dargestellten Zusammenhänge basieren auf meiner vertieften Auseinandersetzung mit Cloud-Wechseln und Exit-Szenarien im Rahmen meines Beitrags zum

👉 Fachbuch „Compliance-Handbuch EU Data Act“ – ISBN 978-3-452-30432-2

Die Analyse verbindet rechtliche Vorgaben mit der technischen und organisatorischen Realität von Unternehmen – genau an dieser Schnittstelle entstehen in der Praxis die entscheidenden Risiken.

Es handelt sich um den ersten Beitrag einer Reihe –

👉 Beitrag 2: Cloud ist nicht gleich Cloud – wie die Abstraktionsebenen über den Aufwand des Wechsels entscheiden.
https://trenchant-legal.de/cloud-ist-nicht-gleich-cloud-wie-die-abstraktionsebene-ueber-den-aufwand-des-exits-entscheidet/

👉 Beitrag 3: Cloud-Wechsel: Offene Schnittstellen, Metadaten, Informationen – Neue Pflichten der Anbieter nach Data Act
https://trenchant-legal.de/cloud-wechsel-offene-schnittstellen-metadaten-informationen/

Vor diesem Hintergrund bedarf der Projektvertrag mit dem neuen Anbieter einer gründlichen Vorbereitung in Kenntnis der eigenen Rechte und Pflichten. Ein erfolgreiches Migrationsprojekt kann keine Fußnote im SaaS-Vertrag mit dem neuen Anbieter sein. Dafür sind die Risiken zu groß.

NIS-2 für Unternehmen mit ISO-27001-Zertifizierung – Warum das Zertifikat allein nicht reicht

Posted on by Trenchant

NIS-2 für Unternehmen mit ISO-27001-Zertifizierung –
Warum das Zertifikat allein nicht reicht.

Die Anforderungen an Informationssicherheit steigen stetig – besonders für Cloud-, Rechenzentrums- und andere IT-Anbieter. Viele Unternehmen verlassen sich auf ihr ISO-27001-Zertifikat, ohne zu wissen, dass die NIS-2-Durchführungsverordnung für sie deutlich weitergehende operative Nachweise verlangt. Wer die Unterschiede nicht kennt, riskiert Bußgelder, Haftung und Reputationsschäden. In diesem Beitrag zeige ich kompakt, worauf es bei NIS-2 ankommt und wie ISO 27001 als solide Basis optimal ergänzt werden kann.

– Veröffentlicht am 25. August 2025 · Aktualisiert am 03. Januar 2026 –

Dringlichkeit für IT-Anbieter

Die zunehmende Vernetzung von Menschen und Produkten bietet immer größere Angriffsflächen für Korruption und schwerwiegende Cyberangriffe. Auch unter Innovations- und Kostendruck muss die Sicherheit der zugrundeliegenden Netz- und Informationssysteme daher gewährleistet sein. Mit der NIS-2-Richtlinie hat die EU den Rahmen dafür neu gesetzt. Während Deutschland mit der nationalen Umsetzung bis Dezember 2025 in Verzug war, hatte die EU für bestimmte Sektoren längst Fakten geschaffen:

Für Betreiber von Internet-Knoten, Domänennamensystem-Diensteanbieter (ausgenommen Root-Namenservern), TLD-Namensregister, Anbieter von Cloud- und Rechenzentrumsdiensten, Betreiber von Inhaltszustelldiensten, Vertrauensdiensteanbieter, Anbieter öffentlicher elektronischer Kommunikationsnetze, Anbieter öffentliche zugänglicher elektronischer Kommunikationsdienste, Anbieter verwalteter Dienste (Dienste im Zusammenhang mit der Installation, der Verwaltung, dem Betrieb oder der Wartung von IKT-Produkten, Netzen, Infrastruktur, Anwendungen oder jeglicher anderer Netz- und Informationssysteme durch Unterstützung oder aktive Verwaltung erbringt) und Anbieter verwalteter Sicherheitsdienste gilt seit dem 07.11.2024 unmittelbar die

NIS-2-Durchführungsverordnung (NIS-2-DV).

Sie enthält verbindliche Anforderungen, die unbeschadet des deutschen Umsetzungsgesetzes als sektorale Sonderregelungen unmittelbar einzuhalten sind. Abzustellen ist auf die einzelne rechtliche Einheit – ein Konzernprivileg gibt es nicht.

Auf den ersten Blick ähneln viele der Anforderungen bekannten Standards wie der ISO/IEC 27001. Deshalb verweisen z.B. XaaS-Anbieter oft auf ihre bestehende Zertifizierung, wenn es um NIS-2-Compliance geht. Doch ein Zertifikat allein reicht nicht. Die Durchführungsverordnung ist präziser und umfassender. Selbst Unternehmen mit etabliertem ISMS müssen prüfen, wo zusätzliche Maßnahmen erforderlich sind.

 

ISO 27001: Managementsystem im Fokus

Die ISO 27001 ist ein bewährter Standard für Informationssicherheitsmanagement. Sie hilft Unternehmen, Cyberrisiken strukturiert anzugehen und für selbst definierte Bereiche Prozesse sowie Mindestmaßnahmen zu etablieren. 

Auditoren prüfen dabei vor allem:

  • Gibt es ein Managementsystem?
  • Sind die von der Norm geforderten Prozesse dokumentiert?
  • Wird die kontinuierliche Verbesserung des Managementsystems nachgewiesen?

Fazit: ISO/IEC 27001 ist eine solide Grundlage – bleibt aber auf der Ebene von Managementsystemen und Prozessnachweise.

NIS-2: Operative Umsetzung im Detail

NIS-2 geht deutlich weiter. Gefordert ist nicht nur ein System „auf dem Papier“, sondern der Nachweis, dass Sicherheitsmaßnahmen im Alltag wirksam greifen. 

Wichtige Unterschiede:

IT-Grundschutz als Maßstab: Während ISO 27001 darauf abzielt nachzuweisen, dass ein angemessener Werkzeugkasten zur Herstellung von IT-Sicherheit für einen selbst definierten Scope vorhanden ist, verlangt NIS-2 – ähnlich wie der BSI-Grundschutz – dass ein verbindlicher Werkzeugkasten im gesamten Unternehmen eingesetzt wird und nachweislich IT-Sicherheit schafft.

Berechtigungsmanagement: Es reicht nicht, Regeln festzuschreiben. Revisoren und Behörden prüfen, ob Zugriffsrechte tatsächlich regelmäßig implementiert, kontrolliert und entzogen werden – systemgenau und auf Revisionsniveau, denn NIS-2-DV ist ein Gesetz. 

Reifegradmodelle: Organisationen müssen darlegen, wie weit ihre Maßnahmen entwickelt sind und wie sie Fortschritte messen. Ein Konzept, das die ISO 27001 nicht kennt.

 

Praxisbeispiel: ISO-Zertifikat – und trotzdem nicht NIS-2-konform

In einem von mir begleiteten Projekt zeigte sich das sehr deutlich: 

  • Das Unternehmen war nach ISO 27001 zertifiziert und wähnte sich NIS-2-konform.
  • Prüfungsergebnis:
    • Das Berechtigungsmanagement war dokumentiert, aber nicht operativ auf NIS-2-Niveau umgesetzt.
    • Ein Reifegradmodell zur Bewertung der Sicherheitsmaßnahmen fehlte
    • Vorgaben des IT-Grundschutzes wurden nicht berücksichtigt, weil sie in der ISO/IEC 27001 gar nicht vorgesehen sind.
    • Beispiel: Regelmäßige systemgenaue Rechteprüfungen wurden nicht durchgeführt, obwohl NIS-2 dies zwingend verlangt.

Fazit: Ohne Nachbesserungen wäre das Unternehmen bei einer NIS-2-Prüfung durchgefallen – trotz Zertifikat. Erst durch die Ergänzung um Grundschutz-Elemente und den Aufbau eines Reifegradmodells konnte die Compliance-Lücke geschlossen werden.Dieses Beispiel macht deutlich: ISO 27001 ist eine gute Basis – ersetzt NIS-2 aber nicht. 

Wo entsteht die gefährliche Lücke?

Viele Unternehmen mit ISO/IEC-Zertifikat – und ihre Kunden, die sich darauf verlassen – wiegen sich in Sicherheit. Doch NIS-2 verlangt weitere operative Nachweise, die in der ISO/IEC 27001 gar nicht vorgesehen sind.

Das Risiko:

  • Ein ISO-Audit wird bestanden – eine NIS-2-Prüfung dagegen nicht.
  • Geschäftsleitung haftet persönlich.
  • Bußgelder und Reputationsschäden drohen.

Besonders kritisch: Verantwortung liegt explizit bei Geschäftsführung und Vorstand – nicht allein bei der IT.

Der richtige Ansatz: Brücke zwischen ISO und NIS-2

  • Ergänzende NIS-2-spezifische Maßnahmen schließen die Lücken
  • Ein ganzheitlicher Reifegrad-Ansatz ist unverzichtbar

Checkliste für Unternehmen: 

  • Welche NIS-2-Anforderungen werden bereits durch ISO/IEC 27001 und 27002 abgedeckt?
  • Welche weiteren Werkzeuge aus diesen Normen können genutzt werden, um Lücken zu schließen?
  • Wo sind Elemente des BSI-Grundschutz notwendig?
  • Welche Anforderungen der NIS-2-DV gehen darüber hinaus und wie können sie umgesetzt werden?
  • Welche Maßnahmen sind zwar umgesetzt, aber noch nicht nachweisbar dokumentiert? 

Fazit: Machen Sie eine Bestandsaufnahme und lassen Sie sich rechtlich beraten

Die Zeiten, in denen ein ISO-Zertifikat als „Schutzschild“ genügte, sind vorbei. NIS-2 verlangt mehr – Behörden prüfen wie Revisoren (detailliert und operativ), nicht wie Auditoren.

Für Geschäftsleitungen bedeutet das:

  • Ignorieren ist keine Option.
  • Haftung und Verantwortung sind nicht delegierbar.
  • Nur ein an NIS-2 angepasster Sicherheitsrahmen schafft echte Rechtssicherheit.

FAQ: ISO/IEC 27001 und NIS-2

Reicht ISO 27001 für NIS-2 aus?
☞ Nein. ISO 27001 prüft das Vorhandensein eines Managementsystems; NIS-2 verlangt den Nachweis, dass Maßnahmen unternehmensweit tatsächlich umgesetzt werden.

Welche zusätzlichen Anforderungen stellt NIS-2?
☞ Unter anderem Reifegradmodelle, ein stärkerer Bezug zum IT-Grundschutz sowie detaillierte operative Nachweise, z. B. beim Berechtigungsmanagement.

Was bedeutet das für mein Unternehmen?
☞ Ein ISO-Zertifikat ist eine gute Basis, ersetzt aber keine NIS-2-Compliance. Unternehmen sollten prüfen, welche Lücken bestehen, und diese gezielt schließen.

Wer ist verantwortlich für die Umsetzung von NIS-2?
☞ Die Verantwortung liegt ausdrücklich bei Geschäftsführung und Vorstand. Die IT-Leitung kann das nicht übernehmen.

Welche Folgen drohen bei NIS-2-Verstößen?
☞ Bußgelder, aufsichtsrechtliche Maßnahmen und erhebliche Haftungsrisiken für die Geschäftsleitung.

Jetzt handeln: Haben Sie ein ISO 27001-Zertifikat und möchten wissen, ob Ihr Unternehmen NIS-2-konform ist? Dann prüfen Sie jetzt Ihre Lücken und handeln Sie gezielt. 

EU-Gesetz zur Förderung von Cloud-Kapazitäten und KI-Entwicklung

Posted on by Trenchant

EU-Gesetz zur Förderung von Cloud-Kapazitäten und KI-Entwicklung – Mehr als GAIA-X 2.0

Die Europäische Kommission plant einen neuen Rechtsrahmen zur Förderung nachhaltiger Rechenzentren und sicherer Cloud-Dienste. Ziel ist es, Europas digitale Souveränität und Wettbewerbsfähigkeit zu stärken – insbesondere im Hinblick auf KI-Anwendungen.

Ziel und Hintergrund

Am 9. April 2025 stellte die EU-Kommission einen ehrgeizigen „Aktionsplan“ für einen europäischen KI-Kontinent vor, dessen Ziel es ist, auf dem Gebiet der künstlichen Intelligenz weltweit führend zu werden – und das am besten auf Basis digitaler Souveränität. Als Hemmnis für dieses Ziel wurde u.a. das zunehmende Ungleichgewicht zwischen dem wachsenden Bedarf und den aktuell verfügbaren Rechenkapazitäten in der EU ausgemacht. Während die USA und China bei Rechenzentren führend sind, besteht in Europa erheblicher Nachholbedarf. So will die Kommission nun ein Netz von KI-Fabriken aufbauen – ein gutes Dutzend davon sollen bereits im Umfeld weltweit führender Supercomputer in Europa in der Entstehung sein. Im „Kompass für Wettbewerbsfähigkeit“ kündigte die EU zudem die Einrichtung von KI-Gigafabriken an, sofern dies für erforderlich erachtet wird. Ein entsprechender „Call for expression of interest“ läuft bereits: 

https://eurohpc-ju.europa.eu/document/download/47492db7-592e-4ad8-b672-9c822f94afa0_en?filename=AI%20GIGAFACTORIES%20CONSULTATION.pdf

Um Anreize für ➡ Investitionen des Privatsektors in Cloud-Kapazitäten und Rechenzentren zu schaffen, schlägt die Kommission zudem einen „Rechtsakt über Cloud- und KI-Entwicklung“ vor.

Inhalte des geplanten Rechtsaktes

Das Vorhaben zielt darauf ab, den derzeit ungünstigen Bedingungen für den Privatsektor für den Aufbau von Rechenkapazitäten abzuhelfen. Dabei stehen nicht nur technische, sondern auch rechtliche und wirtschaftliche Rahmenbedingungen im Fokus. Im Einzelnen geht es um

  • die Förderung von Forschung und Innovation zur Verbesserung des Energiemanagements, der Kühlung, des allgemeinen Betriebs und der Integration in Energie- und Wasserversorgungssysteme zur Errichtung effizienter und nachhaltiger Rechenzentren;
  • Anreize und Unterstützung von Investitionen in nachhaltige Rechenzentren durch Abbau von Hürden wie langen Genehmigungszeiten und Schwierigkeiten beim Zugang zu Energie, Wasser, Grund und Boden sowie Kapital und durch Bereitstellung möglicher finanzieller Unterstützung;
  • die Schaffung hochsicherer, in der EU angesiedelter Cloud-Kapazitäten für bestimmte hochkritische Anwendungsfälle, etwa im Bereich kritischer Infrastrukturen.

Regulierungsoptionen und Konsultationsprozess

Die Kommission prüft aktuell verschiedene Regulierungsoptionen – von unverbindlichen Leitlinien über eine Richtlinie bis hin zu einer umfassenden Verordnung mit zentraler Durchsetzungsbehörde. Die bevorzugte Option soll dabei nicht nur für einheitliche Mindeststandards sorgen, sondern auch gemeinsame Investitionen der Mitgliedstaaten in ein europäisches Cloud-Ökosystem ermöglichen.

Für IT-Unternehmen und industrielle Anwender ergeben sich hieraus potenziell weitreichende Veränderungen – nicht nur in der Nutzung von Cloud- und KI-Diensten, sondern auch bei der Auswahl von Anbietern, der Planung eigener Infrastrukturprojekte und der Integration in europäische Wertschöpfungsketten. Auch rechtlich ist mit neuen Anforderungen und Kooperationsmöglichkeiten zu rechnen, etwa bei der Vergabe öffentlicher Aufträge, der Nutzung von Fördermitteln oder der Umsetzung von Nachhaltigkeitsvorgaben.

Im Laufe des Jahres 2025 wird eine umfassende Folgenabschätzung durchgeführt, bei der auch Unternehmen und Stakeholder zur Mitwirkung eingeladen sind. Für Akteure aus der Digitalwirtschaft empfiehlt es sich, diese Entwicklung aktiv zu begleiten – nicht zuletzt, um die eigenen Interessen frühzeitig einzubringen und sich auf kommende regulatorische Anforderungen vorzubereiten.

Vergleich Europäische Cloud vs. EU-Rechtsakt zu Cloud- und KI-Infrastruktur

Weiterführende Links:

Möglichkeit zur Einsicht in das Papier und zur Mitwirkung (Call for evidence): 
https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/14628-Cloud-and-AI-Development-Act_en

Aktionsplan der EU für einen KI-Kontinent:
https://ec.europa.eu/commission/presscorner/detail/de/ip_25_1013

KI-Training: Web-Crawling vs. Urheberrecht

Posted on by Trenchant

KI-Trainingsdaten aus dem Netz
Web-Crawling vs. Urheberrecht –
1:0 für Innovation

Für das grundlegende Training von KI-Modellen bedarf es einer möglichst großen Menge qualitativ hochwertiger Daten. Diese können von Datenplattformen bezogen oder aus dem Internet generiert werden. Letzteres, auch Web-Crawling oder Data Mining genannt, ging bisher für Unternehmen mit erheblichen rechtlichen Unsicherheiten einher, denn die im Internet verfügbaren Bilder und Texte (Werke) sind im Grundsatz erstmal urheberrechtlich geschützt, ihre Nutzung von der Zustimmung des Urhebers abhängig.

Rechtliche Grundlagen

Verfassungsrechtliche Grundlagen des Urheberrechts sind Art. 14 Abs. 1 GG und Art. 17 Satz 1 EU-Grundrechtscharta (GRCh), die den Schutz des Eigentums gewährleisten. Allerdings unterliegt dieses Recht Schranken, da gemäß Art. 14 Abs. 2 GG und Art. 17 Satz 3 GRCh Eigentum auch der Allgemeinwohlverpflichtung unterliegt. Entsprechend müssen Ausnahmen die Entwicklung und den Einsatz neuer Technologien zum gesellschaftlichen Nutzen rechtlich sicher ermöglichen und gewährleisten, siehe auch EuGH, Urteil vom 05.06.2014 – C-360/13. Gewicht hat in diesem Zusammenhang zudem das Grundrecht der unternehmerische Freiheit der KI-Trainer aus Art. 12 GG und Art. 16 GRCh, das mit dem Urheberrecht in Ausgleich zu bringen ist ➡ Grundrechtsabwägung. 

Um in der Privatwirtschaft Innovationen anzuregen, definierte die EU im Jahr 2019 darauf basierend mit der so genannten DSM-Richtlinie (Richtlinie (EU) 2019/790) den Begriff des Text und Data Mining und legte Ausnahmen vom Urheberrechtsschutz fest. Dem unternehmerischen KI-Trainer wurde ohne Zustimmung des Urhebers ermöglicht, Kopien der Werke anzufertigen und so lange wie zum Zweck des Text und Data Mining erforderlich aufzubewahren. 

Umsetzung der Richtlinie in deutsches Recht

Die Richtlinie wurde mit Wirkung zum 07.06.2021 in Deutschland umgesetzt:

§ 44b UrhG

(1) Text und Data Mining ist die automatisierte Analyse von einzelnen oder mehreren digitalen oder digitalisierten Werken, um daraus Informationen insbesondere über Muster, Trends und Korrelationen zu gewinnen.

(2) Zulässig sind Vervielfältigungen von rechtmäßig zugänglichen Werken für das Text und Data Mining. Die Vervielfältigungen sind zu löschen, wenn sie für das Text und Data Mining nicht mehr erforderlich sind.

(3) Nutzungen nach Absatz 2 Satz 1 sind nur zulässig, wenn der Rechtsinhaber sich diese nicht vorbehalten hat. Ein Nutzungsvorbehalt bei online zugänglichen Werken ist nur dann wirksam, wenn er in maschinenlesbarer Form erfolgt.

Der Wortlaut des § 44b UrhG scheint auf den ersten Blick eindeutig. Tatsächlich gibt es aber auch hier eingehende Diskussionen. Ein wesentlicher Aspekt ist, dass eine wichtige europarechtliche Vorgabe zum Schutz der Urheber vom deutschen Gesetzgeber nicht umgesetzt wurde. Aus Art. 5 Abs. 5 InfoSoc-RiLi iVm Art. 7 Abs. 2 S. 1 DSM-RiLi ergibt sich: 

➡ § 44b UrhG darf „nur in bestimmten Sonderfällen angewandt werden, in denen die normale Verwertung des Werks oder des sonstigen Schutzgegenstands nicht beeinträchtigt wird und die berechtigten Interessen des Rechtsinhabers nicht ungebührlich verletzt werden.“

Klarstellungen des Landgericht Hamburg

  1. Die Berufung des Urhebers auf Art. 5 Abs. 5 InfoSoc-RiLi iVm Art. 7 Abs. 2 S. 1 DSM-RiLi mit der Behauptung, dass Text und Data Mining immer zu einer ungebührlichen Verletzung der Interessen des Rechtsinhabers führt, überzeugte das Gericht nicht. Beim Zusammenstellen des Trainigssatzes (1. Handlung) mag die Nutzung zur Herstellung eines konkurrierenden Werks zwar angestrebt sein, absehbar ist aber weder, ob das Training (2. Handlung) erfolgreich sein wird, noch welche konkreten Inhalte mit der trainierten KI generiert  werden (3. Handlung). Bei der Bewertung der Rechtmäßigkeit der Vervielfältigungshandlung zum Zweck der Erstellung des Trainingsdatensatzes könne es wegen der anderenfalls entstehenden Rechtsunsicherheit allein auf den Einfluss dieser Handlung auf die Rechtsposition des Urhebers ankommen und dieser sei nicht ungebührlich. Jede andere Bewertung würde dem Zweck der Innovationsförderung gänzlich zuwiderlaufen. Die Risiken für KI-Trainer wären schlicht nicht akzeptabel. 
  2. Eine in der juristischen Literatur teilweise geforderte einschränkende Auslegung (teleologische Reduktion) dahingehend, dass mit § 44b Abs. 1 UrhG nur die Erschließung der „in den Daten verborgenen Information“, nicht aber die Nutzung des „Inhalts der geistigen Schöpfung“ ausnahmsweise erlaubt sei, überzeugt nach Auffassung des Gerichts nicht, weil eine hinreichend rechtssichere Abgrenzung der verborgenen Informationen von dem Inhalt der geistigen Schöpfung nicht möglich ist. 
  3. Davon abgesehen habe der europäische Gesetzgeber mit Art. 53 Abs. 1 lit. c) KI-VO unzweifelhaft zum Ausdruck gebracht, dass die Erstellung von zum Training künstlicher neuronaler Netze bestimmten Datensätzen durch Text und Data Mining grundsätzlich zulässig ist, wenn a) der Urheber nicht in maschinenlesbarer Form einen diesbezüglichen Vorbehalt erklärt hat (§ 44b Abs. 3 UrhG), b) die normale Verwendung des Schutzgegenstandes nicht beeinträchtigt wird und c) die berechtigten Interessen des Rechtsinhabers nicht ungebührlich verletzt werden, s.o.

Fazit

Das Landgericht Hamburg hat sich in diesem ersten deutschen Urteil zum Thema

Text und Data Mining zum Zweck des KI-Training

deutlich zum Erfordernis der Rechtsklarheit zu Gunsten der Innovation bekannt. Einschränkungen dieser Technologie müssen für Entwickler so klar sein, dass rechtliche Risiken erkannt und bewertet werden können.

Quellen

LG Hamburg, Urt. v. 27.09.2024 – 310 O 227/23
EuGH, Urt. v. 05.06.2014, Az. C-360/13, Rn. 43 
EuGH, Urt. v. 16.07.2009, Az. C-5/98

  • Richtlinie 2001/29/EG des EP und des Rates vom 22.5.2001 zur Harmonisierung bestimmter Aspekte des Urheberrechts und der verwandten Schutzrechte in der Informationsgesellschaft (InfoSoc-RiLi)
  • Richtlinie (EU) 2019/790 des EP und des Rates vom 17.4.2019 über das Urheberrecht und die verwandten Schutzrechte im digitalen Binnenmarkt und zur Änderung der Richtlinie 96/9/EG und 2001/29/EG (DSM-RiLi)

Data Act – Teilen von Geschäftsgeheimnissen

Posted on by Trenchant

Data Act – Machen Sie aus Daten Geschäftsgeheimnisse

Nach einem mehrjährigen Gesetzgebungsprozess ist am 11.01.2024 der Data Act (DA) in Kraft getreten. Er gilt in seinen wesentlichen Teilen ab dem 12.09.2025. Von besonderer Bedeutung für Hersteller von Produktionsmaschinen, Medizingeräten oder anderen vernetzten Produkten ist der Schutz von Geschäftsgeheimnissen. Auf diesen werden sich nur gut vorbereitete Unternehmen erfolgreich berufen können.

Um welche Daten geht es?


Es geht um Daten, die bei der Nutzung vernetzter Produkte entstehen und von datengenerierenden Sensoren oder Systemen erfasst werden. Außerdem geht es um Daten von sogenannten „verbundenen Diensten“. Interessant sind solche Daten, weil mit ihnen komplementäre Leistungen erbracht oder KI-Modelle trainiert werden können. Soweit der DA nun anordnet, dass der Nutzer der Maschine oder des Geräts die Bereitstellung dieser Daten an sich oder an einen Dritten verlangen kann, ist das wettbewerbsrechtlich relevant. Aus diesem Grund hat der Gesetzgeber dem Hersteller gewisse Möglichkeiten an die Hand gegeben, sich zu schützen. Unter engen Voraussetzungen kann der Hersteller die Bereitstellung der Daten unter Berufung auf das Geschäftsgeheimnisgesetz (GeschGehG) verweigern.

Was sind überhaupt Geschäftsgeheimnisse?


Bis zum 25.04.2019 waren im „geschäftlichen Verkehr anvertraute Vorlagen oder Vorschriften technischer Art“ (Geschäftsinformationen) per Gesetz geschützt. Die unbefugte Verwendung oder Mitteilung an Dritte war strafbar. Vertraulichkeitsvereinbarungen mit Kunden oder Lieferanten umfassten, wenn sie überhaupt geschlossen wurden, alle übergebenen oder offengelegten Informationen (catch-all-Vereinbarung). Besondere Schutzmaßnahmen, wie z.B. die verschlüsselte Übertragung oder Speicherung, waren selten Gegenstand der Regelungen.

Relativ unbeachtet hat sich diese Rechtslage aber mit dem Inkrafttreten des GeschGehG am 26.04.2019 fundamental geändert.

Seitdem sind Geschäftsinformationen nur dann geschützt, wenn sie – verkürzt

a) von wirtschaftlichem Wert sind, weil sie Dritten nicht bekannt sind,
b) wenn der Unternehmer ein berechtigtes Interesse an der Geheimhaltung hat und
c) wenn sie Gegenstand von „den Umständen nach angemessenen Geheimhaltungsmaßnahmen“ sind.

Hierbei handelt es sich um konstitutiven Voraussetzungen. Werden sie nicht erfüllt, sind Ihre Geschäftsinformationen keine Geschäftsgeheimnisse i.S.d. GeschGehG und damit auch nicht i.S.d. DA.

Was sind „den Umständen nach angemessene“ Geheimhaltungsmaßnahmen?

Zu den geforderten Geheimhaltungsmaßnahmen gehören sowohl technische und organisatorische Maßnahmen (TOM) als auch der Abschluss qualifizierter Vertraulichkeitsvereinbarungen. So genannte „Catch-all-Vereinbarungen“ genügen nicht mehr.

Die Vereinbarungen müssen nun die Geschäftsinformationen in verschiedene Klassen einteilen und dann für jede Klasse angemessene technische und organisatorische Maßnahmen (TOM) vorschreiben. Wer ISO/IEC 27001-zertifiziert ist, kennt das aus „Control“ A.5.12 i.V.m. der „Informationssicherheit in Lieferantenbeziehungen“.

Etabliert haben sich in Deutschland in Anlehnung an BSI-Standard 200-2 Klassen wie a) offen, b) intern, c) vertraulich und d) streng vertraulich.  Werden hier Fehler gemacht, kann das zur Unwirksamkeit der Vereinbarung führen, denn strengste Vorgaben für nur „interne“ Informationen könnten „überraschend“ i.S.d. deutschen AGB-Rechts sein.

Hersteller vernetzter Produkte sollten bis spätestens 11.09.2025 sicherstellen, dass sensible Daten, die nach dem DA dem Nutzer oder sogar Dritten zugänglich gemacht werden müssten „Geschäftsgeheimnisse“ in diesem Sinne sind. Wenn das schon nicht gegeben ist, braucht man die Schutzmöglichkeiten nach dem DA gar nicht erst prüfen.

Konkret

  • Sammeln oder verarbeiten Sie die generierten Daten in einer fremden SaaS-Lösung?
  • Möchten Sie die Daten einem Datenpool oder einem KI-Trainer zur Verfügung stellen?
  • Werden Sie fremde Service-Unternehmen mit der Wartung des vernetzten Produkts beauftragen?

Dann sollten Sie mit diesen Anbietern geeignete Vereinbarungen zum Schutz Ihrer Daten abschließen.

Urteil: Bestellung von Zeitkontingenten – Rückzahlungsanspruch bei Nichtausschöpfung

Posted on by Trenchant

Urteil: Bestellung von Zeitkontingenten – Kein Rückzahlungsanspruch bei Nichtausschöpfung

Im Juli 2023 hatte das Landgericht Hannover entschieden, dass ein IT-Anbieter im Falle des Kaufs eines Dienstleistungskontingents auch dann keine Rückzahlung schuldet, wenn das Kontingent vom Kunden nicht aufgebraucht wurde. Aus den Urteilsgründen ergibt sich, worauf bei der richtigen Formulierung der Vertragsklauseln zu achten ist.

Sachverhalt

In dem beurteilten Fall hatte der Kunde bei einem IT-Anbieter ein Dienstleistungskontingent über 200 Stunden à 120,00 Euro gekauft. Die Rechnung in Höhe von insgesamt 24.000,00 Euro war mit dem Kauf des Kontingents zur Zahlung fällig.

Gegenstand der Dienstleistungen waren u.a. Helpdesk, Unterstützung via Remote-Zugriff und Installationsleistungen. Die Abrechnung (Darlegung des Kontingentverbrauchs) erfolgte auf der Basis von Tätigkeitsnachweisen nach jeweiliger Auftragserteilung [z.B. via Ticket].

Der Auftraggeber „kündigte“ den Vertrag zu einem Zeitpunkt, an dem 52 Stunden des Kontingents noch nicht verbraucht waren und verlangte die Rückzahlung von 6.240,00 Euro. Der IT-Anbieter verweigerte die Zahlung.

Das Urteil und die Begründung

Das Gericht gab dem IT-Anbieter recht.

Gegenstand des Vertrages sei der Erwerb eines Guthabens von 200 Dienstleistungsstunden gewesen, entsprechend dem Erwerb einer Telefonkarte oder eines Gutscheins. Mit dem Verkauf des Kontingents habe sich der IT-Anbieter verpflichtet, bestimmte Leistungen anzubieten und das Kontingent als Zahlungsmittel für noch zu beauftragende („nach jeweiliger Auftragserteilung„) und abzurechnende Leistungen zu akzeptieren. Nutzt der Kunde das von ihm gekaufte Guthaben nicht, besteht kein Rückzahlungsanspruch des Kunden gegenüber den IT-Anbieter.

Die Kündigung eines Kaufvertrages kommt aus Rechtsgründen nicht in Betracht.

Abgegrenzt wurde in dem Urteil der Fall einer Vorauszahlung im Rahmen eines bereits vereinbarten Dauerschuldverhältnisses. Ein typisches Beispiel hierfür ist die Wartung einer Dritt-Standardsoftware durch unverzügliches Einspielen von durch den Hersteller bereitgestellte Updates für einen bestimmten Zeitraum. Im Rahmen eines solchen Vertragsverhältnisses besteht die Leistungspflicht des IT-Anbieters ohne weitere Beauftragung [z.B. via Ticket]. Bei wirksamer Kündigung vor Verbrauch der Anzahlung dürfte i.d.R. ein Rückzahlungsanspruch möglich sein.

Empfehlung

Achten Sie bei der Vertragsgestaltung auf eindeutige Formulierungen. Unterscheiden Sie zwischen dem a) Abschluss eines Dauerschuldverhältnisses mit anschließenden Vorauszahlungen für bestimmte Zeiträume oder b) einem Guthabenvertrag z.B. zur Sicherung von Preisen oder Kapazitäten für künftig zu bestellende Leistungen.