Incident Response Plan erstellen: Vorlage und Anleitung

Die 8 Abschnitte eines Incident Response Plans #

1. Executive Summary & Zweck #

Was gehört rein:

• Definition: Was ist für diese Organisation ein “Incident”? Ist es ein verdächtiger Login-Versuch? Ein erkannter Malware-Fund? Ein Datenverlust? Formulieren Sie klar.
• Zweck des Plans: Schnelle, strukturierte Reaktion auf Cybersicherheit-Events.
• Geltungsbereich: Welche Systeme, Abteilungen und Scopes deckt dieser Plan ab? (Alle kritischen Systeme? Auch Filiale-LANs?)
• Autorisierungsignaturen: Wer hat diesen Plan genehmigt und wann?

Tipp: Der Executive Summary sollte sich auf einer Seite zusammenfassen lassen. Er ist für C-Level bestimmt, die keine technischen Details brauchen.

2. Incident Severity Levels #

Nicht alle Incidents sind gleich kritisch. Definieren Sie ein klares Klassifizierungssystem:

Level	Kriterium	Response Time	Eskalation
SEV 1 (Critical)	Kompletter Ausfall kritischer Systeme, Ransomware aktiv, Datenverlust	< 15 Min	Sofort CEO + Vorstand + BSI (72h Meldepflicht)
SEV 2 (High)	Beeinträchtigung produktiver Systeme, verdächtige Admin-Aktivität	< 1 Std	CIO + Security
SEV 3 (Medium)	Ungewöhnliche Aktivität, einzelne User betroffen	< 4 Std	IT-Security-Team
SEV 4 (Low)	Verdächtige aber blockierte Aktivität, False Positives	< 1 Tag	Documentation

Tipp: Severity sollte sowohl vom Impact (wie viele User betroffen?) als auch vom Likelihood (ist das ein echter Angriff?) abhängig sein.

3. Rollen & Verantwortlichkeiten #

Incident Commander: Koordiniert die gesamte Response. Klare Befehlskette, nicht per Diskussion.

• Typischerweise: IT-Security Lead oder CIO
• Verantwortung: Eskalation, Entscheidungsfindung, Kommunikation

IT-Incident-Response-Team: Technische Umsetzung.

• Systemadministratoren, Netzwerk-Techniker
• Verantwortung: Isolation, Forensik, Recovery

Forensik-Lead: Sammlung, Konservierung und Analyse von Evidenz.

• IT-Security-Spezialist oder externer Consultant
• Verantwortung: Chain of Custody, Beweissicherung

Legal & Compliance: Meldepflichten, Datenschutz, Haftung.

• General Counsel oder Datenschutzbeauftragter
• Verantwortung: Beratung zu NIS2 (72h BSI-Meldung), DSGVO (Benachrichtigung Betroffene)

Communications: Interne und externe Kommunikation.

• HR / PR Manager
• Verantwortung: Mitarbeiter-Mitteilungen, Kunden-Mitteilungen, Media

Senior Management Escalation: Vorstand, CEO, CFO.

• Verantwortung: Board-Informationen, Geschäftsentscheidungen

Tipp: Dokumentieren Sie für jede Rolle Namen, Telefon, E-Mail, und wer der Backup ist. Diese Liste sollte OFFLINE verfügbar sein — gedruckt im Tresor.

4. Auslösekriterien #

Wann wird der IR-Plan aktiviert? Sein Sie spezifisch:

• Ransomware-Verdacht (verdächtige .exe Datei erkannt, Dateien mit unbekannter Extension)
• Aktive Malware-Erkennung (EDR Alert, mehrdeutiger Pattern)
• Unbefugter Zugriff (verdächtige SSH-Session, RDP-Login aus Hochrisiko-Land)
• Datenverlust / Exfiltration (ungewöhnliche Datenmengen-Transfers nach extern)
• Denial of Service Angriff (DDoS, Ressourcen-Erschöpfung)
• Physischer Sicherheits-Incident (Server-Raum-Einbruch)

5. Eskalationspfade #

Beispiel für SEV 1:

1. Alert im SIEM → Team leads aufwecken (jederzeit)
2. Incident Commander wird informiert (< 5 Min)
3. IT-Response-Team beginnt Isolation (< 15 Min)
4. CEO + Vorstand werden benachrichtigt (< 30 Min)
5. BSI wird notifiziert (< 72 Std, aber schneller ist besser)
6. Externe Forensik wird engagiert (falls intern nicht möglich)

Tipp: “Anrufen, nicht E-Mail” für SEV 1. E-Mails werden übersehen. Haben Sie On-Call-Nummerierung.

6. Incident Handling: Die 6 Phasen #

Preparation (vor Incident):

