NIS2 Maßnahme 1 — Risikoanalyse und Informationssicherheit

NIS2 Risikoanalyse: Maßnahme 1 verständlich erklärt

Die NIS2-Maßnahme 1 gemäß Art. 21(2)(a) verpflichtet betroffene Unternehmen, Konzepte für die Risikoanalyse und die Sicherheit ihrer Informationssysteme zu entwickeln und umzusetzen. Für die Praxis heißt das: Maßnahme 1 von 10 verlangt eine belastbare NIS2 Risikoanalyse, die Bedrohungen, Schwachstellen, Auswirkungen und Behandlungsentscheidungen systematisch dokumentiert und sich gut auf ISO 27001 Kapitel 6 und 8 sowie ISO 27005 oder BSI-Standard 200-3 abbilden lässt.

Letzte Aktualisierung: 20. März 2026

Wenn Sie nur die Kernaussage brauchen, gilt Folgendes: NIS2 verlangt kein bestimmtes Tool und keine einzige vorgeschriebene Methode, aber eine nachvollziehbare, wiederholbare und zur Unternehmensgröße passende Risikologik. Ein Excel-Risikoregister kann für ein KMU ausreichend sein, wenn Scope, Bewertung, Maßnahmen, Verantwortliche und Review-Zyklen sauber geführt werden. Wer die Gesamtlogik der Richtlinie einordnen will, sollte ergänzend die NIS2-Checkliste, den Beitrag zu NIS2 Maßnahme 2 Incident Handling und den Leitfaden zur Haftung der Geschäftsführung bei NIS2 lesen.

NIS2 Risikoanalyse ist kein isoliertes Dokument für Auditoren, sondern die Grundlage für Prioritäten in Informationssicherheit, Budget und Managemententscheidungen. Genau deshalb hängen daran auch weitere Maßnahmen wie Wirksamkeitsprüfung nach NIS2 Maßnahme 6 und die organisatorische Verankerung in einer NIS2-Schulung. Ohne Risikoanalyse bleibt offen, welche Systeme zuerst abgesichert werden müssen, welche Restrisiken akzeptabel sind und wo Geschäftsführung und Fachbereiche aktiv entscheiden müssen.

Was verlangt Art. 21(2)(a) NIS2 zur Risikoanalyse?

Art. 21(2)(a) NIS2 fordert „Konzepte in Bezug auf die Risikoanalyse und die Sicherheit von Informationssystemen“. Die Norm ist bewusst offen formuliert, damit Unternehmen anerkannte Methoden einsetzen können. Inhaltlich verlangt sie aber eine klare Mindestlogik: Sie müssen kritische Werte und Dienste identifizieren, relevante Bedrohungen und Schwachstellen bewerten, Auswirkungen auf Verfügbarkeit, Integrität und Vertraulichkeit einschätzen und daraus konkrete Behandlungsmaßnahmen ableiten.

Für deutsche Unternehmen ist die Formulierung besonders relevant, weil sie in der nationalen Umsetzung typischerweise in § 30 Abs. 2 Nr. 1 BSIG beziehungsweise in entsprechenden BSIG-E-Formulierungen gespiegelt wird. Der regulatorische Kern bleibt gleich: Informationssicherheit darf nicht nur aus Einzelmaßnahmen bestehen, sondern muss risikobasiert gesteuert werden. Das schließt Technik, Prozesse, Organisation, Lieferkette und Managemententscheidungen ein.

Wichtig ist außerdem der Proportionalitätsgedanke. NIS2 erwartet keine Konzernbürokratie von jedem Mittelständler. Die Tiefe Ihrer Analyse darf sich an Größe, Kritikalität, Bedrohungslage und Komplexität orientieren. Für einen regionalen IT-Dienstleister mit 120 Mitarbeitenden kann eine einfache, aber stringente Methodik angemessen sein. Für einen Betreiber kritischer digitaler Infrastrukturen reicht dieselbe Vereinfachung regelmäßig nicht aus.

In der Praxis sollten Sie Maßnahme 1 deshalb als Steuerungsrahmen lesen. Die Risikoanalyse beantwortet drei Managementfragen:

1. Welche Systeme und Prozesse sind für unsere wesentlichen oder wichtigen Dienste wirklich kritisch?
2. Welche Risiken bedrohen diese Systeme realistisch und mit welchem Schadenspotenzial?
3. Welche Risiken werden behandelt, übertragen, vermieden oder dokumentiert akzeptiert?

