NIS-2 verschiebt den Schwerpunkt der Informationssicherheit. Nicht nur Firewalls, Patches oder einzelne technische Maßnahmen stehen im Vordergrund, sondern der Umgang mit Risiken. Gesetzgeber und Aufsicht richten den Blick auf Strukturen, auf Verantwortlichkeiten und auf die Frage, wie Organisationen Risiken erkennen, bewerten und behandeln.
Der IT-Grundschutz des BSI bietet dafür seit Jahren einen Rahmen. Mit den Standards 200-1 ( Managementsysteme für Informationssicherheit) und 200-2 (IT-Grundschutz-Methodik) liegt eine Methodik für den Aufbau eines Informationssicherheitsmanagementsystems (ISMS) vor, inklusive Geltungsbereich, Strukturanalyse, Schutzbedarfsfeststellung und Modellierung mit Bausteinen des IT-Grundschutz-Kompendiums. An diese Stelle setzt BSI-Standard 200-3 an: Er beschreibt ein Verfahren zur Risikoanalyse auf dieser Grundlage und verknüpft damit NIS-2-Anforderungen mit gelebter Praxis in Organisationen.
Risikobehandlung nach BSI Standard 200-3
Ein Risikomanagement nach 200-3 steht nicht isoliert. Es baut auf einem ISMS auf, das grundlegende Aufgaben bereits erfüllt, und bildet zugleich einen integralen Bestandteil dieses Systems.
Der Informationsverbund liegt vor, der Geltungsbereich ist definiert. Geschäftsprozesse, Anwendungen, IT-Systeme und Infrastrukturen stehen in einer Strukturanalyse. Schutzbedarfe für Vertraulichkeit, Integrität und Verfügbarkeit sind zugeordnet. Bausteine aus dem IT-Grundschutz-Kompendium decken typische Gefährdungen und Maßnahmen ab, ein erster IT-Grundschutz-Check markiert Lücken.
An diesem Punkt reicht der Blick auf Standardmaßnahmen nicht mehr aus. NIS-2 verlangt Orientierung an konkreten Risiken, an Bedrohungsszenarien und an der Frage, welche Funktionen einer Organisation kritisch sind. BSI-Standard 200-3 greift diese Frage auf.
Gefährdungsübersicht und Risikobewertung
Im Zentrum der Methode stehen Zielobjekte: etwa ein Fachverfahren, ein Rechenzentrum, ein Cloud-Dienst oder ein geschäftskritischer Prozess.
Für jedes Zielobjekt entsteht eine Gefährdungsübersicht. Grundlage bildet der Katalog der 47 elementaren Gefährdungen aus dem IT-Grundschutz – etwa Abhören, Manipulation von Informationen, Feuer oder Personalausfall – ergänzt um spezifische Szenarien aus der eigenen Lage.
Ransomware, Lieferkettenangriffe oder Ausfälle von Dienstleistern fließen dort ein, ebenso klassische Themen wie physische Schäden oder Fehlbedienung.
Auf diese Übersicht folgt die Bewertung. Fachbereiche, IT und Informationssicherheitsbeauftragte diskutieren Eintrittshäufigkeit und mögliche Schadenshöhe. Qualitative Skalen strukturieren die Einschätzung. Am Ende steht eine Risikomatrix mit Kategorien wie gering, mittel, hoch oder sehr hoch.
Solch eine Matrix liefert keine mathematische Wahrheit, aber sie schafft ein gemeinsames Bild. Leitung, Fachbereich und Technik sprechen über dasselbe Risiko, mit derselben Einordnung und denselben Begriffen. Für NIS-2 entsteht damit ein wichtiger Baustein: Nachweis, dass Risiken nicht nur intuitiv wahrgenommen, sondern systematisch bewertet sind.
Risikobehandlung : Vermeidung, Reduktion, Transfer, Akzeptanz
Nach der Bewertung folgt die Behandlung. BSI-Standard 200-3 unterscheidet vier Richtungen.
Vermeidung steht für Entscheidungen, die eine Risikosituation vollständig aus dem Betrieb nehmen, etwa durch Abschaltung eines veralteten Systems oder Verzicht auf ein besonders riskantes Verfahren.
Reduktion zielt auf zusätzliche technische oder organisatorische Maßnahmen, etwa härtere Zugangskontrollen, Segmentierung, Monitoring oder klare Prozessvorgaben.
Transfer verlagert Anteile des Risikos auf Dritte, etwa im Rahmen von Dienstleistungsverträgen oder Versicherungen.
Am Ende bleibt stets ein Rest, der zur bewussten Akzeptanz führt oder als nicht akzeptabel gilt. Jede dieser Entscheidungen verlangt Dokumentation und Begründung, sonst bleibt sie angreifbar.
Die Gesamtheit dieser Entscheidungen fließt in ein konsolidiertes Sicherheitskonzept und in ein Risikoregister. Dort stehen Risiken, Maßnahmen, Verantwortliche und Fristen, verbunden mit einem Prozess zur regelmäßigen Überprüfung. Für NIS-2 ergibt sich damit ein belastbarer Nachweis: Risiken stehen unter Beobachtung, nicht nur auf einer Folie.
Governance und Einbettung in bestehende Strukturen
Risikomanagement nach BSI-Standard 200-3 bleibt ohne klare Governance unvollständig. Leitungen definieren Grundsätze zur Risikoanalyse, legen Risikoappetit und Akzeptanzkriterien fest und statten Rollen mit Mandat aus. Informationssicherheitsbeauftragte moderieren Analysen, bringen Methodenkenntnis ein und achten auf Konsistenz. Fachbereiche liefern Einschätzungen zu Auswirkungen, technische Teams bringen Wissen über Architekturen und Bedrohungen ein.
Regelmäßige Überprüfungen halten Ergebnisse aktuell. Neue Projekte, geänderte Lieferketten, Cloud-Migrationen oder organisatorische Umbrüche verändern die Risikolage. Ein statisches Register passt nicht mehr in eine NIS-2-geprägte Umgebung. Standards wie ISO 31000 und ISO 27005 liefern Begriffe und Strukturen, BSI-Standard 200-3 übersetzt diese in eine konkret nutzbare Vorgehensweise, abgestimmt auf den IT-Grundschutz.
Risikomanagement im Atlassian-Umfeld
In vielen Organisationen laufen Projekte, Serviceprozesse und Änderungen bereits in Werkzeugen aus dem Atlassian-Kosmos. Vorgänge in Jira bilden Incidents, Changes, oder die Meldung von Sicherheitsvorfällen ab. Confluence enthält Konzepte, Richtlinien und Protokolle. Assets strukturiert Systeme, Dienste, Standorte und andere Configuration Items.
Ein Risikomanagement nach BSI-Standard 200-3 fügt sich dort ein, nicht daneben. Risiken lassen sich als eigener Vorgangstyp in Jira abbilden. Jedes Risiko steht als Ticket mit klar beschriebenem Zielobjekt, Gefährdungslage, Einstufung und Risikomatrix. Verknüpfungen führen zu den betroffenen Objekten in Assets, zu Konzepten und Richtlinien in Confluence und zu Maßnahmen in Form von Changes oder Projekttickets.
Risiken erhalten Responsible Owner. Diese Personen tragen die Verantwortung für Brutto- und Nettorisiko, beschreiben die Ausgangslage, ordnen Maßnahmen zu und stimmen sich mit Fachbereich und ISB ab. Bruttorisiko beschreibt die Lage ohne zusätzliche Maßnahmen, Nettorisiko die Lage nach Umsetzung einer konkreten Richtlinie, eines Bausteins oder einer technischen Änderung.
Dashboards in Jira zeigen offene Risiken, hohe Nettorisiken, überfällige Überprüfungen oder noch nicht umgesetzte Maßnahmen. Assets bildet Abhängigkeiten ab: Ein Blick auf ein System reicht für die Einsicht, welche Risiken daran hängen und welche Vorgänge noch laufen. Confluence liefert die Erläuterung der Methode, die Dokumentation von Workshops und die formale Richtlinie zur Risikoanalyse.
So entsteht ein Risikoregister, das nicht nur Auditfragen beantwortet, sondern auch den Alltag der Teams widerspiegelt. NIS-2 spricht von Meldewegen, Verantwortlichkeiten und strukturierten Prozessen. Ein Ansatz auf Basis von BSI-Standard 200-3 und Atlassian-Werkzeugen bildet genau das ab.
Honicon als Begleiter zwischen Normen, Recht und Werkzeugen
An dieser Stelle setzt Honicon an. Wir kommen aus der Prozessberatung und bringen Erfahrung mit. Wir wissen wie sich Abläufe in Jira, Confluence und Assets sauber modellieren lassen. Zertifizierte Informationssicherheitsbeauftragte aus dem Team kennen BSI-Standard 200-3, IT-Grundschutz, ISO 27001 und die Anforderungen aus NIS-2.
In gemeinsamen Workshops entsteht zuerst die methodische Grundlage: Zielobjekte, Gefährdungen, Skalen, Risikomatrix, Governance. Anschließend folgt die Übersetzung in Projektstrukturen, Vorgangstypen, Workflows und Felder. Aus formalen Vorgaben entsteht ein greifbarer Prozess, der sich an den vorhandenen Arbeitsweisen orientiert.
Auf diese Weise entsteht für Organisationen ein Risikomanagement, das NIS-2 im Blick behält, BSI-Standard 200-3 ernst nimmt und zugleich in der vertrauten Umgebung von Jira, Confluence und Assets stattfindet.
