NIS2 in der Praxis

Einordnung — was NIS2 ist und wen es betrifft

Die NIS2-Richtlinie (Directive (EU) 2022/2555) ist die Nachfolgerin von NIS1 aus 2016. Sie weitet den Kreis der betroffenen Unternehmen drastisch aus, harmonisiert die Anforderungen auf europäischer Ebene und führt verbindliche Sanktionen ein — bis hin zur persönlichen Haftung der Geschäftsführung. Auf nationaler Ebene wird die Richtlinie in Deutschland über das NIS-2-Umsetzungs- und Cybersicherheits­stärkungsgesetz (NIS2UmsuCG) umgesetzt, das BSI-Gesetz und weitere Sektorgesetze entsprechend anpasst.

Drei Eigenschaften machen NIS2 zu einer Zäsur und nicht zu einer schlichten Fortschreibung. Erstens: der Anwendungsbereich verzehnfacht sich. Wo NIS1 nur „Betreiber wesentlicher Dienste" und einige digitale Diensteanbieter erfasste, fallen unter NIS2 deutlich mehr Sektoren und kleinere Unternehmen in den Geltungsbereich. Schätzungen sprechen für Deutschland von rund 30.000 betroffenen Einrichtungen — gegenüber wenigen Tausend unter NIS1. Zweitens: die Anforderungen sind konkreter. Artikel 21 listet zehn Mindestmaßnahmen, die jede betroffene Einrichtung umsetzen muss; dazu kommen klare Meldepflichten und Nachweispflichten. Drittens: die Geschäftsleitung haftet persönlich. Ein einfaches „delegieren und vergessen" ist nicht mehr möglich — die Geschäftsführung muss die Maßnahmen genehmigen, überwachen und im Ernstfall geradestehen.

Für die Tenvias-Zielbranchen ist die Lage eindeutig: Energie und Banken sind als wesentliche Einrichtungen direkt betroffen, Versicherer sind über die Aufnahme in Annex I ebenfalls erfasst, kommunale Versorger fallen über die digitale Infrastruktur, Trinkwasser, Abwasser und ÖPNV in den Geltungsbereich, und die öffentliche Verwaltung ist auf Bundes- und Landesebene explizit aufgenommen. Wer sich heute fragt, ob sein Unternehmen unter NIS2 fällt, kommt in den allermeisten Fällen zu „ja" — die offene Frage ist nur, ob als wesentliche oder wichtige Einrichtung.

Dieser Artikel zielt nicht auf die juristische Auslegung — dafür gibt es Anwaltskanzleien — sondern auf die technische Übersetzung. Was muss ein Software-Team konkret tun? Welche Maßnahmen lassen sich aus den abstrakten Artikeln ableiten? Wo überschneidet sich NIS2 mit bestehenden Standards (ISO 27001, BSI IT-Grundschutz, BAIT/VAIT), sodass bereits geleistete Arbeit anrechenbar ist? Und wie sieht ein pragmatischer Einstiegspfad aus, der nicht in Compliance-Theater erstickt?

Geltungsbereich — wer fällt unter NIS2

Die Richtlinie kennt zwei Kategorien: wesentliche Einrichtungen (Annex I) und wichtige Einrichtungen (Annex II). Die Unterscheidung ist nicht akademisch — die Sanktionsrahmen, die Aufsichtsintensität und einige Pflichtdetails unterscheiden sich.

Sektoren in Annex I (wesentliche Einrichtungen)

Energie (Strom, Gas, Fernwärme, Erdöl, Wasserstoff), Verkehr (Luft, Schiene, Wasser, Straße), Bankwesen, Finanzmarktinfrastrukturen, Gesundheitswesen, Trinkwasser, Abwasser, digitale Infrastruktur (DNS-Diensteanbieter, TLD-Registries, Cloud-Computing-Dienste, Datacenter-Anbieter, Content-Delivery-Networks, Vertrauensdiensteanbieter), Verwaltung von IKT-Diensten (Managed Service Provider, Managed Security Service Provider), öffentliche Verwaltung (Zentralregierungen und im Ermessen der Mitgliedstaaten regionale Verwaltungen) sowie Weltraum.

Sektoren in Annex II (wichtige Einrichtungen)

Post- und Kurierdienste, Abfallwirtschaft, Produktion und Handel mit Chemikalien, Lebensmittelproduktion und -handel, verarbeitende Industrie (Medizinprodukte, EDV-Hardware, Elektroprodukte, Maschinenbau, Fahrzeugbau und andere Verkehrsmittel), Anbieter digitaler Dienste (Online-Marktplätze, Online-Suchmaschinen, Plattformen sozialer Netzwerke) sowie Forschungseinrichtungen.

