Ein anonymisierter Incident-Response-Fall aus der Praxis
Bei Ransomware denken viele Unternehmen zuerst an verschlüsselte Server, Lösegeldforderungen und hektische Wiederherstellung. Diese Perspektive ist verständlich, greift im Ernstfall aber oft zu kurz. Denn ein größerer Cyberangriff ist nicht nur ein technisches Ereignis. Er betrifft den Geschäftsbetrieb, die Kommunikation, rechtliche Bewertungen, Kundenbeziehungen und Managemententscheidungen unter hohem Zeitdruck.
Ein anonymisierter Incident-Response-Fall aus der Praxis zeigt genau diese Dynamik. Betroffen war ein mittelständisch geprägtes Unternehmen aus einem regulierten Konsumgüterumfeld mit rund 1.000 Mitarbeitenden. Die interne IT war erfahren, die wichtigsten Systeme bekannt, die Infrastruktur war beherrschbar und es gab ausreichend technische Ressourcen, um auf einen Sicherheitsvorfall zu reagieren.
Als der Angriff erkannt wurde, handelte die IT schnell. Betroffene Systeme wurden identifiziert, isoliert und vom Netz getrennt. Die unmittelbare Ausbreitung konnte eingedämmt werden. Aus technischer Sicht war das eine starke erste Reaktion – professionell und wirksam. Trotzdem kam der Wiederanlauf kurz darauf nahezu zum Stillstand.
Der kritische Moment: Wiederherstellen konnten viele. Entscheiden durfte niemand.
Unsere Incident-Response-Experten wurden hinzugezogen, als die erste technische Eindämmung bereits erfolgt war. Vor Ort zeigte sich schnell: Das Unternehmen verfügte durchaus über technisches Know-how. Es gab Teams, die Server wiederherstellen konnten. Es gab Personen, die Netzwerkbereiche bewerten konnten. Es gab Admins, die Systeme prüfen, bereinigen und neu aufsetzen konnten. Was fehlte, war keine operative IT-Kompetenz, sondern eine verbindliche Führungsstruktur für den Cyber-Krisenfall.
Nach der Eindämmung standen Fragen im Raum, die nicht allein technisch beantwortet werden konnten: Welche Systeme müssen zuerst wieder anlaufen? Wer darf den Wiederanlauf freigeben? Welche Restrisiken sind akzeptabel? Welche Informationen dürfen an Kunden, Partner und Dienstleister kommuniziert werden? Wer entscheidet, wenn IT, Fachbereich, Geschäftsführung und Recht unterschiedliche Prioritäten setzen?
Ein Satz aus dem Einsatz beschreibt die Situation sehr treffend: „Drei Leute konnten den Server wiederherstellen. Keiner durfte entscheiden, welcher zuerst.“ Genau hier lag das eigentliche Problem. Die Organisation konnte technisch reagieren, aber sie konnte den Wiederanlauf nicht ausreichend steuern.
Die gefährliche Annahme: Wenn die IT die Systeme im Griff hat, läuft der Wiederanlauf
Vor dem Angriff gab es im Unternehmen eine unausgesprochen die Annahme: Wenn die IT einen Vorfall technisch beherrscht, wird der Rest schon funktionieren. Diese Annahme ist nachvollziehbar, Sie ist nachvollziehbar, weil Cybervorfälle häufig zunächst als IT-Problem wahrgenommen werden. Im Ernstfall kann sie jedoch gefährlich werden. Denn bei einem größeren Ransomware-Vorfall geht es nicht nur um Technik. Es geht um Geschäftsbetrieb, Haftung, Kommunikation, Datenschutz, Kundenvertrauen und Prioritäten unter Zeitdruck.
Die IT kann Systeme isolieren, Backups prüfen, Server wiederherstellen Konten sperren und technische Spuren analysieren. Aber sie kann nicht allein entscheiden, welcher Geschäftsprozess zuerst wieder anlaufen muss, ob und wann eine Kommunikation an Kunden, Behörden, Versicherer oder Partner notwendig ist, oder welches Restrisiko die Geschäftsleitung akzeptieren sollte.
Warum der Wiederanlauf ins Stocken geriet
Während die technischen Teams arbeiteten, entstanden Verzögerungen an den Schnittstellen an den Schnittstellen zwischen IT, Management und Fachbereichen. Einzelne Systeme waren technisch bereit für die Wiederherstellung, aber es gab keine eindeutige Freigabe für den Wiederanlauf. Fachbereiche meldeten dringenden Bedarf an, konnten aber nicht verbindlich begründen, warum ihr Prozess geschäftskritischer war als andere. Parallel wuchs der Kommunikationsdruck von außen: Kunden und Partner wollten wissen, ob Leistungen weiterhin erbracht werden konnten und ob Schnittstellen sicher betrieben wurden.
So entstand eine typische Krisendynamik: Die IT wartete auf Managemententscheidungen. Das Management wartete auf ein vollständiges Lagebild. Die Fachbereiche warteten auf die Wiederaufnahme ihrer Prozesse. Gleichzeitig liefen operative, rechtliche und kommunikative Anforderungen auf.
Der Zeitverlust entstand also nicht durch Untätigkeit. Im Gegenteil: Alle Beteiligten arbeiteten unter hoher Belastung. Das Problem war, dass der Vorfall nicht eindeutig geführt wurde. Es fehlten klare Rollen, vorbereitete Eskalationswege und verbindliche Kriterien für Priorisierung und Freigabe.
Incident Response ist eine Führungsaufgabe
Dieser Fall zeigt sehr deutlich: Incident Response ist kein reines IT-Projekt. Ab einer bestimmten Größenordnung wird ein Cyberangriff zur Unternehmenskrise. Und Unternehmenskrisen brauchen Führung.
Dabei geht es nicht darum, technische Entscheidungen durch Managemententscheidungen zu ersetzen. Vielmehr müssen technische, fachliche, rechtliche und geschäftliche Perspektiven zusammengeführt werden. Nur so kann ein Unternehmen im Ernstfall bewerten, welche Systeme zuerst wiederhergestellt werden, welche Risiken tragbar sind, welche Kommunikationspflichten bestehen und welche Geschäftsprozesse temporär manuell weitergeführt werden müssen.
Eine wirksame Incident-Response-Organisation sollte deshalb vor dem Ernstfall folgende Aspekte festlegen:
1. Eine definierte Krisenorganisation
Wer sitzt im Krisenstab? Wer entscheidet? Wer berät? Wer dokumentiert? Wer kommuniziert?
2. Vorab definierte Wiederanlaufprioritäten
Nicht jedes System ist gleich kritisch. Unternehmen müssen vor dem Vorfall wissen, welche Prozesse für Betrieb, Umsatz, Kundenverpflichtungen und Compliance entscheidend sind.
3. Freigabeprozesse für den Wiederanlauf
Ein Restore ist nicht automatisch ein sicherer Wiederanlauf. Es muss klar sein, wer technische, fachliche und geschäftliche Freigaben erteilt.
4. Vorbereitete Krisenkommunikation
Kunden, Partner, Behörden, Versicherer und Mitarbeitende brauchen im Ernstfall belastbare Informationen. Wer erst während des Angriffs entscheidet, wer was sagen darf, verliert wertvolle Zeit.
5. Übungen unter realistischen Bedingungen
Ein Incident-Response-Plan, der nie getestet wurde, ist oft nur ein Dokument. Tabletop-Übungen zeigen, ob Rollen, Eskalationswege und Entscheidungen tatsächlich funktionieren.
Die wichtigste Lehre aus dem Einsatz
Der Vorfall wurde nicht dadurch kritisch, dass keine technischen Fähigkeiten vorhanden waren. Kritisch wurde er, weil technische Handlungsfähigkeit und unternehmerische Entscheidungsfähigkeit nicht ausreichend miteinander verbunden waren. Das ist eine typische Governance-Lücke: Die Organisation ist technisch besser vorbereitet als organisatorisch. Sie kann Systeme analysieren, isolieren und wiederherstellen, aber sie hat nicht verbindlich geregelt, wer im Krisenfall priorisiert, entscheidet, freigibt und kommuniziert.
Für Geschäftsführung, CIOs, CISOs und Compliance-Verantwortliche ist das eine zentrale Erkenntnis. Incident Response beginnt nicht erst mit dem Angriff. Sie beginnt vorher: mit klaren Verantwortlichkeiten, priorisierten Geschäftsprozessen, Kommunikationsplänen und geübten Entscheidungen unter Unsicherheit.
Was Unternehmen daraus ableiten sollten
Nach dem Vorfall wurde deutlich, dass nicht nur technische Schutzmaßnahmen überprüft werden mussten. Ebenso wichtig war die Frage, wie das Unternehmen künftig Entscheidungen im Cyber-Krisenfall trifft.
Dazu gehören unter anderem ein getesteter Incident-Response-Plan, ein klarer Krisenstab mit Entscheidungsbefugnissen, definierte Wiederanlaufprioritäten für kritische Systeme, vorbereitete Kommunikationsbausteine für Kunden und Partner, Einbindung von Datenschutz, Recht, Geschäftsführung und Fachbereichen, und regelmäßige Simulationen realistischer Angriffsszenarien. Denn im Ernstfall zählt nicht nur, ob Systeme wiederhergestellt werden können. Es zählt, ob das Unternehmen weiß, in welcher Reihenfolge, mit welcher Freigabe und mit welchem Risiko.
Fazit: Technik stoppt den Angriff. Führung bringt das Unternehmen zurück.
Die interne IT hat in diesem Fall schnell und richtig reagiert. Sie hat betroffene Systeme identifiziert, isoliert und damit Schlimmeres verhindert. Doch der Wiederanlauf zeigt: Cyber-Resilienz entsteht nicht allein durch Tools, Backups oder technische Expertise. Sie entsteht durch das Zusammenspiel aus Technik, Führung, Kommunikation und vorbereiteten Entscheidungen.
Genau hier setzt professionelle Incident-Response-Readiness an. Denn wenn der Angriff läuft, ist keine Zeit mehr, um Rollen zu diskutieren, Prioritäten auszuhandeln oder Kommunikationswege zu improvisieren. Dann muss klar sein, wer entscheidet und was zuerst wieder laufen muss.
Ein guter Incident-Response-Plan beantwortet deshalb nicht nur die Frage, wie Systeme wiederhergestellt werden. Er beantwortet die entscheidendere Frage: Wie bleibt das Unternehmen auch unter Druck führungs- und handlungsfähig?