• Backups sind gesichert
• Recovery-Umgebung ist einsatzbereit
• Tools sind vorhanden (Forensik, Isolation)

Detection & Analysis (0-2 Stunden):

• SIEM Alert wird bestätigt
• Ist das ein echtes Incident oder False Positive?
• Severity wird zugeordnet
• Incident wird dokumentiert (ID, Zeit, Beschreibung)

Containment (2-4 Stunden):

• Betroffene Systeme werden isoliert
• Weitere Ausbreitung wird verhindert
• Aber: Nicht alles sofort abschalten — Forensik braucht Live-Evidence

Eradication (4-24 Stunden):

• Malware wird entfernt
• Angreifer-Zugang wird geschlossen (ändere alle Passwords)
• Schwachstellen werden behoben

Recovery (1-7 Tage):

• Systeme werden aus sicheren Backups wiederhergestellt
• Funktionalität wird verifiziert
• Phased Return to Production

Post-Incident Review (1-2 Wochen):

• Was ist passiert? Warum?
• Was hätten wir besser machen können?
• Dokumentation, Dokumentation, Dokumentation

7. NIS2 Meldepflichten #

Seit 6. Dezember 2025 gilt in Deutschland: Wenn Sie einen Cyberangriff haben, müssen Sie das BSI innerhalb von 72 Stunden benachrichtigen (§30 BSIG-neu).

Was muss im IRP stehen:

• Wer kontaktiert das BSI? (Legal + Security)
• Wie viel Information geben Sie beim initial contact? (Genug um zu zeigen, dass Sie ernst meinen — aber nicht so viel, dass Sie Beweise gefährden)
• Wer sind die BSI-Kontakte? (Dokumentieren Sie vorab)
• Was dokumentieren Sie für regulatorische Zwecke? (Zeitstempel aller Aktionen, wer hat was entschieden)

Tipp: Die Meldung an das BSI ist nicht nur eine Compliance-Pflicht — es ist auch eine Ressource. Die Behörde kann helfen.

8. Kommunikationsplan #

Nicht nur intern kommunizieren — extern auch:

Interne Kommunikation (Mitarbeiter):

• Wer informiert die Mitarbeiter, dass ein Incident läuft?
• Wie oft werden Updates geben?
• Was sagen Sie wenn Sie nicht wissen, was los ist? (Honesty ist besser als Fake-Sicherheit)

Externe Kommunikation (Kunden):

• Wann müssen Kunden informiert werden? (Typisch: wenn deren Daten betroffen sind oder der Service beeinträchtigt)
• Was ist das Template für die Kundenmitteilung?
• Wer unterschreibt? (CFO, CEO, nicht nur IT)

Media Handling:

• Wer spricht mit Journalisten? (Nur eine Person, vorbereitet)
• Was ist der “holding statement” für die erste Stunde?

Regulatory Communication:

• BSI (72 Stunden)
• Datenschutzbehörde (wenn Personendaten betroffen)
• Versicherer (Cyber-Versicherung braucht schnelle Notifizierung)

Tipp: Schreiben Sie die Templates JETZT, nicht während des Incidents. Ein Muster: “Wir haben ein Sicherheits-Event erkannt. Unser Team arbeitet daran. Sicherheit ist unsere Priorität. Details folgen in 24 Stunden.”

Zusätzliche Anforderung: Disaster Recovery Plan (DR-Plan) offline verfügbar #

Der IR-Plan selbst ist nur die Hälfte. Sie brauchen auch einen verknüpften Disaster Recovery Plan, der zeigt, wie Sie Systeme wiederherstellen. Und dieser Plan MUSS offline verfügbar sein:

• Gedrucktes Exemplar im Tresor (aktualisiert vierteljährlich)
• Kopie im Safe-Schloss oder der Bank
• Recovery-Runbooks für jedes kritische System

Warum offline? Weil wenn Ihre IT komplett down ist, können Sie nicht auf das Wiki zugreifen. Sie brauchen ein Papierblatt, das zeigt “Hier sind die Backup-Koordinaten, hier ist das Admin-Password für die Recovery-Umgebung, hier ist die Reihenfolge der Systemwiederherstellung.”

Häufige Fragen #

Wie häufig sollten wir den IRP updaten? Mindestens jährlich. Nach jedem größeren Vorfall sofort. Nach größeren Systemänderungen (neue Software, neuer Partner).

Was ist ein “guter” IRP? Einer, der tatsächlich genutzt wird und verstanden wird. Das bedeutet: Trainingssessions für das Response-Team, Tabletop Exercises mindestens 2x pro Jahr.

Brauchen kleine Unternehmen auch einen IRP? Ja. Ein KMU-IRP ist einfacher (vielleicht 5 Seiten statt 20), aber unbedingt notwendig.

---