Schwellenwerte

In den meisten Sektoren ist NIS2 nur dann anwendbar, wenn eine der folgenden Größenschwellen überschritten wird:

• Mittlere Unternehmen (auf wichtige und wesentliche Einrichtungen anwendbar): ≥ 50 Beschäftigte oder Jahresumsatz / Bilanzsumme > 10 Mio. Euro.
• Große Unternehmen (typisch wesentliche Einrichtungen, wenn Annex I): ≥ 250 Beschäftigte oder Jahresumsatz > 50 Mio. Euro oder Bilanzsumme > 43 Mio. Euro.

Unabhängig von der Größe erfasst sind bestimmte Einrichtungen — qualifizierte Vertrauensdiensteanbieter, TLD-Registries, DNS-Diensteanbieter, die öffentliche Verwaltung auf Bundesebene und einige weitere Spezialfälle. „Wir sind zu klein" ist also für die meisten Branchen ein verlässliches Argument nur unterhalb von 50 Mitarbeitenden und 10 Mio. Euro Umsatz — in regulierten Sektoren auch dann nicht zwangsläufig.

Selbstidentifikation und Registrierung

Anders als unter NIS1 muss die betroffene Einrichtung sich selbst beim BSI registrieren — sie erhält keine individuelle Benachrichtigung. Die Frist nach Inkrafttreten ist eng (in Deutschland typischerweise drei Monate). Wer die Selbstidentifikation versäumt, riskiert einen Bußgeldtatbestand bereits unabhängig vom konkreten Sicherheitsniveau. Das Self-Assessment, ob das eigene Unternehmen unter NIS2 fällt und in welche Kategorie, gehört deshalb an den Anfang jeder Roadmap.

Artikel 21 — die zehn Mindestmaßnahmen

Artikel 21 der NIS2-Richtlinie listet zehn Mindestmaßnahmen, die jede betroffene Einrichtung umsetzen muss. Die Liste ist absichtlich abstrakt formuliert — sie soll branchen-, größen- und technologieunabhängig gelten. Wer sie ernsthaft umsetzt, hat damit ein vollständiges Information-Security-Management-System (ISMS) aufgebaut. Im Folgenden die zehn Punkte mit ihrer praktischen Auslegung.

(a) Risikoanalyse und Sicherheitskonzept

Eine fortlaufende Risikoanalyse — keine einmalige Übung, sondern ein Prozess. Sie identifiziert Assets, Bedrohungen, Schwachstellen und bewertet das Risiko. Das Ergebnis fließt in Sicherheitskonzepte ein, die formell beschlossen und regelmäßig überprüft werden. Technisch: ein Inventar aller Anwendungen und Systeme als Pflicht (Asset-Management), eine Bedrohungsmodellierung pro Anwendung (z. B. STRIDE), eine dokumentierte Risikobewertungs-Methodik.

(b) Bewältigung von Sicherheitsvorfällen

Ein dokumentierter Incident-Response-Prozess — von der Detektion über Eindämmung und Eradikation bis zur Wiederherstellung und Lessons-Learned. Technisch: ein Security Operations Center (SOC) oder ein externer MSSP, definierte Eskalationspfade, Runbooks für die häufigsten Vorfallstypen, regelmäßige Tabletop-Exercises.

(c) Aufrechterhaltung des Betriebs (BCM und Backup)

Business Continuity Management plus Backup- und Wiederherstellungs­strategien. Technisch: 3-2-1-Backup-Regel als Minimum (drei Kopien, zwei Medien, eine offsite/offline), getestete Restore-Prozesse mit nachweisbarem RTO/RPO, Disaster-Recovery-Konzept mit jährlichem Test.

(d) Sicherheit der Lieferkette

Bewertung und Steuerung von Risiken in der Lieferkette — also bei direkten Lieferanten, Dienstleistern und IT-Drittanbietern. Technisch: SBOM (Software Bill of Materials) für die eigenen Produkte und kritischen Drittanbieter-Komponenten, regelmäßiger CVE-Abgleich, Vertragsklauseln zu Sicherheitsanforderungen und Audit-Rechten, definierte Kriterien für Lieferantenauswahl.

(e) Sicherheit in Beschaffung, Entwicklung und Wartung