Ohne diese drei Antworten bleiben Folgepflichten unscharf. Incident Handling, Business Continuity, Lieferkettensicherheit und Wirksamkeitsprüfungen werden erst dann belastbar, wenn die Risikologik sauber steht.

Methodik — ISO 27005 vs. BSI 200-3 im Vergleich

Die gute Nachricht für Unternehmen lautet: NIS2 schreibt keine einzelne Methode vor. Die bessere Nachricht lautet: Sie müssen das Rad nicht neu erfinden. Für die meisten deutschen Unternehmen sind ISO 27005 und BSI-Standard 200-3 die beiden naheliegendsten Modelle für eine NIS2 Risikoanalyse.

ISO 27005 ist international anschlussfähig und passt besonders gut, wenn bereits ein ISMS nach ISO 27001 existiert oder geplant ist. Die Methode strukturiert den Prozess in Kontextfestlegung, Risikoidentifikation, Risikoanalyse, Risikobewertung und Risikobehandlung. Sie ist managementnah, flexibel und gut für Organisationen geeignet, die mit mehreren Standards arbeiten.

BSI-Standard 200-3 ist für die deutsche Praxis oft noch konkreter. Er setzt auf Zielobjekte, Schutzbedarfe, Gefährdungen und nachvollziehbare Szenarien auf Basis von IT-Grundschutz. Das hilft vor allem Unternehmen, die sehr operativ arbeiten wollen oder bereits Elemente des BSI-Grundschutzes nutzen. Die Methode ist besonders geeignet, wenn Fachbereiche und Technikteams gemeinsam reale Ausfallszenarien durchdenken sollen.

Für viele KMU ist daher nicht die Frage „ISO oder BSI?“, sondern „welche Logik passt zu unserer Organisation?“. ISO 27005 eignet sich gut, wenn internationale Kunden, Auditfähigkeit und Managementsysteme im Vordergrund stehen. BSI 200-3 eignet sich gut, wenn deutsche Praxisnähe, konkrete Gefährdungskataloge und operative Umsetzbarkeit wichtiger sind.

Die folgende Tabelle zeigt das Mapping von NIS2 Maßnahme 1 auf ISO 27001 und die beiden typischen Methoden:

Das ISO-27001-Mapping ist für NIS2 deshalb nützlich, weil viele Unternehmen bereits mit ISO-Vokabular arbeiten. Maßnahme 1 ist dabei kein isolierter Punkt, sondern verbindet Planung, Betrieb und Kontrollen. Besonders relevant sind Kapitel 6 für die Planung, Kapitel 8 für den operativen Umgang mit Risiken und die Annex-A-Bereiche A.5 bis A.8 für organisatorische, personelle, physische und technologische Kontrollen.

Risikobewertungsmatrix erstellen (Schritt-für-Schritt)

Eine NIS2 Risikoanalyse wird erst dann steuerbar, wenn Sie eine klare Bewertungsmatrix verwenden. Ohne definierte Skalen diskutieren Teams endlos darüber, ob ein Risiko „hoch“ oder „mittel“ ist. Mit einer einfachen Matrix entstehen dagegen vergleichbare Entscheidungen.

Für KMU ist eine 5x5-Matrix meist ausreichend. Sie bewertet Eintrittswahrscheinlichkeit und Auswirkung jeweils auf einer Skala von 1 bis 5. Der Risikowert ergibt sich aus der Multiplikation beider Werte. Wichtig ist weniger mathematische Perfektion als eine im Unternehmen verstandene und konsequent verwendete Logik.

Ein pragmatisches Modell sieht so aus:

Die Bewertung läuft dann in fünf Schritten ab:

1. Definieren Sie den Bewertungsgegenstand. Das kann ein kritischer Dienst, ein System, ein Prozess oder eine Lieferantenabhängigkeit sein.
2. Beschreiben Sie ein konkretes Risikoszenario. Beispiel: „Ransomware verschlüsselt das zentrale ERP-System nach kompromittiertem Administratorzugang.“
3. Bewerten Sie die Eintrittswahrscheinlichkeit auf Basis realer Bedrohungslage, Exponierung, Historie und vorhandener Kontrollen.
4. Bewerten Sie die Auswirkung auf Verfügbarkeit, Integrität, Vertraulichkeit, regulatorische Pflichten und Geschäftsfortführung.
5. Leiten Sie die Risikostufe und die notwendige Behandlung ab.

