Tabletop-Übung planen und durchführen: So testest du deinen Notfallplan

Warum Notfallpläne getestet werden müssen

Ein Notfallplan ist nur so gut wie sein letzter Test. Das klingt nach einer Binsenweisheit, trifft aber auf eine Realität, in der die Mehrheit der mittelständischen Unternehmen ihre Notfallpläne nie oder bestenfalls einmal nach der Erstellung getestet hat.

Das Problem liegt auf der Hand: Ein Notfallplan wird unter ruhigen Bedingungen geschrieben. Am Schreibtisch, mit viel Zeit und klarem Kopf. Im Ernstfall sind die Bedingungen grundlegend anders: Stress, Zeitdruck, unvollständige Informationen, verunsicherte Mitarbeiter. Und genau unter diesen Bedingungen zeigt sich, ob der Plan funktioniert.

Die häufigsten Probleme, die bei Tests auffallen:

• Unklare Zuständigkeiten: Der Plan nennt Rollen, aber die konkreten Personen wissen nicht, dass sie diese Rolle haben.
• Veraltete Kontaktdaten: Der IT-Dienstleister hat eine neue Hotline-Nummer, die Mobilnummer des IT-Leiters hat sich geändert.
• Fehlende Entscheidungskompetenz: Niemand weiß, wer im Abwesenheitsfall des Geschäftsführers bestimmte Entscheidungen treffen darf.
• Unrealistische Zeitvorgaben: Der Plan sieht 30 Minuten für die Lagebeurteilung vor, in der Praxis braucht allein die Erreichbarkeit des Teams 45 Minuten.
• Kommunikationslücken: Alle kümmern sich um die technische Behebung, aber niemand informiert die Mitarbeiter oder Kunden.

Eine Tabletop-Übung deckt diese Schwächen auf, ohne dass du dafür Systeme herunterfahren oder den Geschäftsbetrieb unterbrechen musst. Sie ist das ideale Format für den Einstieg in Notfallübungen.

Übungstypen im Überblick

Bevor wir in die Details der Tabletop-Übung einsteigen, ein Überblick über die vier gängigen Übungstypen. Sie unterscheiden sich in Komplexität, Aufwand und Realitätsnähe.

Tabletop-Übung (Planspiel)

• Format: Moderierte Diskussionsrunde am Tisch
• Dauer: 2 bis 4 Stunden
• Teilnehmer: 6 bis 15 Personen
• Realitätsnähe: Mittel (reine Diskussion, keine technischen Aktionen)
• Aufwand: Gering (1-2 Wochen Vorbereitung)
• Geeignet für: Einstieg, jährliche Routine, neue Szenarien testen
• Kosten: Minimal (nur Personalzeit)

Die Tabletop-Übung ist das Arbeitspferd unter den Notfallübungen. Sie ist vergleichsweise schnell vorbereitet, erfordert keine technische Infrastruktur und bringt die richtigen Leute an einen Tisch. Die Teilnehmer besprechen, wie sie auf ein fiktives Szenario reagieren würden, Schritt für Schritt, moderiert durch einen Übungsleiter.

Walkthrough-Übung

• Format: Detaillierter Durchgang durch den Notfallplan anhand eines Szenarios
• Dauer: 4 bis 8 Stunden
• Teilnehmer: 8 bis 20 Personen (inkl. operative Teams)
• Realitätsnähe: Mittel bis hoch (Prozesse werden im Detail durchgegangen, aber nicht ausgeführt)
• Aufwand: Mittel (2-4 Wochen Vorbereitung)
• Geeignet für: Validierung neuer oder überarbeiteter Pläne, Training neuer Teammitglieder

Die Walkthrough-Übung geht tiefer als die Tabletop-Übung. Hier wird nicht nur diskutiert, was man tun würde, sondern Schritt für Schritt der Notfallplan durchgegangen: Seite 5, Abschnitt 3, Schritt 1 - wer macht das? Wie genau? Wo steht die Anleitung? Die Teilnehmer haben den Notfallplan vor sich und prüfen, ob er vollständig und verständlich ist.

