NIS2-Readiness: Warum Cybersecurity jetzt ein Betriebsmodell braucht

Der Fragebogen kommt vor dem Audit

Ein österreichischer B2B-Zulieferer mit 60 Mitarbeitenden bekommt an einem Dienstagmorgen eine unscheinbare E-Mail vom wichtigsten Kunden. Kein Audit-Termin, keine Behörde, kein Panikton. Nur ein Lieferantenfragebogen: aktuelle Systemliste, Verantwortliche für kritische Anwendungen, Nachweis eines getesteten Backups, Incident-Kontaktweg, Übersicht der wichtigsten IT-Dienstleister und Bestätigung, dass Management Cybersecurity-Risiken regelmäßig prüft.

Die Firma hat nichts ignoriert. Es gibt Microsoft 365, einen IT-Dienstleister, ein CRM, Backups beim Hoster, einige n8n-Workflows, eine Passwortregel und eine Security-Policy im SharePoint. Trotzdem kann niemand den Fragebogen sauber ausfüllen. Die Systemliste ist veraltet. Der Backup-Test wurde nie dokumentiert. Der Incident-Kontaktweg steht in keinem Runbook. Die Lieferantenliste liegt in der Buchhaltung, nicht bei IT. Die Geschäftsführung weiß, dass Cybersecurity wichtig ist, aber nicht, welche Nachweise im Betrieb entstehen.

Genau so wird NIS2 für viele KMU zuerst spürbar: nicht als abstrakter Gesetzestext, sondern als Kundenfrage, Lieferantenprüfung, Versicherungsanforderung oder Incident-Druck. Manche Unternehmen sind direkt im Anwendungsbereich, andere nicht. Aber fast alle, die in digitalen Lieferketten arbeiten, müssen zeigen können, dass ihre digitale Maschine verstanden, gepflegt und wiederherstellbar ist.

Was NIS2 praktisch verändert

NIS2 ist die Richtlinie (EU) 2022/2555. Sie ersetzt die erste NIS-Richtlinie, erweitert Cybersecurity-Erwartungen auf mehr Sektoren und verlangt von wesentlichen und wichtigen Einrichtungen angemessene technische, operative und organisatorische Risikomanagementmaßnahmen. Dieser Artikel ist keine Rechtsberatung und ersetzt keine Klassifizierung durch Rechtsberatung oder zuständige Stellen. Er betrachtet NIS2 aus der Perspektive des Betriebs: Welche Nachweise, Routinen und Zuständigkeiten müssen existieren, damit Readiness nicht nur Papier bleibt?

Die praktische Veränderung liegt in der Kombination aus Management-Verantwortung, Risikomanagementmaßnahmen, Lieferkettensicherheit, Incident-Meldelogik und kontinuierlicher Nachweisfähigkeit. Artikel 20 verpflichtet Leitungsorgane betroffener Einrichtungen, Cybersecurity-Risikomanagementmaßnahmen zu genehmigen, ihre Umsetzung zu überwachen und Schulungen zu folgen. Artikel 21 nennt unter anderem Risikoanalyse, Incident Handling, Business Continuity, Backup, Krisenmanagement, Lieferkettensicherheit, sichere Beschaffung, Wirksamkeitsprüfung, Cyberhygiene, Schulung, Zugriffskontrolle, Asset Management und gegebenenfalls MFA.

Für KMU ist besonders wichtig: Die Frage nach NIS2 endet nicht bei der direkten Anwendbarkeit. Die Europäische Kommission beschreibt NIS2 grundsätzlich für mittlere und große Einrichtungen in erfassten Sektoren, mit Ausnahmen und Sonderfällen. Gleichzeitig enthält Artikel 21 ausdrücklich Anforderungen an die Sicherheit direkter Lieferanten und Dienstleister. Das erzeugt kommerziellen Druck entlang der Lieferkette. Wer selbst nicht direkt registrierungspflichtig ist, kann trotzdem einen Fragebogen von einem größeren Kunden bekommen, der seine eigene Lieferkettenprüfung ernst nimmt.

Deutschland und Österreich zeigen außerdem, warum vorsichtige Formulierungen wichtig sind. Die Umsetzung ist inzwischen nationalrechtlich geprägt: Deutschland verweist auf das NIS2-Umsetzungsgesetz und BSI-Registrierungswege, Österreich hat mit BGBl. I Nr. 94/2025 das NISG 2026 veröffentlicht. Details zu Klassifizierung, Zuständigkeit und Fristen sollten Unternehmen mit Rechtsberatung oder der zuständigen Behörde prüfen. Das ändert aber wenig an der operativen Grundlage: Systeme, Eigentümer, Backups, Lieferanten, Logs, Runbooks und Reviews müssen in jedem Fall belastbar sein.