Ein Beispiel: Ein mittelständischer Lebensmittelhersteller betreibt Produktion, Logistik und Rechnungsstellung über ein integriertes ERP. Die IT-Leitung stuft die Wahrscheinlichkeit einer erfolgreichen Phishing-Kampagne mit 4 ein, weil MFA noch nicht vollständig ausgerollt ist. Die Auswirkung eines ERP-Ausfalls wird mit 5 bewertet, weil Produktion und Auslieferung binnen Stunden betroffen wären. Das Risiko liegt damit bei 20 und gehört klar in die oberste Prioritätsklasse.

Wesentlich ist, dass die Matrix nicht abstrakt bleibt. Jedes bewertete Risiko gehört in ein Register mit Risiko-ID, Asset, Szenario, Ursache, aktuelle Kontrollen, Lücken, Eigentümer, Zieltermin und Review-Datum. Genau dieses Register wird später zum Nachweis gegenüber Prüfern und zur Arbeitsgrundlage für Technik, Fachbereich und Management.

Scope festlegen — welche Systeme müssen bewertet werden?

Der häufigste Fehler in NIS2-Projekten ist ein falscher Scope. Unternehmen bewerten entweder viel zu breit und verlieren sich in Detailarbeit oder viel zu eng und übersehen genau die Systeme, auf die es rechtlich und operativ ankommt. Maßnahme 1 beginnt deshalb mit einer klaren Scope-Entscheidung.

Bewertet werden müssen alle Systeme, Prozesse und Abhängigkeiten, die wesentliche oder wichtige Dienste stützen. Dazu gehören in der Regel:

• Geschäftskritische Anwendungen wie ERP, CRM, Ticketsysteme oder Produktionssteuerung
• Identitäts- und Zugriffsinfrastrukturen wie Active Directory, Entra ID oder MFA-Dienste
• Netzwerk- und Kommunikationskomponenten
• Cloud-Plattformen, Hosting, Backups und Recovery-Umgebungen
• Relevante OT-Systeme und Schnittstellen zwischen OT und IT
• Kritische Lieferanten, Managed Services und externe Administratorzugänge
• Informationswerte wie Kundendaten, Betriebsgeheimnisse, Konfigurationsdaten und Notfallunterlagen

Nicht jedes Hilfssystem braucht dieselbe Tiefe. Ein internes Umfragetool ohne Bezug zu kritischen Diensten ist anders zu behandeln als die zentrale Backup-Umgebung. Entscheidend ist die Frage, ob der Ausfall, die Manipulation oder die Offenlegung eines Systems erhebliche Auswirkungen auf den regulierten Dienst hätte.

Gerade bei Scope-Fragen lohnt sich die Verknüpfung mit bestehenden Inventaren. Nutzen Sie vorhandene Asset-Listen, Datenschutzdokumentation, Business-Continuity-Unterlagen oder Lieferantenregister. Das reduziert Aufwand und erhöht Konsistenz. Wenn diese Basis noch fehlt, hilft oft eine einfache Top-down-Logik: zuerst kritische Dienste definieren, dann unterstützende Systeme kartieren, dann die wichtigsten Abhängigkeiten ergänzen.

Ein weiterer häufiger Blindspot ist die Lieferkette. NIS2 Risikoanalyse endet nicht an der eigenen Firewall. Wenn Ihr Dienst auf einem Cloud-Provider, einem Rechenzentrum, einem SIEM-Dienstleister oder einem Fernwartungspartner aufsetzt, gehört diese Abhängigkeit in den Scope. Wer das Thema vertiefen will, sollte anschließend NIS2 Maßnahme 4 zur Lieferkettensicherheit lesen.

Risikobehandlung — Vermeiden, Mindern, Übertragen, Akzeptieren

Eine Risikoanalyse ist erst vollständig, wenn aus Bewertungen Entscheidungen werden. NIS2 erwartet deshalb nicht nur ein Register, sondern nachvollziehbare Risikobehandlung. In der Praxis gibt es vier Grundoptionen: vermeiden, mindern, übertragen oder akzeptieren.

Vermeiden bedeutet, die riskante Aktivität ganz zu beenden oder strukturell zu ändern. Wenn ein unsicherer Fernzugang nicht beherrschbar ist, kann seine Abschaltung die beste Entscheidung sein. Diese Option ist selten bequem, aber oft sehr wirksam.

