Artikel vom 3. März 2026
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), (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 (E 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:
- Alert im SIEM → Team leads aufwecken (jederzeit)
- Incident Commander wird informiert (< 5 Min)
- IT-Response-Team beginnt Isolation (< 15 Min)
- CEO + Vorstand werden benachrichtigt (< 30 Min)
- BSI wird notifiziert (< 72 Std, aber schneller ist besser)
- 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.
DSGVO
Die DSGVO (Datenschutz-Grundverordnung, EU 2016/679) ist die europäische Regulierung zum Schutz personenbezogener Daten — für IT-Infrastruktur besonders relevant in Art. 5 (Grundsätze), Art. 17 (Recht auf Löschung), Art. 28 (Auftragsverarbeiter) und Art. 32 (Sicherheit der Verarbeitung).
Disaster Recovery
Disaster Recovery bezeichnet die strukturierten Prozesse und technischen Maßnahmen, die sicherstellen, dass IT-Systeme nach einem schwerwiegenden Ausfall — Ransomware-Angriff, Hardwareversagen, Rechenzentrumsausfall — innerhalb definierter Zeitrahmen (RTO) mit maximalem Datenverlust (RPO) wiederhergestellt werden können.