Aus der Theorie wird Ernst

Als das NIS2-Umsetzungsgesetz im Dezember 2025 in Kraft trat, war die häufigste Reaktion im Mittelstand ein kollektives Abwarten. "Bis das BSI wirklich prüft, dauert es noch." Dieser Satz war falsch. Seit Januar 2026 hat das BSI seinen Aufsichtsbetrieb schrittweise aufgenommen – und die ersten Erkenntnisse aus technischen Prüfungen und Registrierungsgesprächen zeichnen ein ernüchterndes Bild.

Wir begleiten aktuell mehrere Unternehmen durch NIS2-Readiness-Projekte und sprechen regelmäßig mit Gleichgesinnten aus der Branche. Was wir hören, deckt sich mit dem, was aus dem BSI-Umfeld durchsickert: Die meisten Unternehmen, die glaubten, "eigentlich gut aufgestellt" zu sein, haben mehr offene Flanken als erwartet.

Flanke 1: Der Meldeprozess, der im Ernstfall versagt

NIS2 schreibt bei erheblichen Sicherheitsvorfällen eine klare Meldekette vor: 24 Stunden für die Erstmeldung, 72 Stunden für den Folgebericht. Klingt machbar. In der Praxis stellt sich heraus, dass viele Unternehmen zwar wissen, dass sie melden müssen – aber keinen funktionsfähigen Prozess haben, um das tatsächlich zu tun.

Was in einer Tabschprüfung als "Incident Response Prozess dokumentiert" abgehakt wurde, ist in der Realität oft ein Word-Dokument aus 2022, das niemand kennt. Die entscheidenden Fragen – wer ruft wen an, wer hat die BSI-Zugangsdaten, wer formuliert die Meldung unter Zeitdruck – sind nicht geregelt. Bei einer simulierten Übung mit einem unserer Kunden (Maschinenbau, rund 400 Mitarbeiter) dauerte es drei Stunden, bis überhaupt klar war, wer intern der "Single Point of Contact" für das BSI sein soll. Die 24-Stunden-Frist wäre längst abgelaufen.

Die Lösung ist keine Raketenwissenschaft, aber sie erfordert tatsächliche Vorbereitung: ein schriftlich definierter, geübter Meldeprozess, klare Verantwortlichkeiten, vorbereitete Meldeformulare und – ganz konkret – einen getesteten Zugang zum BSI-Meldeportal. Nicht erst dann anlegen, wenn der Angriff läuft.

Flanke 2: Die Lieferkette, die niemand wirklich kennt

NIS2 verlangt ausdrücklich, dass betroffene Unternehmen die Sicherheit ihrer Lieferkette aktiv managen. Das klingt nach einem abstrakten Governance-Thema – bis man anfängt, die eigene Zuliefererstruktur aufzuzeichnen.

Ein typisches Beispiel aus unserem Projektalltag: Ein Unternehmen betreibt eine ERP-Schnittstelle zu einem Logistikdienstleister. Die Schnittstelle wurde vor acht Jahren von einem externen Entwickler eingerichtet, der inzwischen nicht mehr für das Unternehmen arbeitet. Wer hat Zugriff auf diese Schnittstelle? Welche Daten fließen durch sie? Ist der Logistikdienstleister selbst NIS2-pflichtig? Wird die Verbindung verschlüsselt? Wann wurde zuletzt ein Penetrationstest durchgeführt?

Auf keine dieser Fragen gab es sofort eine Antwort. Das ist keine Ausnahme – das ist die Regel. Supply-Chain-Sicherheit bedeutet eben nicht, einen Fragebogen an Lieferanten zu schicken. Es bedeutet, die eigenen Systemgrenzen zu kennen, und das ist überraschend vielen Unternehmen nach wie vor nicht klar.

Flanke 3: Logging – das stille Compliance-Problem

Für eine BSI-Prüfung müssen Unternehmen nachweisen können, was in ihren Systemen passiert – und zwar rückwirkend. Wer hat sich wann wo eingeloggt? Welche administrativen Zugriffe fanden statt? Gab es Anomalien im Netzwerkverkehr?

Das setzt voraus, dass Logs überhaupt strukturiert erfasst werden, lange genug aufbewahrt werden (NIS2 orientiert sich an mindestens zwölf Monaten für sicherheitsrelevante Ereignisse) und im Ernstfall tatsächlich ausgewertet werden können. Was wir in der Praxis vorfinden: Windows-Eventlogs mit einer Aufbewahrungszeit von 30 Tagen, Firewall-Logs, die auf dem Gerät selbst liegen und bei einem Angriff sofort verloren sind, und keine zentrale Aggregation der Logs aus unterschiedlichen Systemen.

Ein SIEM (Security Information and Event Management) ist keine Luxuslösung mehr – für NIS2-pflichtige Unternehmen wird es zur operativen Voraussetzung. Die gute Nachricht: Gute Open-Source-Lösungen wie Wazuh oder kommerzielle Alternativen in der Cloud lassen sich auch im Mittelstand implementieren, ohne ein Großprojekt daraus zu machen.

Was jetzt realistisch ist

Die ehrliche Einschätzung nach drei Monaten NIS2-Praxis: Wer noch keine strukturierte Gap-Analyse durchgeführt hat, schiebt ein wachsendes Problem vor sich her. Das BSI prüft zunächst bevorzugt "besonders wichtige Einrichtungen" – aber die Reihe kommt zu allen, die betroffen sind.

Drei Maßnahmen, die sofort Wirkung zeigen und keine Monate in der Umsetzung dauern:

  1. Meldeprozess testen: Simulieren Sie einen Vorfall. Nicht auf dem Papier – sondern mit den tatsächlichen Verantwortlichen, in Echtzeit. Was bricht dabei zusammen, zeigt Ihnen, wo Priorität liegt.
  2. Systemgrenzen kartieren: Erfassen Sie alle Schnittstellen zu Dritten – APIs, VPN-Zugänge, Remote-Support-Tools von Lieferanten. Jede Verbindung nach außen ist ein potenzieller Eintrittspunkt.
  3. Zentrales Log-Management einrichten: Auch ein einfaches Setup mit einem zentralen Syslog-Server ist besser als verteilte, kurzlebige Logs auf Einzelgeräten. Fangen Sie klein an – aber fangen Sie an.

NIS2 ist kein Papiertiger. Die ersten Verfahren werden kommen. Wer jetzt handelt, handelt mit Vorsprung.