20. März 2025
Die Anforderungen an die Vertragsgestaltung im Digital- und Cybersecurity-Recht sind grundsätzlich seit längerem bekannt. Für diese Anforderungen, die sich primär aus dem Zivilrecht, den datenschutzrechtlichen technischen und organisatorischen Maßnahmen, sowie sonstigen technischen Standards (ISO, NIST, usw.) ergeben, sind daher auch grundsätzlich Problembewusstsein und Gestaltungsmöglichkeiten im Standard-Repertoire von Juristen und Fachabteilugen vorhanden.
Für eine Vielzahl an EU-Rechtsakten, die in letzter Zeit zum Thema Digital- und Cybersecurity-Recht in Kraft getreten sind oder demnächst in Kraft treten werden – wie etwa Produktsicherheitsverordnung, Digital Services Act, NIS-2, CRA, Data Act, AI Act, usw. –, sind Problembewusstsein und Gestaltungsmöglichkeiten hingegen oftmals noch nicht vorhanden.
Während bei den meisten Unternehmen bereits das Bewusstsein besteht, was den Anwendungsbereich, die technischen und organisatorischen Pflichten sowie die Sanktionen angeht, geht oftmals unter, dass es für eine umfassende Implementierung der Anforderungen auch vertraglicher Anpassungen bzw. Neu-Regelungen bedarf. Erst recht nicht bekannt sind Gestaltungsmöglichkeiten für die erforderlichen vertraglichen Anpassungen bzw. Neu-Regelungen. In der Praxis führt das fehlende Problembewusstsein bisher oftmals dazu, dass Lücken in der Compliance mit den Anforderungen der neuen EU-Rechtsakte aus dem Digital- und Cybersecurity-Recht entstehen und damit einhergehenden nicht zu unterschätzenden Sanktionsrisiken.
Nachfolgend wird daher einen Überblick darüber gegeben, bei welchen EU-Rechtsakte aus dem Digital- und Cybersecurity-Recht erhöhter Handlungsbedarf besteht und welche Problemfelder insofern zu beachten sind.
Der Digital Services Act („DSA“) ziel darauf ab einen sicheren digitalen Raum zu schaffen, bei dem die Rechte aller Nutzer (dies können z.B. Endkunden aber auch Händler einer Online-Plattform sein) geschützt sind und somit gleiche Bedingungen für alle bestehen.
Vor diesem Hintergrund des DSA werden für sog. Vermittlungsdienste – im Prinzip jeder Dienst, der Nutzerinformationen speichert oder bereitstellt – über Art. 14 DSA konkrete Anforderungen an deren AGB gestellt. Die Anbieter von Vermittlungsdiensten müssen in ihren AGB etwaige Mechanismen für Beschränkungen der von Nutzern bereitgestellten Informationen darlegen, sofern es solche Beschränkungen gibt. Die bedeutet, es muss hinreichend transparent in den AGB beschrieben werden, wie Moderationsentscheidungen getroffen werden und welche Konsequenzen den Nutzern damit einhergehend drohen, also etwa welche Verhaltensweisen nicht erwünscht sind (z.B. Hochladen rechtswidriger Inhalte, Beleidigungen, usw.) und welche Sanktionen damit verbunden werden (z.B. die zweitweise Sperre eines Nutzerkontos oder die Kündigung eines Nutzerkontos). Die vertragsgestalterische Umsetzung dieser Anforderungen erfordert von Unternehmen sich vorab darüber Gedanken zu machen, welche Verhaltensweisen von Nutzern nicht erwünscht sind und welche Konsequenzen es geben soll, einschließlich ob diese gestuft, alternativ oder kumulativ durchgesetzt werden.
Daneben verpflichtet Art. 27 DSA Anbieter von Online-Plattformen in ihren AGB die wichtigsten Parameter von Empfehlungssystemen darzustellen. „Empfehlungssysteme“ meint insofern die Logik dahinter, weshalb bestimmte Inhalte bzw. Informationen in einer bestimmten Reihenfolge, größer oder Prägnanz dargestellt werden (also z.B. weshalb ein bestimmte Schuh einer bestimmten Marke ganz oben als erstes angezeigt wird). Die „Parameter“ sind insofern die einzelnen Entscheidungsfaktoren, die in der Gesamtheit die konkrete Darstellung bestimmen (z.B. Filter, Preisklasse, laufende Kampagnen, Restbestände, usw.). Rein pragmatisch erfordert die vertragsgestalterische Umsetzung von Unternehmen intern zu erforschen, welche Entscheidungsfaktoren überhaupt berücksichtigt werden und welche Gewichtung diesen zukommt – so trivial dies auf den ersten Blick erscheint, ist es technisch aufgrund der häufig abteilungsübergreifenden Verantwortlichkeiten oftmals gar nicht so leicht die Logik in der Gesamtheit nachzuvollziehen. Aus rechtlicher Sicht ist zudem zu überlegen, was denn die „wichtigsten“ Parameter sind und wie diese hinreichend transparent dargestellt werden können.
Abgesehen von diesen konkreten inhaltlichen AGB-Pflichten, bestehen daneben noch allgemeine Pflichten im Zusammenhang mit AGB, wie etwa: (i) die Pflicht zur Information über Änderungen von AGB, (ii) die Bereithaltung in verschiedenen Sprachversionen der AGB je Mitgliedsstaat in dem der Dienst angeboten wird und (iii) die Bereitstellung von Zusammenfassungen der AGB, (iv) die Wiedergabe von Moderationsentscheidungen im Zusammenhang mit den AGB in jährlichen Transparenzbericht sowie (ii, iii, und iv nur für große und sehr große Online-Plattformen) (v) sowie ein Melde- und Abhilfeverfahren, dass auch die Meldung von AGB-widrigen Nutzerinhalten ermöglicht.
Auch wenn die beiden inhaltlichen Anforderungen an AGB im B2B-Bereich bereits in vergleichbarer Weise aus der P2B-Verodnung ((EU) 2019/1150) bekannt sind, sind sie zumindest im B2C-Bereich neu. Und selbst Unternehmen aus dem B2B-Bereich, die bereits die Anforderungen der P2B-Verordnung umgesetzt haben, dürfte die „B2C-Brille“ mit einem strengeren AGB-Maßstab neue Herausforderungen bereithalten.
Durch die NIS-2-Richtlinie und das noch kommende NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz („NIS2UmsuCG“) soll eine funktionierende und resiliente IT-Infrastruktur sichergestellt werden. Im Fokus sind dabei wiederum organisatorische, aber vor allem auch technische Vorgaben für Unternehmen der kritischen Infrastruktur, aber auch solcher Unternehmen, die durch ihre Größe und ihr Tätigkeitsfeld eine gewissen Einfluss auf die wirtschaftliche Sicherheit haben.
Im Sinne der organisatorischen Maßnahmen verpflichtet § 30 Abs. 2 Nr. 4 BSIG-E besonders wichtige und wichtige Einrichtungen sodann zur „Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern“. Hintergrund dieser Anforderung ist die Überlegung, dass vom NIS2UmsuCG erfasste Unternehmen weiterhin nicht hinreichend sicher sind, solange sie durch Schwachstellen in der IT-Lieferkette weiterhin mittelbar Cyberangriffen ausgesetzt sind.
In der Gesetzesbegründung des NIS2UmsuCG werden dann auch ausdrücklich „vertragliche Vereinbarungen mit Zulieferern und Dienstleistern zu Risikomanagementmaßnahmen, Bewältigung von Cybersicherheitsvorfällen, Patchmanagement, sowie der Berücksichtigung von Empfehlungen des Bundesamt in Bezug auf deren Produkten und Dienstleistungen“ als (einziges) Beispiel zur Gewährleistung der Sicherheit in der Lieferkette genannt. Schematisch kann man sich bei der Vertragsgestaltung grundsätzlich an vertraglichen Regelungen aus dem Bereich des Lieferkettengesetzes („LkSG“) bedienen. Der geforderte Detailgrad dürfte im Bereich der NIS-2-Richtlinie bzw. des NIS2UmsuCG aber deutlich höher sein, da die relevanten organisatorischen und insbesondere technischen Anforderungen je nach Wirtschaftssektor stark variieren dürften und damit im Sinne der Transparenz eine vertragliche Konkretisierung gefordert sein dürfte. Zu generische „catch it all“-Regelungen dürften daher im Zweifel die gesetzlichen Anforderungen nicht erfüllen. In tatsächlicher Hinsicht erfordert die vertragliche Regelung somit eine genaue Kenntnis der Lieferkette und etwaiger Schwachstellen, damit diese entsprechend vertraglich berücksichtigt werden können.
Mit der neuen Produktsicherheitsverordnung („GPSR“), welche als Verordnung unmittelbar ohne Umsetzungsakt Anwendung findet, sind nunmehr erstmalig wohl auch Software-Produkte (bzw. digitale Produkte) allgemein im B2C-Bereich (für Verbraucher bestimmt oder unter vernünftigerweise vorhersehbaren Bedingungen wahrscheinlich von Verbrauchern benutzt) unmittelbar von Produktsicherheitsanforderungen erfasst. Bisher gab es Produktsicherheitsvorgaben allenfalls in bestimmten speziellen Sektoren für Software-Produkte, wie etwa im Gesundheitsrecht durch die Digitale Gesundheitsanwendungen-Verordnung. Obwohl Software-Produkte in der GPSR selbst nicht genannt werden, scheint zumindest die Europäische Kommission ausgehend von deren FAQs diese eindeutig als umfasst anzusehen. Vor diesem Hintergrund müssen nunmehr auch für Software-Produkte die Anforderungen aus dem Produktsicherheitsrecht erfüllt werden, also insbesondere: (i) Gewährleistung des allgemeinen Sicherheitsgebotes, (ii) Erstellung einer internen Risikoanalyse, (iii) Erstellung technischer Unterlagen, (iv) klare Kennzeichnung der Produkte zur Identifikation (Typen-, Chargen-, Seriennummern) sowie Herstellerangaben (Name, Handelsmarke, Anschrift, E-Mail-Adresse oder Link zu einem online-Kontaktformular für den schnellen Kontakt), (v) Erstellung von Gebrauchsanweisungen und Sicherheitsinformationen sowie (vi) Bereithaltung eines öffentlich zugänglichen Kommunikationskanals für Hinweise und Beschwerden, auch zu Informationen über Unfälle und Sicherheitsproblemen.
Dieser im Gegensatz zur bisherigen Rechtslage erweiterte sachliche Anwendungsbereich dürfte aus vertraglicher Sicht insbesondere für solche Software- oder digitalen Produkte Auswirkungen haben, bei denen Ersteller und nach außen auftretender Wirtschaftsakteur auseinanderfallen. Insofern ist zu berücksichtigen, dass man im Sinne des Produktsicherheitsrechts bereits als Hersteller – mit vollem Pflichtenkanon – gilt, sofern man Produkte unter eigenem Namen oder unter eigener Marke vertreibt. Und auch Händler treffen bestimmte, wenn auch reduziertere als beim Hersteller, Pflichten.
Insbesondere etwa im Bereich von Apps für Verbraucher (etwa eine App für einen Online-Shop) ist das aufgezeigte Auseinanderfallen der Wirtschaftsakteure eine typische Konstellation. Apps werden sehr häufig von App-Entwicklern für andere Unternehmen zur Nutzung zu deren Zwecken im Außenverhältnis entwickelt und gewartet. Der nach außen die App anbietende Wirtschaftsakteur (der Hersteller oder Händler), wird in der Regel gerade nicht in der Lage sein die Produktsicherheitsvorgaben unter der GPSR zu erfüllen, da ihm hierzu schlicht die Fachkenntnisse und sonstigen Informationen fehlen. Dieses Wissensgefälle lässt sich nur dadurch lösen, dass der nach außen das Software-Produkt anbietende Wirtschaftsakteur den eigentlichen Ersteller verpflichtet, die relevanten Informationen bereitzustellen und ggf. sogar schon in die gefordert Darstellung zu bringen, z.B. dass nicht nur die Informationen für eine Risikoanalyse bereitgestellt werden, sondern die Risikoanalyse selbst bereits durch den Ersteller durchgeführt und dokumentiert wird.
Gleichermaßen sind vertragliche Vorkehrungen aber auch bei Software in Form von Zukaufprodukten zu beachten, also wenn Softwareteile in die eigene Software implementiert werden. Hier kann es ebenfalls sinnvoll und erforderlich sein, von dem Ersteller des Zukaufprodukte die Bereitstellung von Informationen vertraglich abzusichern.
Vom Prinzip erfordert die Vertragsgestaltung im Bereich der GPSR eine typische Weiterleitung von Pflichten in der Vertragskette. Im Unterschied zu den üblichen generischen Regelungen, die oftmals sogar nur eine Informationserteilung und Nachweiserbringung auf Aufforderung umfassen, sind hier aber deutlich detailliertere, aktive Leistungs- und Mitwirkungspflichten zu regeln. Damit einhergehend ist auch an die Regelung eines geeignetes Haftungssystems zu denken. Denn jede Falschinformation der unvollständige Information des Erstellers kann auch Implikationen für den Hersteller/Händler haben.
Der Data Act verfolgt das Ziel den Zugang zu und die Nutzung von Daten innerhalb der Europäischen Union zu revolutionieren. Vor dem Hintergrund der fortschreitenden Digitalisierung und der wachsenden Bedeutung von Daten für Innovation und Wettbewerbsfähigkeit hat die EU erkannt, dass ein rechtlicher Rahmen erforderlich ist, um Daten effizient zu teilen und zu nutzen.
Mit Blick auf die Vertragsgestaltung enthält der Data Act umfassende Anforderungen, die sich auf die unterschiedliche Teilbereiche erstrecken:
Der Data Act gewährt Nutzern von IoT-Produkten ein Zugangsrecht zu den durch das IoT-Produkt generierten Daten gegenüber dem Dateninhaber. Die Daten sind dem Nutzer entweder direkt (Art. 3 Abs. 1 DA) oder indirekt, d.h. auf Verlangen, (Art. 4 Abs. 1 DA) bereitzustellen. Ferner kann der Nutzer vom Dateninhaber die Weitergabe der Daten an einen Dritten (Datenempfänger) verlangen (Art. 5 Abs. 1 DA).
Die Nutzung von (nicht-personenbezogenen) Daten durch den Dateninhaber darf nach Art. 4 Abs. 13 DA nur noch auf Grundlage eines Vertrags mit dem Nutzer erfolgen. Im Vergleich zur bisherigen Rechts- und Sachlage stellt dies einen deutlichen Paradigmenwechsel dar: Die durch Nutzung des IoT-Produkts bzw. den verbundenen Dienst generierten Daten sind rechtlich dem Nutzer zugewiesen. Zuvor konnten Dateninhaber (nicht-personenbezogene) IoT-Daten ohne Einschränkung nutzen. Maßgeblich war allein wer tatsächlichen Zugriff hatte. Nach dem Data Act ist es mithin zukünftig erforderlich, dass der Nutzer dem Dateninhaber ein vertragliches Datennutzungsrecht einräumt.
Das Recht der Nutzer auf Datenzugang umfasst nach den Regelungen des Data Act grundsätzlich auch die Offenlegung von Geschäftsgeheimnissen. Allerdings sind Nutzer und Dateninhaber dazu angehalten nach Art. 4 Abs. 6 DA eine Vereinbarung zu angemessenen technischen und organisatorischen Maßnahmen („TOM“) zum Schutz der Daten, die Geschäftsgeheimnisse darstellen, zu schließen. Kann bezüglich der Vereinbarung zu den TOM keine Einigung erzielt werden oder setzt der Nutzer die TOM nicht um, kann der Dateninhaber dem Nutzer den Zugang zu den Daten verweigern (Art. 4 Abs. 7 DA).
Verlangt der Nutzer vom Dateninhaber die Bereitstellung von IoT-Daten an einen Dritten (sog. Datenempfänger), so schließt der Dateninhaber mit dem Datenempfänger eine Vereinbarung über die Ausgestaltung der Datenbereitstellung entsprechend Art. 8 Abs. 1 DA. Darin kann auch eine angemessene Gegenleistung für die Datenbereitstellung durch den Dateninhaber geregelt sein (Art. 9 Abs. 1 DA). Daneben haben auch Dateninhaber und Datenempfänger eine Vereinbarung über TOM zum Schutz von Geschäftsgeheimnissen zu schließen (Art. 5 Abs. 9 DA).
Unternehmen, die von den Vorgaben zu IoT-Produkten unter dem Data Act betroffen sind, müssen alle vorgenannten Konstellationen vertraglich abbilden können. In den meisten Unternehmen werden in Bezug auf die Datenbereitstellung noch keine Muster-Verträge bestehen, da es sich hierbei – wie oben dargestellt – um ein neues Verständnis der rechtlichen Zuweisung von Daten handelt. Vor diesem Hintergrund sollten Unternehmen frühestmöglich mit der Vorbereitung entsprechender Muster beginnen.
In Art. 13 DA hat der europäische Gesetzgeber eine Klauselkontrolle für Vertragsklauseln in Bezug auf Datenzugang und Datennutzung in B2B-Verträgen vorgesehen. Ähnlich zum bestehenden deutschen AGB-System enthält Art. 13 DA ein abgestuftes Prüfsystem hinsichtlich der Missbräuchlichkeit bestimmter Klauseln. So sind beispielsweise Klauseln, die inhaltlich unter Art. 13 Abs. 4 DA fallen, per se als missbräuchlich und damit nicht bindend anzusehen (z.B. Haftungsausschluss für vorsätzliche und grob fahrlässige Handlungen).
Zukünftig ist bei der Prüfung von AGB eine gespaltene Inhaltskontrolle möglich. Denn Art. 13 DA geht dem deutschen AGB-Recht hinsichtlich der Prüfung datenzugangs- und datennutzungsbezogenen Regelungen vor. Für die restlichen Klauseln findet das allgemeine AGB-Recht Anwendung.
Insgesamt bestehen hinsichtlich Art. 13 DA noch viele Unklarheiten. So wird beispielsweise diskutiert, ob Art. 13 DA auch in B2C-Verhältnissen anwendbar ist.
Kapitel VI des Data Acts widmet sich dem Wechsel zwischen Datenverarbeitungsdiensten. Betroffen sind insbesondere Anbieter von IaaS, SaaS, PaaS und weitere Cloud-Dienste. Neben einem allgemeinen Verbot von Hindernissen für den Wechsel zwischen Datenverarbeitungsdiensten (Art. 23 DA) enthält der Data Act auch ganz spezifische Anforderungen an den Inhalt von Cloud-Verträgen in Bezug auf den Wechsel (Art. 25 DA).
Hierzu zu zählen z.B. Regelungen zu angemessenen Unterstützungsleistungen durch den Anbieter des Datenverarbeitungsdienstes, Angaben zu Datenkategorien, die übertragen bzw. nicht übertragen werden können, eine Mindestfrist für den Datenabruf von 30 Tagen. Besonders zu erwähnen ist, dass Art. 25 Abs. 2 lit. c DA eine Vertragsklausel mit einer Fiktion der Vertragsbeendigung für bestimmte Fälle vorsieht. Dies ist wohl als Art Sonderkündigungsrecht neben ggf. bestehenden vertraglichen Kündigungsrechten zu verstehen.
Der Wechselprozess zwischen Datenverarbeitungsdiensten nach dem Data Act sieht insbesondere folgenden zeitlichen Ablauf vor: Die Kündigungsfrist darf zwei Monate nicht überschreiten (Art. 25 Abs. 2 lit. d DA). An die Kündigungsfrist schließt sich eine Übergangsfrist von 30 Kalendertagen an. Die Übergangsfrist kann bei technischer Undurchführbarkeit binnen 30 Kalendertagen auf maximal sieben Monate erweitert werden. Nach der Übergangsfrist beginnt die Mindestfrist von 30 Kalendertagen für den Datenabruf durch den Kunden.
Die Anforderungen des Data Act an Cloud-Verträge führen für betroffene Unternehmen zu einem enorm hohen Anpassungsbedarf. Doch nicht nur bestehende Muster-Verträge und AGB sind zu überarbeiten, weitaus mehr Aufwand in der Praxis wird die erforderliche Umstellung der Prozesse bedeuten, die implizit aus den Mindestanforderungen des Data Acts folgt.
Der AI Act regelt den Einsatz von Künstlicher Intelligenz auf Basis eines risikobasierten Ansatzes mit dem Ziel, Innovation zu ermöglichen und gleichzeitig Grundrechte, Sicherheit und Verbraucherschutz zu gewährleisten. Zu diesem Zweck werden KI-Systeme in verschiedene Risikokategorien eingeteilt: Unzumutbare KI-Systeme wie Social Scoring werden verboten, Hochrisiko-KI-Systeme wie in der Medizin oder bei kritischen Infrastrukturen unterliegen strengen regulatorischen Anforderungen, für bestimmte KI-Systeme werden Transparenzanforderungen festgelegt.
Anders als der Data Act enthält der AI Act jedoch keine unmittelbaren Vorgaben für die Vertragsgestaltung zwischen den Vertragsparteien. Indirekte Auswirkungen auf Vertragsbeziehungen ergeben sich allerdings aus den Pflichten der verschiedenen Akteure. Unternehmen müssen sicherstellen, dass ihre Vertragsbeziehungen den Anforderungen des AI Act entsprechen, insbesondere wenn sie als Hersteller oder Betreiber auftreten. Hierzu können vertragliche Zusicherungen zur Einhaltung der Vorgaben des AI Act (z.B. Risikoanalyse, Transparenzverpflichtungen) sinnvoll sein.
Solche Regelungen können z.B. Definitionen oder Abgrenzungen enthalten. Eine gängige Vertragsklausel beinhaltet die Klarstellung, dass der Vertragsinhalt ein KI-System umfasst und daher die Vorgaben des AI Act einzuhalten sind oder aber eine Ausnahme greift, etwa weil die Parteien ein KI-System nur zu militärischen Zwecken einsetzen. Ebenso kann eine Klarstellung des räumlichen Geltungsbereichs erfolgen, indem sich die Parteien verpflichten, die von der KI-Lösung generierten Ergebnisse nicht in der EU zu nutzen (bzw. deren Nutzung nicht zu gestatten).
Es können aber auch detailliertere Regelungen vereinbart werden. Da der AI Act unterschiedliche Pflichten in der KI-Lieferkette vorsieht, z.B. unterliegt der Anbieter eines KI-Systems (i.d.R. der Entwickler) weitergehenden Pflichten als der Betreiber (i.d.R. der Kunde), können die Parteien durch vertragliche Regelungen ihre Position in der Lieferkette klären. Angesichts des risikobasierten Ansatzes kann der beabsichtigte Zweck des KI-Systems im Vertrag dokumentiert werden, um die Risikokategorisierung der Parteien nachvollziehbar zu machen. Anbieter können auch sicherstellen, dass ihre KI-Systeme nicht für eine in Anhang I oder Anhang III aufgeführte Hochrisikonutzung eingesetzt werden.
Ferner können sich die Parteien zur Einhaltung bestimmter Pflichten aus dem AI Act verpflichten und diese vertraglich ausgestalten. Dabei können auch konkrete Rechtsfolgen vereinbart werden, wie etwa ein außerordentliches Kündigungsrecht bei schwerwiegenden Verstößen gegen Regelungen des AI Act.
Angesichts der vielschichtigen Anforderungen an Verträge, die mit den neuen EU-Digitalgesetzen verbunden sind, sollten Unternehmen frühzeitig mit der Gestaltung von Muster-Verträgen bzw. Muster-Klauseln beginnen. Ebenso sind bestehende Muster auf Anpassungsbedarf zu prüfen. Denn oftmals können durch eine vertragliche „Achillesferse“ die restlichen Compliance-Bemühungen konterkariert werden. Eine unzureichende vertragliche Ausgestaltung wird in der Regel dazu führen, dass insgesamt keine Compliance mit den neuen EU-Rechtsakten und damit das volle Sanktionsrisiko besteht.