Ein sicherer Software Development Lifecycle (SDLC). Technisch: Security-by-Design als Pflicht in der Architektur, statische und dynamische Codeanalyse in der CI, Schwachstellenscans (SCA für Abhängigkeiten, DAST für Anwendungen — siehe unser Artikel zur Webanwendungs-Sicherheit mit OWASP ZAP), strukturiertes Patch-Management mit SLAs nach Schweregrad (Critical < 7 Tage, High < 30 Tage).

(f) Wirksamkeitsmessung

Konzepte zur Bewertung der Wirksamkeit der getroffenen Cybersicherheits-Maßnahmen. Technisch: KPIs für Sicherheits-Reife (Mean Time to Detect, Mean Time to Respond, Patch-Compliance-Quote, Phishing-Klickrate), regelmäßige Audits, externe Penetrationstests im jährlichen Rhythmus.

(g) Cyberhygiene und Schulung

Grundlegende Cyberhygiene-Praktiken plus Schulungen für alle Beschäftigten, die Geschäftsleitung eingeschlossen. Technisch: verbindliche jährliche Awareness-Schulung, Phishing-Simulationen, Onboarding-Module für neue Mitarbeitende, dedizierte Schulung der Geschäftsleitung zu IT-Risiken.

(h) Kryptographie und Verschlüsselung

Konzepte und Verfahren zum Einsatz von Kryptographie. Technisch: Transport-Verschlüsselung (TLS 1.2+) durchgängig, Datenverschlüsselung in Ruhe (Festplatten- und Datenbank-Verschlüsselung), Key-Management mit klaren Rotations-Zyklen, ein Verzeichnis verwendeter kryptographischer Algorithmen mit Migrations­pfad weg von veralteten Verfahren (RC4, MD5, SHA-1, TLS 1.0/1.1).

(i) Personalsicherheit, Zugriffskontrolle, Asset-Management

Konzepte für den sicheren Personalwechsel, Zugriffsrechte nach Need-to-Know, durchgängiges Asset-Management. Technisch: Joiner-Mover-Leaver-Prozesse mit automatischer De-Provisionierung, rollenbasiertes Zugriffsmanagement (RBAC), regelmäßige Rezertifizierung von Berechtigungen, ein zentrales Identity-and-Access-Management wie Keycloak, das Berechtigungen über Anwendungs­grenzen hinweg konsistent verwaltet.

(j) Multi-Faktor-Authentifizierung und gesicherte Kommunikation

MFA, kontinuierliche Authentifizierung, gesicherte Sprach-, Video- und Text-Kommunikation für die interne Notfallkommunikation. Technisch: MFA für alle administrativen Zugänge als unverhandelbare Mindestanforderung (idealerweise Phishing-resistent über WebAuthn/FIDO2), MFA für alle Mitarbeitenden-Zugänge zur Geschäftsanwendung, abgesicherter Out-of-Band-Kanal für die Krisenkommunikation (z. B. dediziertes Messenger-Tool mit eigener Authentifizierung, das auch bei kompromittierter Hauptinfrastruktur funktioniert).

Meldepflichten — der 24/72/1-Workflow

Die Meldepflicht ist die Stelle, an der NIS2 für viele Unternehmen am direktesten spürbar wird. Bei einem erheblichen Sicherheitsvorfall greift ein klar getakteter Workflow mit drei Pflichtterminen.

Was als „erheblicher Vorfall" gilt

Ein Vorfall ist meldepflichtig, sobald er erheblich ist — das heißt entweder schwerwiegende betriebliche Störungen verursacht oder verursachen kann, oder andere natürliche oder juristische Personen durch erheblichen materiellen oder immateriellen Schaden beeinträchtigt. Der Schwellenwert ist bewusst weit gefasst; im Zweifel ist zu melden. Ein Ransomware-Angriff auf produktive Systeme, ein bestätigter Datenabfluss mit Bezug auf Kunden- oder Mitarbeiterdaten, eine Kompromittierung eines administrativen Zugangs zu kritischer Infrastruktur: alles erheblich.

Die ZAC und das Single-Reporting-Point-Prinzip

Die Meldung erfolgt nicht direkt an die jeweilige Sektor-Aufsicht, sondern an die Zentrale Anlaufstelle für Cybersicherheit (ZAC) des BSI. Diese leitet die Meldung an die relevanten Behörden weiter — bei Bedarf auch über Landesgrenzen hinweg an die EU-CSIRT-Netze. Das Single-Reporting-Point-Prinzip soll vermeiden, dass ein meldendes Unternehmen während der ersten Stunden eines Vorfalls mehrere Behörden parallel bedienen muss.

