Ein Cyberangriff am Freitagabend, verdächtige Administratorzugriffe am Samstagmorgen oder der Ausfall eines zentralen Produktionssystems: Für betroffene Unternehmen beginnt in solchen Situationen nicht nur die technische Incident Response. Handelt es sich um einen erheblichen Sicherheitsvorfall, können zugleich gesetzliche Meldefristen laufen.
In Deutschland ist für besonders wichtige und wichtige Einrichtungen insbesondere § 32 BSI-Gesetz (BSIG) maßgeblich. Danach ist ein erheblicher Sicherheitsvorfall unverzüglich, spätestens jedoch innerhalb von 24 Stunden nach Kenntniserlangung mit einer frühen Erstmeldung zu melden. Innerhalb von 72 Stunden folgt eine weitergehende Meldung. Spätestens einen Monat nach dieser 72-Stunden-Meldung ist grundsätzlich eine Abschlussmeldung vorgesehen.
Die Herausforderung besteht deshalb nicht darin, innerhalb von 24 Stunden eine vollständige forensische Untersuchung abzuschließen. Unternehmen müssen vielmehr organisatorisch in der Lage sein, einen potenziell erheblichen Vorfall frühzeitig zu erkennen, seine Auswirkungen zu bewerten, die richtigen Verantwortlichen einzubeziehen und die vorgeschriebene Meldung rechtzeitig auf den Weg zu bringen.
Zuerst klären: Für wen gilt die Meldepflicht?
Die Meldepflicht des § 32 BSIG richtet sich nicht pauschal an jedes Unternehmen in Deutschland. Sie betrifft insbesondere Unternehmen und Organisationen, die nach § 28 BSIG als „besonders wichtige Einrichtungen“ oder „wichtige Einrichtungen“ einzuordnen sind. Für die Einordnung spielen unter anderem Einrichtungsart, Sektor und Unternehmensgröße eine Rolle. Betreiber kritischer Anlagen zählen zu den besonders wichtigen Einrichtungen.
Damit sollte eine grundlegende Frage bereits vor dem ersten Sicherheitsvorfall geklärt sein:
Fällt unsere Organisation in den Anwendungsbereich des BSIG und welche Meldepflichten gelten konkret für uns?
Diese Betroffenheitsprüfung gehört nicht in ein Incident-Response-Meeting am Samstagabend. Sie sollte dokumentiert und regelmäßig überprüft werden, beispielsweise wenn sich Unternehmensgröße, Geschäftstätigkeit oder Konzernstruktur verändern.
Für besonders wichtige und wichtige Einrichtungen besteht daneben grundsätzlich eine Registrierungspflicht. § 33 BSIG sieht hierfür eine Frist von drei Monaten ab dem Zeitpunkt vor, ab dem eine Organisation erstmals oder erneut als entsprechende Einrichtung gilt.
Nicht jeder Cybervorfall ist ein meldepflichtiger Vorfall
Ein zentraler Punkt für die Praxis ist die Unterscheidung zwischen einem Sicherheitsvorfall und einem erheblichen Sicherheitsvorfall.
§ 2 BSIG definiert einen Sicherheitsvorfall als Ereignis, das die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit gespeicherter, übermittelter oder verarbeiteter Daten oder der von Netz- und Informationssystemen angebotenen oder zugänglichen Dienste beeinträchtigt.
Für die Meldepflicht nach § 32 BSIG kommt es auf die Erheblichkeit an. Nach der gesetzlichen Definition ist insbesondere relevant, ob ein Vorfall schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste für die betroffene Einrichtung verursacht hat oder verursachen kann oder ob andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt wurden oder werden können.
Damit wäre es zu pauschal, jeden Malware-Fund oder jeden erfolgreichen Phishing-Angriff automatisch als meldepflichtig einzustufen. Entscheidend sind die konkreten Auswirkungen beziehungsweise das entsprechende Schadenspotenzial.
Für Unternehmen ergibt sich daraus eine praktische Aufgabe: Das Security-Team benötigt eine Erheblichkeitsprüfung, die bereits während der Erstbewertung eines Vorfalls durchgeführt werden kann.
Eine interne Bewertungsmatrix kann beispielsweise berücksichtigen, ob ein wesentlicher Dienst beeinträchtigt ist, welche geschäftskritischen Systeme betroffen sind, wie lange eine Betriebsunterbrechung voraussichtlich dauert, welche Kunden oder Geschäftspartner betroffen sein könnten und ob erhebliche finanzielle Auswirkungen zu erwarten sind.
Eine solche Matrix ersetzt keine rechtliche Einzelfallbewertung. Sie sorgt aber dafür, dass potenziell relevante Fälle frühzeitig an die zuständigen Personen eskaliert werden.
Die 24 Stunden sind keine Frist für die vollständige Forensik
§ 32 BSIG sieht bewusst eine gestufte Meldung vor.
Stufe 1 – frühe Erstmeldung: unverzüglich, spätestens innerhalb von 24 Stunden nach Kenntniserlangung. Anzugeben ist insbesondere, ob der Verdacht besteht, dass der erhebliche Sicherheitsvorfall auf rechtswidrige oder böswillige Handlungen zurückzuführen ist oder grenzüberschreitende Auswirkungen haben könnte.
Stufe 2 – Meldung des Sicherheitsvorfalls: unverzüglich, spätestens innerhalb von 72 Stunden nach Kenntniserlangung. Dabei werden die bisherigen Informationen bestätigt oder aktualisiert und um eine erste Bewertung von Schweregrad und Auswirkungen sowie gegebenenfalls vorhandene Kompromittierungsindikatoren ergänzt.
Stufe 3 – Abschlussmeldung: grundsätzlich spätestens einen Monat nach der 72-Stunden-Meldung. Sie umfasst unter anderem eine ausführlichere Beschreibung, Schweregrad und Auswirkungen, die wahrscheinliche Ursache beziehungsweise Art der Bedrohung sowie ergriffene und laufende Abhilfemaßnahmen. Dauert der Vorfall zu diesem Zeitpunkt noch an, sieht § 32 BSIG zunächst eine Fortschrittsmeldung vor.
Dieses Verfahren entspricht in seinen Grundzügen Art. 23 der NIS2-Richtlinie. Für die Praxis bedeutet das: Unvollständige Erkenntnisse in den ersten Stunden sind systembedingt. Die Organisation sollte deshalb nicht auf eine abgeschlossene Root-Cause-Analyse warten, bevor sie die regulatorische Relevanz prüft.
Praxisbeispiel: Ransomware am Freitagabend
Angenommen, das Monitoring erkennt um 19:40 Uhr ungewöhnliche Aktivitäten auf mehreren Servern. Um 20:05 Uhr stellt der Bereitschaftsdienst fest, dass Dateien verschlüsselt werden. Ein zentrales ERP-System ist betroffen.
Ein belastbarer Prozess könnte nun folgendermaßen aussehen:
20:05 Uhr – Incident eröffnen: Incident-ID vergeben, Incident Commander bestimmen und ein fortlaufendes Ereignisprotokoll beginnen.
20:15 Uhr – Eindämmung: Betroffene Systeme isolieren, kompromittierte Zugänge sperren und relevante Log- und Forensikdaten sichern. Technische Sofortmaßnahmen haben weiterhin Priorität.
20:30 Uhr – Business Impact feststellen: IT und Fachbereich klären, welche Dienste und Geschäftsprozesse betroffen sind. Können Aufträge verarbeitet werden? Ist die Produktion betroffen? Können Kunden weiterhin beliefert werden?
21:00 Uhr – regulatorische Bewertung starten: Informationssicherheit beziehungsweise die dafür festgelegte Funktion prüft anhand vorbereiteter Kriterien, ob ein erheblicher Sicherheitsvorfall im Sinne des BSIG vorliegen könnte.
21:30 Uhr – parallele Meldepflichten prüfen: Datenschutz, vertragliche Kundenpflichten und gegebenenfalls sektorspezifische Anforderungen werden getrennt bewertet.
22:00 Uhr – Management-Lagebild: Die Geschäftsleitung erhält ein kompaktes Lagebild: betroffene Dienste, bekannte Auswirkungen, Unsicherheiten, laufende Maßnahmen und regulatorischer Status.
Danach – Erstmeldung vorbereiten: Wird der Vorfall als meldepflichtig bewertet, werden die für die frühe Erstmeldung verfügbaren Informationen zusammengestellt und der vorgesehene Meldeweg genutzt.
Die genannten Uhrzeiten sind keine gesetzlichen Vorgaben. Sie sind beispielhafte interne Reaktionsziele und zeigen, warum Unternehmen deutlich schneller handeln sollten als die gesetzliche Höchstfrist von 24 Stunden vermuten lässt.
Ein Zeitstempel entscheidet über die Meldekette
Besondere Aufmerksamkeit verdient der Zeitpunkt der Kenntniserlangung. § 32 BSIG knüpft die 24- und 72-Stunden-Fristen an die Kenntniserlangung von einem erheblichen Sicherheitsvorfall.
Für die betriebliche Praxis ist deshalb eine belastbare Ereignischronologie wesentlich.
Dokumentiert werden sollten mindestens der erste technische Alarm, die Validierung als tatsächlicher Sicherheitsvorfall, Erkenntnisse zu Auswirkungen und möglicher Erheblichkeit, die interne regulatorische Eskalation, die Bewertung der Meldepflicht sowie Zeitpunkt und Inhalt der erfolgten Meldungen.
Dabei sollte nicht vorschnell angenommen werden, dass jeder technische Alarm bereits automatisch die gesetzliche Frist auslöst. Maßgeblich ist nach dem Wortlaut des § 32 BSIG die Kenntniserlangung von einem erheblichen Sicherheitsvorfall. Wann diese Voraussetzung im konkreten Fall erfüllt ist, kann eine Einzelfallbewertung erfordern. Gerade deshalb ist eine nachvollziehbare Dokumentation der Erkenntnisentwicklung wichtig.
Ein Incident braucht zwei parallele Arbeitsstränge
Ein organisatorisches Risiko besteht darin, die technische Incident Response gleichzeitig mit allen regulatorischen Aufgaben zu belasten.
Besser ist ein Modell mit zwei eng gekoppelten Arbeitssträngen.
Der technische Strang konzentriert sich auf Erkennung, Eindämmung, Beweissicherung, Bereinigung und Wiederherstellung.
Der Koordinations- und Compliance-Strang führt das Ereignisprotokoll, überwacht Fristen, bewertet Meldewege, bereitet Meldungen vor und koordiniert Management, Datenschutz, Kommunikation und gegebenenfalls externe Fachberater.
Damit bleibt das technische Team handlungsfähig, während gleichzeitig die regulatorischen Anforderungen systematisch bearbeitet werden.
NIS2 und DSGVO: Zwei unterschiedliche Prüfungen
Bei einem Cyberangriff können parallel weitere Meldepflichten entstehen. Besonders relevant ist Art. 33 DSGVO.
Die DSGVO-Meldung wird jedoch nach anderen Voraussetzungen bewertet. Liegt eine Verletzung des Schutzes personenbezogener Daten vor, muss der Verantwortliche diese grundsätzlich unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden an die zuständige Datenschutzaufsichtsbehörde melden – es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen.
Deshalb gilt nicht:
NIS2-Meldung = automatisch DSGVO-Meldung.
Ebenso wenig ersetzt eine DSGVO-Meldung die Prüfung nach § 32 BSIG.
In einem Incident-Response-Playbook sollten daher getrennte Entscheidungspfade vorhanden sein: BSIG/NIS2, DSGVO, vertragliche Meldepflichten und gegebenenfalls weitere sektorspezifische Anforderungen.
Praxis-Checkliste: Ist Ihr Unternehmen für den 24-Stunden-Ernstfall vorbereitet?
Die folgende Checkliste kann als Grundlage für einen Readiness-Check oder eine Tabletop-Übung verwendet werden.
Vor dem Sicherheitsvorfall
☐ Die Einordnung als besonders wichtige oder wichtige Einrichtung nach BSIG wurde geprüft und dokumentiert.
☐ Die für das Unternehmen geltenden gesetzlichen, regulatorischen und wesentlichen vertraglichen Meldepflichten sind bekannt.
☐ Kriterien für die Bewertung eines erheblichen Sicherheitsvorfalls sind im Incident-Response-Prozess hinterlegt.
☐ Incident Commander, CISO beziehungsweise ISB, IT-Leitung, Datenschutz, Compliance und Geschäftsleitung besitzen definierte Rollen.
☐ Für alle kritischen Rollen existieren Vertretungsregelungen.
☐ Eine 24/7-Eskalationskette einschließlich Telefonnummern und alternativer Kommunikationswege ist verfügbar.
☐ Der Meldeweg und die erforderlichen Zugänge für eine Meldung nach § 32 BSIG sind vorbereitet und getestet.
☐ Eine Vorlage für die frühe Erstmeldung und die weitere Incident-Dokumentation ist vorbereitet.
☐ Der Prozess berücksichtigt parallele Prüfungen nach DSGVO sowie relevante vertragliche oder sektorspezifische Pflichten.
☐ Der Ablauf wurde mindestens einmal anhand eines realistischen Cybervorfalls geübt.
In den ersten Stunden eines Vorfalls
☐ Incident-ID und Incident Commander wurden festgelegt.
☐ Zeitpunkt des ersten Alarms und alle weiteren relevanten Zeitpunkte werden protokolliert.
☐ Betroffene Systeme, Dienste und Geschäftsprozesse werden identifiziert.
☐ Technische Maßnahmen zur Eindämmung und Beweissicherung laufen.
☐ Auswirkungen auf Verfügbarkeit, Integrität und Vertraulichkeit werden bewertet.
☐ Die mögliche Erheblichkeit des Vorfalls nach BSIG wird geprüft.
☐ Informationssicherheit, IT-Leitung und gegebenenfalls Geschäftsleitung wurden entsprechend der Eskalationsmatrix informiert.
☐ Datenschutz und weitere mögliche Meldepflichten werden separat geprüft.
☐ Bekannte Tatsachen werden klar von Vermutungen und noch offenen Punkten getrennt dokumentiert.
☐ Die verbleibende Zeit bis zum Ablauf relevanter Meldefristen wird aktiv überwacht.
Vor Abgabe der frühen Erstmeldung
☐ Zeitpunkt der Kenntniserlangung und zugrunde liegende Erkenntnisse sind dokumentiert.
☐ Die Bewertung als erheblicher Sicherheitsvorfall ist nachvollziehbar festgehalten.
☐ Betroffene Dienste und bekannte Auswirkungen sind beschrieben.
☐ Verfügbare Informationen über Art und Umfang des Vorfalls wurden zusammengetragen.
☐ Der Verdacht auf rechtswidrige oder böswillige Handlungen sowie mögliche grenzüberschreitende Auswirkungen wurde berücksichtigt.
☐ Verantwortliche Person und Freigabeweg für die Meldung sind geklärt.
☐ Zeitpunkt und Inhalt der abgegebenen Meldung werden beweissicher beziehungsweise nachvollziehbar dokumentiert.
☐ Verantwortlichkeiten und Termine für die 72-Stunden-Meldung und weitere Folgemeldungen sind festgelegt.
Wer mehrere Punkte dieser Checkliste nicht eindeutig abhaken kann, hat einen konkreten Ansatzpunkt für die Verbesserung des Incident-Response-, ISMS- oder BCMS-Prozesses.
Tabletop-Test: Schafft Ihre Organisation die ersten vier Stunden?
Eine NIS2-Übung sollte nicht nur fragen, ob ein Notfallhandbuch vorhanden ist. Sie sollte die tatsächliche Reaktionskette testen.
Ein geeignetes Szenario beginnt beispielsweise freitags um 21:15 Uhr: Ransomware auf mehreren Systemen, ERP nicht verfügbar, Administratorzugang möglicherweise kompromittiert, Ursache unbekannt.
Nach 30 Minuten sollte klar sein, wer Incident Commander ist. Nach 60 Minuten sollte eine erste Übersicht der betroffenen Dienste vorliegen. Nach 90 Minuten sollte die regulatorische Erheblichkeitsprüfung laufen. Nach zwei Stunden sollten die notwendigen Management-, Security-, Datenschutz- und Compliance-Funktionen eingebunden sein.
Nach drei bis vier Stunden sollte eine Organisation zumindest in der Lage sein, auf Basis des aktuellen Erkenntnisstands einen Entwurf der frühen Erstmeldung zu erstellen – sofern sich der Vorfall als meldepflichtig erweist.
Diese Zeiten sind bewusst interne Übungsziele und keine gesetzlichen Fristen. Ihr Zweck besteht darin, ausreichend Reserve für technische Probleme, fehlende Informationen und Abstimmungen zu schaffen.
Fazit: Die 24-Stunden-Frist testet die Organisation, nicht nur die IT
§ 32 BSIG macht Incident Response zu einer interdisziplinären Managementaufgabe. Die technische Erkennung eines Angriffs allein reicht nicht. Unternehmen müssen innerhalb kurzer Zeit technische Erkenntnisse in eine Bewertung der geschäftlichen Auswirkungen und der regulatorischen Relevanz überführen können.
Entscheidend sind deshalb vorbereitete Erheblichkeitskriterien, eindeutige Verantwortlichkeiten, ein 24/7-Eskalationsweg, belastbare Zeitstempel, vorbereitete Meldeinformationen und regelmäßig getestete Abläufe.
Das Ziel sollte nicht lauten, einen komplexen Cyberangriff innerhalb von 24 Stunden vollständig aufzuklären. Das realistischere Ziel lautet: Innerhalb weniger Stunden ein belastbares Lagebild herstellen, die Meldepflicht qualifiziert prüfen und – soweit erforderlich – die gesetzlich vorgesehene Erstmeldung fristgerecht abgeben.
Damit wird die NIS2-Meldepflicht zugleich zu einem aussagekräftigen Reifegradtest für Incident Management, ISMS und BCMS.
Quelle und weiterführende Information
Für die rechtlichen Kernaussagen wurde die aktuelle Fassung des BSI-Gesetzes herangezogen. Insbesondere § 2 BSIG enthält relevante Begriffsbestimmungen, § 28 regelt besonders wichtige und wichtige Einrichtungen und § 32 die Meldepflichten bei erheblichen Sicherheitsvorfällen.
Als unionsrechtliche Grundlage wurde die Richtlinie (EU) 2022/2555 (NIS2) berücksichtigt. Insbesondere Art. 23 regelt die Berichtspflichten bei erheblichen Sicherheitsvorfällen.
Für die Abgrenzung einer möglichen parallelen Datenschutzmeldung wurde die Datenschutz-Grundverordnung, insbesondere Art. 33 DSGVO, herangezogen.
Als aktueller fachlicher Ausgangspunkt wurde außerdem der Beitrag „NIS2-Meldepflichten: 24h, 72h, 1 Monat im Detail“ von KCERT berücksichtigt. Die rechtlichen Kernaussagen des vorliegenden Beitrags wurden anhand der genannten Primärquellen abgeglichen; werbliche Inhalte wurden nicht übernommen.
Sehr gelungener und praxisnaher Beitrag. Besonders hilfreich finde ich die klare Darstellung der 24- und 72-Stunden-Fristen sowie die Checkliste für den Ernstfall. Als Ergänzung wäre eine kompakte grafische Übersicht des Meldeprozesses – von der Erkennung bis zur Abschlussmeldung – hilfreich, um die Abläufe und Verantwortlichkeiten noch schneller erfassen zu können.