Warum eine Policy allein nicht reicht

Eine Policy ist nützlich. Sie sagt, was gelten soll. Aber NIS2-Readiness entsteht nicht dadurch, dass ein PDF im richtigen Ordner liegt. Sie entsteht, wenn die Firma zeigen kann, was tatsächlich passiert: Wer besitzt welches System? Wer hat Admin-Zugriff? Wann wurde der letzte Restore getestet? Welcher Lieferant verarbeitet kritische Daten? Welcher Alarm löst welche Handlung aus? Wer entscheidet bei einem Incident?

Der Unterschied klingt banal, wird aber im Alltag groß. Eine Policy kann festlegen, dass Zugänge regelmäßig geprüft werden. Ein Betriebsmodell zeigt, wann die letzte Prüfung stattfand, welche Konten entfernt wurden, welche Ausnahmen akzeptiert wurden und wer die Entscheidung getragen hat. Eine Policy kann Backups verlangen. Ein Betriebsmodell zeigt den Restore-Test, die Dauer, die Datenlücke, den verantwortlichen Eigentümer und den nächsten Verbesserungsschritt.

Viele KMU verwechseln Dokumente mit Nachweisfähigkeit. Das Risiko ist nicht, dass gar nichts existiert. Das Risiko ist, dass die Informationen verteilt sind: technische Details beim Dienstleister, Lieferantenverträge in der Buchhaltung, Zugangsentscheidungen in E-Mails, Backup-Status beim Hoster, Incident-Wissen im Kopf einer Person. Unter Druck muss daraus plötzlich ein belastbares Bild entstehen.

Die Kosten der Betriebsblindheit

Betriebsblindheit kostet nicht erst dann Geld, wenn eine Behörde anklopft. Sie kostet schon vorher Zeit, Vertrauen und Entscheidungskraft. Ein Kunde verzögert die Freigabe, weil der Lieferantenfragebogen unvollständig ist. Eine Cyberversicherung fragt nach Restore-Tests, aber niemand findet den Nachweis. Ein Incident beginnt, und das Team verbringt die ersten Stunden nicht mit Eindämmung, sondern mit der Suche nach Systemen, Zuständigkeiten und Kontaktwegen.

ENISA beschreibt in seinem NIS Investments Report 2025, dass Organisationen bei Patching, Business Continuity und Lieferkettenrisikomanagement besonders häufig Schwierigkeiten sehen. Für kleine und mittlere Unternehmen nennt ENISA außerdem den Bedarf an zugänglicher Anleitung, bezahlbaren Werkzeugen, Managed Services und Fähigkeitenaufbau. Das passt zur KMU-Realität: Das Problem ist selten fehlender Wille. Es ist der Mangel an einem leichten, betreibbaren System.

Der Schaden entsteht in mehreren Schichten. Erstens durch Verzögerung: Sales, Operations und Management warten auf Antworten, die eigentlich aus dem Betrieb kommen müssten. Zweitens durch Nacharbeit: Berater, Dienstleister und interne Teams rekonstruieren Fakten, die längst dokumentiert sein sollten. Drittens durch Incident-Risiko: Wenn die Firma nicht weiß, welche Systeme kritisch sind, welche Logs zählen und wer berichtet, wird auch die NIS2-Meldelogik schwer. Für signifikante Incidents sieht NIS2 eine frühe Warnung innerhalb von 24 Stunden, eine Meldung innerhalb von 72 Stunden und einen Abschlussbericht innerhalb eines Monats nach der Incident-Meldung vor. Ohne Runbook ist das kein Formularproblem, sondern ein Zeitproblem.

Viertens entsteht Management-Reibung. Die Geschäftsführung trägt Verantwortung, bekommt aber keine klare Betriebssicht. Dann werden Entscheidungen entweder zu defensiv oder zu spät getroffen: noch ein Tool kaufen, noch einen Audit-Workshop buchen, noch eine Excel-Liste bauen. Das kann kurzfristig beruhigen, schafft aber keine dauerhafte Nachweisfähigkeit.

Die NIS2-Operations-Map