Mapping auf ISO 27001 und BSI IT-Grundschutz

Wer ein etabliertes ISMS auf Basis von ISO 27001 oder dem BSI IT-Grundschutz betreibt, hat den Großteil der NIS2-Maßnahmen bereits abgedeckt — das ist die gute Nachricht. Die schlechte: NIS2 hat eigene Schwerpunkte, die ein ISO-zertifiziertes ISMS nicht zwangsläufig adressiert.

Hohe Überschneidung mit ISO 27001:2022

Die ISO-27001-Annex-A-Kontrollen, in der 2022er-Fassung von 114 auf 93 reduziert und neu strukturiert, decken den Großteil der NIS2-Anforderungen direkt ab. Risikomanagement, Zugriffskontrolle, Kryptographie, Personalsicherheit, Lieferanten­beziehungen, Vorfallsbewältigung, Business Continuity — alles ist sowohl Pflicht unter ISO 27001 als auch unter NIS2 Artikel 21. Wer eine ISO-27001-Zertifizierung hält, kann diese als Basis seines NIS2-Nachweises nutzen.

BSI IT-Grundschutz

Das BSI IT-Grundschutz-Kompendium ist die deutsche Schwester. Es ist konkreter (knapp 100 Bausteine mit ausformulierten Maßnahmen) und für die öffentliche Verwaltung historisch der Standardweg. Für NIS2 ist Grundschutz die natürlichste Andockstelle — das BSI als Aufsichtsbehörde nimmt diese Methodik als Nachweis selbstverständlich an.

Wo NIS2 über die Standards hinausgeht

Drei Punkte sind in ISO 27001 schwächer ausgeprägt: (1) die Meldepflichten mit ihren engen Zeitfenstern — ein Audit-fähiger ISMS-Prozess heißt nicht zwangsläufig „in 24 Stunden eine BSI-Meldung formuliert"; (2) die persönliche Haftung der Geschäftsführung — ISO verlangt Management-Commitment, aber keine persönliche Strafbarkeit; (3) die Lieferketten-Anforderungen — Annex A.5.20 (Information Security in Supplier Relationships) ist allgemeiner gefasst als der NIS2-Artikel 21(d). Wer ISO-27001-zertifiziert ist, hat ungefähr 80 Prozent der NIS2-Maßnahmen bereits dokumentiert — die restlichen 20 Prozent sind aber gerade die, die im Ernstfall am meisten Schmerzen verursachen.

Lieferkette und Drittanbieter

Eine der einschneidendsten Neuerungen unter NIS2 ist die explizite Verantwortung für die eigene Lieferkette. Wer als wesentliche oder wichtige Einrichtung gilt, muss seine direkten Lieferanten — Cloud-Anbieter, SaaS-Dienste, MSPs, IT-Berater, sicherheitsrelevante Softwarezulieferer — auf ihre Sicherheits­praxis prüfen, die Ergebnisse dokumentieren und regelmäßig nachhalten.

Praktisch heißt das: ein Lieferantenregister mit Sicherheits-Klassifikation, ein Onboarding-Fragebogen, der die NIS2-relevanten Maßnahmen abprüft (üblich sind Anlehnungen an die VdS-3473- oder TISAX-Frageböge), Vertragsklauseln zu Sicherheitsanforderungen und Meldepflichten gegenüber dem eigenen Unternehmen, gegebenenfalls Audit-Rechte. Für IT-relevante Lieferanten kommt ein zusätzliches Element dazu: eine Software Bill of Materials (SBOM) in einem maschinenlesbaren Format (CycloneDX oder SPDX), die transparent macht, welche Open-Source- und Drittanbieter-Komponenten in einem zugelieferten Produkt stecken. Ohne SBOM ist ein CVE-Abgleich nach einem öffentlichen Bekanntwerden einer Schwachstelle (Log4Shell als Lehrstück) praktisch unmöglich.

Tenvias selbst ist als Software-Zulieferer in regulierten Branchen unmittelbar von dieser Dynamik betroffen. Unsere Kunden fordern bereits heute SBOMs für die ausgelieferten Komponenten ein und verlangen Auskünfte zu Patch-Zyklen, Code-Review-Prozessen und Incident-Notification-Pflichten. Wer als IT-Dienstleister diese Vertragsanforderungen nicht erfüllt, fliegt aus Ausschreibungen — unabhängig davon, ob das eigene Unternehmen selbst unter NIS2 fällt oder nicht.

