NIS2 ist da – und jetzt? Was Mittelständler wirklich tun müssen

Hier ist die Frage, die viele Unternehmen zu spät stellen: Nicht mehr, was NIS2 irgendwann von Ihnen verlangt, sondern was es jetzt auslöst, wenn Sie bisher zu wenig getan haben. Denn das Gesetz gilt in Deutschland seit Dezember 2025, und viele Mittelständler haben die erste Registrierung beim BSI schlicht verpasst.

Klartext: Die Pflicht ist damit nicht verschwunden. Für die Geschäftsleitung zählen jetzt vor allem zwei Dinge – persönliche Haftung und die Frage, wie belastbar Ihr Unternehmen bei einem Vorfall oder einer Prüfung dasteht. Das hier wird keine Paniksendung. Es geht um einen sauberen Neustart in vier Schritten: Betroffenheit klären, Bestand aufnehmen, Struktur aufbauen, kritische Lücken schließen. Und bevor Sie über Maßnahmen reden, müssen Sie zuerst wissen, ob Sie überhaupt im Anwendungsbereich liegen.

Abschnitt 1: Sind Sie betroffen, und sind Sie schon zu spät dran?

Seien wir ehrlich – genau hier beginnt bei vielen Unternehmen das Durcheinander. Nicht, weil die Grundlogik kompliziert wäre, sondern weil viele das Thema lange als KRITIS-Sonderfall betrachtet haben. Das greift heute zu kurz. NIS2 betrifft längst nicht mehr nur klassische Betreiber kritischer Infrastruktur, sondern einen deutlich breiteren Teil des Mittelstands.

Der erste Filter ist im Kern simpel: Sektor plus Unternehmensgröße. Typisch geht es um Unternehmen ab 50 Mitarbeitenden oder 10 Millionen Euro Jahresumsatz, wenn sie in einem der erfassten Sektoren tätig sind. Genau an dieser Stelle merken viele zum ersten Mal, dass sie nicht nur indirekt betroffen sind, sondern direkt reguliert. Und da versteckt sich das Risiko – weil die Selbsteinschätzung oft zu spät oder zu oberflächlich gemacht wird.

Sie müssen nicht jedes juristische Detail im ersten Schritt auswendig kennen. Aber Sie müssen sauber prüfen, in welchem Sektor Sie unterwegs sind und ob Ihre Größe Sie in den Geltungsbereich zieht. Die Unterscheidung zwischen wichtigen und besonders wichtigen Einrichtungen wird vor allem dann relevant, wenn es um Aufsicht, Nachweise und Bußgelder geht. Für die erste Managemententscheidung reicht oft eine nüchterne Frage: Fallen wir darunter, ja oder nein?

Nun kommt der unbequeme Teil: Rund 18.500 von etwa 29.500 betroffenen Unternehmen haben die erste BSI-Registrierungsfrist verpasst. Das ist keine Randnotiz. Es zeigt, wie viele Unternehmen das Thema entweder falsch eingeordnet oder im Tagesgeschäft nach hinten geschoben haben. Wenn Sie dazugehören, dann hilft keine Diskussion darüber, ob die Frist fair war oder nicht. Die Pflicht bleibt bestehen.

Eine abgelaufene Frist hebt die Registrierungspflicht nicht auf. Wenn Sie betroffen sind und noch nicht registriert haben, ist die richtige Reaktion nicht Abwarten, sondern Nachregistrieren. So schlicht ist das. Später registriert ist immer noch besser als gar nicht registriert, auch wenn die Verspätung formal bereits ein Problem ist.

Worauf Sie nicht setzen sollten: dass das BSI Sie schon finden und freundlich an die Hand nehmen wird. Das BSI wird Sie nicht anrufen und Ihre Einstufung für Sie übernehmen. Diese Verantwortung liegt bei Ihnen. Genauer gesagt, bei Ihrer Organisation und am Ende bei der Geschäftsleitung. Das ist keine Technikfrage. Das ist eine Governance-Frage.