Simulation

• Format: Realitätsnahe Übung mit simulierten Systemausfällen oder Angriffen
• Dauer: 4 bis 8 Stunden (aktive Übung) + Vorbereitung und Auswertung
• Teilnehmer: 10 bis 30 Personen (alle operativen Teams)
• Realitätsnähe: Hoch (Systeme werden in einer Testumgebung tatsächlich wiederhergestellt)
• Aufwand: Hoch (4-8 Wochen Vorbereitung, ggf. Testumgebung aufbauen)
• Geeignet für: Validierung der technischen Recovery-Fähigkeit, Erfüllung regulatorischer Anforderungen

Bei einer Simulation wird es technisch: Ein Restore aus dem Backup wird durchgeführt, die Wiederherstellungszeiten werden gemessen, und die Teams arbeiten unter simulierten Stressbedingungen. Das erfordert deutlich mehr Vorbereitung, liefert aber auch die härtesten Erkenntnisse.

Full Exercise (Vollübung)

• Format: Komplette Notfallübung unter realistischen Bedingungen, ggf. ohne Vorwarnung
• Dauer: 1 bis 3 Tage
• Teilnehmer: Gesamtes Unternehmen oder große Teile
• Realitätsnähe: Sehr hoch (möglichst nah am Ernstfall)
• Aufwand: Sehr hoch (2-3 Monate Vorbereitung)
• Geeignet für: Organisationen mit hoher Reife, regulatorische Anforderungen (z. B. KRITIS-Betreiber)

Die Vollübung ist die Königsdisziplin. Sie ist teuer, aufwändig und disruptiv, liefert aber Erkenntnisse, die kein anderes Format bieten kann. Für die meisten mittelständischen Unternehmen ist sie erst sinnvoll, wenn die grundlegenden Prozesse bereits stabil sind.

Welcher Typ passt zu dir?

Für den Mittelstand ist die Tabletop-Übung der richtige Einstieg. Sie hat das beste Verhältnis von Aufwand zu Erkenntnisgewinn und lässt sich auch ohne dediziertes BCM-Team durchführen.

Eine Tabletop-Übung planen

Die Planung einer Tabletop-Übung dauert typischerweise ein bis zwei Wochen. Der größte Aufwand liegt in der Szenarioentwicklung und der Terminkoordination.

Ziele definieren

Bevor du das Szenario entwickelst, definiere klar, was die Übung erreichen soll. Die Ziele bestimmen das Szenario, die Teilnehmer und die Auswertungskriterien.

Typische Ziele:

• Prüfen, ob die Eskalationsketten im Notfallhandbuch funktionieren
• Testen, ob alle Beteiligten ihre Rollen und Verantwortlichkeiten kennen
• Identifizieren von Kommunikationslücken zwischen IT und Fachbereichen
• Prüfen, ob die Meldepflichten (BSI, Datenschutz) im Team bekannt sind
• Sensibilisierung der Geschäftsführung für Krisenmanagement-Themen

Formuliere die Ziele konkret und messbar. "Testen des Notfallplans" ist zu vage. "Prüfen, ob die Eskalation von Stufe 2 auf Stufe 3 innerhalb von 15 Minuten erfolgt und die richtigen Personen informiert werden" ist konkret genug, um anschließend bewerten zu können, ob das Ziel erreicht wurde.

Szenario entwickeln

Das Szenario ist das Herzstück der Übung. Es muss realistisch genug sein, um ernst genommen zu werden, und komplex genug, um echte Diskussionen auszulösen.

Eigenschaften eines guten Szenarios:

• Realistisch: Es könnte deinem Unternehmen tatsächlich passieren. Ein Ransomware-Angriff auf einen Maschinenbauer ist realistisch. Ein Asteroiden-Einschlag ist es nicht.
• Schrittweise eskalierend: Das Szenario beginnt harmlos und wird zunehmend ernster. Das erzeugt natürliche Diskussionspunkte und zeigt, ab wann die Teilnehmer eskalieren.
• Mehrdeutig: Nicht alle Informationen liegen sofort vor. Die Teilnehmer müssen Entscheidungen unter Unsicherheit treffen - genau wie im Ernstfall.
• Zeitsensibel: Es gibt Fristen (NIS2-Meldefristen: 24 Stunden, DSGVO: 72 Stunden), die berücksichtigt werden müssen.
• Bereichsübergreifend: Das Szenario berührt nicht nur die IT, sondern auch Geschäftsführung, Kommunikation, Recht und Fachbereiche.