Eine pragmatische NIS2-Readiness beginnt mit einer Operations-Map. Sie ist keine vollständige Rechtsklassifizierung und kein schweres GRC-System. Sie ist die Betriebslandkarte, die zeigt, welche digitalen Fähigkeiten existieren, wer sie besitzt, wie sie abgesichert werden und welche Nachweise im Alltag entstehen.

Was auf die Map gehört

Die Map sollte mit den Systemen beginnen, die den Betrieb wirklich tragen: Kundenkommunikation, CRM, Abrechnung, Identität, Hosting, Automatisierung, Backups, Monitoring und die Dienstleister dahinter. Jeder Eintrag braucht einen fachlichen Eigentümer, einen technischen Verantwortlichen, eine Kritikalität, eine Datenklasse und einen einfachen Nachweispfad. Wenn ein System nicht zugeordnet, wiederhergestellt, überwacht oder erklärt werden kann, gehört es weit nach oben auf die Lückenliste.

Hier wird auch Lieferkettendruck praktisch. Ein Dienstleister ist nicht nur eine Rechnungsadresse in der Buchhaltung. Er kann Daten hosten, Infrastruktur administrieren, Identität bereitstellen, Automatisierungen auslösen oder Recovery beeinflussen. Die Map sollte diese Abhängigkeit zeigen, bevor ein Kundenfragebogen oder Incident sie unter Zeitdruck erzwingt.

Die sechs Ebenen sind bewusst einfach:

Ebene	Leitfrage	Typischer Nachweis
Asset-Inventar	Welche Systeme, Datenflüsse und Automatisierungen sind kritisch?	Systemliste mit Eigentümer, Kritikalität und Datenklasse
Identität und Zugriff	Wer darf was, warum und bis wann?	Rollen, MFA-Status, Admin-Konten, Offboarding-Protokoll
Backup und Recovery	Was kann wiederhergestellt werden und wurde es getestet?	Restore-Test, RTO/RPO-Annahme, Backup-Ausnahme
Logging und Monitoring	Welche Signale zeigen Geschäfts- und Sicherheitsvorfälle?	Alert-Regel, Log-Aufbewahrung, Incident-Ticket
Lieferantenregister	Welche Dienstleister sind Teil des Risikos?	Lieferantenliste, Security Owner, Vertrags- oder Fragebogenstatus
Incident- und Runbook-Loop	Wer reagiert, kommuniziert, meldet und lernt?	Runbook, Kontaktweg, Review-Protokoll

Diese Landkarte übersetzt NIS2 von einer Liste an Maßnahmen in einen laufenden Betrieb. Sie verbindet Artikel-21-Themen wie Risikomanagement, Incident Handling, Business Continuity, Lieferkettensicherheit und Wirksamkeitsprüfung mit konkreten Arbeitsroutinen. Sie hilft auch, die ENISA-Pain-Points nicht isoliert zu behandeln: Patching ohne Asset-Liste bleibt Glück, Business Continuity ohne Restore-Test bleibt Hoffnung, Lieferkettensicherheit ohne Register bleibt Erinnerung.

Planfold ordnet diese Map entlang der Methode Plan -> Unfold -> Resonate ein. Plan bedeutet, Assets, Risiken, Lieferanten und Eigentümer zu kartieren. Unfold bedeutet, Workflows, Zugriffskontrollen, Backup-Tests, Monitoring und Automatisierung in die digitale Maschine einzubauen. Resonate bedeutet, Reviews, Logs, Restore-Tests und Incident-Learnings regelmäßig zurückzuführen, damit Readiness nicht nach dem ersten Workshop verfällt.

Wie aus der Map Nachweis entsteht

Nachweis entsteht, wenn jede Ebene regelmäßig ein verwertbares Ergebnis produziert. Das Inventar hat ein Review-Datum. Zugriffsprüfungen hinterlassen Entscheidungen. Restore-Tests dokumentieren Dauer, Umfang und Lücken. Monitoring-Alarme erzeugen Tickets, statt in Postfächern zu verschwinden. Lieferantenprüfungen haben Eigentümer und Status. Incident-Runbooks werden getestet, bevor sie gebraucht werden.

Dieser Rhythmus ist wichtig, weil NIS2-Readiness kein einmaliger Export ist. Sie ist ein wiederholbares Betriebsmuster. Eine kleine, gepflegte Map mit monatlichen Review-Notizen ist oft belastbarer als eine große Tabelle, die einmal für einen Audit-Workshop erstellt und danach vergessen wurde.

Warnsignale: Wo KMU zuerst nachsehen sollten

