NIS-2 in der Praxis: Risikoanalyse und IT-Sicherheitskonzepte verständlich erklärt

Vor ein paar Tagen habe ich mein neues Cheatsheet zum deutschen NIS-2-Umsetzungsgesetz veröffentlicht – und es hat sich offenbar wie ein Lauffeuer verbreitet. Ich freue mich sehr zu sehen, dass die Inhalte für so viele Menschen relevant sind. Gleichzeitig wird deutlich, wie groß der Bedarf an strukturierten Informationen und praktischen Hilfestellungen zu diesem anspruchsvollen Gesetz ist.

Ein guter Grund, mich intensiver mit den inhaltlichen Anforderungen des Gesetzes zu beschäftigen – auch wenn die NIS-2-Regulierung für mich als Bankpraktikerin nur eine untergeordnete Rolle spielt, denn für Finanzunternehmen gilt bekanntlich DORA als „Lex Specialis“.

Der erste Eindruck

Mein erster Eindruck bei der inhaltlichen Analyse von NIS-2: Viele Begriffe und Formulierungen sind so abstrakt, dass nur schwer zu erkennen ist, was praktisch tatsächlich erwartet wird. Hier gibt es einen deutlichen Unterschied zu den DORA-Vorgaben, die im Vergleich dazu sehr konkret und detailliert beschrieben sind.

Das ist Fluch und Segen zugleich. Auf der einen Seite lassen derart offene Formulierungen viel Raum für Interpretation und unternehmensindividuelle Ausgestaltung. Auf der anderen Seite führt diese Unschärfe zu erheblicher Unsicherheit – insbesondere in Unternehmen, die noch keine langjährige Vorerfahrung mit europäischer IT-Regulierung haben. Schließlich geht es um potenzielle Beanstandungen, signifikante Bußgelder bis hin zu persönlichen Haftungsfragen der Geschäftsleitungen. Und Unsicherheit ist bekanntlich auch ein idealer Nährboden für Vertriebsargumente teurer Beratungshäuser, Zertifizierungsstellen und Toolanbieter.

Mein Ziel daher: ein wenig mehr Sicherheit und Orientierung geben und einige, zentrale Anforderungen in eine verständliche, praxisnahe Sprache übersetzen.

Auslegungshilfe in der Durchführungsverordnung (EU) 2024/2690

Hilfreich für die Auseinandersetzung mit dem NIS-2-Umsetzungsgesetz ist die Durchführungsverordnung (EU) 2024/2690. Sie ist deutlich weniger bekannt als die NIS-2-Richtlinie, da sie sich nur an einen eingeschränkten Kreis von NIS-2-Einrichtungen richtet – darunter beispielsweise Cloud-Computing- und Rechenzentrumsdienstleister, Managed Service Provider sowie Betreiber von Online-Marktplätzen.

Inhaltlich präzisiert die Verordnung die Anforderungen aus NIS-2 und legt technische und methodische Mindestanforderungen an die Cybersicherheit der adressierten Unternehmen fest. Damit liefert sie genau das, was in der NIS-2-Richtlinie und im nationalen Umsetzungsgesetz fehlt: konkrete inhaltliche Auslegungshilfe für ansonsten sehr abstrakt formulierte Anforderungen.

Wichtig dabei: für NIS-2-Einrichtungen außerhalb des Geltungsbereichs dieser Verordnung sind die Anforderungen natürlich nicht verpflichtend, können aber bei der inhaltlichen Ausgestaltung trotzdem verwendet werden und sehr hilfreich für das Verständnis sein!

Heute im Fokus: Konzepte der Risikoanalyse und Sicherheit der Informationstechnik

In diesem Beitrag möchte ich die Anforderung aus §30 (2) Nr. 1 des deutschen NIS-2-Umsetzungsgesetzes näher beleuchten. Unternehmen müssen demnach technische und organisatorische Maßnahmen festlegen, die Folgendes umfassen:

Konzepte in Bezug auf die Risikoanalyse und auf die Sicherheit in der Informationstechnik

Auf den ersten Blick klingt das recht intuitiv. Auf den zweiten Blick erinnert die Formulierung jedoch fast an KI-generierten Text: sprachlich korrekt, formal sauber – aber inhaltlich bleibt offen, was eigentlich gemeint ist.

Konzept in Bezug auf die Risikoanalyse

Beginnen wir mit dem Konzept zur Risikoanalyse. Ein Blick in die oben genannte Durchführungsverordnung schafft tatsächlich Klarheit und vieles davon erinnert mich an DORA-Anforderungen. Kurz gesagt versteht man darunter alle internen Vorgaben, Verfahren und Nachweise, die mit der Identifikation und Behandlung von IKT-Risiken zusammenhängen.

