¶ NIS2-Risikoregister
Leeres Musterregister: Auf dieser öffentlichen Seite sind keine realen Risiken, Systeme, Schwachstellen, Bewertungen oder Maßnahmen erfasst. Reale Detailbewertungen werden in einer geschützten führenden Ablage verwaltet. Das Wiki beschreibt Struktur, Statuslogik und kontrollierte Referenzen.
Keine Statusbehauptung: Farbige Ampeln und Musterzeilen dienen ausschließlich der Veranschaulichung. Sie zeigen weder die Risikolage noch den Umsetzungsstand eines Unternehmens.
Das Risikoregister ist die zentrale Steuerungsansicht für identifizierte NIS2-Cyberrisiken. Es verbindet relevante Dienste, Risikoszenarien, Bewertungen, Kontrollen, Behandlungen, Entscheidungen und Reviews. Die Risikomethodik bestimmt wie bewertet wird; das Register dokumentiert was wann von wem bewertet, entschieden und nachverfolgt wurde.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-REG-02-02 |
| Dokumentenart | Führungs- und Registerstruktur für NIS2-Cyberrisiken |
| Wiki.js-Pfad | /NIS2/02-Risikomanagement-und-Nachweise/NIS2-Risikoregister |
| Prozesseigner | Geschäftsleitung / NIS2-Risikokoordination |
| Fachverantwortung | Risk Owner je Risikoeintrag |
| Status | Entwurf – keine realen Risiken erfasst, bewertet oder freigegeben |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Intern; Detailregister und technische Risikoinhalte regelmäßig vertraulich oder höher |
| Rechtsbezug | § 30 BSIG; ergänzend § 38 BSIG und Artikel 21 NIS2-Richtlinie |
| Regelprüfung | Gesamtregister mindestens quartalsweise; Einzelrisiken nach Kritikalität und Ereignis |
Risiken mit Diensten, Maßnahmen, Entscheidungen und Nachweisen eindeutig verbinden. Eigene redaktionelle SVG-Grafik; zum Vergrößern öffnen.
¶ 1. Register-Cockpit ohne Echtdaten
Die folgenden Karten zeigen das vorgesehene Layout. Der Gedankenstrich bedeutet: Auf dieser Musterseite liegen keine Echtdaten vor.
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
Ein reales Cockpit nennt zusätzlich Stichtag, Scope, Datenquelle und Aussagegrenze. Leere oder unbekannte Werte werden nicht als Null interpretiert.
¶ 2. Zweck und Arbeitsergebnisse
Das Register soll sicherstellen, dass
- jedes Risiko eine eindeutige Identität und einen Risk Owner besitzt,
- Dienst-, Prozess-, Asset-, Standort- und Anbieterbezüge nachvollziehbar sind,
- Szenario, Annahmen, Quellen und Datenqualität erkennbar bleiben,
- Brutto- und Restrisiko nach der freigegebenen Methodik geführt werden,
- Kontrollen, Maßnahmen und Nachweise über stabile IDs verknüpft sind,
- Akzeptanzen, Eskalationen und Freigaben nachvollziehbar dokumentiert werden,
- Fälligkeiten, Änderungen und Reviews aktiv überwacht werden,
- Dubletten, Kaskaden und Konzentrationsrisiken sichtbar werden,
- Managementberichte keine Scheingenauigkeit erzeugen.
Arbeitsergebnisse sind ein geschütztes führendes Register, definierte Workflows, aktuelle Bewertungen, verfolgte Maßnahmen, dokumentierte Entscheidungen, vollständige Historien und stichtagsbezogene Berichte.
¶ 3. Abgrenzung zu verbundenen Arbeitsmitteln
| Arbeitsmittel | Führende Aufgabe | Was nicht doppelt gepflegt wird |
|---|---|---|
| NIS2-Risikomethodik | Skalen, Ampel, Datenqualität, Toleranz und Bewertungsregeln | einzelne Risikodatensätze |
| NIS2-Risikoregister | Szenario, Bewertung, Owner, Entscheidung und Lebenszyklus | detaillierter Projektplan jeder Maßnahme |
| Risikobehandlungsplan | Arbeitspakete, Ressourcen, Termine und Fortschritt | vollständige Risikobeschreibung |
| Maßnahmenkatalog | gesetzliche Anforderungen und interne Kontrollen | individuelle Risikobewertung |
| Nachweisregister | Nachweismetadaten und geschützte Originalreferenzen | technische Rohdaten im Risikoregister |
| ISMS-Risikoregister | organisationsweites führendes Informationssicherheitsrisiko | NIS2-Doppelkopie ohne Zusatznutzen |
Eine Organisation kann ein gemeinsames führendes Risikoregister verwenden. Dann müssen NIS2-Dienstbezug, Rechtsreferenz, Ampellogik, Entscheidungsstatus und Filter eindeutig abbildbar sein.
¶ 4. Eindeutige Risiko-ID und Versionierung
Ein mögliches Schema lautet:
NIS2-R-[Jahr]-[laufende Nummer]
Beispiel: NIS2-R-2026-001. Die Nummer sagt nichts über Risikohöhe oder Priorität aus. Ein Datensatz erhält zusätzlich eine Version oder unveränderbare Änderungshistorie.
Bei Nutzung eines gemeinsamen ISMS-Registers wird die bestehende Risiko-ID beibehalten und um NIS2-Merkmale ergänzt. Eine neue NIS2-ID wird nur angelegt, wenn ein fachlich eigenständiges Szenario oder eine kontrollierte Referenz erforderlich ist. Verweise müssen in beide Richtungen prüfbar sein.
¶ 5. Pflichtfelder des Risikoregisters
| Feldgruppe | Mindestinhalt |
|---|---|
| Identität | Risiko-ID, Kurztitel, Version, Datensatzstatus, Erfassungs- und Änderungsdatum |
| Scope | Einrichtung, relevanter Dienst, Prozess, Asset, System, Standort und Anbieter |
| Szenario | Ursache/Bedrohung, Schwachstelle/Abhängigkeit, Ereignis und Wirkung |
| Quellen | Register, Vorfall, Audit, Bedrohungsinformation, Prüfer und Stichtag |
| Bruttobewertung | Eintritt, Auswirkung, Score, Ampel und Begründung |
| Datenqualität | belastbar, teilweise belegt oder hohe Unsicherheit mit Begründung |
| Kontrollen | Kontroll-ID, Scope, Umsetzung, Prüfung und Wirksamkeitsstatus |
| Restrisiko | Eintritt, Auswirkung, Score, Ampel und verbleibende Wirkung |
| Behandlung | Option, Maßnahmenreferenz, Zwischenkontrolle, Owner und Termin |
| Entscheidung | Akzeptanz, Eskalation, Freigabeinstanz, Bedingungen und Gültigkeit |
| Lebenszyklus | letzter Review, Ergebnis, nächster Review, Auslöser und Abschlussgrund |
| Beziehungen | Vorfälle, Nachweise, Anforderungen, Risiken, Kaskaden und Risikofamilien |
Pflichtfelder werden technisch validiert, soweit das Werkzeug dies unterstützt. Eine vollständig ausgefüllte Maske ist dennoch kein Beweis für fachliche Qualität.
¶ 6. Farbige Risikoampel
Die Risikofarbe wird aus der freigegebenen NIS2-Risikomethodik übernommen. Das Register berechnet keine abweichenden Schwellen.
überwachen und planmäßig prüfen
Behandlung oder Akzeptanz prüfen
priorisiert behandeln und informieren
unverzüglich eskalieren
Farbe wird stets mit Symbol, Buchstabe, Text und Score gespeichert. Ein grünes Risiko bestätigt weder Gesetzeserfüllung noch vollständige Kontrollwirksamkeit.
¶ 7. Datenqualitätskennzeichnung
| Kennzeichnung | Bedeutung | Registerfolge |
|---|---|---|
| ✓ GRÜN · belastbar | bestätigter Scope, aktuelle Quellen und nachvollziehbare Begründung | regulärer Review |
| ! GELB · teilweise belegt | Annahmen oder einzelne Datenlücken | Analysemaßnahme und Termin |
| × ROT · hohe Unsicherheit | Scope, Quellen oder Wirkung unzureichend | Entscheidung unter Vorbehalt, Eskalation und kurzfristige Datenerhebung |
Risikoampel und Datenqualität werden nicht vermischt. Ein niedrig bewertetes Risiko mit roter Datenqualität bleibt sichtbar und kann konservativ behandelt werden.
¶ 8. Workflowstatus des Datensatzes
| Status | Darstellung | Bedeutung | Zulässiger Folgeschritt |
|---|---|---|---|
| Erfasst | ○ ERFASST | Mindestinformationen vorhanden, Bewertung offen | Analyse zuweisen |
| In Bewertung | ◆ BEWERTUNG | Fakten, Scope und Kriterien werden geprüft | fachliche Prüfung |
| Zur Entscheidung | ◇ ENTSCHEIDUNG | Behandlung oder Akzeptanz liegt vor | befugte Freigabe |
| In Behandlung | ▲ BEHANDLUNG | freigegebene Maßnahmen laufen | Wirksamkeitsprüfung |
| Überwacht | ● ÜBERWACHT | Restrisiko genehmigt oder innerhalb Toleranz | planmäßiger Review |
| Geschlossen | ■ GESCHLOSSEN | Szenario nachweisbar entfallen oder Scope beendet | archivieren |
„Geschlossen“ wird nicht allein vergeben, weil eine Aktivität abgeschlossen ist. Das Szenario muss entfallen oder ein geregelter Übergang in einen anderen Datensatz nachgewiesen sein.
¶ 9. Fälligkeitsampel
Die Fälligkeit wird getrennt vom Risikostatus dargestellt.
| Fälligkeit | Darstellung | Musterregel |
|---|---|---|
| im Plan | ✓ IM PLAN | Termin liegt außerhalb der Vorwarnzeit |
| bald fällig | ! BALD FÄLLIG | Vorwarnzeit erreicht; Owner informieren |
| überfällig | × ÜBERFÄLLIG | Termin überschritten; Eskalation nach Risikostufe |
| ausgesetzt | Ⅱ AUSGESETZT | nur mit dokumentiertem Grund, Entscheidung und neuem Termin |
Eine Verschiebung überschreibt den ursprünglichen Termin nicht. Historie, Begründung und Genehmigung bleiben erhalten.
¶ 10. Szenariobeschreibung im Register
Das Szenario folgt der freigegebenen Methodik:
Wenn
[Ursache/Bedrohung]auf[Schwachstelle/Abhängigkeit]trifft, kann[Ereignis]eintreten. Dadurch kann[relevanter Dienst]für[Dauer/Umfang]beeinträchtigt werden und[Wirkung]entstehen.
Das Register speichert zusätzlich:
- betroffene und abhängige Dienste,
- wichtigste Assets, Standorte und Anbieter,
- Wirkungsdimensionen,
- bestehende Warnindikatoren,
- Quellen und Annahmen,
- verwandte Vorfälle und Risiken.
Zu allgemeine Titel wie „Cyberangriff“ oder „Ausfall“ reichen nicht aus. Zu detaillierte Angriffspfade und Schwachstellen bleiben in geschützten Anlagen.
¶ 11. Brutto- und Restrisiko
Das Bruttorisiko dokumentiert die Ausgangsexposition. Das Restrisiko wird nach Prüfung der tatsächlich umgesetzten und wirksamen Kontrollen neu begründet.
| Prüffeld | Bruttorisiko | Restrisiko |
|---|---|---|
| Betrachtung | ohne Anrechnung risikomindernder Kontrollen | nach belegter Kontrollwirkung |
| Eintritt | Ausgangslage und Exposition | verbleibende Wahrscheinlichkeit |
| Auswirkung | plausibel schwerste Wirkung | verbleibende Wirkung und Kaskaden |
| Datenqualität | Qualität der Ausgangsinformationen | Qualität der Kontroll- und Ergebnisnachweise |
| Entscheidung | Bedeutung und Behandlungsbedarf | Toleranz, Akzeptanz oder weitere Behandlung |
Geplante Maßnahmen und ungeprüfte Kontrollen werden nicht vorzeitig als Risikominderung verbucht.
¶ 12. Kontrollen und Nachweise verknüpfen
Der Risikodatensatz enthält keine losen Dokumenttitel, sondern stabile Referenzen:
- Kontroll-ID aus dem Maßnahmenkatalog,
- Control Owner und betroffener Scope,
- Umsetzungsstatus,
- letzter Wirksamkeitstest und Ergebnis,
- Nachweis-ID aus dem Nachweisregister,
- offene Abweichung oder Ausnahme,
- nächster Prüftermin.
Ein Nachweis kann mehrere Risiken unterstützen, wenn seine Aussage und sein Scope passen. Ein Zertifikat, Screenshot oder Prüfbericht wird nicht pauschal als Beleg für alle Risiken verwendet.
¶ 13. Behandlung und Maßnahmenreferenz
Das Risikoregister speichert die Behandlungsentscheidung und verweist auf den führenden Risikobehandlungsplan.
Mindestangaben sind:
- Behandlungsoption: vermeiden, vermindern, übertragen/teilen oder akzeptieren,
- Zielzustand und erwartete Risikowirkung,
- Maßnahmen-ID und Maßnahmen-Owner,
- Zieltermin und Meilenstein,
- kompensierende Zwischenkontrolle,
- Ressourcen- oder Budgetentscheidung,
- erwarteter Wirksamkeitsnachweis,
- Termin der Restrisikoneubewertung.
Fortschritt und Risikoampel werden getrennt geführt. Eine zu 80 Prozent erledigte Maßnahme senkt das Risiko nicht automatisch um 80 Prozent.
¶ 14. Risikoakzeptanz
Eine befristete Akzeptanz enthält:
- Risiko-ID und aktuelles Restrisiko,
- Datenqualität und offene Annahmen,
- gesetzliche und vertragliche Bezüge,
- geprüfte Alternativen,
- Begründung und Bedingungen,
- kompensierende Kontrollen,
- befugte Entscheidungsperson,
- Entscheidung und Zeitstempel,
- Ablaufdatum und Review-Auslöser.
Eine interne Risikoakzeptanz hebt keine gesetzliche Verpflichtung auf. Abgelaufene Akzeptanzen werden nicht stillschweigend verlängert, sondern erneut bewertet und entschieden.
¶ 15. Rollen und RACI-Grundmodell
| Aktivität | Risk Owner | NIS2-Koordination | Dienst-/Asset-Owner | Maßnahmen-Owner | Geschäftsleitung/Akzeptanzinstanz |
|---|---|---|---|---|---|
| Szenario anlegen | A | R | C | I | I |
| Fakten und Scope bestätigen | A | C | R | I | I |
| Bewertung moderieren | A | R | C | I | I |
| Behandlung planen | A | C | C | R | I/C |
| hohes Restrisiko akzeptieren | C | C | I | I | A/R |
| Maßnahme umsetzen | I | C | C | A/R | I |
| Wirksamkeit prüfen | A | C/R | C | C | I |
| Review abschließen | A | R | C | C | I/C |
R = ausführend, A = rechenschaftspflichtig/entscheidend, C = konsultiert, I = informiert. Das Muster wird an Rechtsform, Governance und Kompetenzordnung angepasst.
¶ 16. Berechtigungs- und Schutzkonzept
Reale Risikoregister können Angriffswege, Schwachstellen, Lieferantenprobleme, Geschäftsgeheimnisse und personenbezogene Angaben enthalten. Deshalb werden mindestens geregelt:
- Rollen mit Lese-, Schreib-, Prüf- und Freigaberechten,
- Funktionstrennung für Bewertung und Akzeptanz,
- Zugriff auf besonders sensible Anlagen,
- Protokollierung von Änderungen und Exporten,
- sichere Übertragung und geschützte Sicherungen,
- Behandlung externer Prüfer und Berater,
- Aufbewahrung, Archivierung, Löschung und Legal Hold,
- regelmäßige Berechtigungsreviews.
Die öffentliche Wiki-Seite enthält keine reale Registerdatei und keinen direkten Link auf vertrauliche Originale.
¶ 17. Workflow eines Risikoeintrags
- Erfassen: Mindestdaten, vorläufigen Owner und Dienstbezug anlegen.
- Vervollständigen: Scope, Szenario, Quellen und Abhängigkeiten bestätigen.
- Bewerten: Brutto-Risiko und Datenqualität nach Methodik bestimmen.
- Kontrollen prüfen: Umsetzung, Scope und Wirksamkeit belegen.
- Restrisiko bestimmen: verbleibende Eintritts- und Wirkungsstufe begründen.
- Behandlung vorbereiten: Option, Maßnahme, Ressourcen und Zwischenkontrolle festlegen.
- Entscheiden: befugte Stelle genehmigt Behandlung oder befristete Akzeptanz.
- Nachverfolgen: Maßnahmen, Termine, Indikatoren und Änderungen überwachen.
- Wirksamkeit prüfen: Ergebnis testen und Restrisiko neu bewerten.
- Überwachen oder schließen: Review aktiv halten oder Wegfall nachweisen.
Jeder Statuswechsel enthält Datum, Rolle, Begründung und gegebenenfalls Freigabe. Rücksprünge, etwa von „Überwacht“ zu „In Bewertung“, bleiben historisch sichtbar.
¶ 18. Dublettenmanagement
Vor Neuanlage wird nach ähnlichen Szenarien, Diensten, Assets, Anbietern und Ursachen gesucht. Eine mögliche Dublette wird nicht vorschnell gelöscht. Geprüft werden:
- identische oder unterschiedliche Ursache,
- gleiche oder verschiedene Dienstwirkung,
- gleiche oder unterschiedliche Owner,
- abweichende Kontrollen und Behandlung,
- verschiedene Standorte oder Anbieter,
- notwendige rechtliche Zusatzbewertung.
Zusammenführungen dokumentieren führende Risiko-ID, übernommene Beziehungen, Historie und Entscheidungsgrund. Eine geschlossene Dublette verweist auf den verbleibenden Datensatz.
¶ 19. Kaskaden und Risikobeziehungen
Beziehungen werden typisiert, zum Beispiel:
- verursacht,
- verstärkt,
- ist Folge von,
- teilt gemeinsame Ursache,
- teilt Kontrolle,
- teilt Anbieter oder Standort,
- ersetzt oder fasst zusammen.
Beispiel: Der Ausfall eines zentralen Identitätsdienstes kann mehrere Portale, Fernzugänge und administrative Funktionen beeinträchtigen. Das Primärrisiko und die dienstbezogenen Folgen bleiben unterscheidbar.
¶ 20. Konzentrationsrisiken und Risikofamilien
Risikofamilien bündeln gemeinsame Ursachen oder Themen, ohne Einzelrisiken zu verlieren. Sinnvolle Auswertungen sind:
- Abhängigkeit von einem Cloud- oder Telekommunikationsanbieter,
- gemeinsame privilegierte Identitäten,
- zentrale Standorte oder Netzübergänge,
- End-of-Life-Komponenten,
- Wissens- und Personalkonzentration,
- gleichartige Lieferanten- oder Softwareabhängigkeiten,
- gemeinsame Backup- oder Notfallressourcen.
Mehrere mittlere Risiken können zusammen eine hohe Konzentration ergeben. Diese Bewertung wird zusätzlich dokumentiert und nicht durch einfache Addition von Scores erzeugt.
¶ 21. Änderungs- und Ereignisprotokoll
Das Register zeichnet mindestens auf:
- Zeitpunkt und ausführende Rolle,
- geändertes Feld mit altem und neuem Wert,
- Grund und Quelle der Änderung,
- Änderung der Risiko- oder Datenqualitätsampel,
- neue oder entfernte Beziehungen,
- Freigabe, Ablehnung oder Rückfrage,
- Terminverschiebungen,
- Ergebnis von Review und Wirksamkeitsprüfung.
Änderungsprotokolle sind gegen unbefugte Manipulation zu schützen. Massenänderungen, Importe und Schnittstellenläufe werden gesondert protokolliert.
¶ 22. Reviewarten
| Reviewart | Auslöser | Mindestprüfung |
|---|---|---|
| planmäßig | festgelegter Termin | Szenario, Bewertung, Kontrollen, Maßnahmen, Entscheidung und nächster Termin |
| anlassbezogen | Dienst-, System-, Standort- oder Anbieteränderung | Auswirkungen der Änderung und neue Abhängigkeiten |
| vorfallbezogen | Sicherheitsvorfall oder Beinahevorfall | Annahmen, Eintritt, Wirkung und Kontrollversagen |
| bedrohungsbezogen | neue Schwachstelle oder aktive Bedrohung | Exposition, Zwischenmaßnahme und Dringlichkeit |
| maßnahmenbezogen | Umsetzung oder Wirksamkeitstest | belegte Wirkung und Restrisikoneubewertung |
| rechtlich | neue oder geänderte Vorgabe | Scope, Pflichtbezug und erforderliche Anpassungen |
Reviews erhalten Prüfer, Datum, Ergebnis, Abweichungen und nächste Fälligkeit. Eine reine Datumsverlängerung ist kein Review.
¶ 23. Eskalationsregeln
Eine sofortige oder beschleunigte Eskalation wird beispielsweise ausgelöst durch:
- kritisches Restrisiko,
- hohes Risiko außerhalb der genehmigten Toleranz,
- mögliche erhebliche Dienstwirkung oder Meldepflicht,
- rote Datenqualität bei möglicher schwerer Wirkung,
- fehlenden Risk Owner,
- nicht verfügbare Zwischenmaßnahme,
- überfällige Behandlung eines hohen oder kritischen Risikos,
- wiederholt unwirksame Kontrollen,
- auslaufende Akzeptanz ohne Entscheidung,
- erhebliche Konzentrations- oder Kaskadeneffekte.
Eskalationsweg, Reaktionszeit, Empfänger, erforderliche Unterlagen und Vertretung werden organisationsbezogen freigegeben.
¶ 24. Managementbericht
Der Bericht enthält nicht nur Anzahl und Farbe. Er zeigt mindestens:
- höchste Restrisiken nach relevantem Dienst,
- Änderungen seit dem letzten Stichtag,
- neue, eskalierte und geschlossene Risiken,
- Risiken außerhalb Toleranz,
- rote und gelbe Datenqualität,
- überfällige Reviews, Maßnahmen und Akzeptanzen,
- unwirksame oder ungeprüfte Kontrollen,
- Konzentrations- und Kaskadenrisiken,
- Ressourcen- und Entscheidungsbedarf,
- Aussagegrenzen und fehlende Daten.
Die Geschäftsleitung erhält so eine entscheidungsorientierte Sicht, ohne vertrauliche technische Details in den Bericht zu übernehmen.
¶ 25. Filter und Auswertungsansichten
Sinnvolle Filter sind:
- relevanter Dienst und Dienst-Owner,
- Risiko- und Datenqualitätsampel,
- Workflow- und Fälligkeitsstatus,
- Risk Owner und Maßnahmen-Owner,
- §-30-Mindestbereich,
- Standort, Anbieter oder Assetgruppe,
- offene Akzeptanz oder auslaufende Freigabe,
- ungeprüfte oder unwirksame Kontrolle,
- Vorfall-, Audit- oder Lieferantenbezug,
- letzter und nächster Review.
Gespeicherte Ansichten erhalten Zweck, Owner und Filterdefinition. Ein Export nennt Stichtag, Scope und Schutzklasse.
¶ 26. Kennzahlen und Aussagegrenzen
| Kennzahl | Aussage | Grenze |
|---|---|---|
| Risiken oberhalb Toleranz | Entscheidungs- und Behandlungsbedarf | sagt nichts über Vollständigkeit des Registers |
| überfällige Reviews | mögliche Veraltung des Lagebilds | nicht jedes überfällige Risiko ist hoch |
| Risiken ohne Owner oder Dienstbezug | strukturelle Datenlücken | misst Datenqualität, nicht Risikohöhe |
| Maßnahmenverzug bei hohen Risiken | Ressourcen- und Eskalationsbedarf | Fortschritt ist keine Wirksamkeit |
| Anteil wirksam geprüfter Kontrollen | Prüfabdeckung mit positivem Ergebnis | abhängig von Scope und Testqualität |
| Risiken mit roter Datenqualität | Entscheidungsunsicherheit | rote Datenqualität ist nicht automatisch rotes Risiko |
| abgelaufene Akzeptanzen | fehlende aktuelle Entscheidung | Akzeptanzablauf ändert nicht automatisch den Score |
Kennzahlen werden mit Trend, Stichtag, Scope und Datenquelle berichtet.
¶ 27. Musteransicht mit ausschließlich fiktiven Einträgen
Keine Echtdaten: Die folgenden Zeilen demonstrieren Felder und Farben. „Demo-Dienst A/B/C“ bezeichnet keine reale Organisation, Technik oder Schwachstelle.
| Risiko-ID | Dienst/Szenario | Restrisiko | Datenqualität | Workflow | Fälligkeit | Entscheidung |
|---|---|---|---|---|---|---|
| DEMO-R-001 | Demo-Dienst A – generisches Verfügbarkeitsszenario | ■ K · Muster | ! GELB | ◇ ENTSCHEIDUNG | × ÜBERFÄLLIG | nur Demonstration |
| DEMO-R-002 | Demo-Dienst B – generisches Lieferkettenszenario | ▲ H · Muster | ✓ GRÜN | ▲ BEHANDLUNG | ! BALD FÄLLIG | nur Demonstration |
| DEMO-R-003 | Demo-Dienst C – generisches Zugriffsszenario | ● N · Muster | × ROT | ◆ BEWERTUNG | ✓ IM PLAN | nur Demonstration |
Die dritte Musterzeile verdeutlicht: Eine grüne Risikoampel mit roter Datenqualität ist kein belastbarer Abschluss.
¶ 28. Import, Export und Schnittstellen
Bei Tabellenimporten oder Schnittstellen werden geprüft:
- eindeutige IDs und zulässige Werte,
- Datums-, Zahlen- und Ampelformate,
- referenzierte Dienste, Assets und Owner,
- Dubletten und verwaiste Beziehungen,
- Schutzklasse und Berechtigung,
- Herkunft, Zeitpunkt und Vollständigkeit,
- Fehlerprotokoll und Freigabe des Imports.
Exporte werden nach Zweck, Empfängerkreis und Mindestumfang begrenzt. Vertrauliche Details werden nicht ungeprüft in Präsentationen oder E-Mails übertragen.
¶ 29. Archivierung und Schließung
Ein Risiko kann geschlossen werden, wenn
- der relevante Dienst oder Scope nachweisbar entfallen ist,
- das Szenario dauerhaft nicht mehr plausibel ist,
- es kontrolliert in einen anderen führenden Datensatz überführt wurde,
- die Abschlussentscheidung und Beziehungen dokumentiert sind.
Risikoreduktion auf Grün allein ist kein Schließungsgrund; solche Risiken werden gewöhnlich überwacht. Archivierte Einträge bleiben entsprechend Rechts-, Vertrags- und Nachweisanforderungen nachvollziehbar.
¶ 30. Regelmäßige Datenqualitätsprüfung
Die Risikokoordination prüft stichprobenartig und regelbasiert:
- Pflichtfelder und zulässige Statuswerte,
- Risiken ohne Owner, Dienst oder Reviewtermin,
- widersprüchliche Ampel und Behandlung,
- geplante Maßnahmen, die bereits das Restrisiko senken,
- abgelaufene Nachweise oder Akzeptanzen,
- ungültige oder verwaiste Referenzen,
- Dubletten und nicht aufgelöste Kaskaden,
- geschlossene Risiken ohne Abschlussbegründung,
- fehlende Änderungsprotokolle.
Fehler werden mit Owner, Priorität und Korrekturfrist nachverfolgt. Der Datenqualitätsbericht wird nicht mit dem Cyberrisikobericht verwechselt.
¶ 31. Qualitätscheck vor Freigabe eines Eintrags
- Ist der relevante Dienst bestätigt?
- Ist das Szenario verständlich und bewertbar formuliert?
- Sind Scope, Quellen und Annahmen dokumentiert?
- Entsprechen Eintritt, Auswirkung und Ampel der freigegebenen Methodik?
- Ist die Datenqualität separat bewertet?
- Sind Kontrollen mit Scope, Status und Wirksamkeitsnachweis verknüpft?
- Sind Brutto- und Restrisiko getrennt und begründet?
- Passen Behandlung, Owner, Termin und Zwischenkontrolle zusammen?
- Ist die Entscheidungsinstanz befugt und die Gültigkeit befristet?
- Sind Kaskaden, Dubletten und Konzentrationen geprüft?
- Sind nächster Review und Änderungsereignisse festgelegt?
- Sind vertrauliche Details angemessen geschützt?
¶ 32. Häufige Fehler und Gegenmaßnahmen
| Fehler | Folge | Gegenmaßnahme |
|---|---|---|
| Risikoregister wird nur als Maßnahmenliste genutzt | Szenario und Restrisiko gehen verloren | Risiko- und Maßnahmenobjekte getrennt verknüpfen |
| geplante Kontrolle reduziert sofort den Score | Lagebild wird zu positiv | Wirkung erst nach Umsetzung und Prüfung berücksichtigen |
| Farbe ohne Datenqualität | unsichere Bewertung erscheint belastbar | separate Datenqualitätsampel verwenden |
| geschlossene Maßnahme = geschlossenes Risiko | Restwirkung wird übersehen | Restrisiko neu bewerten und überwachen |
| Kopien zwischen ISMS und NIS2 | widersprüchliche Datenstände | führende ID und kontrollierte Referenzen |
| technischer Export ohne Schutzprüfung | Schwachstellen werden offengelegt | Empfänger, Zweck und Mindestdaten begrenzen |
| Gesamtzahl ohne Scope | Management wird fehlgeleitet | Stichtag, Scope und Aussagegrenzen nennen |
¶ 33. Offene Punkte vor organisationsbezogener Freigabe
- führendes Risikoregister und System festlegen,
- Risiko-ID-, Versions- und Historienmodell genehmigen,
- Pflichtfelder und Referenzregister bestätigen,
- Risiko-, Datenqualitäts-, Workflow- und Fälligkeitsstatus freigeben,
- Rollen, RACI und Akzeptanzkompetenzen bestimmen,
- Berechtigungs- und Schutzkonzept umsetzen,
- Eskalationszeiten und Reviewfrequenzen genehmigen,
- Import-, Export-, Archivierungs- und Löschregeln abstimmen,
- Managementberichte und Kennzahlen freigeben,
- fiktive Demonstrationsdaten vor produktiver Nutzung entfernen,
- Pilotregister mit repräsentativen Szenarien prüfen.
¶ 34. Verknüpfte Seiten im Wiki
- NIS2-Risikomethodik
- Risikobehandlungsplan
- Maßnahmenkatalog nach BSIG
- Wirksamkeitsprüfung
- Nachweisregister
- Geltungsbereich und relevante Dienste
- Kritikalität und Abhängigkeiten
- ISMS Risikoregister
¶ 35. Amtliche Grundlagen
Die externen Links öffnen in einem neuen Tab. Vor Verwendung sind Rechtsstand, Betroffenheit und organisationsbezogene Registerführung erneut zu prüfen.
- § 30 BSIG – Risikomanagementmaßnahmen besonders wichtiger und wichtiger Einrichtungen
- § 38 BSIG – Umsetzungs- und Überwachungspflicht der Geschäftsleitung
- EUR-Lex – Richtlinie (EU) 2022/2555, insbesondere Artikel 21
- EUR-Lex – Durchführungsverordnung (EU) 2024/2690 für bestimmte digitale Einrichtungsarten
¶ 36. Weiterführende Unterstützung durch SMCT-Management
SMCT-Management unterstützt bei Datenmodell, Risikoworkshops, Ampellogik, Registerbereinigung, Risikobehandlung, Nachweisführung und Managementberichten. Informationen zur NIS2-Beratung öffnen.
¶ 37. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Register-Cockpit, Systemabgrenzung, Pflichtfelder, farbige Risiko-, Datenqualitäts-, Workflow- und Fälligkeitsstatus, Brutto-/Restrisiko, Kontrollen, Behandlung, Akzeptanz, RACI, Schutz, Workflow, Dubletten, Kaskaden, Historie, Reviews, Eskalation, Managementbericht, Kennzahlen und fiktive Musteransicht umfassend ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Rollen, Registerbeziehungen, Workflow, Kaskaden, Berichtswesen, Datenqualität und Freigabekriterien fachlich vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Leere Musterstruktur für das NIS2-Risikoregister erstellt | Ausstehend |