Unabhängiges Informationsangebot. Nicht verbunden mit dem Bundeskriminalamt, der Polizei oder einer anderen Behörde.
Unternehmen

Ransomware-Notfallplan

Ein Notfallplan ersetzt im Ernstfall Bauchgefühl durch dokumentierte Entscheidungen. Er beschreibt, wer wann was tut, wenn ein Ransomware-Verdacht entsteht, und macht das Unternehmen unter Druck handlungsfähig.

Unabhängiges Informationsangebot. Nicht verbunden mit dem Bundeskriminalamt, der Polizei oder einer anderen Behörde. Im Notfall bitte Polizei, BSI oder einen spezialisierten IT-Dienstleister einbinden. Diese Inhalte ersetzen keine professionelle Incident-Response-, Forensik-, Rechts- oder IT-Beratung.

Kurzfassung

  • Ein Notfallplan macht Entscheidungen unter Druck schneller und nachvollziehbarer.
  • Klare Rollen, Erreichbarkeiten und Eskalationswege sind wichtiger als der Umfang.
  • Sofortmaßnahmen, Beweissicherung und Kommunikation gehören zwingend hinein.
  • Der Plan muss regelmäßig geübt und nach jedem Vorfall aktualisiert werden.
  • Eine Offline-Version ist Pflicht, da Intranet und Mail im Ernstfall ausfallen können.

Zielgruppe

Geschäftsführung, IT-Leitung, Datenschutzbeauftragte sowie Security- und Notfallverantwortliche in kleinen und mittleren Unternehmen, die einen eigenen Notfallplan aufbauen oder einen bestehenden Plan überarbeiten.

Wichtiger Hinweis

Diese Inhalte ersetzen keine rechtliche, forensische oder organisatorische Einzelfallberatung. Ein Notfallplan muss auf das einzelne Unternehmen, seine Systemlandschaft und seine Verträge zugeschnitten sein.

Ziele des Notfallplans

  • Schnelle Eindämmung des Vorfalls
  • Klare Rollen und Eskalationswege
  • Beweissicherung für Forensik, Versicherung und Strafverfolgung
  • Geordnete Kommunikation nach innen und außen
  • Strukturierter Wiederanlauf nach Geschäftsprioritäten

Typische Frühindikatoren als Auslöser

Ein guter Notfallplan benennt konkrete Auslöser, ab denen er greift. Das verhindert, dass im Ernstfall über die Aktivierung diskutiert wird, statt zu handeln.

  • Verdacht auf kompromittierte privilegierte Konten
  • Auffällige Deaktivierung von EDR- oder Backup-Agenten
  • Plötzliche, breit gestreute Dateiumbenennungen oder unbekannte Endungen
  • Erpressernotizen oder Lösegeldforderungen auf Endgeräten oder Servern
  • Massenhafte Alarme aus SIEM, EDR oder Backup-System

Bestandteile

  • Geltungsbereich und Auslösekriterien
  • Rollen: Krisenstab, IT-Einsatzleitung, Kommunikation, Recht, Datenschutz
  • Erreichbarkeiten und Vertretungsregelungen, auch außerhalb der Geschäftszeiten
  • Kontaktliste: DFIR-Dienstleister, Polizei und ZAC, BSI, Versicherung, Rechtsbeistand
  • Technische Sofortmaßnahmen und Isolationsverfahren
  • Kommunikationsvorlagen für Mitarbeitende, Kunden, Behörden und Presse
  • Wiederanlauf-Prioritäten je Geschäftsprozess
  • Dokumentationspflichten während des Vorfalls

Erste 15 Minuten im Plan abbilden

  • Wer nimmt den Verdacht entgegen und entscheidet über die Aktivierung?
  • Welcher Kommunikationskanal wird sofort genutzt (out-of-band)?
  • Welche Systeme werden zuerst isoliert?
  • Wer informiert Geschäftsführung und Datenschutz?

Erste 60 Minuten im Plan abbilden

  • Aktivierung des Krisenstabs mit definierter Besetzung
  • Anforderung externer Unterstützung (DFIR, Rechtsbeistand, Kommunikation)
  • Sperrung oder Rotation privilegierter Konten
  • Isolation von Backup-Systemen
  • Erste schriftliche Lageeinschätzung mit Zeitstempel

Erster Arbeitstag im Plan abbilden

  • Strukturierte Beweissicherung nach definiertem Schema
  • Lagebild für Geschäftsführung, mindestens täglich aktualisiert
  • Bewertung möglicher Meldepflichten gemeinsam mit Rechtsbeistand
  • Abgestimmte Kommunikation an Mitarbeitende, Kunden und Partner
  • Erste Wiederanlauf-Planung in isolierter Umgebung

Rolle von Backups und Identitäten

Der Notfallplan muss beschreiben, wer im Ernstfall Zugriff auf Backups hat, wie diese vor Manipulation geschützt sind und wie privilegierte Konten zurückgesetzt werden. Backups und Identitäten sind die zentralen Hebel der Wiederherstellung - und gleichzeitig die wichtigsten Ziele der Angreifer.

  • Eigene Notfall-Identitäten für den Krisenfall, getrennt von der Produktion
  • Dokumentierte Reset-Verfahren für Domain-Admins, Service-Accounts und KRBTGT
  • Schriftliche Festlegung, wer Backups freigeben und wiederherstellen darf
  • Geprüfte Offline- oder Immutable-Kopien als Rückfallebene

Kommunikation und Meldewege (allgemeine Einordnung)

Der Plan benennt Verantwortliche für interne und externe Kommunikation, hält Vorlagen für unterschiedliche Stakeholder bereit und beschreibt grob die in Frage kommenden Melde- und Anzeigewege. Konkrete rechtliche Bewertungen bleiben dem Rechtsbeistand vorbehalten.

Pflege und Test

Ein Notfallplan ist nur so gut wie seine Aktualität. Mindestens jährliche Tabletop-Übungen, regelmäßige technische Tests und ein klarer Eigentümer für die Pflege sind Pflicht.

  • Jährliche Tabletop-Übung mit Krisenstab und IT
  • Technische Restore-Tests dokumentiert durchführen
  • Plan nach jedem realen Vorfall und nach jeder Übung aktualisieren
  • Offline-Version vorhalten, da Intranet im Ernstfall ausfallen kann
  • Versionsstand und Freigabe klar dokumentieren

Häufige Fragen

Wie umfangreich muss ein Notfallplan sein?

Wichtiger als Umfang ist Klarheit. Ein knapper, geübter Plan ist besser als ein dickes Dokument, das niemand kennt. Entscheidend sind Rollen, Erreichbarkeiten und die ersten Schritte.

Reicht ein generisches Muster aus dem Netz?

Muster können ein Startpunkt sein, ersetzen aber keine eigene Risikobetrachtung. Geschäftsprozesse, Systemlandschaft und Verantwortlichkeiten sind in jedem Unternehmen unterschiedlich.

Wer ist der richtige Eigentümer des Notfallplans?

In den meisten KMU die IT-Leitung in enger Abstimmung mit der Geschäftsführung. Datenschutz, Kommunikation und Rechtsbeistand wirken inhaltlich mit. Wichtig ist eine namentlich benannte Person mit Pflegeauftrag.

Wie oft sollte der Plan getestet werden?

Mindestens einmal jährlich als Tabletop-Übung, ergänzt durch technische Restore- und Isolationstests. Nach jedem realen Vorfall ist ein Review zwingend.