Incident-Response-Plan erstellen: Vorlage, Rollen, Meldeketten
Ein Incident-Response-Plan legt vor dem Ernstfall fest, wer entscheidet, wer benachrichtigt wird und in welcher Reihenfolge Systeme abgeschaltet, isoliert und wiederhergestellt werden. Er referenziert die fünf Kern-Kontrollen der Cyberversicherer (MFA, EDR, getrennte Backups, Patch-Prozess, dokumentierter IR-Plan selbst). Ausserdem bindet er die Meldefristen aus revDSG, ISG, FINMA und DORA verbindlich in Rollen und Zeiten ein. Ohne diesen Plan wird die 72-Stunden-Reaktion improvisiert und die Versicherungsleistung angreifbar.
Abgrenzung zu Nachbarthemen
Diese Seite beschreibt den Plan, also das Dokument und die Rollen, die vor einem Vorfall existieren müssen. Die tatsächliche Ausführung inklusive Forensik, Eindämmung und Kommunikation im Ernstfall steht auf Incident Response innerhalb 72 Stunden. Die Wiederherstellungsstrategie für Ransomware im Speziellen liegt auf Ransomware-Backup-Strategie. Meldefristen und Warranties gegenüber Versicherern behandelt SOC und Cyberversicherung. Regulatorische Meldeketten stehen in revDSG und SOC und ISG-Meldepflicht. Das Betriebsbild im Pillar SOC as a Service Schweiz.
Warum ein IR-Plan Pflicht ist, nicht Kür
Cyberversicherer in der Schweiz und der EU verlangen in ihren Antragsformularen einen dokumentierten Incident-Response-Plan als eine der fünf Kern-Kontrollen. Fehlt er im Schadenfall, wird die Deckung gekürzt oder verweigert. revDSG (Artikel 24), ISG (Meldepflicht kritischer Infrastrukturen), FINMA (Aufsichtsmitteilung 05/2020, präzisiert durch AM 03/2024; Resilienz-Erwartung nach Rundschreiben 2023/1) und DORA (Artikel 17 bis 23) fordern eine dokumentierte Reaktionsfähigkeit mit definierten Meldefristen. Ohne vorher festgelegte Entscheider und Kommunikationsketten sind diese Fristen operativ nicht haltbar.
Ein Plan, der beim Antrag als 'vorhanden' angehakt wird, aber im Ernstfall keine aktuellen Kontakte, keine Rollen und keine Übungshistorie zeigt. Versicherer prüfen im Schaden genau diesen Punkt.
Pflichtinhalte eines verlässlichen IR-Plans
- Rollen und Vertretungsregelung: Incident Commander, Kommunikationsverantwortlicher, Rechts- und Datenschutz-Ansprechpartner, technische Leitung, Executive Sponsor. Für jede Rolle Primär- und Stellvertreter-Kontakt inklusive privater Nummern.
- Klassifizierungsschema: niedrig, mittel, hoch, kritisch, mit klaren Kriterien pro Stufe (betroffene Kronjuwelen, Personendatenexposition, regulatorische Anzeigepflicht, Betriebsauswirkung).
- Eskalationspfad mit Zeitzielen (Erstalarm zu Erstentscheid, Erstentscheid zu Executive-Kommunikation, Erstentscheid zu regulatorischer Meldung).
- Meldeketten extern: Kunde, Datenschutzbeauftragter oder EDÖB, Aufsichtsbehörde (FINMA, BAKOM, kantonal), Versicherer, Strafverfolgung, Öffentlichkeit. Vorlage-Texte für die ersten zwei Stunden.
- Technische Playbooks pro Szenario: Ransomware, BEC in M365, Token-Diebstahl, Datenabfluss, DoS. Verweise auf konkrete Runbooks statt Volltext im Rahmenplan.
- Übungs- und Aktualisierungskadenz: mindestens eine Tabletop-Übung pro Jahr, technisches Purple- oder Red-Team-Element alle zwei Jahre, Plan-Review nach jedem Ernstfall und jeder Übung.
Abgleich mit den fünf Kern-Kontrollen der Versicherer
Fünf Kontrollen tauchen auf fast jedem Schweizer und europäischen Antragsformular auf. Es sind MFA für alle privilegierten und Remote-Zugänge, EDR ohne graue Endpoints, getrennte und getestete Backups, ein gepflegter Patch-Prozess und der dokumentierte IR-Plan selbst. Der Plan darf diese Kontrollen nicht nur erwähnen, sondern muss pro Kontrolle einen Eigner, einen Nachweiszyklus (zum Beispiel quartalsweiser Backup-Restore-Test) und die Verknüpfung mit dem Response-Playbook enthalten.
| Kern-Kontrolle | Was der IR-Plan festhält | Bezug im Ernstfall |
|---|---|---|
| MFA | Eigner, Ausnahme-Register, Prüfzyklus. | Bei Kompromittierung: Session-Widerruf und MFA-Neu-Enrollment als erster Schritt. |
| EDR | Abdeckungsgrad, Blindstellen, Isolierungsbefugnis. | Isolation-Entscheid ohne Ticket-Umweg, dokumentiert nach Zeitstempel. |
| Getrennte Backups | Immutabilitäts-Regel, Restore-Test-Historie, Wiederherstellungs-SLA. | Wiederherstellungs-Sequenz, siehe Ransomware-Backup-Strategie. |
| Patch-Prozess | SLA nach Kritikalität, Ausnahme-Genehmigung, Auditspur. | Emergency-Patching-Mandat und Kommunikation an den Betrieb. |
| IR-Plan (dieses Dokument) | Version, Freigabe, letzter Übungslauf, nächster Review. | Vorlage-Texte für die ersten 24 Stunden gegenüber Behörden und Versicherer. |
Meldefristen im Plan verankern
- revDSG Artikel 24: Meldung an den EDÖB so rasch als möglich bei hohem Risiko für die Persönlichkeitsrechte betroffener Personen.
- ISG-Meldepflicht: 24 Stunden Erstmeldung, danach Zwischenmeldung nach der Erstmeldung, dann Abschlussmeldung.
- FINMA-Aufsichtsmitteilung 05/2020, präzisiert durch AM 03/2024: Erstmeldung wesentlicher Cyber-Attacken innert 24 Stunden ab Entdeckung, vollständige Meldung innert 72 Stunden über die EHP. Das Rundschreiben 2023/1 regelt die allgemeine operationelle Resilienz.
- DORA Artikel 19: Erstmeldung, Zwischenmeldung, Abschlussmeldung mit klar getrennten Fenstern.
- Versicherer: Meldung typischerweise innerhalb 24 bis 72 Stunden gemäss Police. Verspätung ist ein häufiger Deckungs-Kürzungsgrund.
Wie ANOMAL den Plan operationalisiert
ANOMAL entwickelt den IR-Plan gemeinsam mit dem Kunden auf Basis der bestehenden Kronjuwelen-Analyse, der Compliance-Scope-Definition (revDSG, ISG, FINMA, DORA) und der Police des Cyberversicherers. Der Plan wird an das laufende SOC-Playbook gebunden, sodass Detection-Signale automatisch die korrekten Rollen alarmieren. Danach: eine Tabletop-Übung pro Jahr, dokumentierte Nachbereitung, Aktualisierung nach jedem realen Vorfall. Kombiniert mit Incident Response innerhalb 72 Stunden ergibt sich ein einheitlicher Plan-plus-Ausführungs-Zyklus.
Häufige Fragen
Wie lang sollte ein IR-Plan sein?
Der Rahmenplan bleibt bewusst kurz, typisch 15 bis 30 Seiten, weil er im Ernstfall gelesen werden muss. Die technischen Playbooks pro Szenario sind separate Runbooks, die aus dem Plan referenziert werden. Ein 200-Seiten-Dokument, das niemand im Ernstfall aufschlägt, erfüllt keine Kontrolle.
Wie oft muss der Plan geübt werden?
Mindestens einmal pro Jahr eine Tabletop-Übung mit Executive-Ebene, alle zwei Jahre ergänzt um ein technisches Element (Purple Team, siehe [Red-Team-Assessment](/de/services/red-team-assessment)). Jeder reale Vorfall zählt als Übung, wenn die Nachbereitung dokumentiert und der Plan aktualisiert wird.
Kann der Plan auf einer Vorlage aus dem Internet basieren?
Als Struktur ja, als Inhalt nein. Rollen, Kontakte, Klassifizierung, Meldeketten und regulatorischer Scope sind unternehmensspezifisch. Ein generischer Plan besteht die versicherungstechnische Prüfung im Schadenfall nicht.
Was ist der Unterschied zwischen IR-Plan und Business-Continuity-Plan?
Der IR-Plan regelt die Reaktion auf einen Sicherheitsvorfall (Erkennen, Eindämmen, Kommunizieren, Melden). Der BCP regelt die Aufrechterhaltung kritischer Geschäftsprozesse bei Ausfällen jeder Art. Bei Ransomware überlappen sich beide, deshalb muss der IR-Plan explizit auf die BCP-Auslöser verweisen.
Wer sollte den Plan freigeben?
Die Geschäftsleitung oder der Verwaltungsrat, dokumentiert mit Datum und Version. Bei FINMA-beaufsichtigten Instituten ist dies explizit Aufsichtserwartung. Ohne Executive-Freigabe ist der Plan im Ernstfall keine verlässliche Entscheidungsgrundlage.
Verwandte Begriffe
- Incident Response Incident Response ist das geordnete Vorgehen, um einen Sicherheitsvorfall einzudämmen, zu bereinigen und den Betrieb wiederherzustellen.
- Playbook Ein Playbook ist eine vordefinierte Prozedur, die beschreibt, wie ein SOC auf eine bestimmte Art von Sicherheitsvorfall reagiert.
- Runbook Ein Runbook ist eine detaillierte operative Prozedur, welche die technischen Schritte für eine spezifische Aufgabe beschreibt.
- Tabletop-Übung Eine Tabletop-Übung spielt einen Sicherheitsvorfall am Tisch durch und prüft Rollen, Entscheide und Kommunikation im Ernstfall.
- Digitale Forensik Digitale Forensik sichert und untersucht digitale Spuren so, dass ein Vorfall nachvollziehbar und als Beweis verwertbar ist.