Wenn Sie wissen wollen, ob Ihr Unternehmen NIS2-ready wirkt, starten Sie nicht mit einer 120-Punkte-Checkliste. Starten Sie mit Warnsignalen, die im Alltag sichtbar sind. Sie zeigen, wo Betrieb und Nachweis auseinanderlaufen.

Ein erstes Warnsignal ist ein veraltetes Systeminventar. Wenn niemand in einer Stunde sagen kann, welche produktiven Systeme, SaaS-Tools, Automatisierungen und Dienstleister kritisch sind, wird jede weitere Maßnahme unscharf. Patching, Logging, Backup und Zugriffskontrolle hängen an dieser Grundlage.

Ein zweites Warnsignal sind geteilte oder unklare Admin-Zugänge. NIS2 nennt Zugriffskontrolle und Asset Management nicht als Dekoration. Wenn mehrere Personen mit demselben Konto arbeiten oder Dienstleisterkonten nicht sauber begrenzt sind, fehlt die Spur, die Sie unter Druck brauchen.

Ein drittes Warnsignal ist ein Backup, das zwar grün ist, aber nie wiederhergestellt wurde. Ein grüner Job ist kein Wiederherstellungsnachweis. Ein kleiner, dokumentierter Restore-Test ist oft wertvoller als ein großer Backup-Plan, den niemand ausprobiert hat.

Ein viertes Warnsignal ist Monitoring ohne Eigentümer. Dashboards, Logs und E-Mail-Warnungen helfen nur, wenn klar ist, wer reagiert, wann eskaliert wird und welcher Nachweis bleibt. Sonst entdeckt der Kunde den Fehler zuerst.

Ein fünftes Warnsignal ist ein Lieferantenregister, das nur kaufmännisch geführt wird. Für Lieferkettensicherheit reicht es nicht, die Rechnungsadresse zu kennen. Sie brauchen eine Sicht darauf, welcher Dienstleister welchen Prozess, welche Daten und welche Wiederherstellungsfähigkeit beeinflusst.

Technischer Deep-Dive: Vom Toolbestand zum beweisbaren Betrieb

Der technische Kern ist keine einzelne Plattform. Er ist ein Daten- und Verantwortungsmodell, das klein genug beginnt und trotzdem automatisierbar wird. Ein guter erster Stand kann aus einer zentralen Inventartabelle, einem Identitätsbezug, einem Backup-Testlog, Monitoring-Ereignissen, einem Runbook-Board und einem Lieferantenregister bestehen. Wichtig ist nicht, dass alles sofort perfekt ist. Wichtig ist, dass jede Zeile einen Eigentümer, einen Status und einen Nachweisweg hat.

Eine pragmatische Architektur sieht so aus:

NIS2-Readiness-Betriebsmodell
├── Inventar: System, Eigentümer, Kritikalität, Datenklasse, Lieferant
├── Identität: Rollen, Admins, MFA, Offboarding, Dienstkonten
├── Recovery: Backup-Quelle, Restore-Test, Ergebnis, nächste Prüfung
├── Monitoring: Signal, Schwelle, Empfänger, Runbook, Ticket
├── Lieferanten: Service, Abhängigkeit, Security Owner, Fragebogenstatus
└── Review: monatliche Lückenliste, Entscheidungen, Automatisierungskandidaten

Am Anfang kann dieses Modell bewusst leichtgewichtig sein. Ein strukturiertes Repository, ein Tabellenmodell, ein Ticketsystem und klare Review-Routinen sind oft besser als ein großes GRC-Tool, das niemand pflegt. Automatisierung kommt danach: n8n kann wiederkehrende Fragebogen-Checks, fehlende Eigentümerfelder, ablaufende Review-Termine oder Backup-Test-Erinnerungen auslösen. Ansible, Semaphore oder GitLab-Workflows können wiederholbare Infrastrukturarbeit nachweisbar machen. Zentrale Identität über LDAP, Active Directory oder Keycloak kann Rollen und Offboarding stabilisieren. Log- und Monitoring-Systeme können Signale direkt mit Runbooks und Tickets verbinden.

Der wichtigste Tradeoff: Starten Sie nicht mit maximaler Tool-Tiefe, wenn das Betriebsmodell noch unklar ist. Ein GRC-System ohne echte Assets und Eigentümer wird zur zweiten Ablage. Ein Monitoring-Tool ohne definierte Signale wird zu Lärm. Eine Automatisierung ohne Verantwortliche wird zum neuen Schattenprozess. Bauen Sie zuerst die Karte, dann die Schleifen.

