Leitfaden
Was gehört in einen Incident-Response-Plan?
Was in einen Incident-Response-Plan gehört: Rollen, Eskalation, Kommunikation, Meldefristen nach NIS2 und CRA, Beweissicherung, Lessons Learned.
Zusammenfassung
Ein nützlicher Incident-Response-Plan legt fest, wer leitet und entscheidet, wann eskaliert wird, wie Vorfälle eingestuft werden, wer intern und extern informiert wird, welche Meldefristen gelten, was dokumentiert wird und wie Erkenntnisse zurück ins ISMS fließen. Er sollte kurz genug sein, um unter Stress nutzbar zu sein, und in Übungen erprobt werden.
Wenn ein Vorfall passiert, hat niemand Zeit, ein 60-seitiges Dokument zu lesen. Ein guter Incident-Response-Plan ist kurz, klar und geübt.
Die Bausteine
1. Geltungsbereich und Begriffe
Was ist ein Sicherheitsereignis, was ein Vorfall, was eine Krise? Klare Begriffe verhindern Über- wie Unterreaktion.
2. Rollen und Verantwortlichkeiten
- Incident-Leitung – koordiniert die Reaktion.
- Entscheider – wer darf Systeme vom Netz nehmen, Externe einbinden, Behörden informieren?
- Technische Reaktion – interne IT und Dienstleister.
- Kommunikation – intern, Kunden, Öffentlichkeit.
- Vertretungen für jede Rolle.
3. Eskalation und Klassifizierung
Ein einfaches Schema (etwa niedrig / mittel / hoch / kritisch) nach Auswirkung auf Vertraulichkeit, Integrität, Verfügbarkeit und Geschäftsprozesse – mit klaren Auslösern für die Eskalation an die Geschäftsführung.
4. Kontakte
Interne Ansprechpartner und externe Partner, auch außerhalb der Geschäftszeiten erreichbar: IT-Dienstleister, Hosting- und Cloud-Anbieter, Cyberversicherung, Forensik, Rechtsberatung, Datenschutzbeauftragte, Behörden.
5. Meldepflichten
Fristen in konkrete Schritte mit Verantwortlichen übersetzen:
| Regelwerk | Typische Fristen |
|---|---|
| NIS2 (erhebliche Sicherheitsvorfälle) | Frühwarnung binnen 24 h, Meldung binnen 72 h, Abschlussbericht binnen eines Monats |
| Cyber Resilience Act (Hersteller) | aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle: Frühwarnung binnen 24 h, Meldung binnen 72 h, anschließend Abschlussbericht |
| DSGVO (Datenschutzverletzungen) | Meldung an die Aufsichtsbehörde binnen 72 h, sofern erforderlich |
6. Kommunikationsvorlagen
Vorbereitete Texte für Mitarbeitende, Kunden und Behörden sparen entscheidende Zeit.
7. Dokumentation und Beweissicherung
Ein einfaches Protokoll: Wer hat wann was bemerkt, welche Entscheidungen wurden getroffen, welche Maßnahmen ergriffen? Wo möglich, Beweise sichern, bevor Systeme wiederhergestellt werden.
8. Wiederherstellung
Kriterien für die Wiederherstellung von Systemen und die Rückkehr in den Normalbetrieb, verknüpft mit Backup- und Notfallplänen.
9. Lessons Learned
Nach jedem relevanten Vorfall: Was ist passiert, was hat funktioniert, was nicht – und welche Korrekturmaßnahmen folgen?
Den Kreis mit dem ISMS schließen
Vorfall → Reaktion → Dokumentation → Lessons Learned → Neubewertung der Risiken → Korrekturmaßnahme → ISMS-Verbesserung. Ein Vorfall, der geschlossen wird, ohne etwas zu verbessern, ist eine verpasste Chance.
Testen
Spielen Sie den Plan mindestens einmal im Jahr in einer Tabletop-Übung durch. Sie werden fehlende Telefonnummern, unklare Entscheidungen und veraltete Annahmen finden – besser in der Übung als im Ernstfall.
Was ein Plan nicht ersetzt
Ein Plan ersetzt kein Security Operations Center, keinen Notfalldienstleister, keine Forensik und keine Rechtsberatung. Er legt fest, wann und wie Sie diese einbinden.
Häufige Fragen
Welche Meldefristen gelten nach NIS2?
Bei erheblichen Sicherheitsvorfällen müssen betroffene Einrichtungen innerhalb von 24 Stunden nach Kenntnisnahme eine Frühwarnung abgeben, innerhalb von 72 Stunden eine Meldung und innerhalb eines Monats einen Abschlussbericht. Prüfen Sie die genauen nationalen Vorgaben für Ihre Einrichtung.
Was ist eine Tabletop-Übung?
Ein Planspiel, bei dem die im Plan benannten Personen ein realistisches Szenario Schritt für Schritt durchsprechen. Es zeigt Lücken bei Rollen, Kontakten und Entscheidungen – ohne produktive Systeme anzufassen.