Mindern ist der Standardfall. Hier reduzieren Sie Eintrittswahrscheinlichkeit oder Auswirkung durch Kontrollen. Typische Beispiele sind MFA, Netzsegmentierung, EDR, Offline-Backups, Hardening, Logging, Patch-Management, Notfallübungen oder strengere Lieferantenanforderungen.

Übertragen heißt nicht, Verantwortung abzugeben. Cyber-Versicherungen, Outsourcing oder vertragliche Haftungsregelungen können finanzielle Folgen teilweise verlagern, lassen aber die Pflicht zur eigenen Steuerung unberührt. Für NIS2 ist Übertragung deshalb nur eine Ergänzung.

Akzeptieren ist zulässig, aber nur mit sauberer Begründung. Ein Restrisiko darf dokumentiert akzeptiert werden, wenn es unterhalb definierter Schwellen liegt oder die Behandlung unverhältnismäßig wäre. Genau hier braucht es Managemententscheidungen, denn akzeptierte Risiken sind Governance-Themen und keine rein technische Nebenfrage.

Ein belastbarer Risikobehandlungsplan enthält mindestens:

1. die Risikobeschreibung und aktuelle Stufe,
2. die gewählte Behandlungsoption,
3. konkrete Maßnahmen,
4. verantwortliche Personen,
5. Budget oder Ressourcenannahmen,
6. Zieltermine,
7. erwartetes Restrisiko nach Umsetzung.

Diese Struktur ist auch deshalb wichtig, weil sie direkt in NIS2 Maßnahme 6 zur Wirksamkeitsprüfung hineinführt. Ohne Zielbild und Restrisikologik können Sie später kaum prüfen, ob Maßnahmen tatsächlich gewirkt haben.

Dokumentationspflichten und Nachweisführung

NIS2 belohnt keine PowerPoint-Compliance. Prüfer und Aufsichtsbehörden interessieren sich für belastbare Nachweise. Bei Maßnahme 1 sollten Sie deshalb weniger an ein langes Konzeptpapier und mehr an ein zusammenhängendes Evidenzpaket denken.

Zum Mindestpaket gehören üblicherweise:

• dokumentierte Methodik inklusive Bewertungslogik und Akzeptanzkriterien,
• Scope-Dokumentation mit kritischen Diensten und einbezogenen Systemen,
• Risikoregister mit aktuellen Bewertungen und Eigentümern,
• Behandlungspläne für hohe und mittlere Risiken,
• Managementfreigaben und Akzeptanzentscheidungen,
• Umsetzungsnachweise für beschlossene Maßnahmen,
• feste Review-Termine und Historie früherer Bewertungen.

Für KMU reicht dafür häufig eine saubere Kombination aus Richtlinie, Tabellenregister und Maßnahmenplan. Wichtig ist nur, dass diese Unterlagen zueinander passen. Ein Risiko mit hoher Priorität darf nicht monatelang ohne Eigentümer im Register stehen. Eine akzeptierte Schwachstelle ohne dokumentierte Begründung ist ebenso problematisch wie ein Maßnahmenplan ohne Abschlussnachweis.

Sinnvoll ist außerdem eine Versionierung. Wenn Sie bei einer Prüfung zeigen können, wie sich Risiken über 12 Monate entwickelt haben, ist das ein starkes Signal für gelebtes Management. Genau diese Historie unterscheidet eine lebende NIS2 Risikoanalyse von einem einmaligen Audit-Dokument.

Wer Dokumentation nur nachholt, wenn ein Vorfall oder eine Prüfung ansteht, arbeitet zu spät. Besser ist ein quartalsweiser Governance-Rhythmus mit Review-Terminen, offenen Maßnahmen, Eskalationen und aktualisierten Restrisikobewertungen.

Umsetzung für KMU — pragmatischer Einstieg

KMU brauchen keine monatelange Methodendebatte, sondern einen Startpunkt. Für viele mittelständische Unternehmen reicht zum Einstieg ein sechswöchiges Vorgehen, wenn die Organisation diszipliniert priorisiert.

Woche 1 und 2: Definieren Sie kritische Dienste, benennen Sie die 10 bis 20 wichtigsten Systeme und halten Sie zentrale Lieferantenabhängigkeiten fest. Entscheidend ist nicht Vollständigkeit bis ins letzte Detail, sondern ein belastbarer erster Scope.

Woche 3: Führen Sie einen Workshop mit IT, Fachbereich und Management durch. Sammeln Sie die wichtigsten Bedrohungsszenarien, etwa Ransomware, Identitätsmissbrauch, Cloud-Ausfall, Lieferantenausfall oder Fehlkonfiguration.

