Die Verantwortung der Hersteller von IT Produkte für die Einhaltung von Gesetzen
Ich hatte gerade wieder Verträge zu prüfen, in denen stand, dass der Anbieter (mein Mandant) „alle anwendbaren Gesetze und Regelungen“ einzuhalten hätte, die „für die vereinbarte Leistungserbringung“ erforderlich sein. Solche vertraglichen Regelungen nennt man CWL Klauseln (compliance with law).
In einer jüngeren Ausgabe der CR stand ein Artikel zu diesem Thema .Der Autor kam nach mehreren Seiten zu dem offensichtlichen Ergebnis, dass CWL Regelungen im deutschen Recht auf Grund von Intransparenzseien unwirksam seien..
CWL Klauseln gibt es in zwei Varianten. Die einen adressieren den Anbieter als Hersteller und stellen letztlich nur fest, dass der Hersteller „die ihn betreffenden Regelungen“ zu erfüllen hat und ist damit etwas Selbstverständliches. Die anderen CWL Klauseln sind gefährlich und sollten somit aus den Verträgen herausverhandelt werden. Sie beinhalten die Pflicht des Anbieters, die den Kunden betreffenden Regelungen einzuhalten. Diese sind unwirksam, was zu zeigen ist.
Der methodische Weg führt erst mal zu den Fragen, wer ist Normadressat, also wer ist für die Einhaltung welcher Regelungen verantwortlich? Das ist nicht so banal wie es scheint. Während die Gesetze eine relativ klare Struktur aufweisen, können die Parteien abweichende vertragliche Regelungen aufstellen und in dem Kontext sind auch CWL Klauseln zu bewerten.
Ich gehe mal zwei Fälle durch:
In dem einen geht es um die scheinbar banale Frage, wer eigentlich für die IT Sicherheit einer Anwendung (wir sagen mal Standardsoftware kommt vom Hersteller, Middleware und Systemumgebung werden vom Kunden administriert) in Sachen Datenschutz, IT Sicherheit verantwortlich ist.
Zweiter Fall: Muss das Produkt des Herstellers Normen erfüllen, die eigentlich den Kunden betreffen (nachfolgend Blog II dieser Serie).
A. Fall I: IT Sicherheit und Datenschutz
Das Problem ist hier, dass die gesetzliche Struktur in der Praxis nicht so gelebt wird, wie es das Gesetz vorsieht.
I. Normalfall der gesetzlichen Konstruktion
Der Normalfall der gesetzlichen Konstruktion trennt zwischen Normen, die sich an den Hersteller wenden und den Normen, die sich an den Anwender richten.
Wir zeigen das mal an einem Beispiel, das sich nicht auf die IT bezieht. Autos passen immer als Metapher.
1.) Es gibt Normen, die sich an den Hersteller des Produkts richten. Diese muss der Hersteller erfüllen. Seine Pflicht geht aber nur so weit, dass der Anwender die Gesetze umsetzen kann: Löschfristen, Rollen und Rechte, Protokollierung und Verschlüsselung müssen konfigurierbar sein. Welche Werte eingestellt werden, entscheidet der Kunde. Tacho und Bremsen also, aber kein Tempomat, der in Seevetal von selbst auf 70 geht. Der CRA ist so ein typisches Gesetz, das sich an Hersteller wendet.
2.) Es gibt Normen, die sich an den Anwender des Produkts wenden. Das Problem ist hier auch weniger, dass das Produkt so erstellt werden kann,sondern dass es den Anforderungen des Kunden entspricht, als vielmehr: Welche Anforderungen muss das Produkt im Standard erfüllen, ohne dass für den Kunden Zusatzkosten entstehen?
Grundsätzlich adressieren die Normen den Kunden. Wenn jemand ein Produkt für den Einsatz der GOBS, DMS für die Einhaltung des Steuerrechts etc. haben möchte, muss er sich ein Produkt suchen, dass diesen Zweck auch erfüllt. Hat er spezielle Anforderungen, “mein Auto soll auch im Gelände fahren können“, muss er das dem Hersteller sagen und ihn entsprechend beauftragen, aber eben auch dafür bezahlen.
Nach Art. 24 DSGVO stellt der Verantwortliche sicher, dass die Verarbeitung rechtmäßig ist, und nach Art. 28 Abs. 1 DSGVO muss er seinen Dienstleister sorgfältig auswählen. Verantwortlicher ist der Kunde.
II. Abweichendes Konstrukt der IT Gesetze
1.) Das Problem in der IT, ist blöd gesagt, dass es an einer Behörde fehlt, die dem Fahrer konkrete Vorgaben darüber macht, was im Einzelfall zu tun oder zu unterlassen ist. Vielleicht ist das auch von Vorteil, aber erstmal erzeugt es Rechtsunsicherheit. Es fehlen die Schilder der Behörde am Straßenrand.
Zum Beispiel gibt es im Datenschutz und in der IT-Sicherheitsrecht diese zweite Stufe nicht, die konkrete Umsetzung durch die StVO. Dort stehen Generalklauseln: geeignete technische und organisatorische Maßnahmen, angemessenes Schutzniveau, Stand der Technik. Ganz im Gegenteil: Im Art 32 DSGVO steht zum Thema IT Sicherheit und der Antwort auf die Frage, was angemessene technisch organisatorische Maßnahmen zur Einhaltung der IT Sicherheit sind, nicht (!) dass das allein Sache des IT Unternehmen ist, die IT Sicherheit einzuhalten. Nach Art. 32 Abs. 1 DSGVO treffen der Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten.
2.) Delegation der Risikobewertung auf die Parteien und das Problem der Praxis
Das Gesetz sagt also: Nicht das BSI oder eine andere Behörde, sondern beide Parteien sollen eine Risikobewertung vornehmen. Das ist eine Delegation der Verantwortung.
Das aber würde voraussetzen, dass sich beide Parteien wirklich hinsetzen und ausdiskutieren, ob angemessene TOMs bestehen. Das ist nicht so. Die Praxis sieht so aus, dass der Anbieter Anwendungsfälle beschreibt, diese anpreist und dann muss auch für diese Anwendungsfälle Sicherheit geboten werden. Wenn man sich die Anlagen 1 und 2 für die AVV anschaut, dann sieht man immer, welche Daten verarbeitet werden, was der Zweck der Durchführung des Vertrags ist und – so die Mechanik – für diese Verarbeitung muss das Risiko durch in den TOMs genannten Maßnahmen auf ein angemessenes Niveau reduziert oder ausgeschlossen sein.
III. Einfluss der vertraglichen Vereinbarung auf die Risikobewertung.
1.) Natürlich können die Parteien die gesetzlichen Vorgaben vertraglich konkretisieren. Ersetzen können sie sie nicht: Die Abwägung nach Art. 32 DSGVO bleibt Pflicht beider Parteien. Der Vertrag kann ihr aber den Gegenstand geben. Beschreibt der Anbieter einen Standardfall und die Maßnahmen, die er dafür trifft, kann der Kunde sich diese Bewertung zu eigen machen, statt sie selbst neu anzustellen.
Wenn ich in Versprechungen von absoluter Sicherheit etc. spreche, habe ich diese auch zu gewährleisten. Wenn ich in Angeboten davon spreche, dass ein Standardfall sicher durchgeführt werden kann, muss sich der Kunde darauf verlassen können.
Denn auch ohne Risikoabwägung im Einzelfall kann sich der Kunde darauf zurückziehen, dass der Anbieter einen Standardfall genau beschrieben hat und der Kunde genau in diesem Anwendungsbereich fällt.
2.) Die wirkliche Unsicherheit
Die wirkliche Unsicherheit stellt sich an der Stelle der Leistungsbeschreibung. Hat der Anbieter den Standardfall so gut beschrieben, dass der Kunde jetzt sagen kann, ja, das ist mein Anwendungsfall, bei mir ist es genauso.
3.) CWL Klausel
Und nun kommen die Anwälte der Kunden. In den AVVs (und die gehen in der Hierarchie denen des eigentlichen Vertrags vor) stehen solche Sätze wie: Der Anbieter ist allein dafür verantwortlich, dass die IT Sicherheit eingehalten wird.
Oder sie schreiben AGBs wie eben die CWL Klausel und verlagern mit einem einzigen Satz die Risikoverteilung der Leistungsbeschreibung. Sie sagen, dass der konkrete Anwendungsfall des Kunden abgesichert wäre und das kann natürlich nicht einfach so geschehen.
Denn damit wäre der Wille des Anbieters, nur für einen bestimmten, angebotenen Fall die erforderliche Sicherheit gewährleisten zu wollen, ausgehebelt. Ohne weitere Prüfung – und entsprechende Kosten – würde sich der Anbieter dazu verpflichten, für den Kunden die erforderliche Sicherheit zu gewährleisten.
Das geht nicht, weil das Gesetz eine klare Vorgabe macht. Das Gesetz sagt im Grundsatz: Beide Parteien haben eine Abwägung zu machen. Sofern der Anbieter von sich aus eine Aussage zu der IT Sicherheit macht und sich der Kunde dieser Aussage anschließt, wäre eine erneute Abwägung eine Formalie.
Das aber der Anbieter verpflichtet wäre, jedweden konkreten Anwendungsfall des Kunden auch außerhalb des in der Leistungsbeschreibung versprochenen Anwendungsbereichs abzusichern, kann nicht mit einer AGB Klausel wie der CWL Klausel fingiert werden. Eine wäre schon nach § 307 II iVm Art 32 I DSGVO unwirksam.