Notfallmanagement: Notfallkonzept, BCM, Disaster Recovery und Incident Response

Notfallmanagement: Notfallkonzept, BCM, Disaster Recovery und Incident Response

https://bildung.social/@oerinformatik/

https://oer-informatik.de/notfallmanagement

Notfallmanagement, Business Continuity Management, BSI-Standard 200-4, Notfallhandbuch, Business-Impact-Analyse, RTO, RPO, Disaster Recovery, Incident Response, Ransomware, Meldepflicht

tl/dr; (ca. 25 min Lesezeit): Ausfälle lassen sich nicht vollständig verhindern – aber vorbereiten. Der Artikel erklärt, wie sich Störung, Notfall und Krise unterscheiden, wie Business Continuity Management (BCM) in vier Phasen funktioniert, wie Du mit einer Business-Impact-Analyse zeitkritische Prozesse sowie RTO und RPO bestimmst, was in Notfallkonzept, Notfallhandbuch und Disaster-Recovery-Plan steht und wie ein Unternehmen auf einen Sicherheitsvorfall wie einen Ransomwareangriff reagiert [AI-Assisted]. (Zuletzt geändert am 28.10.2026)

Dieser Artikel baut auf der Kann-Liste des Artikels Informationssicherheit managen: ISMS, IT-Grundschutz, Risikobehandlung und Penetrationstest auf. Zum Üben gibt es Übungsaufgaben zum Notfallmanagement.

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Als Grundlagen des Notfallmanagements kann ich nach Durchlesen des Artikels…

• … Störung, Notfall, Krise und Katastrophe voneinander abgrenzen.

• … erläutern, welche Bedeutung die schnelle Wiederherstellung von Systemen für das Schutzziel Verfügbarkeit und für den Geschäftsbetrieb hat.

• … die vier Phasen des BCM-Zyklus nennen und ihnen je zwei passende Maßnahmen zuordnen.

• … Inhalte eines Notfallhandbuchs und eines Incident-Response-Plans nennen und erläutern.

• … erläutern, was ein Ransomwareangriff ist, und den Phasen eines Cyberangriffs wirksame Gegenmaßnahmen zuordnen.

• … die Meldefristen bei Datenschutzverletzungen und erheblichen Sicherheitsvorfällen nennen.

Darüber hinaus kann ich als Expertenwissen im Notfallmanagement…

• … mit einer Business-Impact-Analyse zeitkritische Prozesse bestimmen und die Begriffe maximal tolerierbare Ausfallzeit, Recovery Time Objective (RTO) und Recovery Point Objective (RPO) beschreiben und anwenden.

• … die Bestandteile eines Notfallkonzepts beschreiben und einen Disaster-Recovery-Plan in das BCM einordnen.

• … Maßnahmen beschreiben, die eine schnelle Systemwiederherstellung vorbereiten, und technische Maßnahmen gegen Ausfälle auswählen.

• … die Schritte erläutern, mit denen nach einem Verbindungs- oder Systemausfall die Konsistenz von Daten wiederhergestellt wird.

Ein Serverraum steht unter Wasser, ein Ransomwareangriff verschlüsselt alle Dateiserver, der Provider fällt einen Tag lang aus: Solche Ereignisse lassen sich mit Schutzmaßnahmen seltener machen, aber nie ganz ausschließen. Entscheidend ist dann, ob ein Unternehmen vorbereitet ist – ob jede und jeder weiß, wer entscheidet, welche Prozesse zuerst wieder laufen müssen, wo die Sicherungen liegen und wen man informieren muss. Genau das regelt das Notfallmanagement, in Normen meist Business Continuity Management (BCM) genannt.

Die Mindmap zeigt die Themen dieses Artikels im Überblick:

Störung, Notfall, Krise, Katastrophe

