Warum Incident Response vor dem Ernstfall beginnen muss

Zwei Cybervorfälle bei Abbott zeigen: Im Ernstfall zählt nicht nur die Technik. Entscheidend sind vorbereitete Abläufe, klare Zuständigkeiten und Menschen, die wissen, was als Nächstes zu tun ist.

Ich habe bei Berichten über Cyberangriffe oft denselben Gedanken: Der technische Vorfall ist nur der Anfang. Richtig stressig wird es, wenn zehn Menschen gleichzeitig fragen:

Wer darf Systeme abschalten?
Müssen wir Kunden informieren?
Wo sind eigentlich die Protokolldaten?
Wer ruft den Datenschutzbeauftragten an?
Und hat irgendjemand die Nummer unseres Cybersecurity-Dienstleisters?

Spätestens bei der letzten Frage beginnt hektisches Scrollen durch alte E-Mails. Das ist verständlich – aber kein überzeugendes Incident-Response-Konzept.

Ein Cybervorfall ist kein guter Zeitpunkt, um Zuständigkeiten auszudiskutieren, Verträge zu prüfen oder einen geeigneten Forensik-Dienstleister zu googeln.

Das wäre ungefähr so, als würdest du beim Wohnungsbrand erst einmal Vergleichsportale für Feuerlöscher öffnen.

Wie wichtig eine vorbereitete Reaktion ist, zeigen zwei Cybervorfälle beim internationalen Gesundheitskonzern Abbott.

Zwei Vorfälle, viele offene Fragen

Abbott bestätigte im Juli 2026 einen unbefugten Zugriff auf eine begrenzte Anzahl interner Systeme im Geschäftsbereich Cancer Diagnostics. Nach Angaben des Unternehmens waren ältere Systeme von Exact Sciences betroffen, die von den übrigen Abbott-Systemen getrennt betrieben wurden.

Abbott erklärte außerdem, dass der Vorfall keine Auswirkungen auf den Geschäftsbetrieb, die Produktion, den Laborbetrieb, die Produktverfügbarkeit oder die Versorgung von Patienten gehabt habe.

Gleichzeitig wurden Behauptungen einer Erpressergruppe bekannt. Die Angreifer behaupteten unter anderem, große Mengen personenbezogener und medizinischer Informationen entwendet zu haben. 

Fast parallel untersuchte Abbott einen zweiten möglichen Vorfall. Dabei ging es um das extern betriebene Kundenportal LabCentral. Ein Angreifer behauptete, über kompromittierte Zugangsdaten und eine Schwachstelle Dateien abgerufen zu haben.

Abbott widersprach der Darstellung, dass sich dort sensible Kunden- oder Geschäftsdaten befunden hätten. Nach Aussage des Unternehmens enthielt das Portal vor allem öffentlich verfügbare technische Dokumente wie Bedienungsanleitungen, Checklisten und Produktspezifikationen.

Damit lagen innerhalb kurzer Zeit zwei unterschiedliche Situationen auf dem Tisch:

• ein bestätigter unbefugter Zugriff auf interne Systeme,
• ein weiterer möglicher Vorfall bei einem extern betriebenen Portal,
• umfangreiche, aber zunächst unbestätigte Täterbehauptungen,
• potenziell betroffene Identitäten, Cloud-Dienste und Zugangsdaten,
• öffentliche Erpressungsversuche,
• Medienanfragen und mögliche regulatorische Konsequenzen.

Kurz gesagt: kein entspannter Dienstag im Büro.

Was Abbott unmittelbar getan hat

Für IT-Entscheider ist besonders interessant, wie Abbott nach Bekanntwerden des bestätigten Vorfalls reagierte.

Das Unternehmen leitete nach eigenen Angaben sofort Maßnahmen ein, aktivierte seine vorbereiteten Reaktionsabläufe, beauftragte externe Cybersecurity-Experten und schaltete Strafverfolgungsbehörden ein. Parallel wurde untersucht, auf welche Informationen tatsächlich zugegriffen worden war.

Das klingt zunächst unspektakulär. Schließlich würde vermutlich jedes Unternehmen behaupten, „sofort alle notwendigen Maßnahmen“ eingeleitet zu haben.

Das entscheidende Detail lesen wir zwischen den Zeilen: Solche Schritte funktionieren nur schnell, wenn sie vorher vorbereitet wurden.

Du kannst nicht innerhalb weniger Stunden einen geeigneten Forensik-Dienstleister auswählen, Verträge und Vertraulichkeitsvereinbarungen verhandeln, interne Entscheidungsbefugnisse festlegen, Kommunikationswege definieren und herausfinden, welche Behörde eigentlich zuständig ist.