Beispiel-Szenario: Ransomware-Angriff (dreistufig)

Phase 1 (Entdeckung): Montag, 8:30 Uhr

Mehrere Mitarbeiter melden sich beim Helpdesk: Sie können sich nicht am ERP-System anmelden. Der Helpdesk stellt fest, dass der ERP-Server nicht erreichbar ist. Auf der Konsole des Servers erscheint eine Meldung mit einer Lösegeldforderung in Höhe von 2 Bitcoin (ca. 180.000 Euro). Die Dateien auf dem Server sind verschlüsselt.

Fragen an die Teilnehmer:

• Was sind eure ersten drei Maßnahmen?
• Wen informiert ihr zuerst und über welchen Kanal?
• Welche Eskalationsstufe greift?

Phase 2 (Eskalation): Montag, 10:00 Uhr

Die Untersuchung zeigt: Nicht nur der ERP-Server ist betroffen. Auch der Fileserver und zwei weitere Server sind verschlüsselt. Die Angreifer scheinen seit mindestens drei Tagen im Netzwerk gewesen zu sein. Auf dem Fileserver lagen auch Kundendaten und Personaldaten. Hier wird die DSGVO-Datenpanne zum Thema. Erste Medienanfragen gehen ein - ein Kunde hat auf LinkedIn gepostet, dass er keine Lieferung erhalten hat und das Unternehmen nicht erreichbar sei.

Fragen an die Teilnehmer:

• Wie bewertet ihr die Lage jetzt?
• Wer kommuniziert was nach außen?
• Welche Meldepflichten bestehen? An wen und bis wann?
• Wie geht ihr mit der Lösegeldforderung um?
• Welche Daten sind potenziell abgeflossen? Was bedeutet das?

Phase 3 (Recovery-Entscheidung): Montag, 14:00 Uhr

Die Backups wurden überprüft. Das letzte unbeschädigte Full-Backup des ERP-Servers ist von Freitag, 22:00 Uhr. Die Transaction-Log-Backups von Samstag und Sonntag sind ebenfalls verschlüsselt. Das bedeutet: Im besten Fall verliert ihr die Daten von Montag vor dem Angriff (ca. 2 Stunden Arbeit), im schlimmsten Fall die Daten seit Freitag 22:00 Uhr. Der externe Forensik-Dienstleister ist erst morgen früh verfügbar. Die Produktion steht weiterhin still.

Fragen an die Teilnehmer:

• Wie priorisiert ihr die Wiederherstellung?
• Könnt ihr Systeme sicher wiederherstellen, ohne die Angreifer wieder ins Netzwerk zu lassen?
• Wie lange kann die Produktion stillstehen?
• Braucht ihr externe Hilfe? Wenn ja, wen?
• Wie kommuniziert ihr den Status an Mitarbeiter und Kunden?

Teilnehmer auswählen

Die Auswahl der Teilnehmer bestimmt die Qualität der Diskussion. Lade die Personen ein, die im Ernstfall tatsächlich beteiligt wären.

Kerngruppe (sollte bei jeder Übung dabei sein):

• Geschäftsführung (mindestens ein Mitglied)
• IT-Leiter und Stellvertreter
• Informationssicherheitsbeauftragter (falls vorhanden)
• Datenschutzbeauftragter

Erweiterte Gruppe (je nach Szenario):

• Leitung Produktion / Operations
• Leitung Vertrieb / Kundenbetreuung
• Leitung Personal / HR
• Leitung Finanzen
• Unternehmenskommunikation / PR
• Externer IT-Dienstleister (optional, aber wertvoll)

Rollen während der Übung:

• Übungsleiter (Facilitator): Leitet die Diskussion, präsentiert das Szenario, stellt gezielte Fragen, hält den Fokus. Idealerweise eine Person, die nicht selbst im Notfallteam ist.
• Beobachter/Protokollant: Dokumentiert die Diskussion, notiert Findings, hält Entscheidungen und offene Punkte fest. Mindestens eine Person, besser zwei.
• Teilnehmer: Alle anderen. Sie diskutieren, treffen Entscheidungen, identifizieren Lücken.

Checkliste: Vorbereitung der Tabletop-Übung

PLANUNG (2-4 Wochen vorher)
□ Ziele der Übung definiert
□ Szenario entwickelt (mit Phasen und Fragen)
□ Teilnehmerliste erstellt und mit Terminen abgeglichen
□ Übungsleiter bestimmt
□ Beobachter/Protokollant bestimmt
□ Raum reserviert (mit Beamer/Bildschirm, Whiteboard, Flipchart)

VORBEREITUNG (1 Woche vorher)
□ Einladung verschickt mit: Termin, Ort, Dauer, Ziel der Übung (NICHT das Szenario!)
□ Teilnehmer gebeten, den aktuellen Notfallplan vorher zu lesen
□ Szenario-Unterlagen erstellt (Handouts für jede Phase)
□ Auswertungsbogen vorbereitet (welche Aspekte beobachten?)
□ Aktuellen Notfallplan in ausreichender Anzahl ausgedruckt
□ Namensschilder mit Rollen vorbereitet (Übungsleiter, Beobachter, Teilnehmer)

AM TAG DER ÜBUNG
□ Raum vorbereitet (Bestuhlung, Technik, Getränke)
□ Notfallplan und Handouts verteilt
□ Namensschilder aufgestellt
□ Protokollvorlage bereit
□ Zeitplan an die Wand gehängt oder auf Folie

Eine Tabletop-Übung durchführen

Ablauf (Zeitplan für 3 Stunden)

Begrüßung und Spielregeln

Der Übungsleiter eröffnet die Übung mit einer kurzen Einführung:

• Zweck: Dies ist eine Lern- und Verbesserungsübung, keine Prüfung. Es gibt kein Richtig oder Falsch.
• Vertraulichkeit: Was in dieser Übung besprochen wird, bleibt in diesem Raum. Niemand wird für falsche Antworten bloßgestellt.
• Realismus: Bitte antwortet so, wie ihr im Ernstfall handeln würdet, nicht wie es im Plan steht. Wenn ihr den Plan nicht kennt, sagt das. Das ist ein valides Finding.
• Zeitrahmen: Wir haben drei Stunden. Ich werde die Diskussion lenken und ggf. weiterführen, wenn wir bei einem Punkt zu lange verweilen.
• Handys: Bitte stumm schalten. Wir brauchen die volle Aufmerksamkeit.

Durchführung der Szenario-Phasen

Der Übungsleiter präsentiert Phase 1 des Szenarios, idealerweise über Beamer oder als Handout. Die Teilnehmer haben einige Minuten Zeit, die Situation zu erfassen. Dann beginnt die Diskussion.

Tipps für den Übungsleiter:

• Offene Fragen stellen: "Was wären eure ersten drei Maßnahmen?" statt "Würdet ihr den Server herunterfahren?"
• Nachfragen: Wenn jemand sagt "Ich würde den Dienstleister anrufen", frage nach: "Welchen Dienstleister? Hast du die Nummer? Wie erreichst du ihn außerhalb der Geschäftszeiten?"
• Ruhige Teilnehmer einbeziehen: "Frau Schmidt, aus Sicht der Buchhaltung - was bedeutet der ERP-Ausfall für Ihren Bereich?"
• Gruppendynamik steuern: Nicht den Lautesten das Gespräch dominieren lassen. In einer echten Krise müssen alle gehört werden.
• Zeitdruck simulieren: "Wir sind jetzt bei 10:00 Uhr. Die 24-Stunden-Frist für die BSI-Meldung läuft seit 8:30 Uhr. Wer hat die Meldung vorbereitet?"
• Notfallplan einbeziehen: "Schaut in den Notfallplan: Was steht dort für dieses Szenario? Findet ihr die Information schnell?"