Ja, die praktische Seite ist unerquicklich. Sie brauchen in der Regel ein ELSTER-Zertifikat, ein Unternehmenskonto und den Weg durchs BSI-Portal. Das ist bürokratisch, kostet Zeit und nervt. Aber es ist keine tragfähige Ausrede. Wenn Ihr Unternehmen in den Anwendungsbereich fällt, gehört diese Registrierung jetzt auf die kurze Liste der Dinge, die nicht weiter liegenbleiben dürfen.

Was bedeutet das konkret für Sie? Wenn Ihr Status unklar ist, klären Sie ihn zügig. Nicht in drei Monaten, nicht nach dem nächsten Strategie-Workshop, sondern jetzt. Und wenn die Prüfung ergibt, dass Sie betroffen sind und noch nicht registriert haben, holen Sie das umgehend nach. Erst danach lohnt es sich, im nächsten Schritt über Maßnahmen, Lücken und Prioritäten zu sprechen.

Denn hier passiert der nächste klassische Fehler: Unternehmen kaufen Sicherheitstools, bevor sie ihre eigene Umgebung überhaupt verstanden haben. Genau deshalb gehen wir als Nächstes auf den Bestand – nicht auf Prospekte, nicht auf Plattformen, sondern auf das, was bei Ihnen heute wirklich läuft.

Abschnitt 2: Schritt 1, erst Inventur, dann Technik

Der erste operative Schritt klingt unspektakulär, aber genau hier entscheidet sich, ob Sie Ihr Haus sauber steuern oder nur Aktionismus betreiben. NIS2 ist am Anfang kein Einkaufsprojekt, sondern ein Sichtbarkeitsproblem. Wenn Sie nicht genau sehen, welche Leistungen Ihr Unternehmen trägt, welche Systeme dahinterstehen und wo die Abhängigkeiten liegen, dann kaufen Sie im Zweifel Technik an der falschen Stelle und bezahlen später doppelt.

Fangen Sie nicht bei der Firewall an, sondern bei Ihrem Betrieb. Überlegen Sie, welche Leistungen, Prozesse und Zusagen zwingend weiterlaufen müssen, damit Ihr Unternehmen handlungsfähig bleibt. Also nicht abstrakt „IT muss funktionieren“, sondern konkret: Was darf nicht ausfallen, weil sonst Produktion, Logistik, Kundenservice, Auftragsbearbeitung oder externe Lieferverpflichtungen stehen? Genau dort beginnt die Inventur.

Von diesen Geschäftsprozessen gehen Sie einen Schritt tiefer und fragen: Welche Systeme tragen diese Abläufe tatsächlich? Das sind Infrastruktur, Anwendungen, Identitäten, Schnittstellen, Netze und Cloud-Dienste. Und zwar nicht nur die offensichtlichen Systeme im Rechenzentrum oder in Microsoft 365, sondern auch die kleineren Bausteine, die im Alltag gern übersehen werden, bis sie ausfallen. Alte Schnittstellen, Fachanwendungen mit nur einem Administrator, externe Zugänge für Dienstleister, VPN-Strecken, Backup-Ziele, Verzeichnisdienste – da versteckt sich das Risiko.

Wichtig ist dabei: Die Inventur endet nicht bei Technik, sie braucht auch die Personenseite. Wer administriert was, wer ist Service Owner, und welche externen Dienstleister greifen auf kritische Systeme zu? Wer ist im Notfall erreichbar, und wer entscheidet außerhalb der Bürozeiten? Viele Umgebungen wirken auf dem Papier stabil, bis man feststellt, dass drei zentrale Abläufe an einzelnen Personen hängen, deren Wissen nirgends sauber abgelegt ist.

Wenn Sie diese Bestandsaufnahme auf eine brauchbare Mindesttiefe bringen wollen, dann schauen Sie auf ein paar harte Punkte: Welche Assets gibt es überhaupt, welche Abhängigkeiten bestehen zwischen ihnen, wo liegen privilegierte Konten, wie laufen Backup und Restore tatsächlich, und welche Systeme sind von außen erreichbar? Klartext: Das sind keine akademischen Fragen – die fliegen Ihnen im Vorfall oder bei einer Prüfung sofort um die Ohren, wenn sie ungeklärt bleiben.