Zumindest nicht, ohne dass dein Puls dabei neue Höchstwerte erreicht.

Incident Response beginnt nicht mit dem Angriff

Incident Response bezeichnet die strukturierte Reaktion auf einen vermuteten oder bestätigten IT-Sicherheitsvorfall.

Dazu gehört mehr als das Entfernen einer Schadsoftware. Eine vollständige Reaktion umfasst beispielsweise:

• den Vorfall erkennen und bewerten,
• betroffene Systeme und Konten identifizieren,
• die weitere Ausbreitung verhindern,
• Beweise und Protokolldaten sichern,
• Ursachen und Angriffswege untersuchen,
• Geschäftsleitung und relevante Fachbereiche einbinden,
• gesetzliche Meldepflichten prüfen,
• Kunden, Mitarbeitende oder Partner informieren,
• Systeme kontrolliert wiederherstellen,
• aus dem Vorfall lernen und Schutzmaßnahmen verbessern.

Incident Response ist deshalb keine reine Aufgabe der IT-Abteilung. Sie betrifft Geschäftsführung, Datenschutz, Recht, Kommunikation, Personal, Einkauf, Versicherungen und externe Dienstleister.

Sobald Kunden fragen, Medien anrufen oder der Betrieb stillsteht, ist es endgültig kein „IT-Problem“ mehr.

Warum Unternehmen vor dem Vorfall vorbereitet sein müssen

1. Im Ernstfall fehlt die Zeit für Grundsatzdiskussionen

Bei einem laufenden Angriff zählt jede Stunde. Trotzdem braucht es sorgfältige Entscheidungen.

Ein betroffenes Administratorkonto muss möglicherweise sofort gesperrt oder ein kompromittiertes System vom Netzwerk getrennt werden. Ein Cloud-Dienst könnte vorübergehend deaktiviert werden.

Doch wer darf das entscheiden?

Was passiert, wenn dadurch ein wichtiger Geschäftsprozess ausfällt? Wer bewertet die Auswirkungen? Wann wird die Geschäftsführung einbezogen? Wann ist der Vorfall groß genug, um den Krisenstab zu aktivieren?

Ohne vorbereitete Entscheidungswege entsteht entweder Stillstand oder hektischer Aktionismus. Beides hilft dem Angreifer mehr als dem Unternehmen.

2. Gut gemeinte Sofortmaßnahmen können Beweise vernichten

Wenn ein System verdächtig reagiert, liegt der Reflex nahe: ausschalten, zurücksetzen, neu installieren – Problem gelöst.

Leider kann das wichtige Spuren zerstören.

Protokolldaten, aktive Verbindungen, Arbeitsspeicherinhalte und andere technische Informationen helfen, den Angriffsweg zu verstehen und herauszufinden, welche Systeme betroffen sind, ob Daten abgeflossen sind und ob sich der Angreifer noch im Netzwerk befindet.

Deshalb müssen Mitarbeitende und Administratoren wissen, was sie im Verdachtsfall tun dürfen – und was besser nicht.

„Wir haben den Laptop vorsichtshalber komplett formatiert“ ist für einen Forensiker so erfreulich wie ein frisch gewischter Tatort für die Polizei.

3. Niemand kennt am Anfang die ganze Wahrheit

Der Abbott-Fall zeigt ein typisches Problem: Unternehmen, Angreifer und Medien berichten häufig unterschiedliche Versionen eines Vorfalls.

Angreifer neigen dazu, den Umfang ihrer Beute möglichst dramatisch darzustellen. Das erhöht den öffentlichen Druck und verbessert ihre Verhandlungsposition. Unternehmen wiederum können zu Beginn oft noch gar nicht sicher sagen, welche Daten betroffen sind.

Eine gute Incident Response trennt deshalb konsequent zwischen:

• bestätigten Fakten,
• aktuellen Vermutungen,
• Behauptungen der Angreifer,
• noch offenen Untersuchungsfragen.

Das ist für die technische Analyse wichtig – und auch die externe Kommunikation muss belastbar bleiben.

Wer vorschnell Entwarnung gibt, riskiert später einen Vertrauensverlust. Wer ungeprüfte Täterbehauptungen übernimmt, verbreitet möglicherweise selbst falsche Informationen.

Die ehrlichste Aussage lautet manchmal schlicht: „Wir untersuchen das derzeit.“

Das klingt nicht spektakulär – ist aber professionell.