Wenn ich in einer NIS-2-Einrichtung für die Umsetzung dieser Anforderung verantwortlich wäre, würde ich Folgendes tun:

Ich würde …

interne Vorgaben zur Identifikation und Behandlung von IKT-Risiken erstellen, z. B. eine Richtlinie oder Arbeitsanweisung zum IKT-Risikomanagement,
eine Methodik zur IKT-Risikoanalyse (z. B. nach ISO 27005) festlegen,
gemeinsam mit der Geschäftsleitung (und ggf. dem Risikocontrolling) Risikoappetit und IKT-Risikotoleranzschwelle definieren,
die wichtigsten IKT-Assets (Anwendungen, Systeme, Infrastrukturen), deren Abhängigkeiten untereinander und deren Schutzbedarf erheben,
die wichtigsten IKT-Dienstleister des Unternehmens bestimmen,
für diese IKT-Assets und ggf. Dienstleister eine initiale IKT-Risikoanalyse durchführen und mindestens jährlich auf Aktualität prüfen,
Maßnahmen zur Risikobehandlung festlegen und in einem Risikobehandlungsplan dokumentieren, und schließlich
ein Verfahren festlegen, um Restrisiken formell akzeptieren zu können.

Konzepte in Bezug auf die Sicherheit der Informationstechnik

Kommen wir nun zum Konzept in Bezug auf die Sicherheit der Informationstechnik. Hier wird die Interpretation anspruchsvoller, denn auch die Durchführungsverordnung ist nicht ganz einfach zu lesen. Hintergrund ist eine Begriffswelt, die nicht vollständig zu unserem üblichen Sprachgebrauch in der Informationssicherheit passt.

So ist beispielsweise die Rede von „Sicherheit von Netz- und Informationssystemen“ während wir dazu üblicherweise „Sicherheit der Informations- und Kommunikationstechnologie“ oder auch einfach „IKT-Sicherheit“ sagen.

Warum das so ist, lässt sich nur vermuten: unterschiedliche Entstehungszeitpunkte der Regelwerke, verschiedene Arbeitsgruppen und/oder fehlende Vorgaben zur Terminologie. Schade eigentlich – denn hier geht viel Standardisierungspotenzial verloren. Doch Ändern lässt sich das natürlich jetzt nicht, also müssen wir einen pragmatischen Umgang damit finden. Mein Ansatz wäre, einfach konsequent von IKT- und Informationssicherheit zu sprechen.

Zur Erstellung des geforderten Konzepts zur IKT-Sicherheit würde ich …

eine übergeordnete Leitlinie zur Informationssicherheit erarbeiten und durch die Geschäftsleitung genehmigen lassen,
eine IKT-Risikokontrollfunktion oder einen Informationssicherheitsbeauftragten (kurz: ISB) benennen lassen,
eine Ressourcen- und Budgetplanung für das ISM-Team, erforderliche Sicherheitstools sowie Sensibilisierungs- und Weiterbildungsmaßnahmen erstellen,
die erforderlichen IKT-Sicherheitsrichtlinien schreiben, z. B. zu Personalsicherheit, Netzwerksicherheit, Kryptografie, Testen der IKT-Sicherheit, usw.,
einen Kontrollprozess etablieren, um Soll-Vorgaben aus den IKT-Sicherheitsrichtlinien mit der tatsächlichen Umsetzung im Unternehmen abzugleichen,
einmal im Jahr den Implementierungsstand der IKT-Sicherheitsmaßnahmen überprüfen, also einen Soll-Ist-Abgleich durchführen und identifizierte Gaps in die IKT-Risikoanalyse einfließen lassen, und
ein regelmäßiges, quartalsweises Berichtswesen zur IKT- und Informationssicherheit an die Geschäftsleitung etablieren.

Ja, so würde ich diese Anforderung aus § 30 (2) Nummer 1 des NIS-2-Umsetzungsgesetzes wohl angehen. Immer dabei: eine Portion Augenmaß und ein Quäntchen Pragmatismus.

Alles in allem keine Raketenwissenschaft – aber definitiv ordentlich Aufwand. Wie seht ihr das? Wie würdet ihr diese Anforderung operationalisieren? Ich freue mich über eure Gedanken.

P.s. Weitere Infos aus der DORA-Werkstatt gibt es übrigens auf meiner Website www.marlen-hofmann.de. Dort findet ihr zum Beispiel auch die Möglichkeit, meine DORA-Schulungsfolien und einen detaillierten DORA-Anforderungskatalog zu erwerben 🎯