Dann kommen die einfachen Fragen, die oft erstaunlich selten sauber beantwortet werden: Was darf ausfallen, was darf auf keinen Fall ausfallen und für wie lange? Wenn auf diese Fragen nur Schulterzucken oder Bauchgefühl kommt, dann fehlt Ihnen keine Spezialsoftware, sondern ein belastbares Bild Ihres eigenen Betriebs. Ohne dieses Bild ist jede Risikobewertung wacklig.

Schauen Sie sich auch ehrlich an, wie Ihr Unternehmen heute mit Vorfällen und Wiederanlauf umgeht: Wer wird angerufen, wenn ein kritischer Dienst steht, was wird sofort eskaliert, und was bleibt erst einmal im Ticketsystem liegen? Welche Abläufe sind dokumentiert, und welche existieren nur in den Köpfen einzelner Kollegen oder langjähriger Dienstleister? Seien wir ehrlich, im Mittelstand ist genau das oft der Normalfall: Teil-Dokumentation, stilles Erfahrungswissen, geerbte Systeme und Zuständigkeiten, die jeder irgendwie kennt, aber niemand sauber benannt hat.

Das klingt operativ, ist aber ein Managementthema, denn Sie können keine Risikobehandlung freigeben, wenn nicht einmal klar ist, welche Systeme betroffen sind, welche Abhängigkeiten es gibt und wie kritisch ein Ausfall wirklich wäre. Sonst entscheiden Sie über Budget, Prioritäten und Akzeptanz von Risiken auf Basis von Annahmen. Das funktioniert, bis der erste ernste Vorfall eintritt – und dann wird aus Annahme schnell Haftung.

Die gute Nachricht: Sie müssen dafür nicht bei null anfangen. In vielen Unternehmen liegt das Material bereits verstreut herum – DSGVO-Verzeichnisse, ISO-27001-Bausteine, Lieferantenlisten, Admin-Abläufe, Notizen aus BCM-Runden oder alte Betriebsdokumentationen, alles nicht perfekt, aber oft brauchbar als Startpunkt. Nutzen Sie diese Unterlagen, nicht weil sie schon genügen würden, sondern weil sie Ihnen Zeit sparen und erste Lücken sichtbar machen.

Eine Inventur liefert also Fakten, aber wenn sie in Ordnern, Excel-Listen und Köpfen verteilt bleiben, steuern sie noch nichts. Genau darum geht es im nächsten Schritt: aus dieser verteilten Realität eine Struktur zu bauen, mit der Sie Risiken, Zuständigkeiten und Entscheidungen tatsächlich führen können.

Abschnitt 3: Schritt 2, die Struktur aufbauen, die aus verteilter IT echte Steuerung macht

Sobald der Bestand halbwegs klar ist, taucht die nächste unangenehme Wahrheit auf. Den meisten Unternehmen fehlen nicht zuerst Tools, sondern Zuständigkeit, Routine und ein sauberer Nachweis. Genau das ist der Punkt, an dem verteilte IT plötzlich teuer wird, weil niemand mehr sauber sagen kann, wer welche Entscheidung trifft, wer welches Risiko trägt und wie man im Ernstfall innerhalb weniger Stunden handlungsfähig bleibt.

Darum geht es im zweiten Schritt nicht um mehr Technik, sondern um eine kleine, belastbare Führungsstruktur. Sie brauchen klare Verantwortlichkeiten und eine Sicherheitsleitlinie, die nicht aus allgemeinen Floskeln besteht, sondern konkret beschreibt, wie Ihr Unternehmen mit Risiken, Zugriffen, Vorfällen und Dienstleistern umgeht. Dazu kommen ein Risikoregister, in dem offene Punkte mit Owner, Frist und Status geführt werden, und ein Incident-Prozess mit Eskalationsweg, damit nicht erst im Störfall diskutiert wird, wer wen informieren darf.