Nicht jeder Ausfall ist ein Notfall. Der BSI-Standard 200-4 unterscheidet nach Ausmaß und danach, ob die normale Organisation das Ereignis noch bewältigen kann, zwischen Störung, Notfall und Krise. Die Katastrophe ist dagegen ein Begriff aus dem öffentlichen Katastrophenschutz: Für das betroffene Unternehmen ist sie meist eine Krise, bei der zusätzlich Behörden die Lage leiten.

Wichtig ist die Eskalation: Eine Störung kann zum Notfall werden, wenn sie länger dauert als geplant. Deshalb legt das Notfallmanagement Kriterien fest, ab wann der Notfall ausgerufen wird.

Warum die Wiederherstellung so wichtig ist

Das Schutzziel Verfügbarkeit verlangt, dass Systeme und Daten genutzt werden können, wenn sie gebraucht werden. Wie verfügbar ein System über das Jahr ist, hängt von zwei Größen ab: wie oft es ausfällt und wie lange es danach steht. Die Formel V = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}} aus dem Artikel Hochverfügbarkeit zeigt das: Wer die mittlere Wiederherstellungszeit (MTTR) halbiert, gewinnt genauso viel Verfügbarkeit wie mit halb so häufigen Ausfällen. Weil sich Ausfälle nie ganz ausschließen lassen, ist eine schnelle, vorbereitete Wiederherstellung oft der günstigere Hebel.

Für den Geschäftsbetrieb bedeutet jede Stunde Ausfall zum Beispiel:

• Produktion, Verkauf oder Versand stehen still – es entgehen Umsätze, laufende Kosten (Löhne, Miete) fallen trotzdem an.

• Liefertermine und Service-Level-Vereinbarungen (SLA) werden verletzt – Vertragsstrafen und unzufriedene Kundschaft sind die Folge.

• Das Image leidet; Kundinnen und Kunden wechseln womöglich zur Konkurrenz.

• Daten seit der letzten Sicherung gehen verloren und müssen nacherfasst werden.

Business Continuity Management im Überblick

Business Continuity Management (BCM, auf Deutsch auch Notfallmanagement oder betriebliches Kontinuitätsmanagement) sorgt dafür, dass ein Unternehmen seine wichtigsten Geschäftsprozesse auch bei schweren Störungen fortführen oder schnell wieder aufnehmen kann. Es ist eng mit dem ISMS verbunden, betrachtet aber nicht nur die IT, sondern auch Personal, Gebäude und Dienstleister. Maßgebliche Regelwerke sind der BSI-Standard 200-4 (Business Continuity Management, 2023) und die internationale Norm ISO 22301.

BCM ist ein Kreislauf. Eine verbreitete Einteilung in vier Phasen:

Die Erkenntnisse aus Phase 4 fließen wieder in Phase 1 ein – wie beim PDCA-Zyklus des ISMS.

Business-Impact-Analyse: Was muss zuerst wieder laufen?

Nicht alles ist gleich dringend. Die Business-Impact-Analyse (BIA, Folgenabschätzung) untersucht für jeden Geschäftsprozess, welcher Schaden mit zunehmender Ausfallzeit entsteht, und ermittelt so die zeitkritischen Prozesse. Daraus leiten sich die Wiederanlaufziele ab:

  letzte Sicherung        Ausfall                       System läuft wieder
        |<----- RPO ------->|<------------- RTO --------------->|
  ------+-------------------+-----------------------------------+------> Zeit
        Daten dieser Zeit       Ausfallzeit des Systems
        gehen verloren          (muss kleiner sein als die MTA)

Ein Beispiel zum Nachrechnen: Die Bestelldatenbank wird jede Nacht um 2 Uhr gesichert. Fällt sie um 17 Uhr aus, sind die Bestellungen von 15 Stunden verloren – im schlimmsten Fall, wenn der Ausfall kurz vor 2 Uhr passiert, fast ein ganzer Tag. Ein RPO von 15 Minuten ist mit einer nächtlichen Sicherung also nicht erreichbar; nötig sind zum Beispiel Sicherungen des Transaktionsprotokolls alle 15 Minuten oder eine Replikation auf einen zweiten Server. Je kleiner RTO und RPO sein sollen, desto teurer wird die Lösung (Hochverfügbarkeit, Spiegelung, zweites Rechenzentrum).