4. Meldepflichten warten nicht auf ein vollständiges Lagebild

Je nach Branche, Unternehmensgröße, Art des Vorfalls und betroffenen Daten können unterschiedliche Meldepflichten gelten.

Bei meldepflichtigen Datenschutzverletzungen sieht die DSGVO grundsätzlich eine Meldung an die zuständige Aufsichtsbehörde innerhalb von 72 Stunden nach Bekanntwerden vor. Für Unternehmen im Anwendungsbereich der NIS-2-Regelungen können gestufte Meldungen erforderlich sein – unter anderem eine frühe Erstmeldung innerhalb von 24 Stunden und eine Folgemeldung innerhalb von 72 Stunden.

Zu diesem Zeitpunkt ist die forensische Untersuchung häufig noch lange nicht abgeschlossen.

Unternehmen müssen also in der Lage sein, bereits auf Basis eines vorläufigen Lagebilds strukturiert zu handeln. Dazu braucht es vorbereitete Meldewege, klare Dokumentation und Personen, die wissen, welche Informationen benötigt werden.

Der Satz „Wir suchen noch nach dem Passwort für das Behördenportal“ sollte nicht Teil deiner Krisenkommunikation werden.

5. Externe Experten müssen erreichbar sein, bevor du sie brauchst

Nicht jedes Unternehmen kann ein eigenes Team aus Incident-Response-Spezialisten, Forensikern, Malware-Analysten und Krisenkommunikatoren beschäftigen. Das ist auch gar nicht notwendig.

Wichtig ist jedoch, vorher zu klären, wer im Ernstfall unterstützen kann.

Dazu gehören beispielsweise:

• ein spezialisierter Incident-Response-Dienstleister,
• der betreuende IT- oder Cloud-Partner,
• Datenschutz- und Rechtsberatung,
• der Cyberversicherer,
• Kommunikations- oder PR-Unterstützung,
• zuständige Strafverfolgungs- und Aufsichtsbehörden,
• Hersteller kritischer Systeme,
• wichtige Cloud- und SaaS-Anbieter.

Idealerweise werden Erreichbarkeit, Reaktionszeiten, Verantwortlichkeiten und Zugriffswege vertraglich geregelt.

Eine allgemeine Supportadresse mit dem Hinweis „Wir melden uns innerhalb von drei bis fünf Werktagen“ ist für einen aktiven Cyberangriff eher suboptimal.

Im Ernstfall brauchst du einen persönlichen Ansprechpartner, der dein Unternehmen kennt, erreichbar ist und direkt handeln kann.

Warum Cloud-Umgebungen in den Notfallplan gehören

Unternehmen arbeiten mit Microsoft 365, Cloud-Plattformen, extern gehosteten Portalen, SaaS-Anwendungen, mobilen Geräten und zahlreichen Schnittstellen. Ein einzelnes kompromittiertes Benutzerkonto kann Zugriff auf E-Mails, Dokumente, Ticketsysteme, CRM-Daten oder weitere Anwendungen ermöglichen.

Im Umfeld des Abbott-Vorfalls behaupteten Angreifer unter anderem, über Social Engineering Zugang zu einem zentralen Benutzerkonto erhalten zu haben. Auch bei dem zweiten möglichen Vorfall sollen kompromittierte Kundenzugangsdaten eine Rolle gespielt haben. Diese konkreten Täterangaben waren zwar nicht abschließend bestätigt, das beschriebene Angriffsmuster ist aber grundsätzlich realistisch.

Dein Incident-Response-Plan sollte deshalb Fragen beantworten wie:

• Wer kann kompromittierte Cloud-Konten sofort sperren?
• Sind ausreichend Protokolldaten verfügbar?
• Wie lange werden diese Daten gespeichert?
• Welche SaaS-Anwendungen sind mit der zentralen Anmeldung verbunden?
• Welche externen Portale und Dienstleister verarbeiten Unternehmensdaten?
• Wer kann API-Schlüssel, Sitzungen und Zugriffstoken widerrufen?
• Gibt es besonders geschützte Notfallkonten?
• Wie wird weiter kommuniziert, wenn Microsoft 365 oder das normale E-Mail-System nicht genutzt werden kann?
• Sind nicht nur Daten, sondern auch wichtige Cloud-Konfigurationen gesichert?
• Kann nachvollzogen werden, wer wann welche Einstellung geändert hat?

In der Cloud gilt: Was du im Normalbetrieb nicht siehst, kannst du im Notfall nur schwer untersuchen.