Das hängt direkt an der Pflicht der Leitung. Die Geschäftsführung kann das Thema operativ delegieren, aber nicht inhaltlich wegschieben. Wenn Maßnahmen nach NIS2 beschlossen, priorisiert oder akzeptiert werden, dann muss die Leitung diese Entscheidungen billigen, überwachen und in ihrer Tragweite verstehen. Klartext: Es reicht nicht, wenn ein Dienstleister oder ein IT-Leiter sagt, das sei schon erledigt – die Geschäftsführung muss sich berichten lassen, Rückfragen stellen und dokumentieren, was freigegeben wurde und was nicht.

An dieser Stelle fällt oft der Begriff ISMS, und viele schalten innerlich ab, weil sie an Zertifizierungsordner und Beraterdeutsch denken. Lassen Sie es mich einfacher sagen: Ein ISMS ist im Kern eine Betriebsstruktur, in der Risiken, Kontrollen, Entscheidungen und Nachweise an einem Ort zusammenlaufen. Nicht zwangsläufig in einem Tool, aber in einer Form, die steuerbar ist – also nicht fünf verschiedene Listen, drei halbe Richtlinien und zwei Dienstleister, die jeweils nur ihren Ausschnitt kennen.

Was heißt dokumentiert in der Praxis? Dokumentiert heißt nicht, dass irgendwo ein PDF liegt, sondern dass es einen benannten Owner, einen Prüftermin und eine freigegebene Version gibt. Der Ablauf ist für die Beteiligten nutzbar, und die Nachweise liegen auffindbar ab. Wenn Sie etwa einen Meldeprozess haben, dann muss klar sein, wer einen Vorfall bewertet, wer das BSI informiert, wer intern eskaliert und wer die Vertretung übernimmt, wenn die zuständige Person im Urlaub ist. Alles andere ist Papier mit gutem Willen.

Der Takt zur Geschäftsleitung ist ebenso wichtig. Wenn Sie das Thema ernsthaft steuern wollen, dann braucht es einen festen Reporting-Zyklus, nicht nur dann, wenn etwas schiefgeht. Auf den Tisch gehören offene Risiken, akzeptierte Risiken, Budgetentscheidungen, verzögerte Maßnahmen und Abhängigkeiten, die noch ungelöst sind. Wenn etwa ein kritischer Dienst an einem externen Provider hängt, dessen Vertrag keine sauberen Sicherheitsklauseln enthält, dann ist das ein offenes Geschäftsrisiko, über das entschieden werden muss.

Im Verhältnis zum BSI braucht diese Struktur ebenfalls ein paar Grundlagen, die erstaunlich oft fehlen. Sie benötigen einen benannten Ansprechpartner und eine Vertretung sowie einen belastbaren Meldeweg. Und Sie müssen organisatorisch in der Lage sein, Vorfälle in den geforderten Zeitfenstern zu bearbeiten, also Frühwarnung, Folgemeldung und Abschlussmeldung. Das klingt nach Formalie, ist aber im Alltag eine Frage von Rollen, Erreichbarkeit und vorbereiteten Abläufen. Ohne das wird aus jeder knappen Frist hektische Improvisation.

Nun machen viele Unternehmen an dieser Stelle einen anderen Fehler. Sie bauen zu groß, sodass dicke Policy-Ordner, kopierte Vorlagen aus fremden Branchen und Freigabeprozesse entstehen, die im Tagesbetrieb niemand nutzt. Das sieht nach Fleiß aus, löst aber das eigentliche Problem nicht. Denn zwischen Vorlage und Wirklichkeit klafft oft eine Lücke, und genau dort scheitert später die Nachweisbarkeit.