Notfallkonzept, Notfallhandbuch und Wiederanlaufpläne

Das Notfallkonzept (Notfallvorsorgekonzept) beschreibt, wie ein Unternehmen auf Notfälle vorbereitet ist. Das Notfallhandbuch enthält die konkreten Anweisungen für den Ernstfall und muss auch dann verfügbar sein, wenn die IT ausgefallen ist – also zusätzlich ausgedruckt oder offline an mehreren Stellen. Typische Bestandteile:

• Geltungsbereich und Notfallkriterien: Für welche Prozesse und Standorte gilt das Handbuch? Ab wann wird ein Notfall ausgerufen?

• Zuständigkeiten und Notfallorganisation: Wer leitet den Notfallstab, wer entscheidet, wer vertritt wen? Rollen statt nur Namen, damit Vertretungen funktionieren.

• Alarmierungs- und Meldewege: Wer wird wann und wie informiert (Telefonliste, Rufbereitschaft, Eskalationsstufen)? Dazu gehören auch Dienstleister, Versicherung und Behörden.

• Sofortmaßnahmen und Maßnahmenplan: Checklisten für die ersten Minuten (z. B. betroffene Systeme vom Netz trennen, Beweise sichern).

• Notbetrieb und Workarounds: Wie läuft der Prozess ohne IT oder mit eingeschränkter IT weiter (Papierformulare, Notfallarbeitsplätze, Homeoffice, Ausweichstandort)?

• Wiederanlaufpläne: Schritt-für-Schritt-Anleitungen, in welcher Reihenfolge welche Systeme aus welchen Sicherungen wiederhergestellt und getestet werden, mit den Zielen RTO und RPO.

• Kommunikationsplan: Wer informiert Beschäftigte, Kundschaft, Presse und Behörden, mit welchen vorbereiteten Texten?

• Dokumentation und Pflege: Protokollvorlagen für den Notfall, Termine für Übungen und für die regelmäßige Aktualisierung.

Disaster Recovery: die IT wieder zum Laufen bringen

Ein Disaster-Recovery-Plan (DRP) ist der IT-Ausschnitt der Notfallplanung. Er legt fest, was nach einem schweren Schaden – Brand im Serverraum, Totalausfall des Speichersystems, vollständig verschlüsselte Server – mit der IT geschieht: welche Systeme in welcher Reihenfolge zurückkommen, aus welchen Sicherungen, auf welcher Hardware oder an welchem Ort, und wer die einzelnen Schritte ausführt. Oft genügt es zunächst, die wichtigsten Dienste in kleinerem Umfang bereitzustellen. Der DRP gehört zum Business-Continuity-Plan (BCP); dieser regelt zusätzlich, wie Personal, Räume und Abläufe ohne oder mit eingeschränkter IT weiterarbeiten. Sinnvoll schreiben lässt sich ein DRP erst nach Business-Impact-Analyse und Risikoanalyse, denn sie liefern die Reihenfolge und die Zielwerte RTO und RPO.

Für schwere Schäden am Standort selbst sehen Disaster-Recovery-Pläne oft einen Ausweichstandort vor:

Heute übernehmen auch Cloud-Dienste diese Rolle (Disaster Recovery as a Service).

Die Systemwiederherstellung vorbereiten

Ob eine Wiederherstellung im Ernstfall klappt, entscheidet sich vorher. Prüfe die Vorbereitung am besten entlang von fünf Fragen:

Datenkonsistenz nach einem Ausfall wiederherstellen

Fällt eine Verbindung oder ein System nur zeitweise aus, ist das Ziel, dass am Ende keine Daten fehlen und keine doppelt vorhanden sind. Besonders deutlich wird das bei Geräten, die laufend Daten senden (Sensoren, Fahrzeuge, Scanner). Damit nach einer Funklücke alles wieder zusammenpasst, müssen Gerät und Server ein paar Regeln einhalten:

Ist der Puffer voll, überschreiben viele Geräte die ältesten Einträge – auch das erkennt der Server nur über die Nummern. Nach der Wiederherstellung aus einer Sicherung gilt dasselbe Prinzip im Großen: Daten seit der letzten Sicherung werden aus anderen Quellen (Protokolle, Belege, E-Mails) nacherfasst und gegen Dubletten abgeglichen.

Incident Response: auf Sicherheitsvorfälle reagieren

Incident Response (Reaktion auf Sicherheitsvorfälle) ist die geplante Reaktion auf Angriffe wie Ransomware, Datendiebstahl oder kompromittierte Konten. Ein verbreitetes Phasenmodell (nach dem SANS Institute; die US-Behörde NIST fasste in SP 800-61 Revision 2 Eindämmung, Beseitigung und Wiederherstellung zu einer Phase zusammen und ordnet die Incident Response seit Revision 3 von 2025 den sechs Funktionen ihres Cybersecurity Framework 2.0 zu) ist:

1. Vorbereitung: Incident-Response-Plan, Team, Werkzeuge, Übungen.

2. Erkennung und Analyse: Vorfall feststellen (Monitoring, Meldungen von Beschäftigten), Ausmaß und Schweregrad einschätzen.

3. Eindämmung: betroffene Systeme isolieren, Konten sperren, Ausbreitung stoppen – und dabei Spuren für die Analyse sichern.

4. Beseitigung: Schadsoftware entfernen, Schwachstelle schließen, Passwörter ändern.

5. Wiederherstellung: Systeme aus sauberen Sicherungen neu aufsetzen und überwacht in Betrieb nehmen.

6. Nachbereitung: Ursachen dokumentieren, Maßnahmen und Pläne verbessern.

Was ein Incident-Response-Plan festhalten sollte, lässt sich gut an den sechs Funktionen des NIST Cybersecurity Framework (CSF) 2.0 ausrichten, nach denen auch NIST SP 800-61 Revision 3 gegliedert ist:

Ransomware

Bei einem Ransomwareangriff verschlüsselt Schadsoftware die Daten des Opfers und macht sie unbrauchbar. Die Angreifenden fordern ein Lösegeld (englisch ransom), meist in einer Kryptowährung, für den Schlüssel. Häufig kopieren sie die Daten vorher und drohen zusätzlich mit ihrer Veröffentlichung („doppelte Erpressung“). Ein solcher Angriff läuft in mehreren Schritten ab, die sich über Tage oder Wochen hinziehen können. Die frei zugängliche Wissensdatenbank MITRE ATT&CK beschreibt das Vorgehen von Angreifenden als Taktiken; die Tabelle fasst die für Ransomware wichtigsten zu fünf Schritten zusammen. Für jeden Schritt gibt es Anzeichen, an denen man ihn bemerken kann, und Maßnahmen, die ihn verhindern oder bremsen:

Schritte eines Ransomwareangriffs mit zugehörigen ATT&CK-Taktiken, Anzeichen und Gegenmaßnahmen (eigene, vereinfachte Zusammenstellung)

