¶ NIS2-Risikobehandlungsplan
Leerer Planungsentwurf: Diese öffentliche Musterseite enthält keine realen Risiken, Maßnahmen, Budgets, Sicherheitslücken, Termine oder Freigaben. Die farbigen Statuswerte und Musterzeilen dienen ausschließlich der Erläuterung des vorgesehenen Arbeitsablaufs.
Keine Umsetzungs- oder Wirksamkeitsbehauptung: Eine geplante, beauftragte oder technisch abgeschlossene Maßnahme gilt nicht automatisch als wirksam. Umsetzung, Nachweis, Prüfung, Restrisiko und Abschlussentscheidung müssen organisationsbezogen bestätigt werden.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-PLAN-02-03 |
| Dokumentenart | Verfahren und Portfoliostruktur für die NIS2-Risikobehandlung |
| Wiki.js-Pfad | /NIS2/02-Risikomanagement-und-Nachweise/Risikobehandlungsplan |
| Verantwortlich | Risk Owner; Maßnahmen-Owner; NIS2-/Informationssicherheitskoordination |
| Status | Entwurf – keine realen Maßnahmen beschlossen, umgesetzt oder als wirksam bestätigt |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Wiki enthält Muster und Steuerungslogik; technische Details und Budgetdaten geschützt |
| Freigabe | Ausstehend; Prioritäten, Entscheidungsschwellen, Rollen und Berichtstakt festzulegen |
Risikobehandlung mit klaren Verantwortlichkeiten, überprüfbaren Ergebnissen und befristeten Entscheidungen steuern. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Portfolio-Cockpit – Muster ohne Echtdaten
Das Cockpit zeigt die vorgesehene Leitungs- und Arbeitsansicht. Ein Gedankenstrich bedeutet: Auf dieser Musterseite liegt kein realer Messwert vor. Fehlende Werte dürfen nicht als Null, Erfüllung oder termingerechte Umsetzung interpretiert werden.
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
Ein reales Cockpit nennt Stichtag, Scope, Datenquelle, Filter und Aussagegrenze. Die Anzahl geschlossener Tickets ist keine Wirksamkeitskennzahl.
¶ 2. Zweck und erwartete Arbeitsergebnisse
Der Risikobehandlungsplan übersetzt priorisierte Risiken in genehmigte, finanzierte und überprüfbare Veränderungen. Er soll sicherstellen, dass
- jedes zu behandelnde Risiko eine begründete Behandlungsentscheidung erhält,
- relevante Dienste, Systeme, Standorte, Anbieter und Abhängigkeiten berücksichtigt werden,
- Sollzustand und erwartete Risikoreduktion verständlich beschrieben sind,
- Owner, Ressourcen, Budget, Meilensteine und Termine realistisch festgelegt werden,
- Verzögerungen und Blockaden mit Zwischenmaßnahmen und Eskalationen behandelt werden,
- Umsetzung, Nachweis und Wirksamkeit getrennt bewertet werden,
- das verbleibende Risiko befugt, begründet und befristet entschieden wird.
Der Plan ist damit Portfolio, Entscheidungsgrundlage und Steuerungsprozess. Er ersetzt weder das Risikoregister noch Projekt-, Change-, Ticket- oder Nachweismanagement.
¶ 3. Rechtlicher Steuerungsrahmen
§ 30 BSIG verlangt geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen. Bei der Verhältnismäßigkeit sind unter anderem Risikoexposition, Größe, Umsetzungskosten sowie Wahrscheinlichkeit und Schwere möglicher Sicherheitsvorfälle und deren gesellschaftliche und wirtschaftliche Auswirkungen zu berücksichtigen. Die Einhaltung ist zu dokumentieren.
§ 38 BSIG verpflichtet die Geschäftsleitungen besonders wichtiger und wichtiger Einrichtungen, die Risikomanagementmaßnahmen umzusetzen und ihre Umsetzung zu überwachen. Der Risikobehandlungsplan unterstützt diese Steuerung, ersetzt aber keine rechtliche Betroffenheitsprüfung, keine Vollmacht und keine Leitungsentscheidung.
Für Betreiber kritischer Anlagen können zusätzliche Anforderungen nach § 31 BSIG gelten. Sektor-, Vertrags-, Datenschutz-, Arbeits- oder Produktsicherheitsanforderungen werden ergänzend geprüft.
¶ 4. Verbindung der führenden Register
Die Referenzkette lautet:
relevanter Dienst → Risiko-ID → Behandlungsentscheidung → Maßnahmen-ID → Arbeitspakete/Changes → Nachweis-ID → Wirksamkeitsprüfung → Restrisikobewertung → Abschluss- oder Akzeptanzentscheidung
Das Risikoregister bleibt für Szenario und Bewertung führend. Der Behandlungsplan führt Entscheidung und Umsetzung. Das Nachweisregister referenziert kontrollierte Belege. Die Wirksamkeitsprüfung dokumentiert Methode, Ergebnis und Aussagegrenze. Änderungen werden über IDs statt über unkontrollierte Textkopien synchronisiert.
¶ 5. Behandlungsoptionen
| Option | Ziel | Erforderliche Begründung |
|---|---|---|
| Reduzieren | Wahrscheinlichkeit oder Auswirkung senken | Maßnahmen, erwartete Wirkung, Aufwand und Restrisiko |
| Vermeiden | riskante Tätigkeit, Technik oder Abhängigkeit beenden/ändern | Auswirkungen auf Dienst, Vertrag, Kunden und Betrieb |
| Übertragen/Teilen | finanzielle oder operative Folgen verteilen | Umfang, Vertragspartner, Ausschlüsse und verbleibende Eigenverantwortung |
| Akzeptieren | Risiko innerhalb genehmigter Grenzen befristet tragen | Alternativen, Toleranz, Bedingungen, Entscheider und Review |
Eine Versicherung oder vertragliche Haftungsregel überträgt nicht automatisch die Verantwortung für Dienstverfügbarkeit, Sicherheit oder gesetzliche Pflichten. Auch Vermeidung und Akzeptanz sind kontrollierte Behandlungsentscheidungen.
¶ 6. Entscheidung über die Behandlung
Die Auswahl berücksichtigt mindestens:
- Bruttorisiko, Unsicherheit und Geschwindigkeit möglicher Auswirkungen,
- Bedeutung und Wiederanlaufanforderungen des relevanten Dienstes,
- rechtliche, behördliche, vertragliche und interne Bindungen,
- Wirksamkeit bestehender Kontrollen und bekannte Schwachstellen,
- technische Machbarkeit und nachhaltige Betriebsfähigkeit,
- Umsetzungszeit, Beschaffung, Kompetenz und Ressourcen,
- neue Risiken, Nebenwirkungen und Abhängigkeiten der Lösung,
- erwartete Risikoreduktion im Verhältnis zum Aufwand.
Zwingende Pflichten oder unvertretbare Risiken werden nicht allein durch Kostenargumente aufgehoben. Wo mehrere Optionen möglich sind, werden Alternativen und Auswahlgrund dokumentiert.
¶ 7. Eindeutige Maßnahmenidentität
Jede Maßnahme erhält eine dauerhafte ID, beispielsweise NIS2-MA-2026-001. Eine Maßnahme kann mehrere Risiken behandeln; die erwartete Wirkung wird jedoch je Risiko und Scope bewertet. Umgekehrt kann ein Risiko mehrere Maßnahmen benötigen.
Erfasst werden außerdem:
- Titel und verständliche Kurzbeschreibung,
- Programm, Projekt oder Change-Referenz,
- betroffene Risiken, Dienste, Systeme, Standorte und Anbieter,
- Maßnahmen-Owner, Risk Owner, Sponsor und Prüfer,
- Vorgänger, Nachfolger, Ersatz- oder Zwischenmaßnahme,
- Versions- und Änderungshistorie.
„Security verbessern“ oder „Tool einführen“ ist keine ausreichend prüfbare Maßnahmenbeschreibung.
¶ 8. Mindestfelder je Maßnahmensteckbrief
| Feldgruppe | Mindestinhalt |
|---|---|
| Identität | Maßnahmen-ID, Titel, Typ, Version, Programm/Projekt und Status |
| Referenzen | Risiko-ID, Dienst-ID, Anforderung, Kontrollziel und Nachweisbedarf |
| Scope | Organisationseinheit, Prozess, System, Standort, Anbieter und Zeitraum |
| Sollzustand | konkret erwarteter Betriebs- oder Sicherheitszustand |
| Wirkung | erwartete Änderung von Wahrscheinlichkeit, Auswirkung und Erkennungsfähigkeit |
| Verantwortung | Risk Owner, Maßnahmen-Owner, Sponsor, Prüfer, Vertretung und Mitwirkende |
| Planung | Start, Meilensteine, Fälligkeit, Aufwand, Priorität und Abhängigkeiten |
| Ressourcen | Personal, Kompetenz, Budget, Beschaffung, Lizenzen und Betriebsaufwand |
| Sicherheit | Change-, Test-, Rollback-, Datenschutz- und Kontinuitätsanforderungen |
| Zwischenlage | Zwischenmaßnahmen, Gültigkeit, Überwachung und Eskalationsschwelle |
| Nachweis | Lieferobjekte, Protokolle, Tests, Abnahme und kontrollierte Referenzen |
| Wirksamkeit | Hypothese, Messkriterium, Methode, Stichprobe, Termin und Prüfer |
| Restrisiko | Neubewertung, Unsicherheit, Toleranz, Entscheider, Bedingungen und Review |
| Abschluss | Abnahme, offene Punkte, Betriebsübergabe und Abschlussentscheidung |
Pflichtfelder und Wertelisten werden vor produktiver Nutzung genehmigt.
¶ 9. Messbarer Sollzustand
Der Sollzustand beschreibt, was nach Umsetzung beobachtbar anders sein muss. Gute Formulierungen nennen Scope, Zielwert, Zeitpunkt und Betriebsverantwortung. Beispiele für geeignete Musterformulierungen sind:
- Wiederherstellung eines definierten Musterdienstes innerhalb des genehmigten Zielwerts erfolgreich getestet,
- privilegierte Musterzugriffe vollständig einer befugten Rolle und einem regelmäßigen Review zugeordnet,
- kritische Musterupdates innerhalb genehmigter Fristen bewertet, freigegeben und nachweisbar verteilt,
- Lieferantenmeldung und Eskalation für einen Beispieldienst vertraglich und operativ getestet.
Die konkreten Zielwerte werden nicht aus dem Muster-Wiki übernommen, sondern aus Risiko, Dienstanforderung und betrieblichen Möglichkeiten abgeleitet.
¶ 10. Priorisierungsmodell
Priorität ergibt sich nicht nur aus dem numerischen Risikowert. Berücksichtigt werden:
- Überschreitung genehmigter Risikotoleranz,
- drohende Auswirkung auf kritische oder wichtige Dienste,
- gesetzliche, behördliche oder vertragliche Frist,
- Geschwindigkeit der möglichen Schadensentwicklung,
- Abhängigkeit anderer Maßnahmen von dieser Voraussetzung,
- kurzfristig erreichbare Risikoreduktion,
- verfügbare Ressourcen und sichere Umsetzbarkeit,
- Konzentrations- und Kaskadenwirkung.
Prioritätsstufen erhalten eine Definition, Entscheidungsbefugnis, Zielbearbeitungszeit und Eskalationsregel.
¶ 11. Portfolio-Priorität als Ampel
Toleranz überschritten oder unmittelbare wesentliche Dienstwirkung; Leitung und Zwischenmaßnahmen erforderlich.
hohes Risiko oder bindende Frist; verbindlich planen, finanzieren und überwachen.
mittleres Risiko; in Roadmap aufnehmen und regelmäßig prüfen.
niedriges Risiko innerhalb der Toleranz; begründet beobachten oder akzeptieren.
Die Farbe ist nur eine Zusammenfassung. Maßgeblich bleiben begründete Priorität, Entscheidung und dokumentierte Bedingungen.
¶ 12. Statusmodell der Maßnahme
„Technisch abgeschlossen“ bedeutet lediglich, dass definierte Lieferobjekte bereitstehen. Erst ein geeignetes Prüfergebnis erlaubt den Status „wirksam bestätigt“. Auch danach bleibt die Kontrolle im Betrieb zu überwachen.
¶ 13. Termin- und Fälligkeitsampel
Terminstatus berücksichtigt nicht nur das Enddatum, sondern auch kritische Meilensteine, Beschaffung, Testfenster und Abhängigkeiten. Jede Verschiebung enthält Ursache, Risikowirkung, Zwischenmaßnahme, neue Fälligkeit und befugte Entscheidung. Fristen werden nicht stillschweigend überschrieben.
¶ 14. Planung von Arbeitspaketen und Meilensteinen
Komplexe Maßnahmen werden in überprüfbare Arbeitspakete zerlegt. Typische Meilensteine sind:
- fachliches und technisches Zielbild genehmigt,
- Datenschutz-, Betriebs-, Architektur- und Kontinuitätsanforderungen geprüft,
- Beschaffung und Lieferantenauswahl abgeschlossen,
- Testumgebung und Abnahmekriterien bereit,
- Pilot sicher durchgeführt,
- produktiver Rollout mit Rückfallplan abgeschlossen,
- Betrieb, Monitoring, Support und Dokumentation übergeben,
- Nachweise vollständig und Wirksamkeitsprüfung durchgeführt.
Meilensteine erhalten Owner, Soll-/Ist-Termin und objektives Abnahmekriterium.
¶ 15. Ressourcen und Kapazitätsplanung
Der Plan weist nicht nur einmalige Projektaufwände aus. Er berücksichtigt:
- interne Fach-, Betriebs-, Sicherheits- und Projektkapazität,
- benötigte Kompetenzen und Schulungen,
- externe Beratung, Prüfung oder Implementierung,
- Beschaffung, Lieferzeiten und Vertragsfreigaben,
- Lizenzen, Hardware, Migration und Test,
- dauerhaften Betriebs-, Monitoring- und Reviewaufwand,
- Vertretung, Bereitschaft und Notfallkapazität.
Eine Maßnahme ohne realistisch verfügbare Ressourcen gilt nicht als belastbar geplant.
¶ 16. Budget und Wirtschaftlichkeitsbetrachtung
Budgetfelder unterscheiden Investition, laufende Kosten, interne Aufwände, Reserve und Folgekosten. Die Entscheidung betrachtet erwartete Risikoreduktion, Dienstwirkung, Pflichten, technische Lebensdauer und Alternativen. Vertrauliche Beträge bleiben in geschützten Systemen; das Wiki kann Status und genehmigte Referenz abbilden.
Wirtschaftlichkeit bedeutet nicht, allein die günstigste Lösung zu wählen. Eine günstige Maßnahme ohne nachhaltigen Betrieb oder messbare Wirkung kann insgesamt unwirtschaftlich sein.
¶ 17. Abhängigkeiten, Blockaden und kritischer Pfad
Jede Maßnahme erfasst Voraussetzungen und nachgelagerte Abhängigkeiten. Beispiele sind Identitätsplattform, Netzwerksegmentierung, Lieferantenvertrag, Datenklassifizierung, Asset-Inventar, Wartungsfenster oder verfügbare Testumgebung.
Blockaden erhalten Owner, Auswirkung, Zieltermin und Eskalationsweg. Gemeinsame Voraussetzungen mehrerer Maßnahmen werden als Programm gesteuert. So werden konkurrierende Änderungen und Konzentrationsrisiken sichtbar.
¶ 18. Zwischenmaßnahmen
Kann die dauerhafte Lösung nicht rechtzeitig umgesetzt werden, werden geeignete Zwischenmaßnahmen festgelegt. Sie enthalten:
- konkrete Risikowirkung und Grenzen,
- betroffenen Scope und verantwortlichen Betrieb,
- Beginn, Ablaufdatum und Überwachungskennzahl,
- zusätzliche manuelle Kontrollen oder Bereitschaft,
- Auslöser für Eskalation oder sofortige Beendigung,
- Verbindung zur dauerhaften Maßnahme.
Eine Zwischenmaßnahme ist keine unbefristete Ersatzlösung. Ihr Ablauf erzeugt automatisch Review oder Eskalation.
¶ 19. Sichere Entwurfs- und Änderungssteuerung
Maßnahmen können selbst neue Risiken erzeugen. Deshalb werden vor Freigabe unter anderem geprüft:
- Architektur, Schnittstellen und neue Angriffsflächen,
- Berechtigungen, Protokollierung und Administration,
- Datenschutz und Informationsklassifizierung,
- Lieferketten- und Cloud-Abhängigkeiten,
- Notfallbetrieb, Wiederanlauf und Rückfalloption,
- Wartbarkeit, Support und Lebenszyklus,
- Auswirkungen auf andere Dienste und Kontrollen.
Produktive Änderungen folgen dem genehmigten Change-Verfahren. Notfalländerungen erhalten eine zeitnahe Nachprüfung.
¶ 20. Test-, Pilot- und Rolloutplanung
Ein sicherer Rollout definiert Testumfang, Umgebung, Testdaten, Erfolgs- und Abbruchkriterien, Rollback, Kommunikationsweg und Freigabe. Pilotgruppen werden so gewählt, dass wesentliche Betriebsbedingungen vertreten sind, ohne unnötig hohe Auswirkungen zu riskieren.
Test und Produktivbetrieb werden getrennt dokumentiert. Ein erfolgreicher Labortest beweist nicht automatisch die Wirksamkeit im gesamten produktiven Scope.
¶ 21. Kommunikation, Schulung und Betriebsübergabe
Organisatorische Verankerung ist Teil der Maßnahme. Geplant werden:
- betroffene Rollen und Kommunikationsbedarf,
- Arbeits- und Verfahrensanweisungen,
- zielgruppengerechte Schulung oder Einweisung,
- Support-, Eskalations- und Störungsweg,
- Betriebsverantwortung und Vertretung,
- Wartung, Monitoring, Review und Kennzahlen,
- aktualisierte Notfall- und Wiederanlaufunterlagen.
Eine technische Installation ohne handlungsfähigen Betrieb ist kein vollständiger Abschluss.
¶ 22. Nachweise je Phase
| Phase | Mögliche Nachweisarten |
|---|---|
| Entscheidung | Risikoanalyse, Alternativenbewertung, Freigabe und Budgetreferenz |
| Entwurf | Zielbild, Anforderungen, Sicherheits- und Datenschutzprüfung |
| Umsetzung | Change, Konfiguration, Lieferobjekt, Ticket und Abweichungsprotokoll |
| Test/Abnahme | Testplan, Ergebnis, Stichprobe, Fehler, Abnahme und Rollbacknachweis |
| Betrieb | Monitoring, Review, Schulung, Wartung und Leistungsdaten |
| Wirksamkeit | Prüfkriterium, Methode, Ergebnis, Aussagegrenze und Feststellung |
| Abschluss | Restrisikobewertung, Entscheidung, offene Punkte und Übergabe |
Originale verbleiben in geschützten Ablagen. Der Plan referenziert Nachweis-IDs und Prüfstatus.
¶ 23. Umsetzungsabnahme
Die Umsetzungsabnahme bestätigt, dass der genehmigte Sollzustand hergestellt wurde. Geprüft werden Scope, Lieferobjekte, Konfiguration, Dokumentation, bekannte Abweichungen, Rollback, Betrieb und Schulung. Abnahme kann vollständig, mit Auflagen oder abgelehnt erfolgen.
Auflagen erhalten Owner, Termin und Nachprüfung. Eine Abnahme mit offenen Punkten ist kein Wirksamkeitsnachweis.
¶ 24. Wirksamkeitshypothese und Prüfkriterien
Vor Umsetzung wird formuliert, warum die Maßnahme das Risiko reduzieren soll. Beispielstruktur:
Wenn [Maßnahme] im [Scope] vollständig betrieben wird, dann sinkt [Wahrscheinlichkeit/Auswirkung/Erkennungszeit], weil [Wirkmechanismus]. Dies wird mit [Methode] gegen [Kriterium] bis [Termin] geprüft.
Prüfkriterien können Zielwerte, Fehlerquoten, Testresultate, Wiederherstellungszeiten, Erkennungsraten, Stichprobenergebnisse oder qualitative Fachentscheidungen sein. Quelle, Messzeitraum, Toleranz und Aussagegrenze werden festgelegt.
¶ 25. Unabhängigkeit und Qualität der Prüfung
Prüfer benötigen ausreichende Kompetenz, Informationen und Unabhängigkeit vom Umsetzungsinteresse. Je nach Risiko kann eine Selbstprüfung, fachliche Gegenprüfung, interne Revision oder externe Prüfung angemessen sein. Kritische Maßnahmen sollten nicht ausschließlich durch die umsetzende Person als wirksam bestätigt werden.
Nicht bestandene Prüfungen führen zu Nachbesserung, geänderter Behandlung oder neuer Restrisikoentscheidung.
¶ 26. Restrisikobewertung
Nach Umsetzung und Wirksamkeitsprüfung wird das Risiko mit aktueller Tatsachenbasis neu bewertet. Dokumentiert werden:
- tatsächlich wirksame Kontrollen und deren Scope,
- verbleibende Wahrscheinlichkeit und Auswirkung,
- Unsicherheit, Annahmen und fehlende Daten,
- neue oder verlagerte Risiken,
- weiterhin offene Abweichungen,
- Vergleich zum Bruttorisiko und zur genehmigten Toleranz,
- Reviewtermin und Frühwarnindikatoren.
Das Restrisiko wird nicht automatisch auf den geplanten Zielwert gesetzt.
¶ 27. Risikoakzeptanz
Eine Akzeptanz ist eine befugte, begründete und befristete Entscheidung. Sie enthält Risiko-ID, Scope, Tatsachenbasis, Alternativen, Bedingungen, Restrisiko, Entscheider, Gültigkeit und Review. Akzeptanz ersetzt keine zwingende Pflicht und keine fehlende Information.
Änderungen, Vorfälle, neue Schwachstellen, Fristablauf oder Überschreitung von Kennzahlen lösen eine vorzeitige Neubewertung aus.
¶ 28. Entscheidungs- und Freigabeschwellen
Die Organisation definiert, wer abhängig von Risikostufe, Dienstwirkung, Budget und Abweichungsdauer entscheiden darf. Mögliche Ebenen sind Risk Owner, Bereichsleitung, Informationssicherheitsgremium und Geschäftsleitung. Interessenkonflikte und Vertretung werden berücksichtigt.
Geschäftsleitungsberichte enthalten nicht nur Ampeln, sondern wesentliche Risiken, Alternativen, Ressourcenengpässe, Abweichungen, erwartete Wirkung und benötigte Entscheidungen.
¶ 29. RACI-Grundmodell
| Aufgabe | Risk Owner | Maßnahmen-Owner | Fach-/Betriebsteam | Informationssicherheit | Wirksamkeitsprüfer | Geschäftsleitung |
|---|---|---|---|---|---|---|
| Behandlungsoption vorschlagen | V | M | K | M | I | I |
| Maßnahme planen und kalkulieren | M | V | M | K | I | I |
| Priorität und Ressourcen freigeben | M | M | K | K | I | V/E |
| sicher umsetzen | I | V | M | K | I | I |
| Umsetzungsabnahme | M | M | V | K | I | I |
| Wirksamkeit prüfen | K | I | K | M | V | I |
| Restrisiko entscheiden | V/M | I | K | K | M | E nach Schwelle |
| Abschluss und Überwachung | V | M | M | K | K | I |
V = verantwortlich, M = mitwirkend, K = konsultiert, I = informiert, E = entscheidend. Das Muster ist an Vollmachten und Organisation anzupassen.
¶ 30. Eskalationsauslöser
Eine Eskalation wird insbesondere ausgelöst durch:
- hohes oder kritisches Risiko ohne genehmigten Plan,
- fehlenden Owner, Budget oder realistischen Termin,
- gefährdete oder überfällige kritische Meilensteine,
- Ausfall einer Zwischenmaßnahme,
- neue erhebliche Abhängigkeit oder Nebenwirkung,
- nicht bestandene Abnahme oder Wirksamkeitsprüfung,
- Restrisiko oberhalb der Toleranz,
- wiederholte Terminverschiebung oder Statusänderung ohne Begründung,
- bindende Frist oder wesentliche Dienstbeeinträchtigung.
Die Eskalation nennt Entscheidungspunkt, Handlungsoptionen und spätesten Entscheidungstermin.
¶ 31. Managementbericht
Der Bericht trennt Bestands-, Fortschritts- und Entscheidungsinformationen. Er enthält beispielsweise:
- Risiken ohne genehmigte Behandlung,
- Maßnahmen nach Priorität, Status und Dienst,
- überfällige und gefährdete Termine,
- Budget- und Kapazitätsengpässe,
- wirksam bestätigte, ungeprüfte und nicht wirksame Maßnahmen,
- offene Restrisiko- und Akzeptanzentscheidungen,
- Abhängigkeiten und Kaskadenwirkung,
- benötigte Leitungsentscheidungen.
Jeder Bericht nennt Stichtag, Datenquelle, Verantwortlichen und Einschränkungen.
¶ 32. Kennzahlen
| Kennzahl | Aussage und Grenze |
|---|---|
| Risiken ohne genehmigte Behandlung | zeigt ungesteuerte Entscheidungsbedarfe, nicht automatisch Pflichtverletzung |
| überfällige Maßnahmen nach Risikostufe | priorisiert Terminrisiken; Ursache separat bewerten |
| Maßnahmen ohne Owner oder Budget | zeigt mangelnde Planungsreife |
| technisch abgeschlossen, aber ungeprüft | macht Wirksamkeitslücken sichtbar |
| nicht bestandene Wirksamkeitsprüfungen | löst Nachsteuerung und Lernen aus |
| wiederholt verschobene Maßnahmen | zeigt mögliche Struktur- oder Ressourcenprobleme |
| Restrisiken oberhalb Toleranz | erfordert Entscheidung oder weitere Behandlung |
| ablaufende Zwischenmaßnahmen/Akzeptanzen | unterstützt rechtzeitige Neubewertung |
Definition, Datenquelle, Stichtag, Zielwert und Eskalationsschwelle werden genehmigt.
¶ 33. Portfolio- und Roadmapsteuerung
Maßnahmen werden nach gemeinsamen Voraussetzungen, Diensten, Technologien und Umsetzungsfenstern gebündelt. Die Roadmap zeigt kritischen Pfad, Kapazitätsgrenzen und Konflikte. Eine Verschiebung wird auf abhängige Maßnahmen und Risiken durchgerechnet.
Portfolioentscheidungen dürfen die Nachvollziehbarkeit einzelner Risiken nicht aufheben. Jede gebündelte Maßnahme behält ihre Risiko- und Wirkungszuordnung.
¶ 34. Fiktive Musterzeilen
Die folgenden Zeilen sind reine Demonstrationsdaten. Sie bestätigen weder Risiko noch Maßnahmenumsetzung eines Unternehmens.
| ID | fiktive Maßnahme | fiktiver Scope | Priorität | Status | Termin | Wirksamkeit/Restrisiko |
|---|---|---|---|---|---|---|
| DEMO-MA-001 | Wiederanlaufverfahren für Beispieldienst A testen | Muster-Rechenzentrum | ■ P1 · MUSTER | ▲ IN UMSETZUNG | ! GEFÄHRDET | Prüfung und Restrisiko offen |
| DEMO-MA-002 | Review privilegierter Musterkonten automatisieren | Beispielplattform | ▲ P2 · MUSTER | ◇ FREIGEGEBEN | ✓ IM PLAN | Hypothese definiert, nicht geprüft |
| DEMO-MA-003 | Vertragliche Meldewege mit Beispielanbieter ergänzen | fiktiver Lieferant | ! P3 · MUSTER | ○ VORGESCHLAGEN | × ÜBERFÄLLIG | keine reale Entscheidung |
¶ 35. Filter- und Arbeitsansichten
Nützliche Ansichten sind:
- Maßnahmen je relevantem Dienst und Risikostufe,
- meine offenen Aufgaben nach Owner,
- P1-/P2-Maßnahmen ohne Freigabe oder Budget,
- gefährdete und überfällige Meilensteine,
- Maßnahmen ohne Zwischenkontrolle,
- technisch abgeschlossene, aber ungeprüfte Maßnahmen,
- nicht wirksame oder nur teilweise wirksame Maßnahmen,
- offene Restrisiko- und Akzeptanzentscheidungen,
- ablaufende Zwischenmaßnahmen und Akzeptanzen,
- gemeinsame Abhängigkeiten und Blockaden.
Filter verändern nicht den Status. Exporte tragen Stichtag und Filterkriterien.
¶ 36. Umgang mit Planänderungen
Änderungen an Ziel, Scope, Termin, Budget, Owner, Prüfkriterium oder Behandlungsoption werden versioniert. Wesentliche Änderungen erfordern eine erneute Risiko- und Freigabeprüfung. Der Änderungsgrund und die Auswirkung auf erwartete Risikoreduktion werden dokumentiert.
Ein Projektstatusbericht ersetzt keine genehmigte Änderung des Risikobehandlungsplans.
¶ 37. Abschlusskriterien
Eine Maßnahme kann erst abgeschlossen werden, wenn
- der genehmigte Scope umgesetzt oder eine Abweichung entschieden ist,
- Lieferobjekte und Betriebsdokumentation vollständig sind,
- Umsetzungsabnahme und erforderliche Nachweise vorliegen,
- Wirksamkeit nach definierter Methode geprüft wurde,
- Restrisiko mit aktueller Tatsachenbasis bewertet ist,
- offene Punkte, Auflagen und Folgemaßnahmen geklärt sind,
- Betriebs-, Monitoring- und Reviewverantwortung übergeben wurde,
- Abschluss- oder Akzeptanzentscheidung befugt dokumentiert ist.
„Ticket geschlossen“ oder „Rechnung bezahlt“ genügt nicht.
¶ 38. Abbruch, Ersatz und nicht wirksame Maßnahmen
Eine Maßnahme kann abgebrochen oder ersetzt werden, wenn sie technisch ungeeignet, unverhältnismäßig, nicht mehr erforderlich oder durch eine bessere Option überholt ist. Vor der Entscheidung werden Auswirkung, bereits entstandene Abhängigkeiten, Rückbau, Daten, Verträge und Restrisiko bewertet.
Nicht wirksame Maßnahmen werden nicht als Erfolg geschlossen. Sie führen zu Nachbesserung, alternativer Behandlung, begründeter Akzeptanz oder erneuter Eskalation.
¶ 39. Archivierung und Historie
Pläne, Freigaben, Änderungen, Nachweise, Tests, Restrisiko- und Abschlussentscheidungen werden nach Schutz- und Aufbewahrungsregeln geführt. Ersetzte Versionen bleiben nachvollziehbar, ohne als aktuell angezeigt zu werden. Löschsperren aus Vorfällen, Audits oder Rechtsverfahren werden berücksichtigt.
Das Wiki zeigt nur Muster und kontrollierte Metadaten; vertrauliche Projekt-, Budget- und Sicherheitsinformationen verbleiben geschützt.
¶ 40. Qualitätsgate vor Freigabe
- Ist das Risiko aktuell bewertet und einem relevanten Dienst zugeordnet?
- Ist die Behandlungsoption mit Alternativen und Grenzen begründet?
- Sind Sollzustand, Wirkung, Scope und Abschlusskriterien messbar?
- Sind Owner, Sponsor, Prüfer und Stellvertretung benannt?
- Sind Budget, Kompetenz, Kapazität und Betriebsaufwand realistisch?
- Sind Abhängigkeiten, Nebenwirkungen und neue Risiken bewertet?
- Sind Zwischenmaßnahmen und Eskalation bei Verzögerung festgelegt?
- Sind Test, Abnahme, Nachweis und Wirksamkeit getrennt geplant?
- Sind Restrisiko, Toleranz, Entscheider und Review vorgesehen?
- Sind sensible Inhalte und Originalnachweise angemessen geschützt?
Erst nach bestandenem Qualitätsgate erhält die Maßnahme den vorgesehenen Freigabestatus.
¶ 41. Häufige Fehler und Gegenmaßnahmen
| Fehler | Folge | Gegenmaßnahme |
|---|---|---|
| Maßnahme ohne Risiko- und Dienstebezug | Wirkung nicht bewertbar | durchgängige Referenzkette verlangen |
| „Tool einführen“ als Sollzustand | kein prüfbares Ergebnis | Scope, Wirkmechanismus und Zielkriterium definieren |
| unrealistischer Termin ohne Ressourcen | Scheinsicherheit | Kapazität, Beschaffung und kritischen Pfad planen |
| technische Fertigstellung = wirksam | Restrisiko unterschätzt | Abnahme und Wirksamkeitsprüfung trennen |
| Frist wird kommentarlos verschoben | Eskalation wird verborgen | Änderung, Risikowirkung und Entscheidung dokumentieren |
| Zwischenmaßnahme ohne Ablauf | Dauerprovisorium | Gültigkeit, Monitoring und Eskalationsauslöser festlegen |
| Risiko wird automatisch auf Zielwert gesetzt | unbelegte Bewertung | Restrisiko mit aktuellen Prüfergebnissen neu bewerten |
| sensible Projektdetails im Wiki | Offenlegung von Schwachstellen/Budget | nur Metadaten und geschützte Referenzen veröffentlichen |
¶ 42. Offene Entscheidungen vor produktiver Nutzung
- Prioritäts-, Toleranz- und Eskalationsschwellen genehmigen,
- Maßnahmen-ID, Pflichtfelder, Statusmodell und Wertelisten festlegen,
- Freigabe- und Entscheidungsmatrix mit Vollmachten abstimmen,
- Budget-, Kapazitäts- und Portfolioverfahren verbinden,
- Regeln für Zwischenmaßnahmen und Risikoakzeptanzen beschließen,
- Wirksamkeitsmethoden und unabhängige Prüferrollen bestimmen,
- Register-, Change-, Projekt- und Nachweisschnittstellen einrichten,
- Berichtstakt und Kennzahlen durch die Geschäftsleitung festlegen,
- Pilotmaßnahmen verschiedener Prioritäten vollständig durchspielen.
Bis zur Entscheidung bleiben sämtliche Beispielstatus ausdrücklich Entwurf.
¶ 43. Verknüpfte Seiten
- NIS2-Risikoregister
- NIS2-Risikomethodik
- NIS2-Nachweisregister
- Maßnahmenkatalog nach BSIG
- Wirksamkeitsprüfung
- Ressourcen und Berichtswesen
- Ausnahmen und Risikoakzeptanzen
- ISMS Maßnahmen- und Umsetzungsregister
¶ 44. Offizielle Grundlagen
- § 30 BSIG – Risikomanagementmaßnahmen besonders wichtiger und wichtiger Einrichtungen
- § 31 BSIG – besondere Anforderungen für Betreiber kritischer Anlagen
- § 38 BSIG – Umsetzungs- und Überwachungspflicht der Geschäftsleitung
- EUR-Lex – Richtlinie (EU) 2022/2555, insbesondere Artikel 20 und 21
- BSI – Informationen für NIS2-regulierte Unternehmen
Anwendbarkeit, Rechtslage, behördliche Festlegungen und sektorspezifische Anforderungen werden vor einer realen Umsetzung aktuell geprüft. Die Links öffnen in einem neuen Tab.
¶ 45. Weiterführende Unterstützung durch SMCT MANAGEMENT
Unterstützung bei priorisierten NIS2-Maßnahmenportfolios, Verantwortlichkeiten, Nachweisen, Wirksamkeitsprüfungen und Restrisikoentscheidungen.
Informationen zur NIS2-Beratung öffnen
¶ 46. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Portfoliocockpit, Rechtsrahmen, Referenzkette, Priorität, Status- und Terminampeln, Ressourcen, Budget, Abhängigkeiten, Zwischenmaßnahmen, sichere Umsetzung, Wirksamkeit, Restrisiko, RACI, Kennzahlen und Qualitätsgate umfassend ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Auswahl, Maßnahmensteckbrief, Priorisierung, sichere Umsetzung, Wirksamkeitsprüfung, Restrisiko und Eskalation vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Musterverfahren und Mindestfelder für die NIS2-Risikobehandlung erstellt | Ausstehend |