Incident-Response-Playbook: ein praxistaugliches Template

Problem

Die meisten Incident-Response-Playbooks (das Drehbuch für den Sicherheitsvorfall), die man in Audits sieht, sind 60-seitige PDFs auf einem Netzlaufwerk, zuletzt angefasst vor drei Jahren, mit einer Rollenliste voller Menschen, die das Unternehmen zum Teil längst verlassen haben. Im echten Vorfall wird improvisiert, die 72-Stunden-Frist aus DSGVO Art. 33 wird gerissen, die NIS-2-Frühwarnung in 24 Stunden ebenso, und das Post-Mortem (die Nachbetrachtung des Vorfalls) wird wahlweise eher peinlich oder eine einfache Schuldzuweisungsrunde, dass es (angeblich) an jemand anderem lag. Das Playbook war dann nicht wertlos, sondern aktiv schädlich, weil es den Anschein von Vorbereitung erzeugt hat obwohl man ins offene Messer gelaufen ist.

Für wen ist das? Für IT- und Sicherheitsverantwortliche, die einen Vorfall ohne Improvisation bewältigen wollen.

Kurze Antwort

Ein im Stressfall benutzbares Playbook ist eher ein Satz Karteikarten als ein Buch und besteht aus fünf Bausteinen:

• Rollen-Matrix - wer macht im Vorfall was, nach Funktion statt nach Namen.
• Eskalations-Matrix - klare Stufen mit Zeitfenstern und Trigger-Kriterien.
• Kommunikations-Skripte - vorformuliert für intern, Kunden, Behörde, Presse.
• Technische Erstmaßnahmen - eine abhakbare Checkliste für die ersten 60 Minuten.
• Blameless Post-Mortem - eine Nachbetrachtung, die Ursachen sucht statt Schuldige.

Geübt wird mindestens zweimal jährlich, davon einmal als Tabletop (ein durchgesprochenes Planspiel am Tisch) mit Geschäftsleitung.

Tiefgang

Rollen-Matrix

Ein Incident braucht klar benannte Rollen, nicht Titel. Minimalbesetzung:

1. Incident Commander (IC). Einzige Person mit Entscheidungsbefugnis während des Vorfalls. Priorisiert, verteilt Aufgaben, schreibt Timeline mit. Nicht zwingend der technisch Fähigste, sondern der mit der klarsten Schreibe und dem kühlsten Kopf.
2. Tech Lead. Führt die technische Analyse, koordiniert Admins und Entwickler, liefert Lagebilder an den IC.
3. Comms Lead. Verantwortet interne und externe Kommunikation. Sendet nichts ohne Freigabe des IC.
4. Legal Contact. Bewertet Meldepflichten nach DSGVO Art. 33/34, NIS-2, sektorspezifischem Recht (DORA, BAIT, KRITIS). Bei kleineren Organisationen extern auf Abruf.
5. Melde-Autorisierte. Einzige Personen mit Zugang zu den Behörden-Meldeportalen (BSI-Meldeportal NIS-2, Datenschutzaufsicht). Zwei Personen plus Vertretung; Zugangstokens im Passwort-Tresor mit Bruch-Glas-Verfahren (ein nur im Notfall zu öffnender, protokollierter Zugang).

Rollen werden pro Schicht besetzt, nicht pro Person. Die Rollenliste zeigt nicht "Max Mustermann", sondern "IC = Diensthabender Leiter Betrieb, Eskalation an CTO; Legal = Kanzlei X, 24/7-Hotline Y". So bleibt sie gültig, wenn Menschen gehen.

Eskalations-Matrix

Drei bis maximal vier Stufen. Mehr überfordert in der Nacht.

Stufe	Beispiele	Alarmierung	Frist	Wer entscheidet
S3	Verdacht, kein bestätigter Vorfall	On-Call	30 min	Diensthabender Admin
S2	Bestätigter Vorfall, lokal begrenzt	IC, CTO	15 min	IC
S1	Daten-Exfiltration, Ausfall zentraler Dienste, Ransomware	IC, CTO, GF	10 min	IC, Freigabe GF
S0	Leib-und-Leben, kritische Infrastruktur, Massen-Datenschutzvorfall	komplett	sofort	GF