Schritt	ATT&CK-Taktiken	was passiert	woran man es bemerken kann	was den Schritt verhindert oder bremst
1. Zugang verschaffen	Initial Access, Execution	präparierter Mailanhang oder Link, erratenes Passwort am Fernzugang, ungepatchte Schwachstelle in einem Server, der aus dem Internet erreichbar ist	Warnung des Virenschutzes, Anmeldung zu ungewöhnlicher Zeit oder aus einem fremden Land	Sensibilisierung der Beschäftigten, Filter für Anhänge und Makros, Mehr-Faktor-Authentifizierung am Fernzugang, Updates zeitnah einspielen
2. Festsetzen und Rechte sammeln	Persistence, Privilege Escalation, Credential Access	Hintertür einrichten, Passwörter auslesen, Administratorrechte erlangen	neue Dienste oder geplante Tasks, neue Mitglieder in Administratorgruppen	getrennte Administratorkonten ohne E-Mail und Surfen, minimale Rechte, Endpoint Detection and Response (EDR)
3. Im Netz umsehen und ausbreiten	Discovery, Lateral Movement	internes Netz scannen, sich mit erbeuteten Konten an Servern und am Sicherungssystem anmelden	ein Konto meldet sich an ungewöhnlich vielen Rechnern an, Scans im internen Netz	Netzsegmentierung, Sicherungssystem mit eigener Anmeldung, Auswertung der Anmeldeprotokolle
4. Daten sammeln und abziehen	Collection, Exfiltration	Daten packen und nach außen hochladen, um später mit ihrer Veröffentlichung zu drohen	ungewöhnlich große ausgehende Datenmengen, Verbindungen zu unbekannten Cloud-Speichern	Regeln für ausgehenden Verkehr, Alarm bei großen Uploads, sensible Daten verschlüsselt ablegen
5. Schaden anrichten	Impact	Sicherungen löschen, Daten verschlüsseln, Lösegeldforderung hinterlassen	viele Dateien ändern in kurzer Zeit Endung und Inhalt, Sicherungsjobs schlagen fehl	Offline- oder unveränderliche Sicherungen, erprobte Wiederherstellung, Incident-Response-Plan und Notfallhandbuch

Wie schnell die Organisation nach Schritt 5 wieder arbeiten kann, entscheidet nicht mehr der Angriff, sondern die Vorbereitung: Incident Response, Notfallhandbuch und Wiederanlaufpläne.

Das BSI und die Polizei raten davon ab, Lösegeld zu zahlen: Es gibt keine Garantie für den Schlüssel, und die Zahlung finanziert weitere Angriffe.

Meldepflichten

Zur Reaktion gehört, rechtzeitig zu melden:

• Datenschutzverletzung (personenbezogene Daten betroffen): Meldung an die zuständige Datenschutzaufsichtsbehörde möglichst binnen 72 Stunden nach Bekanntwerden (Art. 33 DSGVO), bei hohem Risiko zusätzlich Benachrichtigung der Betroffenen (Art. 34 DSGVO).

• Erheblicher Sicherheitsvorfall bei Einrichtungen, die unter die NIS-2-Regeln fallen: unverzüglich, spätestens 24 Stunden nach Kenntnis eine frühe Erstmeldung an das BSI, spätestens 72 Stunden nach Kenntnis eine Meldung mit erster Bewertung und spätestens einen Monat nach dieser Meldung eine Abschlussmeldung (§ 32 BSIG, seit Dezember 2025 in Kraft).

• Zusätzlich je nach Fall: Anzeige bei der Polizei (Zentrale Ansprechstellen Cybercrime), Information der Cyberversicherung nach deren Bedingungen.

Notfallübungen

Pläne, die nie geübt wurden, scheitern im Ernstfall oft an Kleinigkeiten: Die Telefonliste ist veraltet, das Passwort für die Sicherung kennt niemand, das Zurückspielen dauert dreimal so lange wie gedacht. Deshalb gehören regelmäßige Übungen zum BCM – von der Besprechung am Tisch (Tabletop-Übung: „Was tun wir, wenn …?“) über Alarmierungstests bis zur echten Wiederherstellung eines Systems auf Ersatzhardware. Jede Übung endet mit einer Auswertung, deren Ergebnisse in die Pläne einfließen.

Typische Fehler

• Notfallhandbuch liegt nur als Datei auf dem Server, der gerade ausgefallen oder verschlüsselt ist.

• Sicherungen sind ständig mit dem Netz verbunden und werden mit verschlüsselt.

• RTO und RPO werden festgelegt, ohne zu prüfen, ob Sicherungsintervall und Wiederherstellungszeit sie überhaupt einhalten können.

