Einen Incident Response Plan auf Deutsch erstellen: Was muss rein, damit er in einer echten Krise funktioniert?

Wir hatten einen ähnlichen Prozess mit einem Automobilzulieferer in Stuttgart. Die Prüfer schauen nicht nur auf den Text, sondern darauf, ob im Krisenfall die Rufbereitschaft erreichbar ist. Definiert im Dokument unbedingt einen einzigen rund um die Uhr erreichbaren deutschen Kommunikationskanal, zum Beispiel eine Notfall-E-Mail und eine Zentrale-Hotline.

Verwendet die Begriffe aus den deutschen BSI-Standards wortwörtlich: Eindämmung (containment), Beseitigung (eradication) und Wiederherstellung (recovery). Wenn ihr für euer Technikteam die englischen Entsprechungen in Klammern dahinter setzt, nimmt der Prüfer das nicht übel, sondern sieht es im Gegenteil als internationalen Engineering-Standard.

Letztes Jahr hatten wir für die Erstellung dieses Plans bei einem Beratungsunternehmen in Frankfurt angefragt – die wollten 6.500 EUR. Das war uns zu teuer, also haben wir den Entwurf selbst geschrieben und für 1.200 EUR von einem lokalen IT-Anwalt in 4 Stunden rechtlich prüfen lassen. Das Audit haben wir damit völlig problemlos bestanden.

Will euer Kunde den Plan nur auf dem Papier sehen oder verlangt er auch ein Protokoll von einer Tabletop Exercise aus dem letzten Jahr? Große Konzerne haken meistens auch nach, wann der Plan das letzte Mal getestet wurde.

Als Erstes solltet ihr vorgefertigte Meldevorlagen für die DSGVO in den Plan packen. Der Link zum Meldeformular der zuständigen Landesdatenschutzbehörde und die Stammdaten eures Unternehmens müssen griffbereit in der Datei stehen. Wenn es brennt, hat niemand Zeit, nach Formularen zu suchen.

Vor zwei Jahren hatten wir mal einen Verdacht auf unberechtigten Zugriff: Unser Tech-Team hat auf Englisch kommuniziert, während der Manager des deutschen Kunden völlig in Panik auf Deutsch Sturm geklingelt hat. Keiner hat den anderen verstanden, und wegen 3 Stunden Verzögerung wäre fast der Vertrag gekündigt worden. Seitdem haben wir im Plan einen festen deutschsprachigen Krisensprecher definiert – Problem komplett gelöst.

lasst euch von den deutschen begriffen nicht abschrecken aber gebt das bloß nicht mit deepl/google translate ab der auditor checkt das auf seite 1. am saubersten ist es gesetzliche meldungen auf deutsch und die server- bzw. code-schritte als englisches runbook zu machen.

Im entsprechenden Dokument sollten Rollen unbedingt über Funktionsbezeichnungen und nicht über Personennamen definiert werden. Damit das Dokument bei Personalwechseln seine Gültigkeit behält, empfiehlt sich das Prinzip der rollenbasierten Zuständigkeit sowie eine lückenlos gepflegte Revisionshistorie.

Dieses Thema ist archiviert.

Ich stimme zu.

Ich bin ein kleines Unternehmen, ich erzähle es aus meiner Sicht. Wenn du das nicht von Anfang an schriftlich festhältst, gibt es später Streit.

Ich schreibe kurz, wie das in der Praxis gemacht wird. Überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss.

Ich habe diesen Weg schon hinter mir, ich erzähl mal. Ein automatisierter Scan-Report ist kein Penetrationstest.

Das war's, entschuldige, wenn ich zu lang war.

Ich erzähle mal, was mir passiert ist, vielleicht hilft es euch. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.

Ich hoffe, das hilft dir weiter.

So klar geschriebene Texte sind selten. Lösungen, die im kleinen Maßstab funktionieren, brechen bei Wachstum zusammen, das habe ich spät gelernt.

Viel Erfolg.

Das hier Beschriebene ist genau das, was wir erlebt haben. Menschen verteidigen nicht den Prozess, sondern die Gewohnheit. Der Widerstand kommt daher.

Wenn Genehmigung und Umfang nicht schriftlich vorliegen, darf der Test nicht starten.

Das habe ich auch erlebt. Änderungen an Zahlungsdaten werden niemals über den Kanal bestätigt, über den sie eingehen.

Wenn es jemand anders macht, würde mich das auch interessieren.

Funktioniert das deiner Meinung nach in jeder Größe? Schaut zuerst, welche Daten ihr bei der Entscheidungsfindung zur Hand habt.