Woche 4: Bewerten Sie diese Szenarien mit einer einheitlichen Matrix. Konzentrieren Sie sich zuerst auf die Top-Risiken mit hoher Auswirkung.

Woche 5: Definieren Sie Maßnahmen, Eigentümer und Zieltermine. Trennen Sie Sofortmaßnahmen von strukturellen Verbesserungen.

Woche 6: Lassen Sie die Ergebnisse durch die Geschäftsführung oder das zuständige Leitungsorgan freigeben und verankern Sie feste Review-Termine.

Dieser pragmatische Einstieg hat zwei Vorteile. Erstens wird die NIS2 Risikoanalyse schnell handlungsfähig. Zweitens entsteht früh ein gemeinsames Risikoverständnis zwischen Technik und Management. Genau daran scheitern viele Programme: Die IT sieht Schwachstellen, aber das Management hat keine priorisierte Entscheidungsgrundlage.

Wenn Ihr Unternehmen noch keine gemeinsame Sicherheitsbasis hat, kombinieren Sie Maßnahme 1 mit Schulung und Governance-Aufbau. Unsere NIS2-Schulung hilft dabei, Leitungsorgan, Compliance und Fachbereiche auf dieselbe Risikologik auszurichten. Für den operativen Einstieg lohnt sich außerdem die NIS2-Checkliste, damit aus Analyse zügig ein umsetzbarer Maßnahmenplan wird.

Häufig gestellte Fragen (FAQ)

Was fordert NIS2 zur Risikoanalyse?

Art. 21(2)(a) NIS2 fordert Konzepte in Bezug auf die Risikoanalyse und die Sicherheit von Informationssystemen. Unternehmen müssen also nicht nur einzelne technische Maßnahmen umsetzen, sondern ein nachvollziehbares Verfahren für Identifikation, Bewertung, Behandlung und Überwachung von Risiken betreiben.

Wie führe ich eine NIS2-Risikoanalyse durch?

Praktisch beginnt die NIS2-Risikoanalyse mit dem Scope kritischer Dienste, einer Asset-Liste, Threat- und Schwachstellenanalyse, einer Likelihood- und Impact-Bewertung sowie einem dokumentierten Risikobehandlungsplan. Für KMU reicht dafür häufig ein sauber geführtes Risikoregister mit klaren Eigentümern und Review-Terminen.

Reicht ISO 27001 als NIS2-Risikoanalyse?

ISO 27001 allein reicht nur dann, wenn die Organisation die dort geforderte Risikoermittlung tatsächlich belastbar lebt und dokumentiert. In der Praxis ist ISO 27005 die passendere Methodik für die Detailtiefe der Risikoanalyse, während ISO 27001 den Managementrahmen mit Planung, Betrieb und Kontrollen bildet.

Wie oft muss die NIS2-Risikoanalyse aktualisiert werden?

Mindestens jährlich sollte eine formale Neubewertung stattfinden. Zusätzlich ist eine Aktualisierung nach wesentlichen Änderungen nötig, etwa nach neuen kritischen Systemen, größeren Vorfällen, Outsourcing, M&A, Cloud-Migrationen oder geänderten Bedrohungslagen.

Welche Methoden empfiehlt das BSI für die Risikoanalyse?

Für deutsche Unternehmen ist BSI-Standard 200-3 besonders praxisnah, weil er auf IT-Grundschutz aufsetzt und konkrete Gefährdungen, Zielobjekte und Schutzbedarfe in den Mittelpunkt stellt. Daneben ist ISO 27005 als international anerkannte Methode sehr gut geeignet.

Fazit: Maßnahme 1 ist die Steuerungslogik hinter NIS2

Die NIS2 Risikoanalyse ist kein formaler Annex, sondern die Grundlage für alle weiteren Sicherheitsmaßnahmen. Wer Maßnahme 1 sauber umsetzt, priorisiert Investitionen besser, dokumentiert Restrisiken belastbarer und schafft eine gemeinsame Sprache zwischen IT, Fachbereich und Geschäftsführung.

Wenn Sie diese Logik nicht nur dokumentieren, sondern im Unternehmen verankern wollen, ist der nächste sinnvolle Schritt eine strukturierte NIS2-Schulung. Dort wird aus abstrakter Regulierung ein umsetzbarer Rahmen für Verantwortlichkeiten, Nachweise und wirksame Sicherheitsentscheidungen.