Konkrete Tech-Aufgaben für Software-Teams

Aus den abstrakten Artikeln ergibt sich eine handfeste Aufgabenliste, die ein Software-Team auf einer normalen Roadmap einplanen kann. Die folgende Aufstellung ist nicht erschöpfend, aber sie deckt die 80 Prozent ab, die in den meisten Audits auftauchen werden.

Asset-Inventar

Ein zentrales Verzeichnis aller produktiven Anwendungen, Datenbanken, externen Schnittstellen, Container-Images und kritischen Cloud-Ressourcen. Wer keine vollständige Liste hat, kann auch keine Risiken zuordnen. Tools: ein einfaches Git-versioniertes YAML-Inventar reicht für kleine Setups; in größeren Umgebungen ist eine CMDB oder ein Tool wie ServiceNow oder Snipe-IT angemessen.

Identity- und Zugriffsmanagement

Ein zentrales IAM für Mitarbeitenden- und Service-Identitäten. Keycloak ist hier unsere Standard­empfehlung für Setups, die self-hosted bleiben sollen — dazu kommt im nächsten Artikel dieser Reihe ein eigener Beitrag. MFA für administrative Zugänge ist nicht verhandelbar; idealerweise Phishing-resistent (WebAuthn, FIDO2, Yubikeys).

Logging mit Korrelation

Strukturierte Logs mit durchgängiger Trace-ID, zentral aggregiert (ELK, Loki, Splunk), mit ausreichender Retention für forensische Auswertungen (mindestens 90 Tage, in regulierten Sektoren oft länger). Details haben wir in unserem Artikel zu Logging im Enterprise-Umfeld beschrieben.

Vulnerability- und Patch-Management

SCA (Software Composition Analysis) auf jede Pull-Request mit Block bei Critical-Findings. DAST gegen die wichtigsten Anwendungen wöchentlich. Patch-SLAs: Critical innerhalb 7 Tagen, High innerhalb 30 Tagen, dokumentierte Ausnahmen mit Risikofreigabe.

Secret-Management

Keine Secrets im Git, nirgendwo. Verwaltung über Vault, AWS Secrets Manager, Azure Key Vault oder eine vergleichbare Lösung. Rotation kritischer Credentials mindestens jährlich, idealerweise automatisiert.

Backup mit Test-Restore

3-2-1-Regel als Mindestmaß. Quartalsweise dokumentierte Restore-Tests — ein Backup, das nie wiederhergestellt wurde, ist konzeptionell kein Backup. Offline- oder Air-Gapped-Kopie als Schutz gegen Ransomware.

Incident-Response-Runbook

Ein schriftlich dokumentierter Plan für die häufigsten Vorfallstypen — Ransomware, Datenabfluss, kompromittierter Admin-Zugang, DDoS. Eskalations­ketten, Telefon­liste, vordefinierte Kommunikations­schablonen. Jährliche Tabletop-Übungen mit der Geschäftsleitung.

Monitoring und Detection

Ein durchgängiges Monitoring der Infrastruktur (siehe unsere Artikel zu Gatus und Zabbix + Grafana), eine SIEM-Anbindung für die sicherheits­relevanten Events (Wazuh, Splunk Enterprise Security, oder ein gemanagter SOC-Dienst). Detection-Regeln dokumentiert und versioniert.

SBOM-Pipeline

Erzeugung einer CycloneDX- oder SPDX-SBOM bei jedem Build. Speicherung als Build-Artefakt. Automatisierter Abgleich gegen OSV und NVD in der CI. Bei Treffern: definierter Prozess für Bewertung und Reaktion.

Schulung Geschäftsleitung

Eine Pflicht unter NIS2, die in vielen Organisationen unter den Tisch fällt. Die Geschäftsleitung muss die Maßnahmen genehmigen, ihre Wirksamkeit überwachen und im Vorfall handlungsfähig sein. Eine jährliche zwei- bis dreistündige Schulung mit Fokus auf Entscheidungs­situationen (was tun, wenn der CISO die Geschäftsführung um 23 Uhr anruft?) gehört verbindlich auf den Kalender.

Sanktionen und Geschäftsführungs-Haftung

NIS2 ist kein zahnloser Tiger. Der Sanktionsrahmen orientiert sich an der DSGVO und ist für die meisten Unternehmen erstmals in dieser Höhe für Cybersicherheits-Pflichten anwendbar.

