Die Krisenkommunikation im IT-Notfall entscheidet in vielen Fällen darüber, ob ein technischer Vorfall ein beherrschbares Ereignis bleibt oder zu einem Reputations- und Haftungsproblem wird. Technische Wiederanlaufpläne beschreiben, wie Systeme zurückkommen. Sie beantworten aber nicht die Frage, wer wann welche Information an Kunden, Beschäftigte, Aufsichtsbehörden, Versicherer und Geschäftspartner gibt. Genau diese Lücke wird in der Praxis erst bemerkt, wenn ein Verschlüsselungsvorfall die E-Mail-Infrastruktur mitnimmt und die Geschäftsführung feststellt, dass weder Telefonlisten noch abgestimmte Sprachregelungen außerhalb der betroffenen Systeme verfügbar sind. Ein belastbarer Notfallkommunikationsplan ist deshalb kein Anhang zum IT-Notfallplan, sondern ein eigenständiger Baustein mit eigenen Rollen, eigenen Auslösekriterien und eigener Infrastruktur. Dieser Beitrag beschreibt, wie ein solcher Plan strukturiert wird, welche gesetzlichen Meldepflichten den Zeitrahmen vorgeben, wie Sprachregelungen vorbereitet werden und woran Kommunikationskonzepte in der Umsetzung regelmäßig scheitern.
Hinweis: Dieser Beitrag gibt ausschließlich die redaktionellen Ansichten der Redaktion von cyberschutzbetrieb.de wieder. Er stellt keine Rechtsberatung dar und ersetzt nicht die Beratung durch eine qualifizierte Rechtsanwältin oder einen qualifizierten Rechtsanwalt. Für rechtlich verbindliche Auskünfte zu Ihrem konkreten Fall wenden Sie sich bitte an einen zugelassenen Rechtsbeistand.
Titelbild: Foto von CDC auf Unsplash.
Warum technische Notfallpläne die Kommunikation systematisch unterschätzen
Klassische IT-Notfallpläne sind entlang von Systemen organisiert. Sie beschreiben Wiederanlaufreihenfolgen, Abhängigkeiten zwischen Anwendungen, Wiederherstellungspunkte und Verantwortliche für einzelne Plattformen. Die Kommunikation taucht darin häufig nur als Zeile in einer Checkliste auf, etwa in der Form „Geschäftsführung informieren“. Was diese Information enthalten soll, in welcher Frist sie erfolgt und wer sie freigibt, bleibt offen.
Der zweite Grund liegt in der Rollenverteilung. IT-Notfallpläne werden von der IT geschrieben, Kommunikationspläne von Marketing oder Unternehmenskommunikation. Beide Dokumente entstehen getrennt, verwenden unterschiedliche Begriffe für dieselben Eskalationsstufen und werden getrennt geübt. In der Krise treffen dann zwei Prozesse aufeinander, die nie gemeinsam getestet wurden.
Hinzu kommt eine strukturelle Besonderheit von IT-Vorfällen: Die Faktenlage ist zu Beginn unklar und ändert sich schnell. Bei einem Brand ist der Schaden nach wenigen Stunden beschreibbar. Bei einem Ransomware-Angriff kann sich nach drei Tagen forensischer Analyse herausstellen, dass Daten nicht nur verschlüsselt, sondern zuvor abgeflossen sind. Kommunikation, die zu früh Entwarnung gibt, muss dann korrigiert werden. Genau diese Korrektur richtet den größeren Vertrauensschaden an als der Vorfall selbst.
Der Notfallkommunikationsplan als eigenständiges Dokument
Ein Notfallkommunikationsplan sollte unabhängig vom technischen Notfallhandbuch nutzbar sein. Er richtet sich an Personen, die im Ernstfall keinen Zugriff auf Fachsysteme haben und unter Zeitdruck entscheiden müssen. Der Aufbau folgt deshalb nicht der Systemlandschaft, sondern der Zielgruppenlogik.
Pflichtbestandteile
- Auslösekriterien: Ab welchem Schweregrad wird der Kommunikationsprozess aktiviert und wer darf ihn auslösen.
- Rollenübersicht mit Namen, Vertretung, Mobilnummer und privater Ausweichadresse außerhalb der Unternehmensdomäne.
- Stakeholder-Matrix mit Priorität, Verantwortlichem, Kanal und Erstinformationsfrist.
- Vorformulierte Textbausteine für die ersten Stunden, differenziert nach Zielgruppe.
- Freigabewege inklusive Vertretungsregelung, wenn Geschäftsführung nicht erreichbar ist.
- Übersicht der gesetzlichen und vertraglichen Meldepflichten mit Fristen und Adressaten.
- Dokumentationsvorgaben für die spätere Nachweisführung.
Das Dokument gehört in eine Form, die ohne funktionierende IT lesbar ist. Bewährt hat sich eine ausgedruckte Kurzfassung im Krisenordner, ergänzt um eine verschlüsselte Kopie auf den Diensthandys der Krisenstabsmitglieder. Eine Ablage ausschließlich im Intranet oder im Dateiserver verfehlt den Zweck, weil genau diese Systeme im Ernstfall betroffen sein können.
Rollen im Krisenstab und ihre Abgrenzung
Die häufigste organisatorische Fehlkonstruktion besteht darin, technische Vorfallbearbeitung und Kommunikation in einer Person zu bündeln. Der IT-Leiter, der gleichzeitig Kunden informieren und die Wiederherstellung koordinieren soll, wird beides schlechter machen. Eine saubere Trennung ist auch in kleineren Organisationen möglich, wenn Rollen statt Stellen definiert werden.
| Rolle | Kernaufgabe | Typische Besetzung | Abgrenzung |
|---|---|---|---|
| Krisenstabsleitung | Gesamtsteuerung, Freigabe externer Aussagen, Ressourcenentscheidungen | Geschäftsführung oder benannte Vertretung | Trifft keine technischen Detailentscheidungen |
| Technische Einsatzleitung | Analyse, Eindämmung, Wiederherstellung | IT-Leitung oder externer Incident Responder | Liefert Fakten, kommuniziert nicht nach außen |
| Kommunikationsverantwortung | Erstellung und Versand aller Botschaften, Medienkontakt | Unternehmenskommunikation, Marketing | Formuliert nur freigegebene Sachstände |
| Rechts- und Compliance-Rolle | Meldepflichten, Fristenkontrolle, Vertragsprüfung | Justiziariat, Datenschutzbeauftragter, externe Kanzlei | Prüft Formulierungen auf Haftungsrisiken |
| Dokumentation | Lückenloses Ereignisprotokoll mit Zeitstempeln | Assistenz oder Qualitätsmanagement | Bewertet nicht, protokolliert nur |
| Interne Kommunikation | Information der Belegschaft, Führungskräftebriefing | Personalabteilung | Getrennt von externer Kommunikation |
Für jede Rolle wird mindestens eine Vertretung benannt. In der Praxis fällt ein Teil des Krisenstabs planmäßig aus, weil Vorfälle bevorzugt an Wochenenden und in Urlaubszeiten auftreten. Eine Vertretungsregelung, die nur auf dem Papier existiert und nie geübt wurde, hilft nicht weiter.
Wer in der Krise erst klären muss, wer sprechen darf, hat die entscheidenden ersten Stunden bereits verloren. Die Freigabekette gehört vor den Vorfall, nicht in ihn.
Eskalationsstufen und Auslösekriterien
Ein Kommunikationsplan braucht objektivierbare Auslöser. Formulierungen wie „bei schwerwiegenden Vorfällen“ sind im Ernstfall nicht anwendbar, weil die Bewertung der Schwere selbst strittig ist. Bewährt hat sich eine dreistufige Klassifikation mit klaren Merkmalen.
- Stufe 1, Störung: Einzelne Systeme oder Standorte betroffen, keine Datenabflüsse erkennbar, Wiederherstellung innerhalb der vereinbarten Zielzeit absehbar. Kommunikation beschränkt sich auf interne Statusmeldungen und betroffene Fachbereiche.
- Stufe 2, erheblicher Vorfall: Geschäftskritische Prozesse stehen still, Kunden bemerken Beeinträchtigungen, ein Datenabfluss ist nicht ausgeschlossen. Der Krisenstab tritt zusammen, externe Erstinformation wird vorbereitet, Meldepflichten werden geprüft.
- Stufe 3, Krise: Bestätigter Datenabfluss, Erpressungslage, Ausfall über mehrere Tage oder Betroffenheit Dritter in der Lieferkette. Vollständige Aktivierung von Kommunikations-, Melde- und Eskalationsprozessen inklusive Vorbereitung von Medienanfragen.
Die Stufen sollten mit denen des technischen Incident-Response-Prozesses identisch benannt sein. Zwei parallele Skalen erzeugen Missverständnisse. Wichtig ist außerdem, dass eine Höherstufung jederzeit möglich ist und keine formale Zustimmungskette benötigt, während eine Herabstufung ausdrücklich freigegeben wird.
Meldepflichten als harter Zeitrahmen
Die Kommunikationsplanung wird durch regulatorische Fristen begrenzt. Diese Fristen laufen unabhängig davon, ob die technische Analyse abgeschlossen ist. Der Notfallkommunikationsplan sollte die einschlägigen Pflichten in einer Übersicht führen und für jede Pflicht einen Verantwortlichen benennen.
Datenschutzrechtliche Meldung
Bei einer Verletzung des Schutzes personenbezogener Daten sieht Art. 33 DSGVO eine Meldung an die zuständige Aufsichtsbehörde binnen 72 Stunden nach Bekanntwerden vor, sofern nicht voraussichtlich kein Risiko für die Rechte und Freiheiten natürlicher Personen besteht. Bei voraussichtlich hohem Risiko verlangt Art. 34 DSGVO zusätzlich die unverzügliche Benachrichtigung der betroffenen Personen. Der Verordnungstext ist über die konsolidierte Fassung der Datenschutz-Grundverordnung nachlesbar. Praktisch bedeutet die 72-Stunden-Frist, dass die Meldung in der Regel mit unvollständigem Kenntnisstand erfolgt und später ergänzt wird. Das ist zulässig und ausdrücklich vorgesehen.
Weitere Melde- und Informationspflichten
- Meldepflichten für Betreiber kritischer oder besonders wichtiger Einrichtungen nach den Vorgaben zur Umsetzung der NIS2-Richtlinie, mit gestufter Erstmeldung, Folgemeldung und Abschlussbericht.
- Vertragliche Informationspflichten gegenüber Auftraggebern, häufig verankert in Auftragsverarbeitungsverträgen nach Art. 28 DSGVO und in Rahmenverträgen mit eigenen, oft kürzeren Fristen.
- Anzeigepflichten gegenüber dem Cyberversicherer, deren Verletzung den Deckungsanspruch gefährden kann.
- Kapitalmarktrechtliche Pflichten bei börsennotierten Gesellschaften.
- Strafanzeige und Kontaktaufnahme mit der zuständigen Zentralen Ansprechstelle Cybercrime der Polizei, rechtlich meist freiwillig, aber für die Beweissicherung relevant.
Eine praktische Empfehlung: Die Fristen sollten nicht nur im Plan stehen, sondern im Moment der Aktivierung als konkrete Uhrzeiten auf einem Whiteboard oder in der Protokollvorlage festgehalten werden. Der Bezugspunkt ist der Zeitpunkt des Bekanntwerdens, nicht der Zeitpunkt des Angriffs. Dieser Zeitpunkt ist zu dokumentieren, weil er im Nachgang begründet werden muss.
Zielgruppen und Botschaften differenzieren
Eine einheitliche Sprachregelung für alle Adressaten führt zu Texten, die niemandem nützen. Sinnvoll ist eine Matrix, die je Zielgruppe das Informationsbedürfnis, den Kanal und die Erstinformationsfrist festlegt.
| Zielgruppe | Informationsbedürfnis | Kanal | Erstinformation |
|---|---|---|---|
| Belegschaft | Arbeitsfähigkeit, Verhaltensregeln, Sprachregelung nach außen | Führungskräftekaskade, SMS-Verteiler, Aushang | Innerhalb der ersten Stunden |
| Bestandskunden | Betroffenheit eigener Daten, Lieferfähigkeit, Ansprechpartner | Direkte Mail über Ausweichsystem, Telefon bei Schlüsselkunden | Am ersten Tag |
| Lieferanten und Dienstleister | Schnittstellen, Zahlungsverkehr, Warnung vor gefälschten Nachrichten | Telefon, Ausweich-E-Mail | Am ersten Tag |
| Aufsichtsbehörden | Sachverhalt, Betroffenenkreis, Maßnahmen | Meldeportal der Behörde | Innerhalb der gesetzlichen Frist |
| Versicherer | Schadenanzeige, Kostenfreigaben | Schadenhotline | Unverzüglich |
| Medien und Öffentlichkeit | Belastbarer Sachstand, keine Spekulation | Statement auf Website, benannter Ansprechpartner | Reaktiv, bei Anfragen |
Für Kunden ist eine Unterscheidung zwischen betroffenen und nicht betroffenen Vertragsverhältnissen hilfreich. Wer alle Kunden gleich anschreibt, erzeugt unnötige Nachfragen und bindet Kapazität im Vertrieb, die an anderer Stelle fehlt.
Textbausteine vorbereiten, ohne Fakten zu erfinden
Vorformulierte Bausteine sparen im Ernstfall Zeit, dürfen aber keine Aussagen enthalten, die zum Zeitpunkt der Nutzung nicht belegbar sind. Sätze wie „Es sind keine Kundendaten betroffen“ gehören nicht in eine Vorlage, weil sie im Moment der Erstinformation regelmäßig nicht gesichert sind. Bewährt hat sich stattdessen eine Struktur aus vier Elementen: Sachverhalt in dem Umfang, in dem er gesichert ist, ergriffene Maßnahmen, konkrete Handlungsempfehlung für den Adressaten und Ankündigung des nächsten Updates mit Zeitpunkt.
Der vierte Punkt wird häufig übersehen und ist der wirksamste. Eine feste Zusage, wann die nächste Information kommt, reduziert Rückfragen erheblich und verschafft dem Krisenstab Arbeitsruhe. Die Zusage muss dann allerdings eingehalten werden, auch wenn es nichts Neues zu berichten gibt.
Sprachliche Leitlinien
- Keine Verharmlosung durch Begriffe wie „technische Störung“, wenn ein Angriff vorliegt.
- Keine Schuldzuweisungen an Dienstleister oder Beschäftigte, solange die Ursache nicht geklärt ist.
- Keine Details zu Angriffsvektoren, Sicherheitslücken oder Verhandlungsständen, die Nachahmern nützen.
- Aktive Formulierungen mit klarem Absender statt unpersönlicher Passivkonstruktionen.
- Konsistente Terminologie über alle Kanäle, damit Zitate nicht gegeneinander gestellt werden können.
Ausweichinfrastruktur für den Kommunikationsfall
Ein Kommunikationsplan setzt Kommunikationsmittel voraus, die vom Vorfall nicht betroffen sind. Wenn Active Directory, Exchange und Telefonanlage in derselben kompromittierten Umgebung liegen, fällt die gesamte Kommunikationsfähigkeit gleichzeitig aus. Die Ausweichinfrastruktur sollte technisch und organisatorisch getrennt sein.
- Ein E-Mail-Postfach bei einem externen Anbieter unter einer separaten Domain, das nicht mit dem Unternehmensverzeichnisdienst gekoppelt ist.
- Ein Messenger- oder Konferenzdienst, der ohne Unternehmenskonten funktioniert und dessen Zugangsdaten offline hinterlegt sind.
- Eine Kontaktliste in Papierform mit privaten Rufnummern, deren Verarbeitung datenschutzrechtlich sauber auf Grundlage einer Einwilligung oder einer Betriebsvereinbarung geregelt ist.
- Eine vorbereitete Statusseite, die außerhalb der eigenen Hosting-Umgebung liegt und kurzfristig freigeschaltet werden kann.
- Ein separater Zugang zum Meldeportal der Aufsichtsbehörde, inklusive hinterlegter Zugangsdaten außerhalb des Passwortmanagers im betroffenen Netz.
Diese Komponenten kosten wenig, verfallen aber ohne Pflege. Zugangsdaten laufen ab, Ansprechpartner wechseln, Domains werden nicht verlängert. Eine halbjährliche Funktionsprüfung mit dokumentiertem Ergebnis gehört deshalb in den Regelbetrieb und lässt sich gut an bestehende Prüfzyklen nach ISO 27001 anhängen, insbesondere an die Anforderungen zur Verfügbarkeit von Informations- und Kommunikationstechnik im Kontext der Betriebskontinuität.
Üben, dokumentieren, nachbessern
Ein Kommunikationsplan, der nie geübt wurde, ist eine Absichtserklärung. Wirksam sind Übungsformate, die bewusst Kommunikationsdruck erzeugen, statt nur technische Wiederanlaufschritte abzufragen. In einer Tabletop-Übung lässt sich das gut abbilden, indem die Übungsleitung Einspielungen vorbereitet: eine Presseanfrage nach vier Stunden, ein Kunde, der mit Vertragsstrafen droht, eine Fehlinformation, die über soziale Netzwerke verbreitet wird.
Bewertungskriterien für die Übungsauswertung
| Kriterium | Messgröße | Typische Schwachstelle |
|---|---|---|
| Erreichbarkeit | Zeit bis zur Vollzähligkeit des Krisenstabs | Veraltete Rufnummern, fehlende Vertretung |
| Freigabegeschwindigkeit | Zeit vom Textentwurf bis zur Freigabe | Unklare Zuständigkeit bei Abwesenheit |
| Konsistenz | Abweichungen zwischen internen und externen Aussagen | Parallele Kommunikation aus dem Vertrieb |
| Fristenkontrolle | Rechtzeitige Vorlage der Meldeentwürfe | Bekanntwerdenszeitpunkt nicht dokumentiert |
| Dokumentationsqualität | Vollständigkeit des Protokolls mit Zeitstempeln | Protokoll wird erst nachträglich erstellt |
Die Auswertung sollte in konkrete Maßnahmen mit Verantwortlichen und Terminen münden. Ein Übungsbericht ohne Maßnahmenplan erzeugt keinen Reifegradfortschritt und ist im Auditfall wenig wert.
Typische Stolperfallen in der Praxis
- Erste Aussage zu früh: Eine Entwarnung am ersten Tag muss oft zurückgenommen werden, sobald die Forensik einen Datenabfluss belegt.
- Interne Information nach der externen: Beschäftigte erfahren aus der Presse von der Lage und verlieren Vertrauen in die Führung.
- Kein benannter Ansprechpartner: Anfragen laufen ungesteuert in Fachabteilungen und erzeugen widersprüchliche Antworten.
- Meldefrist auf den Angriffszeitpunkt bezogen: Der maßgebliche Zeitpunkt ist das Bekanntwerden, was ohne Dokumentation schwer nachweisbar bleibt.
- Kommunikation im kompromittierten System: Angreifer lesen die Abstimmung des Krisenstabs mit und passen ihr Vorgehen an.
- Fehlende Betroffenenliste: Ohne aktuelles Verarbeitungsverzeichnis lässt sich der Kreis der zu informierenden Personen nicht bestimmen.
Schritt für Schritt zum belastbaren Plan
- Bestehenden IT-Notfallplan sichten und alle kommunikationsbezogenen Aufgaben herauslösen.
- Stakeholder-Matrix erstellen und je Zielgruppe Kanal, Verantwortung und Frist festlegen.
- Rollen des Krisenstabs mit Vertretungen benennen und schriftlich beauftragen.
- Eskalationsstufen definieren und mit dem technischen Incident-Prozess synchronisieren.
- Melde- und Informationspflichten aus Gesetz, Verträgen und Versicherungspolicen zusammentragen.
- Textbausteine je Zielgruppe und Eskalationsstufe entwerfen und rechtlich prüfen lassen.
- Ausweichinfrastruktur aufbauen, Zugangsdaten offline hinterlegen, Funktionsprüfung terminieren.
- Plan in einer Übung testen, Schwachstellen dokumentieren, Maßnahmen umsetzen.
- Jährliche Überprüfung im Managementreview verankern und Änderungen versionieren.
Der Aufwand für die Ersterstellung liegt in mittelständischen Organisationen erfahrungsgemäß im Bereich weniger Personentage, verteilt auf IT, Recht, Kommunikation und Geschäftsführung. Der laufende Pflegeaufwand ist gering, sofern die Verantwortlichkeit klar zugeordnet ist. Entscheidend ist weniger der Umfang des Dokuments als die Frage, ob die benannten Personen im Ernstfall wissen, was sie in den ersten sechzig Minuten tun.
FAQ
Wer entscheidet, ob der Krisenstab für die Krisenkommunikation im IT-Notfall aktiviert wird?
Die Auslösebefugnis sollte breit verteilt sein, damit keine Zeit verloren geht. In der Praxis erhalten die IT-Leitung, der Datenschutzbeauftragte und die Geschäftsführung ein eigenständiges Auslöserecht. Die spätere Herabstufung bleibt dagegen der Krisenstabsleitung vorbehalten.
Muss ein Vorfall immer öffentlich kommuniziert werden?
Nein. Eine proaktive öffentliche Kommunikation ist nur dann geboten, wenn eine gesetzliche Pflicht besteht, wenn Betroffene selbst Schutzmaßnahmen ergreifen müssen oder wenn der Vorfall ohnehin sichtbar ist. Meldepflichten gegenüber Behörden und vertragliche Informationspflichten bestehen davon unabhängig.
Wie lässt sich der Zeitpunkt des Bekanntwerdens sauber dokumentieren?
Sinnvoll ist ein Ereignisprotokoll, das mit dem ersten Hinweis beginnt und jede Erkenntnis mit Datum, Uhrzeit, Quelle und Empfänger festhält. Das Protokoll sollte außerhalb der betroffenen Systeme geführt und nachträglich nicht verändert werden, sondern nur ergänzt.
Welche Rolle spielt der Cyberversicherer in der Kommunikation?
Viele Policen sehen vor, dass Krisenkommunikation und externe Beratung nur nach vorheriger Abstimmung erstattet werden. Eine frühzeitige Schadenanzeige und die Klärung, welche Dienstleister freigegeben sind, verhindern spätere Deckungsstreitigkeiten.
Wie oft sollte der Kommunikationsplan geübt werden?
Eine jährliche Übung mit Kommunikationsschwerpunkt ist ein realistischer Mindeststandard. Ergänzend genügt eine halbjährliche technische Funktionsprüfung der Ausweichkanäle und der Erreichbarkeitslisten, die deutlich weniger Aufwand verursacht.
Was gehört keinesfalls in eine externe Erstinformation?
Nicht kommuniziert werden sollten Angriffsvektoren, konkrete Schwachstellen, forensische Zwischenergebnisse, Verhandlungsstände mit Angreifern und Schuldzuweisungen. Ebenso ungeeignet sind Aussagen zur Betroffenheit von Daten, solange die Analyse nicht abgeschlossen ist.