Transparenz ist deshalb die Grundlage dafür, schnell und sicher zu reagieren.

Was in einen brauchbaren Incident-Response-Plan gehört

Ein guter Plan muss nicht 200 Seiten lang sein. Im Gegenteil: Ein Notfalldokument, das während des Vorfalls niemand versteht, erfüllt hauptsächlich dekorative Zwecke.

Der Plan sollte so einfach aufgebaut sein, dass er auch unter Zeitdruck funktioniert.

Klare Auslöser

Es muss definiert sein, wann ein Ereignis als Sicherheitsvorfall eingestuft wird und ab wann der Krisenstab zusammenkommt.

Ein einzelner Phishing-Link ist etwas anderes als ein kompromittiertes Administratorkonto. Trotzdem darf aus einem vermeintlich kleinen Ereignis kein großer Vorfall werden, nur weil niemand zuständig war.

Benannte Verantwortliche

Rollen sollten nicht nur Abteilungen, sondern konkreten Personen und Stellvertretungen zugeordnet werden.

Typische Rollen sind:

• Leitung des Vorfalls,
• technische Analyse und Eindämmung,
• Geschäftsführung,
• Datenschutz und Recht,
• interne und externe Kommunikation,
• Kontakt zu Behörden,
• Koordination externer Dienstleister,
• Dokumentation aller Entscheidungen.

„Die IT kümmert sich“ ist keine Rollenbeschreibung.

Erreichbare Kontaktlisten

Kontaktdaten müssen auch dann verfügbar sein, wenn zentrale IT-Systeme ausgefallen oder nicht vertrauenswürdig sind.

Eine aktuelle Offline-Kopie ist daher sinnvoll. Das kann eine besonders geschützte Datei, ein Notfallgerät oder tatsächlich ein ausgedrucktes Dokument sein.

Papier hat viele Schwächen. Ransomware gehört erfreulicherweise noch nicht dazu.

Technische und geschäftliche Prioritäten

Das Unternehmen muss wissen, welche Systeme und Prozesse besonders wichtig sind.

Was muss zuerst wieder funktionieren: Produktion, Kundenservice, E-Mail, Logistik, Identitätsverwaltung oder Zahlungsverkehr?

Ohne diese Priorisierung gewinnt im Ernstfall häufig die Person, die am lautesten ruft. Das ist nicht immer dieselbe Person, deren Prozess für das Unternehmen am wichtigsten ist.

Kommunikationsvorlagen

Vorbereitete Textbausteine helfen bei der Kommunikation mit Mitarbeitenden, Kunden, Partnern, Behörden und Medien.

Natürlich müssen die Inhalte an den konkreten Vorfall angepasst werden. Aber grundlegende Fragen lassen sich vorbereiten:

• Was ist passiert?
• Was ist derzeit bestätigt?
• Welche Systeme sind betroffen?
• Welche Maßnahmen wurden eingeleitet?
• Was sollen Empfänger jetzt tun?
• Wann folgt das nächste Update?
• Wo gibt es verlässliche Informationen?

Gute Kommunikation ist dabei nicht das Schönreden eines Vorfalls. Sie schafft Orientierung, reduziert Spekulationen und schützt Vertrauen.

Wiederherstellungspläne und Backups

Backups sind wichtig, aber sie sind nicht automatisch eine Wiederherstellungsstrategie.

Unternehmen sollten regelmäßig prüfen:

• ob die Sicherungen vollständig sind,
• ob sie vom Produktivsystem getrennt sind,
• ob sie vor Manipulation geschützt sind,
• wie lange eine Wiederherstellung dauert,
• welche Reihenfolge eingehalten werden muss,
• ob auch Konfigurationen und Berechtigungen wiederhergestellt werden können.

Ein Backup, das noch nie getestet wurde, ist zunächst vor allem eine optimistische Vermutung.

Der wichtigste Punkt: Der Plan muss geübt werden

Selbst der beste Incident-Response-Plan hilft wenig, wenn ihn niemand kennt.

Deshalb sollten Unternehmen regelmäßig sogenannte Tabletop-Übungen durchführen. Dabei wird ein realistischer Cybervorfall gemeinsam durchgespielt – ohne echte Systeme abzuschalten.

Ein mögliches Szenario könnte lauten:

Am Montagmorgen wird festgestellt, dass ein Administratorkonto ungewöhnliche Anmeldungen aus dem Ausland aufweist. Gleichzeitig meldet sich ein Angreifer und behauptet, Kundendaten kopiert zu haben. Das zentrale Ticketsystem ist nicht erreichbar. Zwei Stunden später fragt ein Journalist nach einer Stellungnahme.