• RTO und RPO verwechseln: Das RTO ist eine Zeit nach dem Ausfall (bis das System wieder läuft), das RPO ein Zeitraum vor dem Ausfall (wie alt die Daten höchstens sein dürfen).

• Zuständigkeiten nur mit Namen statt mit Rollen und Vertretungen festgelegt.

• Zu allgemeine Antworten in Aufgaben („Backups machen“, „Sicherheit erhöhen“): Nenne die konkrete Maßnahme und ihre Wirkung.

So gehst Du bei Aufgaben vor

1. Ordne das Ereignis ein: Störung, Notfall oder Sicherheitsvorfall? Welche Phase des BCM-Zyklus oder des Angriffs ist gefragt?

2. Achte auf den Operator: „nennen“ verlangt Stichworte, „beschreiben“ und „erläutern“ verlangen, was die Maßnahme tut und warum sie hilft.

3. Beziehe Deine Antwort auf das Szenario: Welche Prozesse sind zeitkritisch, welche Systeme betroffen?

4. Bei Zeitangaben: Rechne nach, ob Sicherungsintervall und Wiederherstellungszeit zu RPO und RTO passen.

Leitfragen

1. Wie unterscheiden sich Störung, Notfall und Krise? Antwort

Eine Störung beeinträchtigt Systeme oder Prozesse mit geringem Schaden und wird im normalen Betrieb behoben. Ein Notfall liegt vor, wenn zeitkritische Prozesse länger ausfallen als hinnehmbar und eine besondere Notfallorganisation nötig ist. Eine Krise lässt sich mit den vorbereiteten Plänen nicht mehr bewältigen oder bedroht das Unternehmen existenziell; siehe Abschnitt „Störung, Notfall, Krise, Katastrophe“.

2. Warum hängt die Verfügbarkeit eines Systems so stark davon ab, wie schnell es wiederhergestellt wird, und was bedeutet ein Ausfall für den Geschäftsbetrieb? Antwort

Ausfälle lassen sich nie ganz ausschließen. Die Verfügbarkeit V = MTBF / (MTBF + MTTR) steigt deshalb nicht nur mit selteneren Ausfällen, sondern genauso mit einer kürzeren Wiederherstellungszeit. Jede Stunde Ausfall kostet Umsatz, verletzt Liefertermine und SLA und schadet dem Image; siehe Abschnitt „Warum die Wiederherstellung so wichtig ist“.

3. Welche vier Phasen hat der BCM-Zyklus, und welche Maßnahmen gehören jeweils dazu? Antwort

Prävention und Vorbereitung (z. B. Abhängigkeiten per BIA erfassen, Single Points of Failure beseitigen, Offline-Kopien), Notfallvorsorge (z. B. Notfallhandbuch offline, Rollen im Notfallstab, Übungen), Reaktion im Notfall (z. B. Notfall ausrufen, Systeme abtrennen, Notbetrieb) sowie Wiederanlauf und Rückkehr zum Normalbetrieb (z. B. Aufbau in geplanter Reihenfolge, Daten nachtragen, Ursachen auswerten); siehe Abschnitt „Business Continuity Management im Überblick“.

4. Was bedeuten MTA, RTO und RPO, und wie hängen sie mit der Sicherungsstrategie zusammen? Antwort

Die MTA ist die maximal tolerierbare Ausfallzeit eines Prozesses. Das RTO ist die Zeit, nach der ein System wieder laufen muss (kleiner als die MTA), das RPO der höchstens hinnehmbare Datenverlust, gemessen als Zeitraum vor dem Ausfall. Das Sicherungsintervall darf nicht größer als das RPO sein, die Wiederherstellungszeit nicht größer als das RTO; siehe Abschnitt „Business-Impact-Analyse“.

5. Was gehört in ein Notfallkonzept bzw. Notfallhandbuch? Antwort

Geltungsbereich und Notfallkriterien, Zuständigkeiten und Notfallorganisation, Alarmierungswege, Sofortmaßnahmen, Notbetrieb und Workarounds, Wiederanlaufpläne, Kommunikationsplan sowie Dokumentation und Pflege. Das Handbuch muss auch ohne IT verfügbar sein; siehe Abschnitt „Notfallkonzept, Notfallhandbuch und Wiederanlaufpläne“.