Was beobachtet werden sollte

Der Beobachter achtet auf folgende Aspekte und dokumentiert seine Beobachtungen:

Kommunikation:

• Wird die Eskalationskette eingehalten?
• Werden alle relevanten Personen informiert?
• Werden Kunden und Partner berücksichtigt?
• Wird die interne Kommunikation an Mitarbeiter bedacht?

Entscheidungsfindung:

• Wer trifft welche Entscheidungen?
• Gibt es klare Entscheidungskompetenz?
• Werden Entscheidungen dokumentiert?
• Wie wird mit Unsicherheit umgegangen?

Notfallplan-Nutzung:

• Wird der Notfallplan herangezogen?
• Finden die Teilnehmer die relevanten Informationen schnell?
• Sind die Informationen vollständig und aktuell?
• Fehlen Informationen, die im Ernstfall gebraucht würden?

Meldepflichten:

• Werden Meldepflichten (BSI, DSGVO) erkannt?
• Kennen die Teilnehmer die Fristen?
• Weiß jemand, wie die Meldung praktisch abgesetzt wird?
• Ist klar, wer die Meldung verfasst und absetzt?

Zusammenarbeit:

• Arbeiten IT und Fachbereiche zusammen oder nebeneinander her?
• Wird die Geschäftsführung einbezogen?
• Werden externe Partner (Dienstleister, Forensik) rechtzeitig kontaktiert?

Auswertung und Feedback

Die letzten 25 Minuten der Übung sind mindestens so wichtig wie das Szenario selbst. Hier werden die Erkenntnisse verdichtet.

Struktur der Auswertung:

1. Blitzrunde: Jeder Teilnehmer nennt in einem Satz seine wichtigste Erkenntnis.
2. Was lief gut: Welche Aspekte haben funktioniert? Was hat das Team gut gemacht?
3. Was muss verbessert werden: Welche Lücken sind aufgefallen? Wo hat es gehakt?
4. Top-3-Prioritäten: Gemeinsam die drei wichtigsten Verbesserungsmaßnahmen identifizieren.
5. Nächste Schritte: Wer macht was bis wann?

Findings dokumentieren und bewerten

Die Dokumentation der Findings ist der Hebel, der aus einer Diskussionsrunde eine messbare Verbesserung macht. Ohne saubere Dokumentation und Nachverfolgung verpuffen die Erkenntnisse.

Finding-Kategorien

Strukturiere die Findings in Kategorien, um sie priorisieren und zuordnen zu können:

Bewertungsmatrix für Findings

Nicht alle Findings haben die gleiche Dringlichkeit. Eine einfache Bewertungsmatrix hilft bei der Priorisierung:

Übungsbericht

Der Übungsbericht ist das formale Ergebnis der Tabletop-Übung. Er dokumentiert den Ablauf, die Erkenntnisse und die abgeleiteten Maßnahmen. Für regulatorische Anforderungen (NIS2, ISO 27001) ist er gleichzeitig der Nachweis, dass du deine Notfallpläne testest.

Aufbau des Übungsberichts:

ÜBUNGSBERICHT: TABLETOP-ÜBUNG [Datum]

1. Rahmendaten
   - Datum, Ort, Dauer
   - Teilnehmer (mit Rollen)
   - Übungsziele

2. Szenario-Beschreibung
   - Kurzfassung des Szenarios mit allen Phasen

3. Verlauf
   - Zusammenfassung der Diskussion und Entscheidungen pro Phase
   - Beobachtungen des Protokollanten

4. Findings
   - Tabellarische Auflistung aller Findings mit Kategorie und Bewertung

5. Maßnahmenplan
   - Priorisierte Liste der Maßnahmen
   - Verantwortlicher und Frist pro Maßnahme

6. Fazit und Empfehlungen
   - Gesamtbewertung
   - Empfehlung für nächste Übung (Typ, Szenario, Zeitpunkt)