Planfolds Sorglospaket ist in diesem Kontext kein Compliance-Versprechen. Planfold gibt keine Rechtsmeinung und zertifiziert keine NIS2-Konformität. Der Beitrag liegt in der Umsetzung: Infrastruktur standardisieren, Zugänge ordnen, Backups testen, Monitoring betreiben, Workflows automatisieren, Lieferanten- und Incident-Pfade dokumentieren und Reviews rhythmisch halten. Das ist die Arbeit, die aus einer Policy eine digitale Maschine macht.

Ein 30-Tage-Startplan für NIS2-Readiness

Readiness darf nicht als Jahresprojekt beginnen, sonst bleibt sie abstrakt. Ein 30-Tage-Startplan reicht nicht für vollständige NIS2-Klassifizierung oder alle Maßnahmen. Er reicht aber, um vom Bauchgefühl zu einer ersten Betriebsgrundlage zu kommen.

Woche 1: Exposure und Kundendruck kartieren. Sammeln Sie die wichtigsten Kunden, Sektoren, Lieferantenfragen, kritischen Systeme und externen Dienstleister. Notieren Sie, wo direkter NIS2-Bezug möglich ist und wo nur kommerzieller Druck besteht. Rechtsfragen bleiben bei Rechtsberatung oder zuständigen Stellen, aber die Betriebskarte kann sofort beginnen.

Woche 2: Eigentümer und Zugriffsgrenzen zuweisen. Für jedes kritische System braucht es einen Business Owner und einen technischen Verantwortlichen. Prüfen Sie Admin-Konten, MFA, Dienstleisterzugänge und Offboarding. Entscheiden Sie, welche geteilten Konten zuerst ersetzt werden.

Woche 3: Einen Restore und ein Incident-Runbook testen. Wählen Sie nicht den einfachsten Test, sondern einen wichtigen Prozess. Stellen Sie eine Datei, Datenbank oder Konfiguration wieder her. Schreiben Sie auf, wie lange es dauerte, was fehlte und wer entscheiden musste. Testen Sie anschließend ein kurzes Incident-Szenario: Wer wird informiert, welches Log zählt, welcher Kunde oder Lieferant wäre betroffen?

Woche 4: Nachweise dokumentieren und Automatisierungslücken wählen. Aus den ersten drei Wochen entsteht eine Lückenliste. Nicht alles muss sofort gelöst werden. Priorisieren Sie die Lücken, die Kundenfragen, Incident-Reaktion oder Wiederherstellung direkt beeinflussen. Danach lohnt sich Automatisierung: Erinnerungen, Checks, Review-Tickets, Lieferantenstatus, Backup-Testprotokolle und Monitoring-Routen.

Wie Planfold dabei hilft, ohne Compliance-Theater zu bauen

NIS2-Readiness braucht keine Angstkommunikation. Sie braucht ein Unternehmen, das seine digitale Maschine unter Druck erklären und betreiben kann. Genau dort liegt der praktische Unterschied zwischen Compliance-Theater und Betriebsfähigkeit.

Planfold kann helfen, diese Grundlage als Sorglospaket aufzubauen: Bestandsaufnahme, Infrastrukturstandardisierung, zentrale Identität, Backup- und Wiederherstellungstests, Monitoring, Statusalarme, Runbooks, Lieferanten- und Automatisierungsübersichten sowie monatliche Reviews. Der Anspruch ist nicht: „Wir machen Sie rechtlich compliant." Der Anspruch ist: „Wir bauen und betreiben die Nachweisgrundlage, die Ihre Kunden, Versicherer, Auditoren und Incident-Teams sehen wollen."

Wenn Ihr Unternehmen gerade den ersten Lieferantenfragebogen bekommt oder merkt, dass Cybersecurity nicht mehr nebenbei laufen kann, beginnen Sie mit der Map. Welche Systeme sind kritisch? Wer besitzt sie? Was kann wiederhergestellt werden? Welche Lieferanten hängen daran? Was passiert in den ersten 24 Stunden eines Incidents?

Für eine breitere Architekturperspektive lohnt sich außerdem unser Proof zur Infrastruktur-Modernisierung:

Das Ergebnis ist nicht ein Ordner voller Beruhigung. Das Ergebnis ist ein Betrieb, der Fragen beantworten kann, bevor ein Vorfall oder Kunde sie erzwingt.