Was ist Incident Response?
Incident Response legt fest, was zwischen dem ersten Hinweis auf einen Vorfall und seiner Auswertung geschieht: wer bewertet, wer entscheidet, wer meldet und wer den Betrieb wiederherstellt. Der Ablauf muss vor dem ersten Vorfall feststehen, weil gesetzliche Meldefristen ab Kenntnis des Vorfalls laufen.
Für besonders wichtige und wichtige Einrichtungen gehört die Bewältigung von Sicherheitsvorfällen nach § 30 Abs. 2 Satz 2 Nr. 2 BSIG zu den Mindestmaßnahmen.
Ab wann ist ein Ereignis ein Sicherheitsvorfall?
Ein Sicherheitsereignis ist eine Beobachtung, die sicherheitsrelevant sein kann, etwa eine Serie fehlgeschlagener Anmeldungen oder ein Alarm der Endpoint Detection and Response. Ein Sicherheitsvorfall ist nach § 2 Nr. 40 BSIG ein Ereignis, das die Verfügbarkeit, Integrität oder Vertraulichkeit von Daten oder Diensten beeinträchtigt.
Erheblich ist ein Vorfall nach § 2 Nr. 11 BSIG, wenn er schwerwiegende Betriebsstörungen oder finanzielle Verluste verursacht hat oder verursachen kann oder andere Personen erheblich schädigt oder schädigen kann. Das gilt, sofern keine Rechtsverordnung nach § 56 Abs. 5 BSIG den Begriff konkretisiert. Für Einrichtungen der in § 30 Abs. 3 BSIG genannten Arten konkretisiert Art. 3 der Durchführungsverordnung (EU) 2024/2690 die Schwelle. Erheblich ist danach etwa ein Vorfall, der einen unmittelbaren finanziellen Verlust über 500.000 Euro oder 5 % des Vorjahresumsatzes verursacht hat oder verursachen kann, je nachdem, welcher Betrag niedriger ist.
Legen Sie schriftlich fest, wer ein Ereignis als Vorfall einstuft und binnen welcher Zeit ein Ereignis bewertet sein muss. Ohne diese Regel entscheidet die diensthabende Person nach Gefühl.
Welche Phasen hat Incident Response?
| Phase | Inhalt |
|---|---|
| Vorbereitung | Rollen, Erreichbarkeit, Eskalationswege, Entscheidungsbefugnisse, Verträge |
| Erkennung und Analyse | Meldewege für Beschäftigte und Technik, Erstbewertung, Einstufung der Schwere |
| Eindämmung | Ausbreitung stoppen, ohne Spuren zu vernichten |
| Beseitigung | Ursache entfernen: kompromittierte Zugänge, Schadsoftware, ausgenutzte Schwachstelle |
| Wiederherstellung | kontrollierte Rückkehr in den Normalbetrieb mit erhöhter Überwachung |
| Nachbereitung | Ursachenanalyse, Maßnahmen, Aktualisierung von Risikobewertung und Ablauf |
NIST SP 800-61 Revision 3 vom April 2025 hat das Vier-Phasen-Modell der Revision 2 abgelöst und ordnet die Vorfallsbehandlung den Funktionen des NIST Cybersecurity Framework 2.0 zu. Ein Phasenmodell taugt weiter für den eigenen Plan; geben Sie das Vier-Phasen-Modell nur nicht als aktuellen NIST-Stand aus.
Welche Meldepflichten gelten nach einem Vorfall?
| Rechtsrahmen | Wen es trifft | Frist | Empfänger |
|---|---|---|---|
| DSGVO, Art. 33 DSGVO | Verantwortliche bei einer Verletzung des Schutzes personenbezogener Daten, außer wenn sie voraussichtlich zu keinem Risiko führt | unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden | zuständige Datenschutzaufsichtsbehörde |
| BSIG, § 32 BSIG | besonders wichtige und wichtige Einrichtungen bei einem erheblichen Sicherheitsvorfall | frühe Erstmeldung binnen 24 Stunden und Meldung binnen 72 Stunden, beide ab Kenntniserlangung; Abschlussmeldung einen Monat nach der 72-Stunden-Meldung; Zwischenmeldung nur auf Ersuchen | gemeinsame Meldestelle von BSI und BBK |
| DORA, Art. 19 der Verordnung (EU) 2022/2554 | Finanzunternehmen bei schwerwiegenden IKT-bezogenen Vorfällen; Einstufung nach der Delegierten Verordnung (EU) 2024/1772 | Erstmeldung binnen 4 Stunden nach Einstufung als schwerwiegend, spätestens 24 Stunden nach Kenntnis. Zwischenmeldung binnen 72 Stunden nach der Erstmeldung, Abschlussmeldung einen Monat nach der Zwischenmeldung (Art. 5 der Delegierten Verordnung (EU) 2025/301) | zuständige Behörde nach Art. 46 DORA |
| CRA, Art. 14 der Verordnung (EU) 2024/2847 | Hersteller bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen ihrer Produkte, seit dem 11. September 2026 | Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden | als Koordinator benanntes CSIRT, in Deutschland das BSI, und ENISA über die einheitliche Meldeplattform |
§ 32 BSIG gilt nach § 28 Abs. 5 BSIG grundsätzlich nicht für Anbieter öffentlicher Telekommunikationsnetze und -dienste und für Energieunternehmen, die den §§ 5c bis 5e EnWG unterliegen. Nach § 28 Abs. 6 BSIG gilt er nicht für Finanzunternehmen nach DORA; für sie gilt die DORA-Zeile. Ein Vorfall kann mehrere Meldungen zugleich auslösen, etwa nach § 32 BSIG und als Datenpanne nach Art. 33 DSGVO.
Beispiel: zwei Meldefristen, ein Zeitpunkt
Beispiel (fiktiv): Eine besonders wichtige Einrichtung bemerkt einen Angriff auf ihren Dateiserver. Ablauf, Zeiten und Inhalte sind frei gewählt und dienen ausschließlich der Veranschaulichung.
| Zeitpunkt | Was geschieht | Entscheidung und Frist |
|---|---|---|
| Mo 05.10.2026, 07:40 | Die Endpoint Detection and Response meldet ungewöhnliche Verschlüsselung auf dem Dateiserver. | Die Bereitschaft bewertet; noch ein Ereignis. |
| Mo 05.10.2026, 09:10 | Die Analyse bestätigt verschlüsselte Dateien und den Abfluss eines Ordners mit Personaldaten. | Die Einsatzleitung stuft als erheblichen Sicherheitsvorfall und Verletzung des Schutzes personenbezogener Daten ein. Frühe Erstmeldung bis Di 06.10.2026, 09:10; Meldung nach § 32 und nach Art. 33 DSGVO bis Do 08.10.2026, 09:10. |
| Mo 05.10.2026, 09:30 | Der Server wird vom Netz getrennt, ein Speicherabbild gesichert. | Eindämmung vor Wiederherstellung, damit Spuren erhalten bleiben |
| Mo 05.10.2026, 14:00 | Die frühe Erstmeldung geht an die gemeinsame Meldestelle. | Frist eingehalten |
| Di 06.10.2026, 15:00 | Meldung nach § 32 Abs. 1 Nr. 2 BSIG und Meldung an die Datenschutzaufsicht übermittelt | Abschlussmeldung bis 06.11.2026; dauert der Vorfall an, tritt eine Fortschrittsmeldung an ihre Stelle. |
In diesem Beispiel gilt 09:10 als Zeitpunkt der Kenntnis, weil erst die Analyse den Vorfall bestätigt; ab dann laufen beide Fristen. Halten Sie diesen Zeitpunkt, die Begründung der Einstufung und die Person fest, die sie getroffen hat. Hat die Verletzung voraussichtlich ein hohes Risiko für die betroffenen Beschäftigten zur Folge, benachrichtigt der Verantwortliche sie zusätzlich nach Art. 34 DSGVO.
Was vor dem ersten Vorfall feststehen muss
- Erreichbarkeit außerhalb der Geschäftszeiten und eine Vertretungsregel
- wer entscheidet, ein produktives System vom Netz zu nehmen, und wer informiert wird
- eine Kontaktliste, die ohne Verzeichnisdienst und Postfächer verfügbar ist, und ein Kommunikationsweg außerhalb der möglicherweise kompromittierten Infrastruktur
- Vorgaben zur Beweissicherung, bevor Systeme neu aufgesetzt werden
- ein Incident-Response-Retainer: ein Rahmenvertrag mit Forensik- und Wiederherstellungsdienstleistern, in dem Kapazität, Reaktionszeit und Stundensätze vorab vereinbart sind
Wie Incident Response in den Aufbau eines ISMS gehört, beschreibt der Leitfaden ISMS einführen.
Wie unterscheidet sich Incident Response vom Notfallmanagement?
Incident Response befasst sich mit der Ursache: wer eingedrungen ist, worüber und was verändert wurde. Das Business Continuity Management befasst sich mit der Wirkung: wie kritische Geschäftsprozesse weiterlaufen, während die Ursache noch untersucht wird. Bei größeren Vorfällen laufen beide parallel und stimmen sich ab, etwa wenn eine schnelle Wiederherstellung aus der Sicherung Spuren überschreiben würde. Die Methodik für den Kontinuitätsteil beschreibt der BSI-Standard 200-4.
Die Nachbereitung klärt, warum der Vorfall nicht früher erkannt wurde, welche Kontrolle versagt und welche gehalten hat und welche Annahme der Risikobewertung falsch war. Ihre Ergebnisse gehören in Schwachstellenmanagement, Risikoanalyse und Übungsplanung.
Incident Response in Rizzqo
Rizzqo zeigt für jedes System, ob es personenbezogene Daten enthält und wer dafür verantwortlich ist. Das beantwortet die erste Frage für eine Meldung nach Art. 33 DSGVO: Sind personenbezogene Daten betroffen? Maßnahmen aus der Nachbereitung laufen als Aufgaben, die sich in beide Richtungen mit Jira synchronisieren.