Follow-up: Aus Findings werden Maßnahmen

Die eigentliche Arbeit beginnt nach der Übung. Die Findings müssen in konkrete Maßnahmen überführt und nachverfolgt werden. Sonst war die Übung eine nette Teambuilding-Maßnahme, aber keine Verbesserung.

Maßnahmenplan erstellen

Für jedes Finding mit der Bewertung "Kritisch" oder "Hoch" wird eine Maßnahme definiert:

Nachverfolgung

Der Maßnahmenplan wird nicht einmal erstellt und dann vergessen. Plane einen festen Termin 4 bis 6 Wochen nach der Übung, um den Stand der Maßnahmen zu prüfen. Die offenen Punkte werden abgearbeitet, bis alle Maßnahmen abgeschlossen oder bewusst zurückgestellt sind.

In ISMS Lite werden Findings als Maßnahmen erfasst und können mit Verantwortlichen, Fristen und Status nachverfolgt werden, 500 Euro pro Jahr für alle Module ohne Benutzerlimit. Die nächste Tabletop-Übung zeigt dann, ob die Maßnahmen tatsächlich gegriffen haben.

Wie oft solltest du üben?

Die Antwort hängt vom Reifegrad deines BCM ab:

Minimum: Einmal pro Jahr eine Tabletop-Übung. Das ist die Empfehlung für Unternehmen, die gerade erst anfangen, und gleichzeitig die Mindestfrequenz, die Auditoren bei ISO 27001 oder NIS2 erwarten.

Empfohlen: Zweimal pro Jahr, mit unterschiedlichen Szenarien. Im Frühjahr ein Ransomware-Szenario, im Herbst ein Rechenzentrumsausfall. So deckst du verschiedene Bedrohungsarten ab.

Fortgeschritten: Vierteljährlich verschiedene Formate. Q1: Tabletop-Übung, Q2: Restore-Test, Q3: Walkthrough mit neuem Szenario, Q4: Simulation oder angekündigter Notfalltest.

Zusätzlich zu den geplanten Übungen sollte nach jedem realen Sicherheitsvorfall ein Lessons-Learned-Workshop stattfinden, der die Erkenntnisse aus dem Vorfall in den Notfallplan einfließen lässt.

Szenarien-Bibliothek: Fünf Szenarien zum Starten

Falls du Inspiration für Szenarien brauchst, hier fünf Vorschläge, die für mittelständische Unternehmen relevant und realistisch sind:

Szenario A: Ransomware mit Datenabfluss

Der oben beschriebene Klassiker. Verschlüsselung plus möglicher Datenabfluss. Testet: Incident Response, Kommunikation, Meldepflichten, Backup/Restore-Entscheidung, Umgang mit Lösegeldforderung.

Szenario B: Ausfall des Cloud-Providers

Euer Microsoft-365-Tenant ist seit 6 Stunden nicht erreichbar. E-Mail, Teams, SharePoint, OneDrive - alles offline. Microsoft meldet ein "Service-Degradation" ohne ETA für die Behebung. Testet: Abhängigkeit von Cloud-Diensten, Kommunikation ohne E-Mail, manuelle Workarounds, Informationspolitik gegenüber Kunden.

Szenario C: Insider-Bedrohung

Ein kürzlich gekündigter Mitarbeiter hat vor seinem Austritt größere Datenmengen auf einen USB-Stick kopiert. Die Zugriffsrechte wurden erst drei Tage nach dem letzten Arbeitstag entzogen - ein typisches Problem bei fehlendem User-Lifecycle-Management. Es handelt sich um Konstruktionszeichnungen und Kundenlisten. Testet: Offboarding-Prozess, Zugriffskontrolle, Beweissicherung, rechtliche Schritte, Kommunikation.

Szenario D: Lieferkettenangriff

Ein Software-Update eures Antiviren-Herstellers hat einen Fehler: Nach der Installation starten die Rechner nicht mehr (Bluescreen). 80 % der Arbeitsplätze und 60 % der Server sind betroffen. Testet: Umgang mit Massenausfall, Priorisierung der Wiederherstellung, Koordination mit dem Softwarehersteller, alternative Arbeitsumgebungen.