6. Was ist ein Disaster-Recovery-Plan, und wie hängt er mit dem Business-Continuity-Plan zusammen? Antwort

Ein DRP legt für die IT fest, wie nach einem schweren Schaden Systeme und Daten zurückkommen: Reihenfolge, Sicherungen, Ersatzhardware oder Ausweichstandort, Verantwortliche. Er gehört zum BCP, der zusätzlich Personal, Räume und Abläufe abdeckt, und baut auf BIA, Risikoanalyse und den Zielen RTO und RPO auf; siehe Abschnitt „Disaster Recovery“.

7. Mit welchen Maßnahmen bereitest Du eine schnelle Systemwiederherstellung vor, und wie stellst Du nach einer Unterbrechung die Datenkonsistenz wieder her? Antwort

Vorbereitung: Ausfälle früh bemerken (Überwachung mit Alarm), brauchbare Daten sicherstellen (Sicherung passend zum RPO, Offline-Kopie, Prüfsummen), einen Wiederanlaufplan mit Reihenfolge und Vertretungen bereithalten, die Wiederherstellung mit Zeitmessung üben und Ersatzhardware sichern, Ausfälle durch Redundanz und Failover abfangen. Konsistenz: Meldungen eindeutig kennzeichnen, im Gerät puffern und erst nach der Quittung des Servers löschen; der Server verwirft Dubletten, fordert Lücken nach und bildet den Zustand aus der zuletzt erfassten Meldung; siehe Abschnitt „Die Systemwiederherstellung vorbereiten“ und Abschnitt „Datenkonsistenz nach einem Ausfall wiederherstellen“.

8. Was ist ein Ransomwareangriff, was steht in einem Incident-Response-Plan, und welche Meldefristen gelten? Antwort

Bei Ransomware verschlüsselt Schadsoftware die Daten, und die Angreifenden fordern Lösegeld für die Entschlüsselung. Einen Incident-Response-Plan kann man nach den Funktionen des NIST CSF 2.0 gliedern: Befugnisse und Geltungsbereich, Übersicht der wichtigen Systeme, vorbereitetes Team und Notfallzugänge, Erkennen und Einstufen von Vorfällen, Playbooks mit Kommunikation und Meldefristen, Freigabe des Wiederanlaufs und Auswertung. Datenschutzverletzungen sind binnen 72 Stunden der Aufsichtsbehörde zu melden (Art. 33 DSGVO); NIS-2-pflichtige Einrichtungen melden erhebliche Vorfälle binnen 24 Stunden (frühe Erstmeldung) und 72 Stunden (Meldung) an das BSI, die Abschlussmeldung folgt spätestens einen Monat später (§ 32 BSIG); siehe Abschnitt „Incident Response“.

Links und weitere Informationen

• Übungsaufgaben zum Notfallmanagement

• Informationssicherheit managen: ISMS, IT-Grundschutz, Risikobehandlung und Penetrationstest, Schutzziele, Schwachstellen und Sicherheitsrisiken und Angriffe und Schadsoftware

• Datensicherung und Archivierung und Serverraum: physische Sicherheit

• als Nachschlagewerk: IT-Grundschutz des BSI mit den BSI-Standards 200-1 bis 200-4 (200-4: Business Continuity Management)

• zur Incident Response: NIST SP 800-61 Rev. 3 (Empfehlungen zur Incident Response, gegliedert nach dem NIST Cybersecurity Framework 2.0) und MITRE ATT&CK: Enterprise-Taktiken

• zu den Meldepflichten: Art. 33 DSGVO und § 32 BSIG

---

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Notfallmanagement: Notfallkonzept, BCM, Disaster Recovery und Incident Response” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/notfallmanagement veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/it-sicherheit/verfuegbarkeit-notfall. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]