Kurz gesagt
NIS2 verpflichtet betroffene Einrichtungen zu einem risikobasierten Sicherheitsmanagement: Grundlage aller Maßnahmen ist eine dokumentierte, wiederholbare Risikoanalyse. Bewährt hat sich ein Vorgehen in sieben Schritten — Scope festlegen, Assets erfassen, Bedrohungen identifizieren, Risiken bewerten, Behandlung festlegen, Maßnahmen umsetzen und die Analyse regelmäßig aktualisieren. Eine bestimmte Methode schreibt NIS2 nicht vor; etabliert sind ISO/IEC 27005 und BSI-Standard 200-3. Die Geschäftsleitung muss die Risikomanagement-Maßnahmen billigen und ihre Umsetzung überwachen — sie kann dafür persönlich verantwortlich gemacht werden.
Was verlangt NIS2 bei der Risikoanalyse?
Kern der NIS2-Pflichten ist ein risikobasierter Ansatz: Betroffene Einrichtungen müssen geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen treffen, um die Risiken für ihre IT und ihre Dienste zu beherrschen (Artikel 21 der Richtlinie, in Deutschland § 30 BSIG). Verhältnismäßig heißt: Die Maßnahmen richten sich nach dem Ausmaß der Risikoexposition, der Größe der Einrichtung und den möglichen Folgen eines Vorfalls — genau das lässt sich ohne Risikoanalyse nicht begründen.
NIS2 folgt dabei einem gefahrenübergreifenden Ansatz (all-hazards): Betrachtet werden nicht nur Cyberangriffe, sondern auch physische Ursachen wie Stromausfälle, Naturereignisse oder menschliche Fehler. Die Risikoanalyse muss dokumentiert, nachvollziehbar und wiederholbar sein — eine einmalige Momentaufnahme genügt nicht. Eine bestimmte Methodik gibt das Gesetz nicht vor.
Schritt 1 und 2: Wie legt man den Scope fest und erfasst Assets?
Am Anfang steht die Frage, was geschützt werden muss. Praktisch bewährt: von den kritischen Diensten und Geschäftsprozessen ausgehen — also den Leistungen, deren Ausfall Kunden, Versorgung oder gesetzliche Pflichten treffen würde — und von dort auf die unterstützenden Systeme, Daten und Dienstleister schließen.
Der zweite Schritt ist ein belastbares Asset-Inventar: Systeme, Anwendungen, Datenbestände, Netzwerke und externe Dienste, jeweils mit Eigentümer, Kritikalität und Klassifizierung nach Vertraulichkeit, Integrität und Verfügbarkeit. Dieses Inventar ist das Fundament — Risiken, die man analysiert, hängen immer an Assets, die man kennt. Veraltete oder unvollständige Inventare sind in der Praxis die häufigste Ursache für blinde Flecken in der Risikoanalyse.
Schritt 3 und 4: Wie identifiziert und bewertet man Risiken?
Bei der Identifikation helfen etablierte Kataloge, damit nichts Wesentliches vergessen wird: die elementaren Gefährdungen des BSI IT-Grundschutzes oder die Bedrohungs- und Schwachstellenlisten aus ISO/IEC 27005. Daraus werden konkrete Risikoszenarien je Asset-Gruppe formuliert — etwa „Ransomware verschlüsselt die Produktionsdatenbank“ oder „Ausfall des einzigen Rechenzentrumsstandorts“.
Bewertet wird jedes Szenario nach Eintrittswahrscheinlichkeit und Schadensausmaß — auf definierten, unternehmensweit einheitlichen Skalen (z. B. vierstufig). Vorab festgelegte Risikoakzeptanzkriterien bestimmen, ab welcher Stufe ein Risiko behandelt werden muss. Das Ergebnis ist ein priorisiertes Risikoregister: die geordnete Liste aller bewerteten Risiken mit Verantwortlichen.
Schritt 5 und 6: Wie behandelt man Risiken und setzt Maßnahmen um?
Für jedes Risiko oberhalb der Akzeptanzschwelle gibt es vier Behandlungsoptionen:
- Mindern: technische oder organisatorische Maßnahmen reduzieren Wahrscheinlichkeit oder Auswirkung — der Regelfall
- Vermeiden: die riskante Tätigkeit oder Technologie wird eingestellt oder ersetzt
- Übertragen: das Risiko wird verlagert, etwa durch Versicherung oder vertragliche Regelungen mit Dienstleistern
- Akzeptieren: das Restrisiko wird bewusst getragen — dokumentiert und von der zuständigen Ebene freigegeben
Als Maßnahmenkatalog hat sich Anhang A der ISO/IEC 27001 (93 Controls) bewährt — er deckt die in § 30 BSIG geforderten Bereiche wie Zugriffskontrolle, Kryptografie, Business Continuity und Lieferkettensicherheit ab. Jede Maßnahme braucht einen Verantwortlichen, eine Frist und einen nachvollziehbaren Umsetzungsstand; das verbleibende Restrisiko wird dokumentiert und formal akzeptiert.
Schritt 7: Wie hält man die Risikoanalyse aktuell?
Eine Risikoanalyse veraltet schnell: neue Systeme, neue Lieferanten, neue Bedrohungslagen. In der Praxis bewährt ist ein fester Review-Zyklus — mindestens jährlich — plus anlassbezogene Aktualisierung bei wesentlichen Änderungen, nach Sicherheitsvorfällen und bei neuen kritischen Dienstleistern.
NIS2 nimmt dabei ausdrücklich die Geschäftsleitung in die Pflicht: Sie muss die Risikomanagement-Maßnahmen billigen, ihre Umsetzung überwachen und sich regelmäßig schulen lassen (§ 38 BSIG) — und kann für Verstöße persönlich verantwortlich gemacht werden. Ein regelmäßiges Management-Reporting mit Risikolage, Maßnahmenfortschritt und offenen Restrisiken ist deshalb nicht Kür, sondern Teil der Compliance.
Welche Methode sollte man wählen — ISO 27005, BSI 200-3 oder eigene Matrix?
NIS2 schreibt keine Methode vor — entscheidend ist, dass das Vorgehen dokumentiert, konsistent und wiederholbar ist. ISO/IEC 27005 ist die richtige Wahl, wenn ohnehin ein ISMS nach ISO 27001 aufgebaut oder zertifiziert werden soll; BSI-Standard 200-3 passt für Organisationen mit IT-Grundschutz-Nähe oder Behördenkontext. Für den Einstieg genügt auch eine schlanke, selbst definierte Risikomatrix — solange Skalen, Akzeptanzkriterien und Verantwortlichkeiten sauber definiert sind.
Wer die Risikoanalyse einmal sauber aufsetzt, erfüllt damit den Kern gleich mehrerer Regelwerke: NIS2, ISO 27001 (Kapitel 6 und 8) und DSGVO-Risikobetrachtungen greifen auf dieselbe Basis zu. Flux Platform bildet den kompletten Zyklus ab — Assets aus der CMDB mit CIA-Klassifizierung, Risikoregister mit Bewertungs- und Behandlungsworkflows, Maßnahmen gemappt auf ISO 27001 und NIS2 sowie Reports, mit denen die Geschäftsleitung ihre Billigungspflicht nachweisbar erfüllt.
Häufige Fragen
Wie oft muss die NIS2-Risikoanalyse wiederholt werden?
NIS2 nennt kein festes Intervall, verlangt aber ein wirksames, aktuelles Risikomanagement. Etabliert ist ein vollständiger Review mindestens einmal jährlich plus anlassbezogene Aktualisierungen — etwa bei neuen Systemen, wesentlichen Änderungen, Sicherheitsvorfällen oder neuen kritischen Dienstleistern.
Welche Methode verlangt NIS2 für die Risikoanalyse?
Keine bestimmte. NIS2 verlangt einen risikobasierten, gefahrenübergreifenden Ansatz mit dokumentiertem, wiederholbarem Vorgehen. In der Praxis etabliert sind ISO/IEC 27005 und BSI-Standard 200-3; auch eine eigene Risikomatrix ist zulässig, wenn Skalen und Akzeptanzkriterien sauber definiert sind.
Reicht eine Excel-Tabelle für die NIS2-Risikoanalyse?
Für den allerersten Durchlauf kann eine Tabelle genügen. Spätestens im laufenden Betrieb wird sie zum Risiko: keine Versionierung, keine Workflows, keine Verknüpfung zu Assets und Maßnahmen, keine belastbaren Nachweise für Aufsicht oder Audit. Ein werkzeuggestütztes Risikoregister hält Bewertungen, Verantwortliche und Historie konsistent.
Muss die Geschäftsleitung die Risikoanalyse freigeben?
Ja. Nach § 38 BSIG muss die Geschäftsleitung die Risikomanagement-Maßnahmen billigen und ihre Umsetzung überwachen — sie kann für Verstöße persönlich verantwortlich gemacht werden. Eine dokumentierte Freigabe der Risikoanalyse und des Maßnahmenplans ist dafür der übliche Nachweis.
Was ist der Unterschied zur Risikoanalyse nach ISO 27001?
Im Kern keiner: Beide verlangen ein dokumentiertes, wiederholbares Risikomanagement mit Bewertung und Behandlung. Wer bereits ein ISMS nach ISO 27001 mit gepflegtem Risikoregister betreibt, erfüllt die NIS2-Anforderung an die Risikoanalyse weitgehend und muss vor allem den gefahrenübergreifenden Blick und das Management-Reporting nachschärfen.