Der bessere Weg ist unspektakulärer. Bauen Sie eine kleine, nutzbare Struktur, die an Ihre realen Assets, Ihre realen Teams und Ihre realen Entscheidungen gekoppelt ist. Wenn Sie fünf kritische Prozesse haben, beginnen Sie dort; wenn Sie zwei besonders sensible Dienstleister haben, gehen Sie zuerst diese Verträge und Meldewege an; und wenn es einen Engpass bei Admin-Rechten oder bei der Vertretung gibt, dann regeln Sie genau das sauber. Kein Architekturtheater, sondern Arbeitsfähigkeit.

Ein Punkt wird dabei gern weich formuliert, obwohl er es nicht ist: Die Schulung der Geschäftsleitung ist Pflicht. Das ist keine nette Awareness-Maßnahme und keine jährliche Folie mit Phishing-Hinweisen, sondern Teil der eigenen Verantwortung. Wer Risiken billigen und überwachen soll, muss genug verstehen, um gute und schlechte Entscheidungen unterscheiden zu können. Sonst unterschreibt die Leitung Formalien, deren Tragweite sie erst beim Vorfall kennenlernt. Und dann wird es bekanntlich teuer.

Wenn diese Struktur steht, ändert sich die Diskussion. Dann reden Sie nicht mehr über diffuse Sicherheitswünsche, sondern über konkrete Lücken mit Gewicht. Genau dort gehen wir als Nächstes hin: Welche Maßnahmen rechtlich und operativ wirklich zählen, und was eben nicht nur gut klingt, sondern im Betrieb trägt.

Abschnitt 4: Schritt 3, auf die Lücken gehen, die operativ und rechtlich wirklich zählen

Sobald diese Grundstruktur steht, landen viele Unternehmen beim nächsten typischen Fehler: Sie stürzen sich sofort auf die Lücken, bevor die Vorarbeit wirklich sitzt. Genau da hilft ein Blick auf die zehn Maßnahmen aus §30 BSIG. Nicht, weil Sie den Paragrafen auswendig lernen müssten, sondern weil er ein praktisches Rückgrat gibt, an dem sich Ihre Prioritäten ordentlich ausrichten lassen.

Vereinfacht gesagt lassen sich diese zehn Punkte auf vier Gruppen herunterbrechen. Erstens Risikomanagement – erkennen, bewerten und steuern. Zweitens Vorfallbehandlung und Notfallfähigkeit – also nicht nur reagieren, sondern auch arbeitsfähig bleiben. Drittens Lieferantensteuerung, denn kritische Abhängigkeiten liegen heute selten nur im eigenen Haus. Und viertens sicherer Betrieb und Zugriff – die Basiskontrollen, die im Alltag oft banal wirken, aber im Vorfall den Unterschied machen.

Schauen wir zuerst auf die Kontrollen, die im Mittelstand meist fehlen oder nur halb sauber dastehen. MFA für kritische Zugänge gehört fast immer dazu – nicht als nette Option, sondern für Admin-Konten, Remote-Zugriffe und sensible Anwendungen. Dann das Asset-Inventar: Ohne saubere Sicht auf Systeme und Dienste bleibt Patchen reine Glückssache. Dazu kommt die Patch-Disziplin, also nicht nur Updates technisch einspielen können, sondern klare Fristen, Prioritäten und Verantwortlichkeiten. Und dann die Trennung von Admin-Rechten, belastbares Logging und getestete Backups. Das ist kein Wunschzettel, sondern die betriebliche Mindesthygiene genau dort, wo es am meisten wehtut.

Klartext: Beim Thema Backup wird viel zu schnell ein Haken gesetzt, denn ein Backup ist noch lange keine Notfallfähigkeit. Wenn niemand den Restore getestet hat, wenn unklar ist, wie lange eine Wiederherstellung dauert, und wenn kein definierter Notbetrieb existiert, dann besitzen Sie im Zweifel nur Datensicherungen – aber keine verlässliche Wiederanlaufstrategie. Der Unterschied wird erst im Ausfall sichtbar, dann aber sehr deutlich.