Trigger-Kriterien explizit benennen: "mehr als 1000 Datensätze betroffen", "Ausfall eines kundenrelevanten Dienstes länger als 30 Minuten", "externer Meldepflicht-Tatbestand". Keine Bauchentscheidungen, sondern Regeln, die jeder Diensthabende anwenden kann.

Die NIS-2-Meldekette taktet die Matrix: Frühwarnung in 24 Stunden, Zwischenbericht in 72 Stunden, Abschlussbericht in einem Monat. DSGVO Art. 33 setzt die 72-Stunden-Schwelle für Aufsichts-Meldung, Art. 34 für Information Betroffener bei hohem Risiko. Diese Fristen gehören oben im Playbook, nicht in Fußnoten.

Kommunikations-Skripte

Vier Empfängerkreise, je ein vorformuliertes Skript in drei Varianten (erste Meldung, Zwischenstand, Abschluss).

Intern. Kurz, nur Fakten. "Um HH:MM wurde ein Verdacht auf X festgestellt. Status: in Untersuchung. Bitte keine Aussagen nach außen. Nächstes Update: HH:MM+60." Der interne Kreis bleibt klein, bis der Status klar ist.

Kunden. Nur freigegeben durch IC und Legal. Benennt: was ist passiert, welche Daten potenziell betroffen, was tun wir, was sollte der Kunde tun, Rückfrage-Adresse. Keine Schuldzuweisung, keine Spekulation, keine absoluten Sicherheitsversprechen.

Behörde. Getrennte Templates für BSI-Meldeportal (NIS-2), Datenschutzaufsicht (DSGVO Art. 33), ggf. Branchenaufsicht (BaFin, BNetzA). Inhalt orientiert sich an den Pflichtfeldern der Formulare, vorgefüllt mit Stammdaten.

Presse. Nur Geschäftsleitung oder benannter Pressesprecher. Default-Antwort sonst: "Ich bin dazu nicht auskunftsberechtigt. Zuständig ist Frau/Herr X unter Y." Schützt vor improvisierten Aussagen, die später nicht einzufangen sind.

Erste 60 Minuten

Checkliste, die nacheinander abgehakt wird.

1. Dokumentation starten. IR-Ticket, Timeline in UTC, jeder Befund mit Quelle. Diese Timeline ist später Grundlage für Meldung und Post-Mortem.
2. Scope abstecken. Welche Systeme, Netze, Identitäten, Daten potenziell betroffen?
3. Isolation entscheiden. Sofortige Netz-Trennung stoppt die Ausbreitung, zerstört aber flüchtige Evidenz (RAM, Sessions, Netz-Verbindungen). Regel: bei aktivem Angriff isolieren, bei Verdachtsbefund zuerst Speicherabbild, dann isolieren. Entscheidung schriftlich begründen.
4. Evidenz sichern. Speicherabbilder, Log-Kopien, Netflow, EDR-Telemetrie (Daten der Endgeräte-Überwachung). Retention-Policy (die automatische Lösch-Regel für alte Daten) pausieren, damit nichts automatisch rotiert.
5. Externe Hilfe aktivieren. IR-on-Retainer (ein vorab beauftragter externer Incident-Response-Dienstleister) jetzt anrufen, nicht später. Die ersten Stunden sind forensisch am wertvollsten.
6. Kommunikations-Schloss. Comms Lead verhindert Alleingänge; Presse-Standardantwort an alle Mitarbeitenden.
7. Meldepflichten einschätzen. Legal prüft DSGVO Art. 33 und NIS-2-Relevanz. Wenn einschlägig: 24h-Frühwarnung an BSI vorbereiten.

Post-Mortem

Blameless nach Google-SRE-Lehre: Ursachen und System-Eigenschaften, nicht Personen.

1. Zusammenfassung. Drei bis fünf Sätze: was, wie lange, welche Wirkung.
2. Timeline. Die Incident-Timeline, gereinigt, UTC.
3. Beitragende Faktoren. Kombination aus technischen, prozessualen und organisatorischen Faktoren, keine Monokausalität.
4. Fünf Warums. Vom Symptom fünfmal Warum fragen, um zur tiefsten adressierbaren Ursache zu kommen. Eine Technik zur Rootcause-Analyse, nicht zur Schuldzuweisung.
5. Was lief gut. Damit das Dokument nicht nur Schmerz enthält und die nächsten Post-Mortems nicht gemieden werden.
6. Maßnahmen. Tickets mit Owner, Fälligkeit, Priorität. Messbar abschließbar. Kein "wir werden aufmerksamer".

