Praxisorientierte Einordnung zu NIS2 umsetzen: Der praxisnahe Fahrplan für betroffene Unternehmen: Anforderungen verstehen, Risiken priorisieren und eine belastbare Umsetzung für NIS2 aufbauen.
Die deutsche NIS2-Umsetzung ist seit dem 6. Dezember 2025 in Kraft. Für betroffene Unternehmen sind Registrierung, Risikomanagement, Vorfallmeldung und Verantwortung der Geschäftsleitung keine zukünftigen Projektziele mehr. Der praktikable Weg besteht trotzdem nicht in hektischer Dokumentenproduktion, sondern in einem belastbaren Betriebsmodell: Betroffenheit begründen, kritische Dienste verstehen, wirksame Maßnahmen priorisieren und Melde- sowie Nachweisfähigkeit im Alltag verankern.
Das neue BSI-Gesetz unterscheidet besonders wichtige und wichtige Einrichtungen sowie Betreiber kritischer Anlagen. Welche Kategorie gilt, hängt von Einrichtungsart, Größe und besonderen gesetzlichen Regeln ab. Diese Einordnung beeinflusst Aufsicht und teilweise Nachweispflichten, ändert aber nichts daran, dass angemessene und wirksame Sicherheitsmaßnahmen tatsächlich betrieben werden müssen.
Der Fahrplan beginnt mit einer belastbaren Betroffenheitsprüfung
Eine Betroffenheitsprüfung kombiniert juristische Einheit, angebotene Waren oder Dienstleistungen, Einrichtungsart nach den Anlagen des BSI-Gesetzes und Größenkriterien. Der Branchenname allein reicht nicht. Ein Industriekonzern kann beispielsweise zugleich Hersteller, Energieversorger und Anbieter eines digitalen Dienstes sein; einzelne Tätigkeiten können unterschiedlichen Regeln unterliegen.
Das Ergebnis wird als Entscheidungsvorlage dokumentiert: geprüfte Gesellschaften, relevante Tätigkeiten, Schwellenwerte, Datenquellen, Ausnahmen, Ergebnis und verantwortliche Freigabe. Umsatz, Bilanz und Beschäftigtenzahl müssen auf der gesetzlich maßgeblichen Ebene betrachtet werden. Beteiligungs- und Partnerunternehmen können die Größenberechnung beeinflussen und gehören in die rechtliche Prüfung.
Besonders wichtige und wichtige Einrichtungen unterscheiden
§ 28 BSIG ordnet unter anderem Betreiber kritischer Anlagen und bestimmte besondere Dienste den besonders wichtigen Einrichtungen zu. Weitere Einrichtungen aus Anlage 1 fallen bei den großen Größenmerkmalen in diese Kategorie. Wichtige Einrichtungen umfassen insbesondere bestimmte Einrichtungsarten aus den Anlagen 1 und 2, wenn die gesetzlichen Schwellen für mittlere Unternehmen erreicht sind.
Die Kategorie sollte nicht als interne Risikobewertung missverstanden werden. Sie ist eine gesetzliche Einordnung. Ein Unternehmen kann zugleich Geschäftsprozesse besitzen, die intern sehr kritisch oder weniger kritisch sind. Für die Umsetzung wird daher nach der Rechtskategorie zusätzlich ein risikobasierter Scope der konkreten Dienste, Systeme, Standorte und Lieferanten gebildet.
Sonderregeln und sektorspezifische Überschneidungen prüfen
Finanzunternehmen, Energieunternehmen, Telekommunikationsanbieter und andere regulierte Sektoren können besonderen Abgrenzungs- oder Vorrangregeln unterliegen. DORA, Energiewirtschaftsrecht oder Telekommunikationsrecht dürfen nicht pauschal als vollständige Ausnahme behandelt werden. Die konkrete Gesellschaft, Tätigkeit und Pflicht muss einzeln verglichen werden.
Eine Regelungsmatrix zeigt je Organisationsteil, welche Registrierung, Sicherheitsmaßnahmen, Meldungen und Aufsicht gelten. Dadurch werden Doppelmeldungen vermieden, ohne Lücken zu erzeugen. Bei widersprüchlichen Annahmen entscheiden Legal und zuständige Fachaufsicht frühzeitig, statt die Frage bis zum ersten Vorfall offen zu lassen.
Geschäftsleitung formell und praktisch einbinden
§ 38 BSIG verpflichtet Geschäftsleitungen besonders wichtiger und wichtiger Einrichtungen zur Umsetzung und Überwachung der Risikomanagementmaßnahmen. Zudem bestehen Schulungspflichten. Diese Verantwortung lässt sich nicht vollständig an CISO, IT-Leitung oder Dienstleister delegieren. Die Leitung benötigt ausreichende Informationen, um Prioritäten, Ressourcen und Restrisiken zu entscheiden.
Ein vierteljährliches Cyber-Risikoberichtswesen kann Systeme, wesentliche Szenarien, Maßnahmenstatus, Ausnahmen, Vorfälle und Lieferantenrisiken zusammenführen. Beschlüsse werden protokolliert. Schulungen sollten auf die konkrete Verantwortung eingehen: Welche Fragen muss die Leitung stellen, wann eskaliert sie und woran erkennt sie, ob Maßnahmen wirksam statt nur formal abgeschlossen sind?
Den Scope aus den erbrachten Diensten ableiten
Die Umsetzung darf nicht nur das Rechenzentrum oder die zentrale IT betrachten. Ausgangspunkt sind die von der betroffenen Einrichtung erbrachten Dienste und deren Abhängigkeiten. Für jeden wesentlichen Dienst werden Prozesse, Informationen, Anwendungen, Infrastruktur, Standorte, Personal und externe Anbieter zugeordnet.
Diese Dienstsicht verhindert zwei typische Fehler: einen zu engen technischen Scope und einen so breiten Scope, dass Prioritäten verschwimmen. Unterstützende Systeme werden einbezogen, wenn ihr Ausfall oder ihre Manipulation die Diensterbringung wesentlich beeinträchtigen kann. Die Begründung ist nachvollziehbar und wird bei organisatorischen Änderungen überprüft.
Risiken als konkrete Ausfalls- und Angriffsszenarien beschreiben
Allgemeine Begriffe wie Ransomware oder Lieferantenausfall sind zu grob. Ein Szenario beschreibt Auslöser, Eintrittspfad, betroffenen Dienst, vorhandene Kontrollen, mögliche Auswirkungen und Wiederherstellungsbedarf. Beispiel: Ein kompromittiertes Administratorkonto verschlüsselt zentrale Produktionsplanung und verhindert drei Tage die termingerechte Auslieferung.
Die Bewertung berücksichtigt Eintrittswahrscheinlichkeit, Schadenausmaß, Reichweite und vorhandene Beherrschbarkeit. Finanzielle Folgen werden mit Sicherheit, Versorgung, Kunden, Recht und Reputation kombiniert. Annahmen bleiben sichtbar. Das Management kann dadurch über konkrete Restexposition entscheiden, statt abstrakte Risikowerte abzunicken.
Die gesetzlichen Maßnahmenbereiche vollständig abdecken
§ 30 BSIG verlangt geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen. Die Themen umfassen unter anderem Risikoanalyse und Sicherheitskonzepte, Bewältigung von Vorfällen, Aufrechterhaltung und Krisenmanagement, Sicherheit der Lieferkette, sichere Beschaffung und Entwicklung, Bewertung der Wirksamkeit, Cyberhygiene und Schulungen, Kryptografie, Personalsicherheit, Zugriffskontrolle und Assetmanagement.
Ein Kontrollregister ordnet jeden Bereich konkreten Kontrollen, Verantwortlichen, Frequenzen und Nachweisen zu. Die bloße Existenz einer Richtlinie beweist keine Wirksamkeit. Für Zugriffskontrolle entstehen beispielsweise Rollenmodell, technische Konfiguration, regelmäßige Rezertifizierung, Stichprobe und Behandlung erkannter Abweichungen.
Mit einer risikobasierten Gap-Analyse starten
Die Gap-Analyse vergleicht gesetzliche Anforderungen und tatsächlichen Betrieb. Interviews und Dokumentensichtung werden durch technische Stichproben ergänzt. So zeigt sich, ob dokumentierte Backups wiederherstellbar, kritische Konten abgesichert und Lieferanten tatsächlich überwacht sind. Aussagen ohne Evidenz erhalten einen niedrigeren Reifegrad.
Feststellungen werden nach Risikowirkung priorisiert. Ein ungeübter Meldeprozess oder ungeschützte privilegierte Zugänge erfordern schnelleres Handeln als eine uneinheitliche Dokumentvorlage. Jede Lücke erhält Zielzustand, Maßnahme, Verantwortlichen, Termin, Abhängigkeiten und Abnahmekriterium. Wesentliche Unsicherheiten werden ausdrücklich als offene Prüfaufträge ausgewiesen.
Sofortmaßnahmen für die ersten dreißig Tage
Zu den frühen Maßnahmen gehören formale Betroffenheitsentscheidung, verantwortlicher Programmauftrag, Registrierungsvorbereitung, zentrale Erreichbarkeit für Vorfälle und Identifikation der wichtigsten Dienste. Parallel werden privilegierte Konten, exponierte Systeme, Backups und kritische Fernzugriffe überprüft. Offensichtliche Hochrisikolücken werden unmittelbar begrenzt.
Die Geschäftsleitung erhält eine erste Risikosicht und entscheidet über Ressourcen. Für den Fall eines erheblichen Sicherheitsvorfalls wird eine provisorische Meldekette mit Vertretung eingerichtet. Diese Schritte ersetzen keine vollständige Umsetzung, reduzieren aber die größte Exposition und schaffen Handlungsfähigkeit.
Registrierung nach § 33 BSIG organisatorisch vorbereiten
Betroffene Einrichtungen müssen sich nach Maßgabe des Gesetzes beim BSI registrieren. Seit Inkrafttreten stellt das BSI hierfür das BSI-Portal bereit; die NIS2-Registrierung erfolgt nach den aktuellen BSI-Hinweisen ausschließlich dort und nicht im bisherigen MIP. Betreiber kritischer Anlagen und Bundesbehörden nutzen in Übergangskonstellationen weiterhin vorrangig das MIP.
Vor der Eingabe werden juristische Stammdaten, Einrichtungsart, Kontaktstellen und erforderliche Nachweise intern verifiziert. Ein Funktionspostfach und mindestens zwei berechtigte Personen verhindern Abhängigkeit von Einzelpersonen. Änderungen an Firma, Anschrift, Tätigkeit oder Kontakt werden durch einen gepflegten Aktualisierungsprozess erfasst.
Die Kontaktstelle rund um die Uhr handlungsfähig machen
Eine eingetragene E-Mail-Adresse genügt nicht, wenn nachts niemand reagiert. Kontaktstelle, SOC oder Bereitschaftsdienst benötigen klare Regeln für Eingang, Authentisierung, Priorisierung und Weiterleitung von BSI-Kommunikation. Vertretungen und sichere Kommunikationswege werden getestet.
Auch ausgehende Meldungen müssen unter Zeitdruck freigegeben werden können. Legal, Informationssicherheit, Geschäftsleitung und Kommunikation besitzen vorab definierte Rollen. Eine Übung außerhalb der Kernarbeitszeit zeigt, ob Zugang zum Portal, erforderliche Informationen und Entscheidungsbefugnisse tatsächlich verfügbar sind. Festgestellte Erreichbarkeitslücken werden unmittelbar mit Vertretungen geschlossen.
Den NIS2-Meldeprozess auf die gesetzlichen Stufen ausrichten
§ 32 BSIG setzt die gestufte Meldelogik für erhebliche Sicherheitsvorfälle um. Sie beginnt mit einer frühen Meldung, wird durch weitere Bewertung ergänzt und endet mit Abschluss- oder Fortschrittsinformationen. Die engen Fristen laufen ab Kenntnis; deshalb muss bereits die interne Erkennung und Eskalation schnell funktionieren.
Das Runbook definiert Kriterien für Erheblichkeit, Entscheidungsträger, Mindestinformationen und Aktualisierung. Anfangsmeldungen dürfen Unsicherheit enthalten, müssen aber als solche gekennzeichnet werden. Technik sichert Fakten und Beweise, während die zuständige Stelle konsistente Meldungen an Behörden, Kunden und gegebenenfalls Datenschutzaufsicht koordiniert.
Erheblichkeit mit einem Entscheidungsschema bewerten
Ein Vorfall ist nicht nur wegen technischer Auffälligkeit erheblich. Das Schema betrachtet verursachte oder mögliche schwerwiegende Betriebsstörungen, finanzielle Verluste und erhebliche Schäden für andere Personen. Sektorspezifische Durchführungsakte und nationale Konkretisierungen werden einbezogen, soweit sie anwendbar sind.
Das SOC benötigt verständliche Trigger, darf die endgültige Rechtsentscheidung aber nicht allein tragen. Bei Grenzfällen eskaliert es früh an Incident Manager und Legal. Die Entscheidung wird mit bekannten Fakten, Annahmen, Zeitpunkt der Kenntnis und verantwortlicher Freigabe dokumentiert. Neue Informationen können eine Neubewertung auslösen.
Incident Response und Krisenmanagement verbinden
Technische Eindämmung, Geschäftskontinuität, Behördenmeldung und externe Kommunikation laufen parallel. Ein Ransomware-Angriff erfordert beispielsweise Isolierung, forensische Sicherung, manuelle Ersatzprozesse, Managemententscheidungen und Information betroffener Partner. Getrennte Pläne müssen an denselben Eskalationspunkten zusammenfinden.
Eine gemeinsame Lageübersicht führt technische Fakten, betroffene Dienste, Entscheidungen, Meldestatus und nächste Fristen. Zeitstempel und Quellen bleiben nachvollziehbar. Regelmäßige Übungen kombinieren Cyberangriff und Geschäftsauswirkung, statt nur technische Reaktion oder Krisenkommunikation isoliert zu testen. Dadurch erkennen Teams widersprüchliche Annahmen vor einem echten Ernstfall.
Business Continuity auf die NIS2-Dienste fokussieren
Für wesentliche Dienste werden maximale Ausfallzeiten, Datenverlusttoleranz, Mindestleistung und Abhängigkeiten bestimmt. Wiederanlaufpläne orientieren sich an dieser Priorität. Backup allein ist kein Kontinuitätsnachweis, wenn Identitäten, Netz, Personal oder externe Plattformen für die Wiederherstellung fehlen.
Tests beginnen bei einzelnen Restores und reichen bis zu Ende-zu-Ende-Wiederanlauf sowie manuellen Ersatzverfahren. Ergebnisse dokumentieren tatsächliche Zeiten, Datenqualität und offene Engpässe. Abweichungen von vereinbarten Zielen werden als Risiko behandelt und der Geschäftsleitung vorgelegt. Verbesserungen werden nach Umsetzung in einem erneuten Test bestätigt.
Lieferkettensicherheit über Verträge hinaus betreiben
Die Einrichtung bleibt von Cloudanbietern, Managed Services, Softwareherstellern und spezialisierten Wartungsfirmen abhängig. Die Bewertung kombiniert Kritikalität des unterstützten Dienstes, Zugriffsrechte, Datenbezug, Konzentration, Alternativen und Sicherheitsreife. Ein allgemeines Zertifikat ist nur ein Nachweisbaustein.
Für kritische Lieferanten werden Vorfallfristen, Sicherheitsanforderungen, Unterauftragnehmer, Prüf- und Informationsrechte, Wiederherstellung und Exit geregelt. Der Regelbetrieb umfasst Monitoring, Serviceberichte, Feststellungen und Änderungen. Technische Fernzugriffe werden minimal berechtigt, zeitlich kontrolliert und protokolliert. Konzentrationsrisiken werden auf Dienst- und nicht nur auf Vertragsebene bewertet.
Sichere Beschaffung, Entwicklung und Wartung verankern
Sicherheitsanforderungen müssen vor Auswahl und Architekturentscheidung feststehen. Beschaffung prüft Updatefähigkeit, Supportdauer, Schwachstellenprozess, sichere Standardkonfiguration und benötigte Nachweise. Entwicklung integriert Bedrohungsmodellierung, Codeprüfung, Abhängigkeitsscans, Secrets Management und Sicherheitsfreigaben.
Änderungen an kritischen Systemen erhalten Risikobewertung, Test, Freigabe und Rückfallplan. Notfalländerungen bleiben möglich, werden aber nachträglich überprüft. Außerbetriebnahme entfernt Zugriffe, Daten, Schlüssel und nicht mehr unterstützte Komponenten kontrolliert aus der Umgebung. Jede Phase erzeugt dabei einen nachvollziehbaren Sicherheitsnachweis. Produktverantwortliche bestätigen offene Restrisiken vor der Abnahme.
Schwachstellenmanagement nach Exposition priorisieren
Ein wirksamer Prozess erfasst eigene Systeme, Drittsoftware, Cloudkomponenten und externe Hinweise. Priorität entsteht nicht nur aus einem CVSS-Wert, sondern aus Ausnutzbarkeit, Exposition, betroffenem Dienst, verfügbaren Gegenmaßnahmen und möglicher Geschäftswirkung. Aktiv ausgenutzte Schwachstellen verlangen besonders schnelle Entscheidung.
Ausnahmen benötigen Eigentümer, kompensierende Kontrolle und Ablaufdatum. Kennzahlen zeigen Zeit bis Bewertung und Behebung, Abdeckung kritischer Assets und überfällige Hochrisikofälle. Stichproben vergleichen Scannergebnis mit tatsächlicher Version und Patchstand, damit blinde Inventarbereiche sichtbar werden. Wiederkehrende Ursachen fließen in Architektur- und Beschaffungsentscheidungen ein.
Identitäten und privilegierte Zugriffe zuerst härten
Viele schwere Vorfälle nutzen kompromittierte Konten. Für kritische Dienste werden starke Mehrfaktorauthentisierung, minimale Rechte, getrennte Administrationskonten und gesicherte Notfallzugänge umgesetzt. Servicekonten besitzen eindeutige Eigentümer, rotierende Geheimnisse und überwachte Nutzung.
Regelmäßige Rezertifizierung vergleicht benötigte und tatsächlich erteilte Rechte. Ausgeschiedene Beschäftigte und beendete Dienstleister verlieren Zugriff zeitnah. Privileged-Access-Lösungen helfen, ersetzen aber keine saubere Rollenentscheidung. Auffällige Anmeldungen und Rechteänderungen fließen in das Security Monitoring. Notfallkonten werden separat geschützt, getestet und nach jeder Nutzung überprüft.
Wirksamkeit systematisch nachweisen
§ 30 verlangt nicht nur angemessene Maßnahmen, sondern auch Wirksamkeit. Ein Kontrolltest definiert Ziel, Methode, Stichprobe, Ergebnis, Abweichung und Nachverfolgung. Beispiele sind Restore-Tests, simulierte Phishing-Angriffe, Rezertifizierungsstichproben, Alarmtests und Lieferantenübungen.
Nachweise entstehen im Betrieb: Tickets, Systemprotokolle, Testberichte, Freigaben und Managementbeschlüsse. Eine separate Ordnersammlung kurz vor einer Prüfung erhöht Aufwand und birgt Widersprüche. Das Kontrollregister verweist auf die jeweils aktuelle Evidenz und ihren Eigentümer. Fehlende oder veraltete Evidenz löst eine kontrollierte Nachprüfung aus.
Nachweispflichten von KRITIS-Betreibern gesondert planen
Betreiber kritischer Anlagen unterliegen nach § 39 BSIG besonderen Nachweispflichten. Sie müssen Prüfzyklen, geeignete Prüfstellen und Einreichung frühzeitig planen. Wichtige und besonders wichtige Einrichtungen außerhalb dieser Kategorie können durch Aufsicht ebenfalls zur Darlegung ihrer Umsetzung aufgefordert werden.
Deshalb sollte jede Einrichtung prüfbereit sein, ohne eine formale Zertifizierung mit gesetzlicher Erfüllung gleichzusetzen. Scope, Methode und Feststellungen externer Prüfungen müssen zur tatsächlichen Diensterbringung passen. Offene Abweichungen erhalten einen transparenten Behandlungsplan. Fristen und Wirksamkeitskontrollen bleiben bis zum bestätigten Abschluss sichtbar.
Ein zwölfmonatiges Umsetzungsprogramm strukturieren
In Phase eins werden Betroffenheit, Scope, Governance, Registrierung und Meldefähigkeit hergestellt. Phase zwei priorisiert technische und organisatorische Hochrisikolücken. Phase drei integriert Lieferanten, sichere Entwicklung, Kontinuität und Wirksamkeitstests. Phase vier führt interne Prüfung, Managementreview und Verbesserungsplan durch.
Arbeitspakete besitzen Zielwirkung statt nur Dokumenttitel. „Backup-Konzept erstellen“ wird zu „kritischen Dienst innerhalb des vereinbarten Ziels aus isolierten Sicherungen wiederherstellen“. Abhängigkeiten und Ressourcen werden zentral gesteuert. Ein monatliches Programmboard löst Hindernisse und eskaliert Restrisiken.
Beispiel: mittelständischer Maschinenhersteller
Ein Hersteller mit mehreren hundert Beschäftigten prüft seine Tätigkeiten gegen Anlage 2 und die Größenkriterien. Er dokumentiert die Einordnung als wichtige Einrichtung und betrachtet Auftragsabwicklung, Produktion, Ersatzteilversorgung und Remote-Service als wesentliche Dienste. ERP, Produktionsnetz, Identitätsplattform und externe Fernwartung bilden die wichtigsten Abhängigkeiten.
Die ersten Maßnahmen sichern privilegierte Konten, segmentieren Fernzugriffe und testen die Wiederherstellung der Produktionsplanung. Ein Lieferantenausfall wird in einer Tabletop-Übung geprobt. Die Geschäftsleitung erhält eine priorisierte Risikosicht und überwacht Maßnahmen, statt nur eine Richtlinie zu genehmigen.
Beispiel: Managed Service Provider
Ein Dienstleister betreibt Infrastruktur mehrerer Kunden und kann als Einrichtung aus dem digitalen Sektor betroffen sein. Seine Geschäftswirkung reicht über die eigene Organisation hinaus. Der Scope umfasst zentrale Managementplattformen, Administratoridentitäten, Remote-Werkzeuge, Kundentrennung und Unterauftragnehmer.
Das Unternehmen führt besonders strikte Kontrolle privilegierter Zugriffe, manipulationsgeschützte Protokolle und kundenspezifische Incident-Kommunikation ein. Melde- und Vertragsfristen werden aufeinander abgestimmt. Eine Übung simuliert die Kompromittierung des Remote-Management-Systems und prüft parallele Eindämmung sowie Information. Die Ergebnisse werden gemeinsam mit ausgewählten Kunden ausgewertet.
Typische Umsetzungsfehler vermeiden
Häufig wird die Betroffenheit ohne belastbare Gesellschafts- und Tätigkeitsdaten entschieden. Andere Programme beschränken sich auf Richtlinien oder ISO-Mappings, ohne technische Wirksamkeit zu testen. Ebenfalls kritisch sind Registrierungen ohne gepflegte Kontaktstelle und Meldepläne, die nur während der Bürozeit funktionieren.
Ein weiterer Fehler ist die Gleichsetzung von NIS2 mit einem reinen IT-Projekt. Geschäftsprozesse, Lieferanten, Personal, Krisenmanagement und Leitungspflichten bleiben dann ungesteuert. Der Fahrplan verbindet deshalb Rechtsprüfung, Geschäftssicht, technische Maßnahmen und Managemententscheidungen in einem Programm.
Fazit: NIS2 wird im Betrieb erfüllt
Ein belastbarer NIS2-Fahrplan beginnt mit dokumentierter Betroffenheit und einem dienstorientierten Scope. Danach folgen Geschäftsleitungseinbindung, Registrierung, Meldefähigkeit, risikobasierte Kontrollen und Wirksamkeitsnachweise. Dokumentation ist wichtig, entsteht aber aus tatsächlich betriebenen und getesteten Prozessen.
BlackMount unterstützt bei der NIS2-Umsetzung: von Betroffenheits- und Gap-Analyse über Risikomanagement, technische Maßnahmen und Lieferantensteuerung bis zu Meldesimulation, Nachweisstruktur und Managementreview. Ziel ist eine prüfbare Cyberresilienz, die auch jenseits einer Aufsichtsprüfung funktioniert. Die Umsetzung bleibt dabei proportional zum tatsächlichen Risiko und Geschäftsmodell.