Ähnlich nüchtern sollten Sie auf die Vorfallbehandlung schauen. Wer bewertet eigentlich die Schwere eines Sicherheitsvorfalls? Ab welchem Punkt wird intern eskaliert? Wer informiert das BSI, und wer bindet die Geschäftsleitung ein? Wenn diese Schwellenwerte nicht definiert sind, diskutieren Teams im Ernstfall erst über Zuständigkeiten, während die Uhr bereits läuft – genau das darf nicht passieren. Ein Vorfallprozess muss nicht elegant sein, aber klar.

Ein Bereich, den viele unterschätzen, ist das Lieferanten- und Cloud-Risiko. Für viele kritische Leistungen hängen Verfügbarkeit, Sicherheit und Meldefähigkeit heute an externen Providern, Plattformen oder spezialisierten Dienstleistern. Also müssen Sie wissen, welche Anbieter für Ihren Betrieb wirklich kritisch sind. Dann prüfen Sie, ob die Verträge Sicherheitsklauseln, Meldepflichten und klare Reaktionswege enthalten. Und Sie schauen auf Single Points of Failure. Wenn ein zentraler Dienst an einem einzigen Anbieter hängt und es weder technische noch organisatorische Ausweichmöglichkeiten gibt, dann liegt dort ein offenes Risiko – nicht theoretisch, sondern ganz praktisch.

Dazu gehört auch die sichere Beschaffung und Wartung – also nicht nur, ob ein System heute funktioniert, sondern wie es gepflegt wird, wie lange es unterstützt wird und welche Drittkomponenten darin stecken. Von außen erreichbare Systeme verdienen besondere Aufmerksamkeit, weil sie unter realem Angriffs- und Ausfallrisiko stehen. Wenn Patch-Prozesse unklar sind, Lebenszyklen ignoriert werden oder Altkomponenten ohne klare Verantwortung weiterlaufen, dann wächst das Risiko leise im Hintergrund. Genau diese stillen Altlasten werden später teuer.

Hier kommt ein Punkt, der gern als weiche Maßnahme abgetan wird, obwohl er prüfbar und verpflichtend ist: Schulung und Awareness. Mitarbeitende müssen wissen, wie sie Auffälligkeiten melden, woran sie riskante Situationen erkennen und welche Grundregeln gelten. Administratoren brauchen vertiefte Schulungen, denn ihre Fehler oder Nachlässigkeiten haben eine andere Tragweite. Und die Geschäftsleitung braucht eine eigene Schulung, getrennt von allgemeiner Awareness, weil es dort um Pflichten, Entscheidungen und Haftung geht. Wichtig ist auch der Nachweis – wenn es stattgefunden hat, muss es belegbar sein.

Dann kommt die Wirksamkeitsprüfung. Maßnahmen zählen nicht schon deshalb, weil sie eingeführt wurden – Sie müssen prüfen, ob sie tatsächlich tragen. Das kann über interne Reviews laufen, über Tabletop-Übungen für Vorfälle, über Restore-Tests, über die regelmäßige Überprüfung von Zugriffsrechten oder über Lessons Learned nach echten Störungen. Sie brauchen einen Rhythmus, in dem Schwächen sichtbar werden, bevor sie zum Vorfall werden. Sonst verwalten Sie Formalien, aber keine Sicherheit.

Seien wir ehrlich: Nicht jede Lücke verlangt nach einer neuen Plattform – das ist die gute Nachricht. Die weniger angenehme Nachricht ist: Jede kritische Lücke braucht einen Owner, eine Frist und eine Managemententscheidung. Wenn ein Risiko bleibt, dann muss es bewusst bleiben, nicht aus Versehen. Genau dort trennt sich Führung von Hoffnung.

Wovor ich in der Praxis regelmäßig warne, ist die Frankenstein-Compliance. Fünf Einzelmaßnahmen, mehrere Tools, vielleicht noch ein externer Bericht – aber keine erkennbare Verbindung zwischen Architektur, Betrieb und Verantwortung. Das sieht nach Aktivität aus, löst aber die eigentliche Aufgabe nicht. Denn isolierte Maßnahmen ohne Betriebsmodell erzeugen oft nur neue Reibung und neue blinde Flecken.