Für wesentliche Einrichtungen sieht die Richtlinie Geldbußen von bis zu 10 Mio. Euro oder 2 Prozent des weltweiten Jahres­umsatzes vor — je nachdem, welcher Betrag höher ist. Für wichtige Einrichtungen liegt der Rahmen bei bis zu 7 Mio. Euro oder 1,4 Prozent des Umsatzes. Diese Höhe ist nicht nur theoretisch; die EU-Mitgliedstaaten sind verpflichtet, „wirksame, verhältnismäßige und abschreckende" Sanktionen tatsächlich zu verhängen.

Eine deutliche Verschärfung gegenüber NIS1 ist die persönliche Haftung der Geschäftsführung. Wer als Geschäftsführerin oder Vorstand die Cybersicherheits­maßnahmen nicht ordnungsgemäß genehmigt, überwacht und umgesetzt hat, kann persönlich in Anspruch genommen werden — bis hin zu einem zeitlich befristeten Berufs­verbot in besonders schweren Fällen. Die Botschaft des Gesetzgebers ist eindeutig: Cybersicherheit ist Chefsache, nicht delegierbar.

Aus dieser Haftungslogik folgt eine praktische Konsequenz: die Schulungspflicht für die Geschäftsführung, die Artikel 20(2) explizit vorschreibt. Eine Geschäftsleitung, die im Audit nicht nachweisen kann, dass sie selbst in IT-Risiken geschult wurde, hat ein Problem — unabhängig davon, wie gut das technische Team aufgestellt ist.

Pragmatischer Start — was am Montag passieren sollte

Der häufigste Fehler bei NIS2-Programmen ist, dass sie monatelang in Konzeptphasen verbringen, bevor irgendetwas Konkretes passiert. Wir empfehlen einen pragmatischen Stufenplan, der binnen weniger Wochen sichtbare Ergebnisse liefert.

Phase 1: Bestandsaufnahme (Wochen 1–4)

Self-Assessment der NIS2-Betroffenheit (Annex I oder II, wesentlich oder wichtig?). Registrierung beim BSI, sobald die nationale Frist es verlangt. Ein Asset-Inventar wird angelegt oder aus bestehenden CMDBs extrahiert. Eine Gap-Analyse gegen die zehn Artikel-21-Maßnahmen wird durchgeführt — typischerweise zeigt sich, dass etwa die Hälfte der Punkte bereits in irgendeiner Form abgedeckt ist.

Phase 2: Quick Wins (Wochen 5–12)

Die offensichtlichsten Lücken werden geschlossen: MFA flächendeckend, Passwort-Policies, Backup-Restore-Test, Logging mit angemessener Retention, Incident-Response-Runbook in einer ersten Version, Tabletop-Übung. Diese Maßnahmen sind technisch nicht schwierig, schaffen aber rasch ein höheres Sicherheitsniveau und liefern Nachweise für den ersten Audit.

Phase 3: Strukturelle Maßnahmen (Monate 4–9)

SBOM-Pipeline, SIEM-Anbindung, Lieferanten­fragebogen mit Rückläufen, formales Risikomanagement, IT-Sicherheits­konzept mit Vorstandsbeschluss, Schulung der Geschäftsleitung, externe Pentests. Diese Phase entscheidet darüber, ob das Unternehmen vor einer Aufsichtsbehörde wirklich bestehen kann oder nur eine oberflächliche Compliance-Fassade aufgebaut hat.

Phase 4: Dauerbetrieb (ab Monat 10)

Das ISMS wird zur Routine. Quartals-Reviews, jährliche Wirksamkeits­bewertung, kontinuierliche Verbesserung, fortlaufende Anpassung an neue Bedrohungs­lagen. NIS2 ist keine einmalige Übung — die laufende Pflege ist der eigentliche Aufwand.

In den meisten Setups, mit denen wir arbeiten, ist die größte Herausforderung nicht die Technik. Die Bausteine — IAM, Logging, Monitoring, MFA, Backups — sind im Markt verfügbar und auch in regulierten Branchen seit Jahren etabliert. Die Herausforderung ist die Konsequenz der Umsetzung: kein „später", keine Ausnahmen für Lieblings­anwendungen, keine Geschäfts­bereiche, die sich der Disziplin entziehen. NIS2 zwingt diese Konsequenz juristisch — und macht Cybersicherheit damit zu dem, was sie hätte schon immer sein müssen: ein Engineering-Thema mit voller Aufmerksamkeit der Geschäftsleitung.