Szenario E: Physischer Zwischenfall

Wasserrohrbruch über dem Serverraum am Wochenende. Der Hausmeister bemerkt den Schaden am Sonntagabend. Mehrere Server und das Storage-System zeigen Wasserschäden. Die USV hat abgeschaltet. Testet: Notfallkette außerhalb der Geschäftszeiten, Versicherungsmeldung, Ausweichstandort, Restore von Offsite-Backup.

Typische Fehler bei Tabletop-Übungen

Fehler 1: Das Szenario ist zu einfach

"Der Mailserver fällt aus. Was tut ihr?" Darauf gibt es eine schnelle, offensichtliche Antwort, und die Übung ist nach 20 Minuten vorbei. Ein gutes Szenario eskaliert, enthält Mehrdeutigkeiten und zwingt zu schwierigen Entscheidungen.

Fehler 2: Die Geschäftsführung fehlt

Ohne die Geschäftsführung fehlen die Entscheidungsträger, die im Ernstfall über Budget, Kommunikation nach außen und strategische Entscheidungen bestimmen. Gleichzeitig ist die Übung eine Gelegenheit, die GF für das Thema zu sensibilisieren.

Fehler 3: Es wird nur über Technik gesprochen

Tabletop-Übungen drehen sich häufig ausschließlich um technische Fragen: Welchen Server stellen wir zuerst wieder her? Welches Backup nehmen wir? Die wichtigeren Fragen sind oft organisatorisch: Wer informiert die Kunden? Wer setzt die BSI-Meldung ab? Wer entscheidet über die Lösegeldforderung?

Fehler 4: Kein Follow-up

Die Übung war produktiv, die Teilnehmer haben viel gelernt, die Findings sind dokumentiert. Und dann passiert nichts. Sechs Monate später hat sich niemand um die identifizierten Lücken gekümmert. Ohne Follow-up ist die Übung wertlos.

Fehler 5: Schuldzuweisungen

Wenn die Übung zur Suche nach Schuldigen wird ("Warum hast du die Nummer nicht?"), schweigen die Teilnehmer beim nächsten Mal. Eine Tabletop-Übung ist eine Lernveranstaltung, kein Tribunal. Der Übungsleiter muss diese Atmosphäre von Anfang an setzen.

Nächste Schritte

Du hast jetzt alles, was du für die Planung und Durchführung einer Tabletop-Übung brauchst. Der pragmatische Weg:

1. Termin finden - Blockiere 3 Stunden, an denen IT-Leitung und Geschäftsführung teilnehmen können. Das ist oft der schwierigste Schritt.
2. Szenario auswählen - Für die erste Übung empfiehlt sich das Ransomware-Szenario. Es ist realistisch, relevant und erzeugt erfahrungsgemäß die besten Diskussionen.
3. Notfallplan bereithalten - Die Übung zeigt nur dann Lücken, wenn die Teilnehmer tatsächlich in den Plan schauen. Falls du noch keinen hast, lies den Artikel zum IT-Notfallhandbuch.
4. Übung durchführen - Folge dem Ablaufplan, halte die Findings fest.
5. Maßnahmen umsetzen - Das ist der Schritt, der den Unterschied macht. Keine Findings ohne Maßnahmen, keine Maßnahmen ohne Frist und Verantwortlichen.

Weiterführende Artikel

• Notfallhandbuch für die IT: Aufbau, Inhalt und PDF-Vorlage
• Incident Response Plan erstellen: Vorlage und Praxisbeispiel
• Wiederanlaufplan erstellen: Anleitung mit Vorlage für den Mittelstand
• Sicherheitsvorfall erkennen, bewerten und melden – der komplette Ablauf
• Backup-Strategie und Restore-Tests: Weil Backups allein nicht reichen

Im nächsten Schritt kannst du die Übung mit einem technischen Restore-Test kombinieren - dazu hilft der Artikel zu Backup-Strategien und Restore-Tests weiter.