Sobald Sie die schweren Lücken so priorisiert haben, stellt sich die nächste praktische Frage: Woran erkennen Sie im Alltag eigentlich, ob der Stand belastbar ist? Genau darum geht es im nächsten Schritt.

Abschnitt 5: Schritt 4, den Stand nachweisbar und im Betrieb beherrschbar machen

An diesem Punkt geht es nicht mehr um Perfektion – die gibt es in der Sicherheit ohnehin nicht. Was Sie brauchen, ist sichtbare Kontrolle: nachvollziehbare Entscheidungen, dokumentierte Zuständigkeiten und Abläufe, die nicht nur einmal aufgeschrieben, sondern wiederholbar sind. Genau das meint Reifegrad im brauchbaren Sinn.

Wenn Sie morgen erklären müssten, wo Sie stehen, dann sollten ein paar Dinge schnell greifbar sein: Ihre Scope-Entscheidung, Ihr Registrierungsstatus, ein belastbarer Blick auf Assets und kritische Abhängigkeiten, eine aktuelle Risikoliste, der dokumentierte Vorfallweg, Nachweise zu Backups und Tests, Schulungsunterlagen und Unterlagen dazu, wie Sie kritische Lieferanten bewerten und einbinden. Nicht schön aufbereitet für eine Folie, sondern so, dass jemand damit arbeiten kann.

Klartext: Nicht dokumentierte Arbeit hilft Ihnen nach einem Vorfall fast nicht mehr. Vielleicht wurde etwas technisch richtig gemacht, vielleicht ein Risiko intern längst erkannt, vielleicht hat ein Administrator seit Monaten sauber gearbeitet – wenn davon nichts nachvollziehbar abgelegt ist, dann zählt es im Ernstfall nur begrenzt. Für die Steuerung ist das schlecht, für die Haftung ist es noch schlechter.

Darum braucht das Ganze einen Betriebsrhythmus. Ein quartalsweises Management-Review ist sinnvoll, damit offene Risiken, Verzögerungen und Entscheidungen nicht versanden. Die Risikoanalyse gehört regelmäßig aktualisiert – mindestens bei wesentlichen Änderungen und nicht erst dann, wenn etwas schiefgeht. Restore-Tests brauchen einen festen Takt, Zugriffsrechte ebenfalls. Und kritische Lieferanten sollten nicht nur beim Vertragsabschluss betrachtet werden, sondern wiederkehrend.

Genau hier zeigt sich auch, ob NIS2 als einmaliges Compliance-Projekt missverstanden wurde. Wenn nach dem Projektordner Ruhe einkehrt, dann war es keine Steuerung, sondern eine Abgabe. NIS2 funktioniert nur als Betriebsdisziplin – als fester Teil von Führung, Betrieb und Veränderung. Nicht glamourös, aber tragfähig.

Unternehmen, die das sauber lösen, wirken von außen oft unspektakulär – keine großen Sicherheitsparolen, keine überzüchteten Programme, kein Theater. Sie führen ihre Abläufe klarer, entscheiden Risiken bewusster und können im Zweifel zeigen, warum etwas so geregelt wurde und wer dafür gerade steht.

Und damit sind wir bei der eigentlichen Entscheidung: Behandeln Sie das Thema als Papierübung, dann entsteht Papier; behandeln Sie es als Steuerung von Geschäftsrisiko, dann entsteht Führbarkeit.

Schluss: Mit der Einordnung anfangen, nicht mit Panik

NIS2 bestraft nicht zuerst die unperfekte IT, sondern unklare Verantwortung und schlecht gesteuertes Risiko.

Prüfen Sie jetzt Ihre Betroffenheit. Holen Sie die Registrierung nach, wenn Sie zu spät dran sind. Und benennen Sie noch in diesem Quartal einen klaren Verantwortlichen für diesen Vier-Schritte-Plan. Wenn Ihnen solche Einordnungen aus der Praxis helfen, abonnieren Sie den Podcast, bevor Day-2-Operations bei Ihnen auch zur Detektivarbeit wird.