Risikomanagement

Ich bin gerade wieder an vielen Stellen mit Mandaten befasst, bei denen es im Kern um das Thema Risikomanagement geht.

Die Fälle gleichen sich im Grunde. Die Anwälte der Kunden möchten gerne durch vertragliche Regelungen (Haftung und Gewährleistung) umfassend Risiken auf die IT- Unternehmen abwälzen.

Beispiele solcher Fälle:

1.) Die Verfügbarkeit eines Cloudsystems soll Tag wie Nacht bei nahezu 100% liegen, aber neue Funktionen sollen nicht etwa auf dem Staging, sondern auf dem „Prodsystem“ getestet werden.

2.) Nach dem Inhalt einer AVV soll immer das IT- Unternehmen dafür haften, dass aktuelle technische Maßnahmen ergriffen werden, die dem jeweiligen Stand der Technik entsprechen: Die Kosten für das Risiko von Aktualisierungen, die teurer sind als es die monatliche Vergütung hergibt, soll allein das IT Unternehmen tragen.

3.) Ein IT- Unternehmen möchte mit einer Staatlichen Stelle einen Cloud- Vertrag nach Maßgaben der EVB IT abschließen, aber eben nicht unter Anwendung des Kriterienkatalogs C5. Und etliche Beispiele mehr.

Das Problem hier ist der Inhalt des Risikomanagements, die Kommunikation über das Thema und die Frage, welche rechtlichen Vereinbarungen man abschließt

I. Ausgangslage: Das Gesetz

Diesen Startpunkt können wir schnell wieder verlassen, weil man – sofern man sich auf die Ebene des europäischen Datenschutz- oder IT- Sicherheitsgesetzes begibt, schnell feststellt, dass es weder eine staatliche Stelle der EU gibt, die selbst festlegt, a.) welche Organisationen der einzelnen EU- Staaten über solche Fragen entscheiden sollen, noch b.) wie solche Festlegungen inhaltlich auszusehen haben. Es gibt keine eindeutigen gesetzlichen Festlegungen darüber, wie eine Methodik für IT- Risikomanagement zu betreiben ist. Nicht umsonst gibt es so viele Anbieter in Deutschland, die als einziges Regelwerk immer wieder auf die ISO 27005:2018 verweisen (und damit nach Ansicht vieler Anderer unnötig viel Aufwand und Kosten verursachen). Die ISO ist aber laut Wikipedia ein Verein des schweizerischen Rechts, aber eben nicht eine EU- Kommission oder ein vom deutschen Parlament autorisiertes Gremium.

II. Der normale Weg

Ein methodischer Weg, der häufig vorgeschlagen wird, lautet:

Im Ersten Schritt geht es um die Frage, welche Schutzgüter bestehen. Das sind im Datenschutz die personenbezogenen Daten.

Im zweiten Schritt sind die Verarbeitungsprozesse zu erfassen, die sich auf die personenbezogenen Daten auswirken, IT-ler würden anstelle des Terminus Verarbeitungsprozesse hier vermutlich eher von Diensten sprechen.

Sofern man denn weiß, welche Dienste operationell für welche Schutzgüter eingesetzt werden, kommt es im Schritt drei zur Identifikation der Risiken (durch wen oder was droht Gefahr),

im vierten Schritt zu einer Risikoanalyse (wie hoch ist die Wahrscheinlichkeit des Eintritts eines Schadens und wie groß sind die Folgen des Schadenseintritts?) und

im letzten Schritt, der Risikobewertung zur Frage, durch welche Maßnahmen man den Risiken begegnen kann und wie man hier eine verhältnismäßige Maßnahme treffen kann. Sowohl bei der Frage des Risikos als auch bei der Frage nach den Maßnahmen wird immer wieder vorgeschlagen, auf eine Matrix mit den Werten „Niedrig/ Mittel/ Hoch“ abzustellen, um schneller zum Ergebnis zu gelangen. Vom Gesetz gefordert ist das freilich nicht.

Das Problem des normalen Wegs ist schlicht, dass einem normalen Menschen die Zeit fehlt, sich mit allen Möglichkeiten eines Risikos (welche Risiken könnten bestehen?) und den Abwägungen zu befassen, die dem Ergebnis vorweg gehen sollen.

Eine Möglichkeit besteht jedoch immer darin, zu schauen, was das BSI macht.

III. Orientierung an einem bestehenden Standard: Der Kriterienkatalog C5 des BSI

Das BSI veröffentlicht Kriterienkataloge, die es den Verantwortlichen in einer Art Checkliste ermöglichen, Vorgaben des BSI abzuarbeiten. Das BSI hat in Standards bestimmte typische Risiken als Standard erfasst und fragt in Kriterienkatalogen, ob diese Risiken bestehen und man diese Risiken angemessen gemindert hat. Die EVB IT haben 2022 Zuwachs in Form der EVB IT Cloud bekommen. Diese enthalten unter der Ziffer 1.2 folgende Formulierung.

Der Auftragnehmer erbringt die Leistungen unter Einhaltung des bei Vertragsschluss jeweils aktuellen Cloud Computing Compliance Criteria Catalogue – C5 (Basiskriterien).

Diesen Katalog findet man hier ….

https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/C5_AktuelleVersion/C5_AktuelleVersion_node.html

Das hat den Vorteil, kostenlose Vorlagen zu erhalten, die gut erklärt sind. Der Nachteil der Unterlagen besteht darin, dass die Unterlagen sehr breit aufgestellt sind. Es ist sehr trockenes Papier.

Man lasse sich aber nicht täuschen: Eben deshalb, weil die Dokumente des BSI (und die referenzieren in Teilen auf die ISO 2700X) eben keine gesetzlichen Regelungen enthalten, kann man die Vorlagen des BSI als Ausgangspunkt verwenden, den Inhalt für sich selbst kürzen (auch dieser Prozess ist dann ja ein Teil des Ergebnisses der Risikoabwägung) und dann das Ergebnis als Unterlage und Kriterienkatalog für sich und sein Unternehmen verwenden.

So man denn einen Vertrag auf der Basis der EVB IT- Cloud abschließen will, gibt es die Möglichkeit, die Anwendung des C5- Katalogs auszuschließen. Aber (!) dann muss man immer noch nachweisen, dass man das Risikomanagement durchgeführt hat. Denn in Deutschland gilt: Wer nicht zertifiziert ist, muss sich auditieren lassen. Man verschiebt das Problem also nicht, sondern muss es anders lösen.

Weitere Beiträge

Programmieren und KI und Urheberrecht Teil II

Im Teil I hatte ich die generellen Probleme dargelegt, die sich daraus ergeben dass der Output eines KI Systems grundsätzlich nicht als urheberrechtsähiges Werk qualifiziert werden kann. Ganz konkret gehen wir in diesem Teil mal der Frage nach, was das

Mehr lesen »
Nach oben scrollen