Post-Mortem geht an die ganze Technik-Organisation, bei S0/S1 auch an die Geschäftsleitung. Vertrauliche Details werden abstrahiert, nicht weggelassen.

Abgelehnte Alternativen

NIST SP 800-61 Rev. 3 als Playbook direkt übernehmen. Hervorragende Referenz, aber als operative Anleitung zu umfangreich und nicht für den 03:00-Uhr-Fall optimiert. Richtige Nutzung: als Checkliste, gegen die das eigene schlanke Playbook jährlich abgeglichen wird.

Externes IR-on-Retainer als Ersatz. Ein Retainer ist wertvoll, ersetzt aber kein internes Playbook. Der Dienstleister braucht Ansprechpartner, Zugang, Kontext. Empfehlung: Retainer zusätzlich, nicht statt.

SOAR-Tools für kleine und mittlere Organisationen. Security Orchestration, Automation and Response (Plattformen, die Sicherheitsalarme automatisiert abarbeiten) lohnt sich für Organisationen mit SOC und hoher Alarm-Last, führt bei kleineren Organisationen zu Werkzeug-Overhead ohne Nutzen. Ein gepflegtes Google-Doc plus ein IR-Chatroom mit Rollenbezeichnungen im Thema-Kopf leistet in der ersten Stunde mehr als ein halb eingerichtetes SOAR.

Was Sie jetzt tun sollten

1. Playbook auf eine Karteikarten-Länge eindampfen. Nehmen Sie die fünf Bausteine und kürzen Sie auf das, was um 03:00 Uhr wirklich gelesen wird. Alles Erklärende wandert in einen Anhang.
2. Rollen nach Funktion eintragen, nicht nach Namen. Hinterlegen Sie hinter jeder Rolle eine Vertretung und eine erreichbare Telefonnummer, inklusive der externen Kontakte (Kanzlei, IR-Dienstleister).
3. Die gesetzlichen Fristen sichtbar an den Anfang setzen. 24h-Frühwarnung und 72h-Meldung nach NIS-2, 72h nach DSGVO Art. 33 - mit Link zum jeweiligen Meldeportal und den Zugangsdaten im Tresor.
4. Einen Tabletop-Termin in den Kalender setzen. Zwei Stunden, ein realistisches Szenario, mit dabei: Geschäftsleitung und Legal. Was dabei hakt, fließt zurück ins Playbook.
5. Den Meldekanal für Schwachstellen-Hinweise einrichten. Eine security.txt nach RFC 9116 auf Ihrer Domain plus eine überwachte Mailbox - so finden externe Hinweisgeber Sie, bevor ein Vorfall eskaliert.

Wie Dernium hier hilft

Dernium Desk stellt eine abgeschottete VM für das IR-Team bereit, auf der verdächtige Dateien, Mails und Dumps gesichtet werden, ohne das reguläre Arbeitsumfeld zu gefährden; auf Wunsch lässt sich die VM danach restlos schreddern (Einweg-Modus), sonst bleibt sie bestehen. Für den Eingangskanal externer Schwachstellen-Hinweise reicht ein sauber gepflegtes security.txt nach RFC 9116 (ein Web-Standard für eine kleine Kontakt-Textdatei an fester Stelle der Website) auf Ihrer Domain plus eine dedizierte Mailbox oder ein internes Ticket-System. Eine startfertige security.txt-Vorlage liefert der kostenlose Dernium Webtools. Den Disclosure-Kanal vorzuhalten ist Pflicht-Baustein nach CRA Art.13 Abs.8 ab September 2026 und für NIS-2-pflichtige Organisationen schon vorher empfehlenswert.

