NIS2 Maßnahme 3 — Business Continuity und Krisenmanagement
Die NIS2-Maßnahme 3 gemäß Art. 21(2)(c) verpflichtet betroffene Unternehmen, Business Continuity Management einschließlich Backup-Management, Disaster Recovery und Krisenmanagement zu implementieren. Für NIS2 Business Continuity bedeutet das praktisch: kritische Prozesse per Business Impact Analysis bewerten, RPO- und RTO-Ziele festlegen, die 3-2-1-Backup-Regel mit unveränderbaren Sicherungen umsetzen und Wiederanlauf- sowie Krisenpläne regelmäßig testen.
Letzte Aktualisierung: 20. März 2026
Die kurze Antwort lautet: Ja, NIS2 verlangt einen belastbaren Plan für die Aufrechterhaltung des Betriebs nach Störungen und Cybervorfällen. Art. 21 Abs. 2 Buchst. c der Richtlinie (EU) 2022/2555 und der deutsche Umsetzungsrahmen über § 30 Abs. 2 Nr. 3 BSIG-E verlangen nicht nur Datensicherungen, sondern eine nachvollziehbare Kombination aus BIA, Wiederherstellungszielen, Redundanz, Krisenorganisation und dokumentierten Tests. Wenn Sie den Gesamtzusammenhang der ersten beiden NIS2-Maßnahmen einordnen möchten, lesen Sie ergänzend NIS2 Maßnahme 1 zur Risikoanalyse, NIS2 Maßnahme 2 zum Incident Handling und die NIS2-Checkliste für Unternehmen.
Business Continuity ist unter NIS2 kein optionales Reifegradthema, sondern ein prüfungsrelevanter Kernbestandteil des Cyber-Risikomanagements. Die Aufsicht wird im Ernstfall nicht nur fragen, ob ein Backup vorhanden war, sondern ob Ihr Unternehmen den Ausfall kritischer Prozesse vorab bewertet, Wiederanlaufzeiten definiert, Zuständigkeiten festgelegt und die Wiederherstellung realistisch geübt hat. Genau deshalb überschneidet sich Maßnahme 3 unmittelbar mit Haftungsfragen der Leitungsebene, wie sie auch im Beitrag zur NIS2-Haftung für Geschäftsführer erläutert werden.
Was verlangt Art. 21(2)(c) NIS2 zur Business Continuity?
Art. 21 Abs. 2 Buchst. c NIS2 verlangt drei Dinge gleichzeitig: die Aufrechterhaltung des Betriebs durch Business-Continuity- und Disaster-Recovery-Pläne, die Vorhaltung von Backup-Kopien und ausreichender Redundanz sowie einen Prozess für Krisenmanagement. Die Norm ist deshalb breiter als eine reine Backup-Pflicht. Sie adressiert die organisatorische Fähigkeit, kritische Dienstleistungen nach Störungen weiterzuführen oder in vertretbarer Zeit wiederherzustellen.
Für die Praxis heißt das erstens: Sie müssen definieren, welche Geschäftsprozesse und Systeme für Ihr Unternehmen so kritisch sind, dass ihr Ausfall regulatorische, finanzielle oder operative Schäden auslöst. Zweitens müssen Sie festlegen, wie schnell diese Funktionen wieder laufen müssen und wie viel Datenverlust maximal akzeptabel ist. Drittens brauchen Sie einen dokumentierten Krisenprozess, der während eines Vorfalls Entscheidungen, Kommunikation, Eskalation und Priorisierung steuert.
Die NIS2-Pflicht ist ausdrücklich cyberbezogen, aber nicht auf technische Einzelmaßnahmen beschränkt. Ein Ransomware-Vorfall, ein Ausfall des Rechenzentrums, ein kompromittierter Cloud-Mandant, ein Lieferkettenproblem oder eine massive Fehlkonfiguration können denselben Business-Continuity-Fall auslösen. Deshalb gehört Maßnahme 3 eng zu Incident Handling unter NIS2: Incident Response behandelt die ersten Stunden der Reaktion, Business Continuity sichert den Betrieb über die akute Eindämmung hinaus.
Unternehmen sollten die Norm deshalb als Management-Anforderung lesen. NIS2 Business Continuity verlangt nicht das schönste Handbuch, sondern belastbare Steuerungsfähigkeit. Ein Unternehmen ist nur dann gut vorbereitet, wenn die Geschäftsleitung Prioritäten kennt, der Fachbereich seine Mindestbetriebsfähigkeit beschreiben kann, die IT Wiederherstellungsabläufe dokumentiert hat und der Krisenstab weiß, wann er zusammenkommt.
Business Impact Analysis (BIA) — kritische Prozesse identifizieren
Die Business Impact Analysis ist der Ausgangspunkt jeder NIS2-konformen Business-Continuity-Organisation. Ohne BIA können Sie weder sinnvolle RTO- und RPO-Werte definieren noch entscheiden, welche Systeme, Daten, Standorte, Mitarbeitenden und Lieferanten vorrangig geschützt oder wiederhergestellt werden müssen. BSI-Standard 200-4 behandelt die BIA daher zu Recht als Kernschritt für Business Continuity Management.
Eine belastbare BIA beginnt nicht bei Servern, sondern bei Geschäftsprozessen. Zuerst wird ermittelt, welche Leistungen zwingend aufrechterhalten werden müssen: etwa Auftragsannahme, Produktionssteuerung, Kundenservice, Zahlungsverkehr, E-Mail, ERP, Identitätsmanagement oder Fernwartung. Danach wird bewertet, welche Folgen ein Ausfall nach 30 Minuten, 4 Stunden, 24 Stunden oder mehreren Tagen hätte. Maßgeblich sind Umsatzverlust, Vertragsstrafen, Sicherheitsfolgen, rechtliche Meldepflichten, Reputationsschäden und Auswirkungen auf Kunden oder Bürger.
Wichtig ist, dass die BIA Abhängigkeiten offenlegt. Ein kritischer Prozess hängt fast nie nur an einer Anwendung. Häufig sind Identitätsdienste, Netzwerkanbindung, Cloud-Plattform, Datenbanken, Schnittstellen, Schlüsselpersonen und externe Dienstleister beteiligt. Wer nur die Anwendungsliste betrachtet, übersieht den praktischen Wiederanlaufpfad. Gerade mittelständische Unternehmen erkennen in der BIA oft erstmals ihre echten Single Points of Failure.
Die BIA sollte mindestens diese Fragen beantworten:
- Welche Geschäftsprozesse sind kritisch?
- Welche Systeme, Daten, Personen und Lieferanten werden dafür benötigt?
- Wie lange darf der Prozess maximal ausfallen?
- Welche Schäden entstehen bei längeren Unterbrechungen?
- Welche manuellen Ersatzverfahren sind vorübergehend möglich?
Ein pragmatisches BIA-Ergebnis ist meist eine priorisierte Liste mit Prozessverantwortlichen, maximal tolerierbarer Ausfallzeit, Mindestressourcen und Abhängigkeiten. Diese Ergebnisse fließen direkt in Ihre NIS2-Risikoanalyse ein. Die BIA beantwortet nämlich nicht nur die Frage, was wichtig ist, sondern auch, wo ein Cyberangriff, Lieferantenausfall oder Infrastrukturproblem den höchsten Schaden verursachen würde.
Typische Fehler in der BIA sind ein zu großer Scope, reine IT-Sicht und fehlende Management-Beteiligung. Wenn jede Anwendung als „kritisch“ markiert wird, verliert die Priorisierung ihren Wert. Wenn nur die IT bewertet, fehlen oft die geschäftlichen Auswirkungen. Und wenn die Leitungsebene die Prioritäten nicht freigibt, bleiben spätere Budget- und Wiederanlaufentscheidungen angreifbar.
RPO und RTO festlegen — Wiederherstellungsziele definieren
RPO und RTO übersetzen Business Continuity in messbare Ziele. Das Recovery Point Objective definiert, wie viel Datenverlust maximal akzeptabel ist; das Recovery Time Objective beschreibt, wie schnell ein System oder Prozess wieder verfügbar sein muss. NIS2 nennt keine festen Zahlenwerte, verlangt aber implizit, dass diese Ziele aus dem Risiko und der Kritikalität Ihrer Prozesse hergeleitet werden.
Ein Beispiel macht die Logik greifbar: Wenn Ihr ERP für Aufträge und Versand geschäftskritisch ist, kann ein RTO von 24 Stunden zu lang sein, weil Stillstand, Lieferverzug und Vertragsverletzungen drohen. Wenn Ihre Datenbank stündlich gesichert wird, aber maximal 15 Minuten Datenverlust tragbar sind, ist das RPO zu schwach. Erst aus der Kombination von BIA, technischer Architektur und Geschäftsauswirkung entsteht ein realistisches Zielbild.
Viele Unternehmen definieren RTO und RPO zu abstrakt. Formulierungen wie „so schnell wie möglich“ oder „möglichst ohne Datenverlust“ sind für Audits, Übungen und Krisenkommunikation wertlos. Besser sind konkrete Zielwerte je kritischem Prozess oder System, ergänzt um verantwortliche Owner, technische Voraussetzungen und den aktuell erreichten Ist-Zustand. So wird sichtbar, ob das Unternehmen die eigenen Anforderungen tatsächlich erfüllen kann.
Die folgende Tabelle zeigt den Unterschied der wichtigsten Kennzahlen:
| Kennzahl | Bedeutung | Leitfrage | Beispiel |
|---|---|---|---|
| RTO | Maximal tolerierbare Wiederherstellungszeit | Wie schnell muss der Dienst wieder laufen? | E-Mail innerhalb von 8 Stunden |
| RPO | Maximal tolerierbarer Datenverlust | Auf welchen Datenstand müssen Sie zurück? | CRM maximal 15 Minuten Datenverlust |
| MTD | Maximal tolerierbare Unterbrechungsdauer | Wann wird der Gesamtausfall existenziell? | Kundenportal maximal 24 Stunden |
RTO und RPO sind keine rein technischen Kennzahlen. Sie beeinflussen Investitionen in Backup-Frequenz, Replikation, Cloud-Architektur, Personalbereitschaft und Testaufwand. Wer sehr kurze Ziele definiert, braucht meist mehr Automatisierung, höhere Redundanz und regelmäßige Übungen. Genau deshalb sollte die Geschäftsleitung diese Ziele kennen und freigeben, statt sie stillschweigend der IT zu überlassen.
Backup-Strategie — 3-2-1-Regel und Immutable Backups
NIS2 Business Continuity scheitert in der Praxis am häufigsten an unzureichenden Backups. Ein Backup ist nur dann regulatorisch und operativ hilfreich, wenn es vollständig, geschützt, zeitnah verfügbar und tatsächlich rücksicherbar ist. Art. 21 Abs. 2 Buchst. c spricht ausdrücklich von Backup-Kopien und ausreichender Redundanz; ENISA und gängige Best Practice leiten daraus eine 3-2-1-Strategie mit zusätzlichem Schutz gegen Manipulation ab.
Die 3-2-1-Regel bedeutet: mindestens drei Kopien der kritischen Daten, auf zwei unterschiedlichen Medientypen, davon eine Kopie ausgelagert. Für viele Unternehmen reicht das heute allein nicht mehr aus, weil Ransomware nicht nur Primärsysteme, sondern auch verbundene Backups verschlüsselt oder löscht. Deshalb sollten mindestens besonders kritische Sicherungen unveränderbar sein, etwa durch Immutable Storage, WORM-Funktionen oder logisch getrennte Aufbewahrung.
Eine NIS2-konforme Backup-Strategie sollte mindestens folgende Punkte abdecken:
- Sicherungsumfang für Daten, Konfigurationen, Identitäten und Wiederanlaufdokumente
- Frequenz auf Basis des RPO, nicht nach Kalendergefühl
- Verschlüsselung bei Speicherung und Übertragung
- Zugriffsschutz mit getrennten Berechtigungen und MFA
- Offsite- oder Cloud-Kopie mit ausreichender geografischer Trennung
- Regelmäßige Integritäts- und Restore-Tests
- Aufbewahrungsfristen, die auch verspätet erkannte Angriffe berücksichtigen
Besonders wichtig ist die Frage der Trennung. Wenn Primärsystem, Backup-Management und Administratorkonten identisch abgesichert sind, kann ein einziger kompromittierter Zugang alle Kopien gefährden. Die Aufsicht wird deshalb zunehmend auf administrative Trennung, gesonderte Zugangsdaten, Netzwerksegmentierung und unveränderbare Kopien schauen. NIS2 verlangt kein bestimmtes Produkt, aber sehr wohl ein Sicherheitsniveau, das einen realen Wiederanlauf erlaubt.
Viele Unternehmen vergessen außerdem, dass Wiederherstellbarkeit nicht nur Daten betrifft. Auch Firewalls, Verzeichnisdienste, Secrets, Infrastruktur-as-Code, virtuelle Maschinen, Cloud-Konfigurationen und Kontaktlisten sind für den Notfall relevant. Wer nur Datenbanken sichert, aber die Betriebsumgebung nicht schnell reproduzieren kann, verfehlt das eigentliche Ziel der Betriebskontinuität.
Disaster Recovery Plan erstellen (Schritt-für-Schritt)
Ein Disaster Recovery Plan ist die operative Übersetzung Ihrer BIA- und Backup-Entscheidungen. Er beschreibt nicht abstrakt, dass Systeme „wiederhergestellt werden sollen“, sondern legt fest, wer wann welche technischen und organisatorischen Schritte in welcher Reihenfolge ausführt. Für NIS2 ist das wichtig, weil Business Continuity erst dann belastbar ist, wenn der Wiederanlauf nicht vom Gedächtnis einzelner Personen abhängt.
Ein pragmatischer Disaster Recovery Plan kann in sieben Schritten aufgebaut werden:
- Kritische Services und Abhängigkeiten aus der BIA priorisieren.
- Pro Service RTO, RPO, Mindestressourcen und Wiederanlaufreihenfolge dokumentieren.
- Backup-Quellen, Speicherorte, Zugangsvoraussetzungen und Restore-Verfahren festhalten.
- Technische Recovery-Runbooks für Systeme, Datenbanken, Netzwerke und Identitäten erstellen.
- Manuelle Ersatzverfahren für den Zwischenbetrieb definieren.
- Kommunikations- und Eskalationswege mit Krisenmanagement verzahnen.
- Tests, Lessons Learned und Aktualisierungen verbindlich planen.
Ein guter Plan ist konkret. Er nennt Systeme, Verantwortliche, Stellvertretungen, Kontakte, Freigabepunkte, Prüfschritte und Abbruchkriterien. Vor allem beschreibt er, in welcher Reihenfolge wiederhergestellt wird. Das ist entscheidend, weil ein Datenbank-Restore wenig bringt, wenn Identitätsdienste, Zertifikate, DNS oder Netzwerkpfade noch nicht verfügbar sind. Gerade hier ist NIST SP 800-34 eine hilfreiche technische Referenz.
Zum Mindestinhalt eines Disaster Recovery Plans gehören typischerweise:
| Baustein | Was dokumentiert werden sollte | Warum es für NIS2 relevant ist |
|---|---|---|
| Scope | Kritische Services, Standorte, Daten und Verantwortliche | Begrenzt den Plan auf prüfungsrelevante Kernfunktionen |
| Auslöser | Wann wird der DR-Plan aktiviert? | Schafft klare Eskalation statt Ad-hoc-Entscheidung |
| Wiederanlaufreihenfolge | Welche Services zuerst? | Sichert priorisierte Betriebsfähigkeit |
| Recovery-Runbooks | Konkrete technische Schritte | Macht Wiederherstellung reproduzierbar |
| Kommunikationsplan | Interne, externe und regulatorische Meldungen | Verzahnt DR mit Art. 23 und Krisenmanagement |
| Test- und Freigabelogik | Wie wird Erfolg nachgewiesen? | Liefert Compliance-Evidenz statt Annahmen |
Der entscheidende Unterschied zwischen einem Dokument und einem wirksamen Plan liegt in der Übung. Wenn Wiederanläufe nie getestet wurden, bleiben RTO und RPO Vermutungen. Unternehmen sollten deshalb nicht nur Papierpläne pflegen, sondern regelmäßig Datenbanken zurücksichern, Notfallzugänge validieren, Alternate-Site-Szenarien prüfen und im Team durchspielen, wie aus einem Incident ein größerer Ausfall wird.
Krisenmanagement und Krisenstab aufbauen
Krisenmanagement ist der organisatorische Teil von Maßnahme 3. Während der Disaster Recovery Plan den Wiederanlauf beschreibt, steuert der Krisenstab Entscheidungen, Prioritäten, Kommunikation und Ressourcen im laufenden Ausnahmezustand. Art. 21 Abs. 2 Buchst. c nennt diesen Prozess ausdrücklich. Unternehmen brauchen also nicht nur Technik, sondern eine belastbare Führungsstruktur für gravierende Vorfälle.
Ein Krisenstab sollte klein genug sein, um schnell zu entscheiden, und breit genug, um die wesentlichen Perspektiven abzudecken. Typische Rollen sind Geschäftsleitung, IT oder Informationssicherheit, Betrieb, Kommunikation, Recht oder Compliance, Datenschutz sowie gegebenenfalls Personal und Fachbereichsverantwortliche. Bei regulierten oder stark kundenabhängigen Unternehmen gehören auch Kundendienst und externe Dienstleister in definierte Kommunikationspfade.
Wesentlich sind klare Aktivierungsregeln. Wenn mehrere kritische Systeme ausfallen, Kundendaten potenziell betroffen sind, die Wiederanlaufziele nicht mehr erreichbar erscheinen oder eine Meldepflicht nach Art. 23 NIS2 droht, sollte der Krisenstab automatisch einberufen werden. Ohne solche Trigger wird zu spät eskaliert, und wertvolle Zeit geht verloren.
Ein belastbarer Krisenprozess sollte mindestens diese Elemente enthalten:
- Aktivierungskriterien und Eskalationsstufen
- Rollen, Entscheidungsbefugnisse und Stellvertretungen
- Kontaktlisten für intern, extern und regulatorisch relevante Stellen
- Vorlagen für Kunden-, Mitarbeiter- und Behördenkommunikation
- Lagebild, Protokollierung und Aufgabenverfolgung
- Rückkehr in den Regelbetrieb und Nachbereitung
Gerade die Kommunikation wird oft unterschätzt. In einer Krise müssen Informationen schnell, konsistent und faktenbasiert fließen. Mitarbeitende brauchen Arbeitsanweisungen, Kunden eine realistische Lageeinschätzung, die Geschäftsleitung Priorisierungsgrundlagen und die Aufsicht gegebenenfalls fristgerechte Meldungen. Deshalb sollte Krisenmanagement nie isoliert von NIS2 Incident Handling gedacht werden.
BSI-Standard 200-4 als Umsetzungsleitfaden
BSI-Standard 200-4 ist für deutsche Unternehmen der praktischste Leitfaden, um NIS2 Business Continuity strukturiert umzusetzen. Der Standard beschreibt ein vollständiges BCM-System mit Initiierung, Business Impact Analysis, Risikoanalyse, Strategieentwicklung, Notfallplanung, Übungen und kontinuierlicher Verbesserung. Er passt deshalb sehr gut zur Anforderung aus Art. 21 Abs. 2 Buchst. c, ohne die Norm auf einzelne technische Maßnahmen zu verengen.
Besonders wertvoll ist der Standard, weil er den Weg von der Governance zur Umsetzung beschreibt. Unternehmen erhalten damit eine nachvollziehbare Reihenfolge: BCM-Geltungsbereich festlegen, kritische Prozesse analysieren, BCM-Strategien definieren, Notfallhandbuch und Wiederanlaufpläne erstellen, Übungen durchführen und Ergebnisse nachschärfen. Genau diese Prozesslogik fehlt in vielen Organisationen, die nur über Backups sprechen, aber keinen belastbaren Wiederanlauf organisieren.
Für die Praxis ist außerdem die Verbindung zu ISO-Standards hilfreich. ISO 22301 liefert ein international anerkanntes Managementsystem für Business Continuity, während ISO 27001 im Annex A.17 beziehungsweise den zugehörigen Continuity-Kontrollen Informationssicherheit im Notfall adressiert. NIS2 bleibt jedoch der verbindliche regulatorische Rahmen. Wer ISO-Strukturen nutzt, sollte deshalb explizit auf Art. 21 Abs. 2 Buchst. c und Art. 23 NIS2 mappen.
Die folgende Tabelle zeigt ein praxistaugliches Mapping:
| NIS2 Maßnahme 3 | ISO 27001 / Annex A.17 bzw. Continuity Controls | ISO 22301 Element | Praktische Bedeutung |
|---|---|---|---|
| Business-Continuity- und Disaster-Recovery-Pläne | Kontrollen zur Informationssicherheitskontinuität und Wiederherstellung | Business continuity plans and procedures | Dokumentierte Wiederanlauf- und Fortführungspläne |
| Backup-Management und Redundanz | Backup- und Wiederherstellungskontrollen, technische Verfügbarkeit | Support resources and recovery strategies | Regelmäßige Sicherungen, getrennte Speicherorte, Wiederherstellbarkeit |
| BIA und Priorisierung kritischer Prozesse | Risikobezogene Continuity-Steuerung | Business impact analysis and risk assessment | Herleitung von Prioritäten, MTD, RTO, RPO |
| Krisenmanagement-Prozess | Governance- und Eskalationskontrollen | Incident response structure and crisis communication | Entscheidungen, Kommunikation und Eskalation im Vorfall |
| Übungen und laufende Verbesserung | Tests, Reviews und Maßnahmenverfolgung | Exercising, evaluation and improvement | Nachweis, dass Pläne realistisch und aktuell sind |
Das Mapping ist wichtig, weil viele Unternehmen glauben, ein vorhandenes ISO-27001- oder ISO-22301-Programm genüge automatisch für NIS2. In der Praxis hilft es stark, ersetzt aber nicht die explizite regulatorische Zuordnung. NIS2 verlangt einen nachweisbaren Bezug zu Cybervorfällen, Wiederherstellung, Redundanz und Krisenmanagement. Deshalb sollten Sie Ihr BCM nicht nur „standardsauber“, sondern auch rechtsbezogen dokumentieren.
Häufig gestellte Fragen (FAQ)
Was fordert NIS2 zu Business Continuity?
NIS2 fordert belastbare Business-Continuity- und Disaster-Recovery-Pläne, Backup-Management mit ausreichender Redundanz und einen Prozess für Krisenmanagement. Praktisch müssen Unternehmen kritische Prozesse identifizieren, Wiederanlaufziele definieren, Sicherungen schützen und die Umsetzung regelmäßig testen.
Brauche ich einen Notfallplan für NIS2?
Ja. Ohne Notfallplan fehlt die dokumentierte Grundlage, um bei Ausfällen strukturiert zu handeln. Ein NIS2-konformer Plan beschreibt Auslöser, Rollen, Wiederanlaufreihenfolge, technische Recovery-Schritte, Kommunikationswege und Übungen.
Welche Backup-Strategie fordert NIS2?
NIS2 schreibt keine einzelne Technologie vor, verlangt aber Sicherungen, Redundanz und Wiederherstellbarkeit. Die belastbarste Praxis ist eine 3-2-1-Strategie mit mindestens einer ausgelagerten Kopie, strenger Zugriffstrennung und möglichst unveränderbaren Backups.
Wie hängen NIS2 und ISO 22301 zusammen?
ISO 22301 ist ein freiwilliger Standard für Business Continuity Management und damit ein gutes Strukturmodell für Prozesse, Rollen und Übungen. NIS2 bleibt jedoch die verbindliche Rechtsgrundlage. Unternehmen sollten ISO 22301 daher als Umsetzungsrahmen nutzen und die Ergebnisse ausdrücklich auf Art. 21 Abs. 2 Buchst. c NIS2 beziehen.
Muss ich Notfallübungen für NIS2 durchführen?
Ja, jedenfalls faktisch. Ohne Übungen lässt sich nicht belegen, dass RTO, RPO, Kommunikationswege und Wiederanlaufpläne tatsächlich funktionieren. Sinnvoll sind mindestens jährliche Krisen- und Restore-Tests, bei kritischen Systemen ergänzt um häufigere Teiltests und Tabletop-Übungen.
Fazit: NIS2 Business Continuity ist eine Führungs- und Nachweispflicht
NIS2 Business Continuity verlangt weit mehr als tägliche Datensicherungen. Art. 21(2)(c) fordert eine belastbare Kombination aus BIA, klaren Wiederherstellungszielen, 3-2-1-Backup-Strategie, Disaster-Recovery-Plan und Krisenmanagement. Wer diese Bausteine dokumentiert, testet und regelmäßig aktualisiert, reduziert nicht nur das Ausfallrisiko, sondern schafft auch belastbare Compliance-Nachweise.
Der pragmatische nächste Schritt ist deshalb nicht der perfekte Großentwurf, sondern ein priorisiertes Startprogramm: kritische Prozesse identifizieren, RTO und RPO festlegen, Backup-Lücken schließen, einen Krisenstab benennen und den ersten Wiederanlauftest terminieren. Wenn Sie Business Continuity, Incident Handling und Management-Verantwortung in einer strukturierten Weiterbildung zusammenführen wollen, ist die NIS2-Schulung für Unternehmen der passende nächste Schritt.