Dann beginnt die Übung:

Wer übernimmt die Leitung?
Wer sperrt das Konto?
Wer prüft die Protokolldaten?
Wer entscheidet über weitere Abschaltungen?
Wer informiert die Geschäftsführung?
Wer bewertet mögliche Meldepflichten?
Wer spricht mit dem Journalisten?
Und wie kommuniziert das Team, wenn die üblichen Systeme möglicherweise kompromittiert sind?

Bei solchen Übungen werden Schwächen sichtbar, die in einem Dokument leicht übersehen werden.

Vielleicht ist die Telefonnummer des Dienstleisters veraltet. Vielleicht hat nur eine Person Zugriff auf wichtige Protokolle. Vielleicht weiß niemand, wer die Cyberversicherung informieren muss. Vielleicht liegt der Notfallplan im Teams-Ordner – auf den während der Übung niemand zugreifen kann.

Das ist nicht peinlich. Genau dafür wird geübt.

Peinlich wäre, all das erst während eines echten Angriffs herauszufinden.

Der Incident-Response-Selbsttest

Kannst du die folgenden Fragen spontan beantworten?

1. Wer darf bei euch offiziell einen Cybernotfall ausrufen?
2. Wer übernimmt die Leitung, wenn die verantwortliche Person nicht erreichbar ist?
3. Welcher externe Cybersecurity-Experte ist rund um die Uhr erreichbar?
4. Wie kommuniziert ihr, wenn E-Mail und Teams ausfallen?
5. Welche Systeme müssen zuerst wiederhergestellt werden?
6. Wo liegen eure wichtigsten Protokolldaten?
7. Welche Behörden, Versicherungen, Kunden oder Partner müssen informiert werden?
8. Wann habt ihr zuletzt eine Wiederherstellung getestet?
9. Sind auch Cloud-Konfigurationen und Identitäten in den Notfallplan einbezogen?
10. Wann wurde der Ablauf zuletzt gemeinsam geübt?

Hast du mehrere „Das müsste ich nachschauen“-Antworten? Dann besteht Handlungsbedarf.

Incident Response ist Führungsverantwortung

Cybersecurity wird häufig daran gemessen, wie viele Angriffe verhindert wurden. Das reicht aber nicht aus.

Kein Unternehmen kann garantieren, dass niemals ein Konto kompromittiert, eine Schwachstelle ausgenutzt oder ein Dienstleister angegriffen wird. Entscheidend ist deshalb auch, wie schnell ein Vorfall erkannt, eingegrenzt und bewältigt werden kann.

Incident Response ist damit ein strategisches Führungsinstrument.

Die Geschäftsleitung muss sicherstellen, dass ausreichend Budget, Personal, externe Unterstützung und Entscheidungsbefugnisse vorhanden sind. Die IT kann technische Maßnahmen vorbereiten. Sie kann aber nicht allein entscheiden, welche Geschäftsprozesse priorisiert, welche Risiken akzeptiert oder wie Kunden informiert werden.

Der Ernstfall betrifft das gesamte Unternehmen. Also muss auch das gesamte Unternehmen vorbereitet sein.

Im Notfall brauchst du keinen perfekten Plan, sondern einen funktionierenden

Die beiden von Abbott untersuchten Vorfälle zeigen, wie komplex die Lage innerhalb kürzester Zeit werden kann.

Ein bestätigter Zugriff trifft auf unbestätigte Erpressungsbehauptungen. Interne Systeme stehen neben extern gehosteten Portalen. Technische Analyse, Geschäftsbetrieb, Strafverfolgung, Datenschutz und öffentliche Kommunikation laufen parallel.

Incident Response beginnt lange vor dem ersten Alarm.

Ein guter Notfallplan schafft klare Zuständigkeiten, macht kritische Systeme sichtbar, regelt die Zusammenarbeit mit externen Experten und bereitet Kommunikations- und Meldewege vor. Und er wird regelmäßig geübt.

Bei all dem muss er einfach genug sein, um unter Stress zu funktionieren.

Bei aixpedIT betrachten wir Incident Response deshalb nicht als PDF, das irgendwo im SharePoint seinen wohlverdienten Ruhestand genießt. Wir fokussieren uns auf das Zusammenspiel zwischen sicherer Cloud, transparenter Umgebung, belastbaren Backups, klaren Prozessen und persönlichen Ansprechpartnern.

Wenn es ernst wird, brauchst jemanden, der rangeht.