.svg)
NIS2 Notfallplanung: Ein vollständiger Leitfaden für Geschäftskontinuität, die wirklich funktioniert
Wenn Ransomware am Freitag um 2 Uhr morgens die Systeme sperrt, rettet der Notfalplan entweder das Unternehmen oder entlarvt sich als reine Theorie. Einen Mittelweg gibt es nicht. Das Dokument, das irgendwo in SharePoint liegt und das niemand gelesen hat, ist in dem Moment wertlos, in dem es tatsächlich gebraucht wird.
Artikel 21 Absatz 2 Buchstabe c der NIS2 Richtlinie verlangt Geschäftskontinuität, etwa Backup Management und Notfallwiederherstellung sowie Krisenmanagement. Dabei handelt es sich nicht um Empfehlungen, sondern um gesetzliche Anforderungen mit möglichen Strafen von bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes für kitische Einrichtugen. Abgesehen vom regulatorischen Druck gibt es jedoch eine grundlegendere Wahrheit: Ein gut aufgebauter Notfallpan entscheidet darüber, ob eine Störung nur Stunden kostet oder die Existenz des Unternehmens bedroht.
Dieser Leitfaden führt Schritt für Schritt durch die Erstellung eines Notfallplans, der die Anforderungen der NIS2 erfüllt und unter realem Druck funktioniert. Keine theoretischen Frameworks. Keine reinen Checkbox Übungen. Sondern praxisnahe Schritte, mit denen bereits tausende europäische Unternehmen echte Resilienz aufgebaut haben.
Was NIS2 tatsächlich verlangt
Die NIS2 Richtlinie fordert keine vage Vorbereitung. Sie verlangt konkrete Fähigkeiten in drei klar definierten Bereichen, die im Notfall zusammenwirken müssen:
Backup Management stellt sicher, dass kritische Daten wiederhergestellt werden können, wenn Primärsysteme ausfallen oder gefährdet werden. Dazu gehört nicht nur das Bereitstellen von Backups, sondern auch deren Funktionsprüfung und der Schutz vor denselben Bedrohungen, denen auch Produktionssysteme ausgesetzt sind.
Notfallwiederherstellung beschreibt die technische Wiederherstellung von Systemen und Services. Wenn ein Datenbankserver ausfällt oder Ransomware die Infrastruktur verschlüsselt, sorgen DR Verfahren dafür, dass Systeme in einer definierten Reihenfolge mit geprüfter Funktionalität wieder online gehen.
Krisenmanagement koordiniert die menschliche Reaktion. Während technische Teams Systeme wiederherstellen, müssen Entscheidungen getroffen, Stakeholder informiert, die 24 Stunden Meldepflicht erfüllt und der Geschäftsbetrieb gegebenenfalls über alternative Wege aufrechterhalten werden.
Die Durchführungsverordnung EU 2024/2690 ergänzt konkrete Nachweisanforderungen: Erwartet werden dokumentierte Pläne, Business Impact Analysen, Backup Richtlinien inklusive Restorationsverfahren, Testnachweise sowie Krisenkommunikationsvorlagen. Regulatoren wollen nicht nur sehen, dass geplant wurde, sondern dass getestet, dokumentiert und auf Basis der Ergebnisse verbessert wurde.
Schritt 1: Business Impact Analysis, was wirklich zählt
Nicht alles kann gleich stark geschützt werden. Der Versuch, alles gleich zu behandeln, verschwendet Ressourcen und sorgt im Ernstfall für Verwirrung. Eine Business Impact Analysis (BIA) identifiziert, was wirklich kritisch ist, und definiert die Wiederherstellungsanforderungen, die alle weiteren Maßnahmen bestimmen.
Identifizierung kritischer Geschäftsfunktionen
Der Ausgangspunkt sind Business Aktivitäten, nicht IT Systeme. Die zentrale Frage lautet, was passiert, wenn diese Funktion eine Stunde, einen Tag oder eine Woche komplett ausfällt?
Ein mittelständisches Produktionsunternehmen könnte beispielsweise folgende kritische Funktionen haben: Kundenauftragsabwicklung, Produktionsplanung, Qualitätsmanagementsysteme und Finanztransaktionen. Dabei handelt es sich bewusst um Business Aktivitäten und nicht um Anwendungen. Das ERP System ist wichtig, weil es diese Funktionen unterstützt, nicht als Selbstzweck.
Für jede Funktion sollte dokumentiert werden, wer davon abhängig ist, welche regulatorischen Anforderungen bestehen und welche operativen Auswirkungen ein Ausfall hat. Der Ausfall eines Kundenportals bei einem SaaS Unternehmen wirkt sich sofort auf Umsatz und Reputation aus. Der Ausfall eines internen HR Systems ist unangenehm, aber über mehrere Tage hinweg verkraftbar.
Wiederherstellungsanforderungen definieren
Jede kritische Funktion benötigt zwei Kennzahlen, die von den Business Stakeholdern definiert werden und nicht ausschließlich von IT.
Das Recovery Time Objective (RTO) beantwortet die Frage, wie schnell eine Funktion wiederhergestellt sein muss, bevor ein nicht akzeptabler Schaden entsteht. Diese Zeit variiert stark. Ein Patientendokumentationssystem in einem Krankenhaus benötigt möglicherweise ein RTO von 15 Minuten. Ein Marketing Analytics Dashboard kann unter Umständen 72 Stunden tolerieren.
Das Recovery Point Objective (RPO) beschreibt, wie viel Datenverlust akzeptabel ist. Wenn tägliche Backups um Mitternacht erstellt werden und ein Vorfall um 23 Uhr eintritt, können fast 24 Stunden an Daten verloren gehen. Für Transaktionssysteme wäre das inakzeptabel. Für selten veränderte Konfigurationsdateien kann dies ausreichend sein.
In der Regel lassen sich RTO und RPO erst sinnvoll bestimmen, wenn die sogenannte Maximum Tolerable Period of Disruption (MTPD) definiert wurde.
Wenn bekannt ist, dass ein Unternehmen beispielsweise maximal drei Tage Downtime überlebt, muss das RTO kleiner oder gleich dieser MTPD sein. Andernfalls würde das Unternehmen den Ausfall nicht überstehen. Die MTPD wird daher typischerweise vor RTO und RPO bestimmt.
Ein praktisches Beispiel für eine Dokumentation sieht folgendermaßen aus:
Diese Werte steuern alle weiteren Entscheidungen. Wenn Kundentransaktionen ein RPO von 15 Minuten erfordern, sind nahezu Echtzeit-Replikation oder sehr häufige Backups notwendig. Wenn die Finanzberichterstattung ein RTO von 72 Stunden erlaubt, besteht deutlich mehr Flexibilität bei der Wiederherstellungsstrategie.
Abhängigkeiten abbilden
Jede Funktion ist abhängig von Systemen, Daten, Personen und Drittanbietern. Diese Abhängigkeiten müssen explizit dokumentiert werden, da eine einzige übersehene Abhängigkeit im Notfall die gesamte Wiederherstellung blockieren kann.
Bei Kundentransaktionen kann die Abhängigkeit wie folgt aussehen: Das Zahlungsgateway erfordert eine Internetverbindung und Anmeldedaten aus einem bestimmten Speicher. Das CRM benötigt Datenbankserver, Anwendungsserver und eine Integration mit dem E-Mail Service. Die Auftragsabwicklung erfordert Zugriff auf ERP und Lagerverwaltungssysteme. Jedes Glied dieser Kette muss innerhalb des definierten RTO wiederherstellbar sein.
Schritt 2: Aufbau eines Backup Management Systems
Backups stellen die letzte Verteidigungslinie dar. Wenn Ransomware Produktionssysteme verschlüsselt und Angreifer Online Backups löschen, entscheidet das Offline Backup darüber, ob eine Wiederherstellung möglich ist oder Lösegeld gezahlt wird.
Die 3-2-1-1-0 Backup Strategie
Moderne Backup Strategien erweitern die klassische 3-2-1 Regel:
Halte drei Kopien kritischer Daten bereit: Produktionsdaten plus zwei Backups. Verwende zwei verschiedene Medientypen, da ein Fehler, der dein primäres Backup-System beeinträchtigt, dein sekundäres System nicht gefährden sollte. Bewahre eine Kopie außerhalb des Standorts auf, geografisch getrennt von deinem primären Standort. Füge eine Kopie offline oder unveränderlich hinzu, die vollständig von jedem Netzwerk getrennt ist, auf das ein Angreifer zugreifen könnte. Überprüfe durch regelmäßige Wiederherstellungstests, dass keine Fehler auftreten.
Besonders die offline oder immutable Kopie ist entscheidend. Moderne Ransomware Angriffe sehen es gezielt auf Backup Systeme ab. Sie gefährden die Anmeldedaten für Backups, löschen Backup Kataloge und verschlüsseln Backups gemeinsam mit Produktionsdaten. Ein Backup, das physisch nicht erreichbar ist, stellt die entscheidende Absicherung dar.
Backup-Konfiguration nach Systemtyp
Unterschiedliche Systeme erfordern unterschiedliche Backup Ansätze, abhängig von ihren RPOAnforderungen.
Für Systeme, die einen RPO von nahezu Null erfordern, implementiere eine synchrone Replikation auf einen sekundären Standort oder eine kontinuierliche Datensicherung, die jede Änderung erfasst.
Systeme mit einem RPO von einer bis 24 Stunden können mit täglichen oder häufigeren geplanten Backups abgesichert werden. Wichtig ist die regelmäßige Überprüfung und ein Quartalsweise Wiederherstellungsprüfung. Die meisten Geschäftsanwendungen fallen in diese Kategorie.
Systeme mit mehrtägigem RPO können mit wöchentlichen Backups und längeren Aufbewahrungsfristen arbeiten. Typische Beispiele sind Dokumentationen, statische Konfigurationen oder Entwicklungsumgebungen.
Dokumentationsanforderungen für Backups
Für NIS2 Compliance muss die Backup Strategie umfassend dokumentiert sein. Dazu gehören Informationen darüber, welche Daten wie häufig gesichert werden, wo Backups physisch und logisch gespeichert sind, wie lange sie aufbewahrt werden, wer Zugriff auf Backup Systeme hat, wie Backups geschützt sind, etwa durch Verschlüsselung und Access Controls, sowie detaillierte Wiederhersellungsverfahren mit Schritt für Schritt Anleitungen.
Schritt 3: Verfahren zur Wiederherstellung nach Ausfällen
Backups ohne Wiederherstellungsverfahren sind lediglich Speicherkosten. Verfahren zur Wiederherstellung nach Ausfällen machen aus Backups eine tatsächliche Wiederherstellungsfähigkeit.
Wiederherstellungsverfahren entwickeln, die funktionieren
Für jedes kritische System müssen Wiederherstellungsverfahren dokumentiert sein, die so detailliert sind, dass auch eine nicht eingearbeitete Person sie ausführen könnte. Dies ist kein Misstrauen gegenüber dem Team, sondern eine realistische Annahme für einen Vorfall um 2 Uhr morgens, bei dem der Hauptverantwortliche möglicherweise nicht erreichbar ist.
Ein Wiederherstellungsverfahren für einen Datenbankserver kann folgende Elemente umfassen:
Vorab-Bewertung der Wiederherstellung: Überprüfe die Ursache des Ausfalls. Verifiziere die Backup Integrität, bevor du mit der Wiederherstellung beginnst. Stelle Netzwerkverbindung zum Wiederherstellungsziel sicher. Schätze die gesamte Wiederherstellungsdauer ab und informiere die Stakeholder.
Wiederherstellungsdurchführung: Beginne mit den detaillierten Schritten. Melde dich an der Sicherungsmanagementkonsole mit den im Password Vault hinterlegten Anmeldeinformationen an. Navigiere zum Backup Katalog und wähle die zuletzt verifizierten Backups aus. Starte die Wiederherstellung auf den vorgesehenen Wiederherstellungsserver. Dies dauert in der Regel zwei bis vier Stunden bei dieser Datenbankgröße. Überwache den Fortschritt und behebe auftretende Fehler.
Verifizierung: Führe nach der Wiederherstellung eine Datenbankintegritätsprüfung mit dem angegebenen Befehl durch. Überprüfe die Anwendungsverbindungen über die vorgesehene URL. Überprüfe die Gültigkeit der Daten, indem du den Zeitstempel der letzten Transaktion kontrollierst. Führe Testtransaktionen über die Anwendung aus.
Fertigstellung: Informiere die Technical Leads über die erfolgreiche Wiederherstellung. Aktualisiere das Ereignisprotokoll mit den Wiederherstellungsinformationen. Plane eine Nachbesprechung des Vorfalls innerhalb von 48 Stunden.
Beachte die notwendige Detailtiefe. Nicht einfach Backup wiederherstellen, sondern klar definieren, wo die Anmeldedaten hinterlegt sind, welche Befehle gebraucht werden, wie lange jeder Schritt dauert, und wie man Erfolg verifizieren kann.
Planung der Wiederherstellungssequenz
Systeme sind voneinander abhängig. Eine Webanwendung kann nicht vor der zugrunde liegenden Datenbank wiederhergestellt werden. Die Wiederherstellungssequenz muss entsprechend dokumentiert werden.
Typischerweise erfolgt die Wiederherstellung in dieser Reihenfolge: Zuerst die zentrale Infrastruktur wiederherstellen, einschließlich Netzwerk, DNS und Authentifizierung. Dann die Datenbanksysteme wiederherstellen. Schließlich muss der Anwendungsserver wiederhergestellt werden. Danach Integrationen und Zwischensoftware. Zum Schluss Benutzersysteme.
Innerhalb jeder Phase sollte die Reihenfolge einzelner Systeme klar definiert sein.
Alternative Betriebsformen
In manchen Fällen dauert eine vollständige Wiederherstellung länger als das Unternehmen tolerieren kann. Deshalb sollten Alternativen dokumentiert werden, um kritische Funktionen vorübergehend aufrechtzuerhalten.
Wenn das Auftragsverwaltungssystem 24 Stunden nicht verfügbar ist, können Bestellungen telefonisch aufgenommen und später manuell erfasst werden. Wenn E-Mail nicht verfügbar ist, kann ein alternativer Kommunikationskanal genutzt werden. Wenn ein gesamtes Rechenzentrum ausfällt, kann der Betrieb vorübergehend von einem zweiten Standort erfolgen.
Diese Alternativen sind nicht ideal, aber sie bieten Kontinuitätsoptionen, während die technische Wiederherstellung voranschreitet.
Schritt 4: Crisis Management Team und Verfahren
Technische Wiederherstellung allein reicht nicht aus. Die Gesamtreaktion muss koordiniert, Entscheidungen getroffen und Kommunikation gesteuert werden.
Definition des Krisenmanagementteams
Das Krisenmanagementteam benötigt klar definierte Rollen mit festgelegten Verantwortlichkeiten und Entscheidungskompetenzen.
Der Exekutive Sponsor trägt die Gesamtverantwortung für wesentliche Entscheidungen, etwa Ressourcenfreigaben, externe Kommunikation und geschäftliche Abwägungen. Diese Rolle kann ohne weitere Freigaben handeln.
Der Krisenkoordinator steuert die Gesamtreaktion, stellt Fortschritt in allen Teams sicher, identifiziert Blocker und pflegt die Zeitachse des Vorfalls. Diese Rolle führt keine technischen Arbeiten aus. Sie sorgen dafür, dass die technischen Arbeiten durchgeführt werden.
Der technischer Leiter koordiniert die IT Wiederherstellungsmaßnahmen, führt technische Teams und liefert Status Updates an den Krisenkoordinator. Er trifft technische Entscheidungen über den Wiederherstellungsansatz sowie -sequence.
Der Kommunikationsleiter verantwortet interne Kommunikation, Kundeninformationen, Medienanfragen und die Abstimmung mit Marketing und PR. Er sorgt dafür, dass einheitliche und zeitnahe Kommunikation im Fokus stehen.
Der Kontakt für Rechts- und Compliance-Fragen kümmert sich um regulatorische Meldepflichten inklusive der 24 Stunden NIS2 Meldung, bewertet rechtliche Risiken und berät zur Kommunikation.
Für jede Rolle muss eine primäre und eine vertretende Person benannt sein, inklusive Kontaktinformationen und Eskalationswegen.
Vorab definierte Entscheidungskompetenzen
Zeitverluste durch Freigabeprozesse sind bei einem Vorfall kritisch. Deshalb sollten Entscheidungsspielräume vorab festgelegt werden.
Der technische Leiter kann befugt sein, bis zu 50.000 € für die Notfallunterstützung durch Anbieter auszugeben, Auftragnehmer hinzuzuziehen und Änderungen an der Systemkonfiguration vorzunehmen. Der Kommunikationsleiter kann interne Updates und Standardbenachrichtigungen an Kunden versenden. Der Executive Sponsor muss möglicherweise externe Medienerklärungen, Ausgaben über dem Schwellenwert und Entscheidungen, die Kundenverträge betreffen, genehmigen.
Diese Kompetenzen müssen explizit dokumentiert sein, damit im Ernstfall keiner ins Zögern kommt.
Vorlagen für Krisenkommunikation
Wenn sich ein Vorfall ereignet, bleibt keine Zeit, Kommunikationen neu zu formulieren. Vorbereitete Vorlagen sind essenziell.
Für interne Mitarbeiterbenachrichtigungen: „Derzeit liegt ein technischer Zwischenfall vor, der [Systeme] betrifft. Unsere Teams arbeiten daran, den Dienst wiederherzustellen. [Von zu Hause aus arbeiten, ins Büro kommen, Anweisungen]. Updates folgen alle [Zeitraum]. Fragen bitte an [Kontakt].“
Zur Benachrichtigung der Kunden: „Wir sind uns eines Problems bewusst, das [Dienste] betrifft. Unsere IT-Teams arbeiten aktiv an einer Lösung. Wir rechnen mit [voraussichtliche Auswirkungen/Zeitrahmen]. Wir werden Sie auf dem Laufenden halten, sobald wir weitere Informationen haben. Wir entschuldigen uns für etwaige Unannehmlichkeiten.“
Für regulatorische Meldungen erfordert NIS2 eine Frühwarnung innerhalb von 24 Stunden an dein CSIRT oder die zuständige Behörde. Diese Vorlage sollte Angaben zur betroffenen Organisation, Beschreibung des Vorfalls, erste Einschätzung der Auswirkungen, Hinweise auf mögliche böswillige Ursachen sowie Kontaktinformationen enthalten.
Die vorherige rechtliche Prüfung dieser Vorlagen beschleunigt die Kommunikation erheblich.
Schritt 5: Testen des Notfallplans
Ein Notfallplan, der vorher nicht getestet wurde, bietet nur eine Annahme darüber, was passieren könnte keine nachgewiesene Fähigkeit. Tests decken Schwächen auf, schaffen Routine und zeigen, ob die Wiederherstellung tatsächlich funktioniert.
Arten von Tests
Simulationsübungen versammeln das Krisenmanagementteam, um Szenarien auf konzeptioneller Ebene durchzugehen. Systeme bleiben unberührt. Ziel ist die Überprüfung von Entscheidungswegen, Kommunikation und Rollenverständnis. Es wird empfohlen dies halbjährlich durchzuführen.
Ein Beispiel Szenario wäre: „Es ist 7 Uhr an einem Montag. Über Nacht wurden 70 Prozent der Server inklusive Domaingesteuerter Rechner durch Ransomware verschlüsselt. Die Forderung beträgt 500.000 Euro in Bitcoin. Der CISO ist im Urlaub ohne zuverlässige Erreichbarkeit per Telefon.”
Nun wird das Vorgehen besprochen: Wer wird zuerst benachrichtigt? Welche Entscheidungen müssen sofort getroffen werden? Wie werden die Mitarbeitenden verständigt, die nicht per E-Mail benachrichtigt werden können? Wann und wie werden Regulierungsbehörden informiert? Wie ist deine Verhandlungsposition in Bezug auf Lösegeld? Jede Frage zeigt, ob deine Vorgehensweisen echte Szenarien berücksichtigen.
Funktionstests prüfen einzelne technische Fähigkeiten. Können Backups tatsächlich wiederhergestellt werden und wie lange dauert es? Für kritische Systeme sollte dies mindestens quartalsweise überprüft werden.
Übungen im vollen Umfang simulieren reale Krisensituationen so realistisch wie möglich, ohne die Produktion zu beeinträchtigen. Aktiviere Reaktionsverfahren, nutze Kommunikationskanäle und arbeite die Wiederherstellungsschritte durch. Führe diese Übungen jährlich oder alle 18 Monate in vollem Umfang durch, mit kleineren Funktionstests über das ganze Jahr verteilt.
Testergebnisse dokumentieren
Für NIS2 Compliance müssen Tests dokumentiert sein. Dazu gehören Datum, Szenario, und Teilnehmende. Notiere was funktioniert und was nicht. Erfasse identifizierte Schwächen und die geplanten Abhilfemaßnahmen mit zugewiesenen Verantwortlichkeiten und Stichtagen. Dokumentiere wie die Abhilfe überprüft wurde.
Diese Dokumentation demonstriert den Behörden, das die Kapazitäten aufrechterhalten werden undmit der Zeit verbessert werden.
Verbesserung auf Basis der Ergebnisse
Jeder Test liefert Optimierungspotenzial. Vielleicht dauerte die Wiederherstellung 6 Stunden anstatt die geplanten 4 Stunden. Möglicherweise wurde das Backup für ein kritisches System zwei Wochen lang nicht erfolgreich ausgeführt. Vielleicht wusste der Krisenkoordinator nicht, wie er den exekutiven Sponsor erreichen kann.
Jede Erkenntnis benötigt einen Verantwortlichen und eine Deadline. Verfolge die Reperatur bis zum Abschluss. Der nächste Test muss zeigen, dass die Maßnahme wirksam war.
Alles zusammenführen: Deine NIS2-Notfallplan Dokumentation
Dein vollständiger Notfallplan sollte folgende Dokumente umfassen:
Business Impact Analysis (BIA) einschließlich Methodik, Identifikation kritischer Geschäftsprozesse, RTO und RPO je Funktion, Abhängigkeitsanalysen sowie Genehmigung durch das Management.
Business Continuity Plan (BCP) einschließlich Geltungsbereich und Zielsetzung, Rollen und Verantwortlichkeiten, Notfall- und Fortführungsmaßnahmen für jede kritische Funktion, Kommunikationsprozesse sowie alternative Betriebsabläufe.
Disaster Recovery Plan (DRP) einschließlich detaillierter, schrittweiser Verfahren zur Systemwiederherstellung, Wiederherstellungsreihenfolge, Ressourcenanforderungen, Kontaktinformationen von Dienstleistern und Supportpartnern sowie alternativer Wiederherstellungsszenarien.
Backup-Management-Dokumentation einschließlich Backup-Richtlinie, Backup-Zeitpläne und -Abdeckung, Aufbewahrungsfristen, Sicherheitsmaßnahmen sowie Wiederherstellungsverfahren.
Krisenmanagement-Dokumentation einschließlich Zusammensetzung des Krisenteams mit Kontaktdaten, Auslösekriterien, Reaktionsprozessen, Kommunikationsvorlagen und Eskalationswegen.
Test- und Übungsnachweise einschließlich Testplanung, Ergebnisse der einzelnen Tests, identifizierter Schwachstellen, umgesetzter Korrekturmaßnahmen sowie deren Verifikation.
Diese Dokumentation erfüllt einen doppelten Zweck: Sie dient als Leitfaden für das tatsächliche Vorgehen bei einem Vorfall und als Nachweis der Compliance gegenüber Aufsichtsbehörden.
Reality Check
Der Aufbau eines vollständigen Notfallplans erfordert Aufwand. Für ein mittelständisches Unternehmen mit wenig vorhandener Dokumentation sind zwei bis vier Monate realistisch, um eine solide Basis zu schaffen. Danach folgt kontinuierliche Pflege.
Die Alternative ist deutlich teurer. Wenn sich ein Vorfall ereignet und man nicht entsprechend vorbereitet ist, werden Entscheidungen unter Druck mit fehlenden Informationen getroffen, um die Systeme ohne dokumentierte Vorgehen wiederherzustellen, wobei unklare Abhängigkeiten durch das Ausprobieren erkannt werden. Die Kosten dessen sind verlängerte Betriebunterbrechung, regulatorische Strafen und Reputationsschäden, die höher sind als eine Investierung in eine gute Vorbereitung wäre.
NIS2 Compliance bedeutet nicht nur, Bußgelder zu vermeiden. Es geht darum, die Fähigkeit aufzubauen, Vorfälle zu überstehen, die häufiger und schwerwiegender werden.
Kertos unterstützt Unternehmen beim Aufbau und der Pflege funktionierender Notfallpläne. Die Plattform bietet integrierte BCP und DRP Dokumentation, Backup Verifikation, Test Management und die Nachweise, die Regulatoren erwarten. Bereits hunderte europäische Unternehmen konnten so Resilienz aufbauen, die Audits und reale Vorfälle besteht.
Erfahre mehr über die automatisierte NIS2 Bewertung.
