.svg)
Wenn Ransomware am Freitag um 2 Uhr morgens die Systeme sperrt, rettet der Notfallplan 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 kritische Einrichtungen. Abgesehen vom regulatorischen Druck gibt es jedoch eine grundlegendere Wahrheit: Ein gut aufgebauter Notfallplan entscheidet darüber, ob eine Störung nur Stunden kostet oder die Existenz des Unternehmens bedroht.
Dieser Leitfaden führt Sie 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 sollten Sie dokumentieren, 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 der 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:
Halten Sie drei Kopien kritischer Daten bereit: Produktionsdaten plus zwei Backups. Verwenden Sie zwei verschiedene Medientypen, da ein Fehler, der Ihr primäres Backup-System beeinträchtigt, Ihr sekundäres System nicht gefährden sollte. Bewahren Sie eine Kopie außerhalb des Standorts auf, geografisch getrennt von Ihrem primären Standort. Fügen Sie eine Kopie offline oder unveränderlich hinzu, die vollständig von jedem Netzwerk getrennt ist, auf das ein Angreifer zugreifen könnte. Überprüfen Sie 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 RPO-Anforderungen.
Für Systeme, die einen RPO von nahezu Null erfordern, implementieren Sie 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 eine 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 die 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 Wiederherstellungsverfahren 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 die hauptverantwortliche Person möglicherweise nicht erreichbar ist.
Ein Wiederherstellungsverfahren für einen Datenbankserver kann folgende Elemente umfassen:
Vorab-Bewertung der Wiederherstellung: Überprüfen Sie die Ursache des Ausfalls. Verifizieren Sie die Backup-Integrität, bevor Sie mit der Wiederherstellung beginnen. Stellen Sie die Netzwerkverbindung zum Wiederherstellungsziel sicher. Schätzen Sie die gesamte Wiederherstellungsdauer ab und informieren Sie die Stakeholder.
Wiederherstellungsdurchführung: Beginnen Sie mit den detaillierten Schritten. Melden Sie sich an der Sicherungsmanagementkonsole mit den im Password Vault hinterlegten Anmeldeinformationen an. Navigieren Sie zum Backup-Katalog und wählen Sie die zuletzt verifizierten Backups aus. Starten Sie die Wiederherstellung auf den vorgesehenen Wiederherstellungsserver. Dies dauert in der Regel zwei bis vier Stunden bei dieser Datenbankgröße. Überwachen Sie den Fortschritt und beheben Sie auftretende Fehler.
Verifizierung: Führen Sie nach der Wiederherstellung eine Datenbankintegritätsprüfung mit dem angegebenen Befehl durch. Überprüfen Sie die Anwendungsverbindungen über die vorgesehene URL. Überprüfen Sie die Gültigkeit der Daten, indem Sie den Zeitstempel der letzten Transaktion kontrollieren. Führen Sie Testtransaktionen über die Anwendung aus.
Fertigstellung: Informieren Sie die Technical Leads über die erfolgreiche Wiederherstellung. Aktualisieren Sie das Ereignisprotokoll mit den Wiederherstellungsinformationen. Planen Sie eine Nachbesprechung des Vorfalls innerhalb von 48 Stunden.
Beachten Sie 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 sich der Erfolg verifizieren lässt.
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. Anschließend die Anwendungsserver. Danach Integrationen und Zwischensoftware. Zum Schluss die 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 Sie Alternativen dokumentieren, 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 müssen getroffen und die Kommunikation muss 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 den Fortschritt in allen Teams sicher, identifiziert Blocker und pflegt die Zeitachse des Vorfalls. Diese Rolle führt keine technischen Arbeiten aus, sondern sorgt dafür, dass die technischen Arbeiten durchgeführt werden.
Der technische Leiter koordiniert die IT-Wiederherstellungsmaßnahmen, führt die technischen Teams und liefert Status-Updates an den Krisenkoordinator. Er trifft technische Entscheidungen über den Wiederherstellungsansatz sowie die -sequenz.
Der Kommunikationsleiter verantwortet die interne Kommunikation, Kundeninformationen, Medienanfragen und die Abstimmung mit Marketing und PR. Er sorgt dafür, dass eine einheitliche und zeitnahe Kommunikation im Fokus steht.
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 Exekutive 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 niemand 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 halten Sie auf dem Laufenden, 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 Ihr CSIRT oder die zuständige Behörde. Diese Vorlage sollte Angaben zur betroffenen Organisation, eine Beschreibung des Vorfalls, eine 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 Beispielszenario wäre: „Es ist 7 Uhr an einem Montag. Über Nacht wurden 70 Prozent der Server inklusive Domänencontroller 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 Ihre Verhandlungsposition in Bezug auf Lösegeld? Jede Frage zeigt, ob Ihre 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. Aktivieren Sie Reaktionsverfahren, nutzen Sie Kommunikationskanäle und arbeiten Sie die Wiederherstellungsschritte durch. Führen Sie diese Übungen jährlich oder alle 18 Monate in vollem Umfang durch, mit kleineren Funktionstests über das ganze Jahr verteilt.
Testergebnisse dokumentieren
Für die NIS2-Compliance müssen Tests dokumentiert sein. Dazu gehören Datum, Szenario und Teilnehmende. Notieren Sie, was funktioniert und was nicht. Erfassen Sie identifizierte Schwächen und die geplanten Abhilfemaßnahmen mit zugewiesenen Verantwortlichkeiten und Stichtagen. Dokumentieren Sie, wie die Abhilfe überprüft wurde.
Diese Dokumentation demonstriert den Behörden, dass die Kapazitäten aufrechterhalten und mit der Zeit verbessert werden.
Verbesserung auf Basis der Ergebnisse
Jeder Test liefert Optimierungspotenzial. Vielleicht dauerte die Wiederherstellung 6 Stunden statt der 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 eine verantwortliche Person und eine Deadline. Verfolgen Sie die Behebung bis zum Abschluss. Der nächste Test muss zeigen, dass die Maßnahme wirksam war.
Alles zusammenführen: Ihre NIS2-Notfallplan-Dokumentation
Ihr 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, Kommunikationsprozessen sowie alternativen Betriebsabläufen.
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änen 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, Ergebnissen 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 Sie nicht entsprechend vorbereitet sind, werden Entscheidungen unter Druck und mit fehlenden Informationen getroffen, Systeme ohne dokumentiertes Vorgehen wiederhergestellt und unklare Abhängigkeiten erst durch Ausprobieren erkannt. Die Kosten daraus, verlängerte Betriebsunterbrechung, regulatorische Strafen und Reputationsschäden, sind höher als eine Investition in eine gute Vorbereitung.
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.
Erfahren Sie mehr über die automatisierte NIS2-Bewertung.
Neu bei NIS2? Den vollständigen Überblick gibt unser Leitfaden zur NIS2-Richtlinie.