Lücken, offen benannt. Einen SOAR-Adapter bieten wir nicht. Ein fertiges IR-Template-Repo mit Markdown-Bausteinen ist geplant, aber noch nicht veröffentlicht. Automatisierte Breach-Notification-Mails an Betroffenen-Listen (DSGVO Art. 34) sind in Planung, derzeit nicht Produkt-Bestandteil; heute ist der Weg eine Export-Liste aus dem CRM plus Mail-Versand mit Audit-Log-Eintrag.

Verifikation

1. NIST SP 800-61 Rev. 3: csrc.nist.gov/pubs/sp/800/61/r3/final.
2. BSI IT-Grundschutz DER.2: bsi.bund.de IT-Grundschutz-Kompendium.
3. ENISA Good Practice Guide for Incident Management: enisa.europa.eu.
4. DSGVO Art. 33 und 34: Verordnung (EU) 2016/679.
5. NIS-2-Richtlinie: Richtlinie (EU) 2022/2555, Art. 23 zu Meldepflichten.
6. Google SRE Postmortem-Kultur: sre.google/sre-book/postmortem-culture.

Offene Punkte

Übungsfrequenz. Ein Playbook, das nicht geübt wird, verrottet. Leider im wahrsten Sinne des Wortes. Mindestens zweimal jährlich: einmal Tabletop mit Geschäftsleitung (zwei Stunden, Szenario durchspielen), einmal Red- oder Purple-Team-Übung mit technischer Ausführung. Für regulierte Branchen höher frequentiert.

Cross-Team-Kalibrierung. Einmal jährlich organisationsweit abklopfen, inklusive Personalabteilung (Kommunikation an Beschäftigte bei Incident mit Identitätsdaten) und Betriebsrat (Mitbestimmung bei Monitoring-Eskalation).

Supply-Chain-Incidents. Der wachsend häufige Fall "unser Dienstleister hat einen Vorfall, unsere Daten sind möglicherweise betroffen" braucht einen eigenen Ableger: Vertragsklausel-Check, Artikel-28-Prüfung, eigene Meldepflicht trotz fremder Quelle. Ein guter Kandidat für den nächsten TechTalk in der Serie.

Häufige Fragen

Wie kurz darf ein Incident-Response-Playbook sein?

So kurz, dass es im Ernstfall tatsächlich gelesen wird. Die operativen Kern-Karten - Rollen, Eskalationsstufen, die ersten 60 Minuten und die Meldefristen - passen auf wenige Seiten. Längere Erklärungen, Hintergründe und Vertragsdetails gehören in einen Anhang, den man in Ruhe nachschlägt, nicht in der ersten Stunde.

Wer sollte Incident Commander sein?

Die Person mit dem kühlsten Kopf und der klarsten Kommunikation, nicht zwingend der technisch Versierteste. Der Incident Commander entscheidet, priorisiert und führt die Timeline, während der Tech Lead die eigentliche Analyse übernimmt. Wichtig ist, dass die Rolle pro Schicht besetzt ist und eine benannte Vertretung hat.

Was bedeutet ein blameless Post-Mortem?

Eine Nachbetrachtung, die nach System-Ursachen sucht statt nach Schuldigen. Die Annahme: Menschen handeln im Rahmen der Informationen und Werkzeuge, die sie hatten - wenn etwas schieflief, lag es meist an Prozessen, fehlenden Schranken oder unklaren Zuständigkeiten. Diese Haltung sorgt dafür, dass Beteiligte offen berichten, statt Fehler zu verschweigen.

Reicht ein externer Incident-Response-Dienstleister als Vorbereitung aus?

Nein. Ein Retainer (eine vorab beauftragte externe Hilfe) ist sehr wertvoll, aber der Dienstleister braucht beim Vorfall Ansprechpartner, Zugänge und Kontext aus Ihrem Haus. Ohne internes Playbook verlieren Sie in den ersten, forensisch wichtigsten Stunden Zeit. Beides gehört zusammen, nicht eines statt des anderen.

Wie oft sollte man das Playbook üben?

Mindestens zweimal im Jahr: einmal als Tabletop-Planspiel mit der Geschäftsleitung und einmal als technische Übung mit tatsächlicher Ausführung. Regulierte Branchen üben häufiger. Jede Übung deckt veraltete Telefonnummern, unklare Zuständigkeiten und fehlende Zugänge auf - genau die Dinge, die im echten Vorfall den Unterschied machen.