Zum Inhalt springen

Vorfallsmanagement

Die 24h/72h/30-Tage-Meldekaskade und was in jede Stufe gehört

Was genau in die 24h-Frühwarnung gehört, was die 72h-Vollmeldung leisten muss und was § 32 BSIG im Abschlussbericht verlangt, samt dem Kenntniserlangungsproblem, das die meisten Unternehmen unterschätzen.

15 Min. Lesezeit · Veröffentlicht 02. März 2026

Schritt 4-2 des NIS2-Leitfadens benennt den Rahmen: dokumentierter Meldeprozess, drei Stufen, klare Fristen. Dieser Artikel füllt den Rahmen aus. Er beantwortet die Frage, die nach der Lektüre des Guide-Schritts bleibt: Was genau muss in welche der drei Meldungen – und was darf warten?

Wann die Uhr wirklich startet: Die Falle der Kenntniserlangung

§32 Abs. 1 S. 1 BSIG schreibt vor: Die Frühwarnung ist „unverzüglich, spätestens 24 Stunden nach Kenntniserlangung" einzureichen. Was nach einer klaren Regelung klingt, enthält eine operative Falle.

Die 24-Stunden-Frist beginnt nicht, wenn der CISO informiert wird. Sie beginnt nicht, wenn der Incident-Response-Prozess formell gestartet wurde. Sie beginnt nicht, wenn das Management von dem Vorfall weiß. Sie beginnt, wenn irgendein Mitarbeiter in Ihrer Einrichtung von dem Vorfall erfährt.

Das ist die entscheidende Abweichung vom DSGVO-Regime: Art. 33 DSGVO knüpft den Fristbeginn daran, dass der Verantwortliche – also die Organisation auf Leitungsebene – Kenntnis erlangt. Das NIS2-Regime ist strenger. §32 BSIG enthält keine Einschränkung auf verantwortliche Personen. Die Kenntniserlangung irgendeines Mitarbeiters genügt.

Was das in der Praxis bedeutet: Ein Tier-1-Analyst, der um 2:34 Uhr morgens einen Monitoring-Alert quittiert. Ein Help-Desk-Mitarbeiter, der ein Ticket über „merkwürdige Systemausfälle" anlegt. Ein Abteilungsleiter, der eine verdächtige E-Mail meldet. Jeder dieser Momente ist potenzielle Kenntniserlangung – und damit potenzieller Fristbeginn.

Der häufigste Fehler: Unternehmen rechnen damit, die Frist beginne, wenn das Incident-Response-Team zusammengerufen wird. Wer die interne Eskalationskette nicht sorgfältig vorbereitet hat, bemerkt diesen Irrtum erst, wenn die 24 Stunden bereits zu laufen begonnen haben.

Was das für die Vorbereitung bedeutet

  • Meldeverantwortlicher + Stellvertreter: Beide müssen 24/7 direkt erreichbar sein – nicht „per Eskalation erreichbar", sondern direkt. Name, Mobilnummer, Vertretungsregelung schriftlich fixiert.
  • Eskalationskette: Der Weg von Tier-1 → CISO/ISB → Meldeverantwortlicher muss in unter 60 Minuten laufen, nicht in 8 bis 12 Stunden. Diese Kette ist die erste Stellschraube für die Einhaltung der 24-Stunden-Frist.
  • Gilt auch nachts und am Wochenende: Die Frist läuft unabhängig von Bürozeiten. Die On-Call-Rotation aus Schritt 4-2-3 ist daher kein optionales Komfortfeature, sondern eine gesetzliche Betriebspflicht.

Die Frühwarnung (24 Stunden): Minimum zuerst, Vollständigkeit danach

Was §32 BSIG zwingend verlangt

§32 Abs. 1 S. 1 BSIG, umgesetzt aus Art. 23 Abs. 4 lit. a NIS2-RL, verlangt für die Frühwarnung inhaltlich genau zwei Angaben:

  • Vorsatz oder Rechtswidrigkeit: Deutet der Vorfall auf vorsätzliches oder rechtswidriges Handeln hin? Antwort: ja / nein / Verdacht. Eine begründete Vermutung genügt – volle Gewissheit ist nicht verlangt.
  • Grenzüberschreitende Auswirkungen: Könnten andere EU-Mitgliedstaaten betroffen sein – weil betroffene Systeme auch Dienste in anderen Ländern erbringen? Antwort: ja / nein / möglicherweise. Das BSI koordiniert bei positivem Befund mit dem CSIRT des betroffenen Mitgliedstaats.

Das ist das gesetzliche Minimum. Mehr ist nicht zwingend vorgeschrieben. Wer zum Zeitpunkt der Meldung noch nicht weiß, ob ein gezielter Angriff vorliegt, markiert es als „Verdacht". Wer keine grenzüberschreitenden Systeme betreibt, beantwortet die zweite Frage mit „nein".

Was das BSI-Portal darüber hinaus erwartet

Das BSI-Portal (portal.bsi.bund.de) ist seit dem 6. Januar 2026 das verpflichtende Meldesystem für NIS2-Einrichtungen. Die Portalmaske erwartet über die gesetzlichen Mindestangaben hinaus weitere Felder:

  • Kontaktdaten: Name, Funktion, Telefonnummer und E-Mail der meldenden Person.
  • Zeitstempel: Entdeckungszeitpunkt (Datum + Uhrzeit, UTC) und mutmaßlicher Eintrittszeitpunkt – falls abweichend.
  • Vorfall-Klassifizierung: Kategorie des Vorfalls: erheblicher Sicherheitsvorfall / Sicherheitsvorfall / Beinahevorfall.
  • Kurzbeschreibung: Art der Störung, betroffene Systeme oder Dienste, erwartete Dauer. Eine Schätzung genügt.
  • Schweregrad-Farbe: rot (vollständiger Ausfall) / orange (erhebliche Einschränkung) / gelb (geringfügige Auswirkung) / grau (kein Impact).
  • Sofortmaßnahmen: Welche ersten Maßnahmen bereits ergriffen wurden. „Incident-Response-Team aktiviert" reicht als Angabe aus.
  • Externe Unterstützung: Ob ein externer IR-Dienstleister oder MSSP eingesetzt wird.

Was die Frühwarnung ausdrücklich nicht leisten muss

Die häufigste Ursache für verspätete Frühwarnungen ist kein technisches Problem – es ist ein selbst auferlegter Qualitätsmaßstab. IT-Leiter und Sicherheitsverantwortliche zögern, weil die Analyse noch nicht abgeschlossen ist, weil der Schadensumfang noch unbekannt ist, weil noch keine IoCs identifiziert wurden. Das Gesetz verlangt das nicht.

Die Frühwarnung muss nicht enthalten:

  • Vollständige Ursachenanalyse
  • Bewiesenen oder quantifizierten Schadensumfang
  • Indicators of Compromise (IoCs)
  • Genaue Zahl betroffener Systeme oder Nutzer
  • Endgültige Schweregrad-Einstufung

Unvollständige Angaben, die als „vorläufig" oder „zum Zeitpunkt der Meldung noch nicht bekannt" markiert sind, sind rechtlich korrekt und vollständig. Die Vollmeldung in 72 Stunden ergänzt und korrigiert.

Die Faustregel: Eine gute-genug-Frühwarnung um Stunde 23 ist besser als eine perfekte Meldung um Stunde 25. Die verfehlte 24-Stunden-Frist ist ein eigenständiger Bußgeldtatbestand – unabhängig davon, wie gut der Rest des Meldeprozesses lief.

Die Vollmeldung (72 Stunden): Erste echte Bewertung

Der Uhrzeiger für die Vollmeldung läuft vom gleichen Startpunkt wie die Frühwarnung – nicht 72 Stunden nach der Frühwarnung, sondern 72 Stunden nach der Kenntniserlangung. Wer die Frühwarnung an Stunde 23 einreicht, hat für die Vollmeldung noch rund 49 Stunden Zeit.

Was §32 BSIG neu hinzuverlangt

§32 Abs. 1 S. 2 BSIG, umgesetzt aus Art. 23 Abs. 4 lit. b NIS2-RL, verlangt für die Vollmeldung drei Dinge:

  • Aktualisierung: Bestätigung oder Aktualisierung aller Angaben aus der Frühwarnung. Was sich seit der Erstmeldung verändert hat, wird hier korrigiert.
  • Erste Bewertung: Einschätzung des Schweregrads und der tatsächlichen sowie potenziellen Auswirkungen des Vorfalls. Das ist kein endgültiges Urteil – eine dokumentierte Einschätzung nach bestem Wissen, mit explizitem Hinweis auf noch offene Punkte.
  • Indicators of Compromise (IoCs): Soweit bereits identifiziert: IP-Adressen, Datei-Hashes, Domain-Namen, Registry-Keys oder andere technische Indikatoren, die den Vorfall beschreiben.

Was das BSI-Portal für die 72-Stunden-Meldung erwartet

Die Vollmeldung baut auf der Frühwarnung auf und erweitert sie. Die Portalmaske erwartet:

  • CIA-Schutzziel: Welches der drei Schutzziele betroffen ist – Vertraulichkeit / Integrität / Verfügbarkeit. Mehrfachnennung ist möglich und häufig zutreffend.
  • Angriffstyp: gezielt (auf Ihre Einrichtung abgezielt) / ungezielt (opportunistisch, Massenkampagne) / unbekannt.
  • Ursache und Angriffsmethode: Technische Ursachenbeschreibung per Dropdown und Freitext – z.B. „Ransomware via Phishing-E-Mail, Ausnutzung CVE-XXXX".
  • Schwachstellen-Details: CVE-Nummer (falls vorhanden), betroffenes Produkt und Hersteller, Patch-Status (verfügbar / ausstehend / nicht verfügbar), aktuelle Schadensbegrenzungsmaßnahmen.
  • Betroffene Systeme und Assets: Liste der betroffenen IT-Systeme, Dienste und Datenkategorien – Schätzungen sind zum jetzigen Zeitpunkt ausdrücklich akzeptabel.
  • Nutzerzahl: Geschätzte Anzahl betroffener Nutzer oder Kunden.
  • Finanzieller Schaden: Geschätzte Schadenshöhe – kann zum Zeitpunkt der 72h-Meldung noch unvollständig sein, sollte aber eine erste Größenordnung benennen.
  • BKA-Weiterleitung: Ob Sie eine Weiterleitung an das Bundeskriminalamt zur Strafverfolgung wünschen. Falls bereits eine Strafanzeige gestellt wurde: Aktenzeichen angeben.
  • Andere Behörden: Welche weiteren Behörden bereits informiert wurden – Datenschutzbehörde, BNetzA, BaFin, gematik oder andere sektorspezifische Stellen.

Die parallele DSGVO-Meldepflicht

Wenn personenbezogene Daten von dem Vorfall betroffen sind, läuft parallel zur NIS2-Meldung eine DSGVO-Meldepflicht nach Art. 33 DSGVO. Beide Pflichten müssen eigenständig und rechtzeitig erfüllt werden – sie sind nicht austauschbar.

  • Empfänger unterscheiden sich: Die NIS2-Meldung geht an das BSI. Die DSGVO-Meldung geht an die zuständige Landesdatenschutzbehörde oder den BfDI.
  • Fristbeginn unterscheidet sich: Art. 33 DSGVO lässt die 72-Stunden-Frist mit Kenntniserlangung des Verantwortlichen beginnen – nicht irgendeines Mitarbeiters. Der NIS2-Startpunkt kann daher früher liegen.
  • Inhalte unterscheiden sich: Beide Meldungen haben unterschiedliche Felder und Schwerpunkte. Eine Meldung ersetzt die andere nicht.

Die Koordination beider Meldepflichten behandelt Artikel B-10a im Detail.

Der Abschlussbericht (30 Tage): Was §32 BSIG konkret verlangt

Dieser Abschnitt behandelt die gesetzlichen Inhaltspflichten des Abschlussberichts – was §32 BSIG in dem Dokument fordert. Die forensische Methodik dahinter: wie eine Ursachenanalyse belastbar untermauert wird und was BSI-Prüfer im Abschlussbericht prüfen, ist Gegenstand von Artikel A-27.

Gesetzliches Minimum: vier Pflichtangaben

§32 Abs. 1 S. 3 BSIG, umgesetzt aus Art. 23 Abs. 4 lit. c NIS2-RL, schreibt vier Pflichtangaben vor:

  • Detaillierte Beschreibung: Schweregrad und tatsächliche Konsequenzen des Vorfalls. An dieser Stelle sind nicht mehr „potenzielle" Auswirkungen gefragt, sondern die abschließende Bewertung: welche Dienste wie lange ausgefallen sind, wie viele Nutzer tatsächlich betroffen waren, welcher finanzielle Schaden tatsächlich eingetreten ist.
  • Bedrohungsart oder Grundursache: Was den Vorfall ausgelöst hat. Diese Angabe ist die anspruchsvollste des Abschlussberichts (mehr dazu im nächsten Abschnitt).
  • Ergriffene und noch laufende Abhilfemaßnahmen: Was zur Behebung des Vorfalls getan wurde und was noch in Arbeit ist. Laufende Maßnahmen müssen nicht abgeschlossen sein – sie müssen benannt und mit voraussichtlichem Abschluss versehen werden.
  • Grenzüberschreitende Auswirkungen: Abschließende Beurteilung, ob und inwiefern andere EU-Mitgliedstaaten betroffen waren. Das BSI greift auf diese Einschätzung zurück, wenn es EU-weit koordinieren muss.

Was „Grundursache" im Abschlussbericht wirklich bedeutet

„Grundursache" ist nicht eine Kategorie – es ist ein spezifischer Befund. Der Unterschied entscheidet darüber, ob der Abschlussbericht eine BSI-Prüfung besteht.

Eine Kategorie klingt so: „Phishing-Angriff" oder „menschliches Versagen". Sie beschreibt, was passiert ist, nicht warum es möglich war.

Ein Befund klingt so: „Ungepatchter Exchange-Server CVE-2023-XXXX (Sicherheitshinweis bekannt seit 14. März 2023), Patch nicht eingespielt, weil kein definierter Patch-Prozess für Serversoftware außerhalb der Schutzkategorie A bestand. Angreifer nutzte die Schwachstelle am [Datum] aus, um initialen Zugriff zu erlangen."

Das BSI-Prüfteam prüft nicht, ob ein Befund bequem klingt. Es prüft, ob die dokumentierten forensischen Artefakte die behauptete Ursache tatsächlich belegen. Artikel A-27 beschreibt, welche Artefakte dazu notwendig sind.

Was einen belastbaren Befund ausmacht:

  • Konkrete technische Schwachstelle oder Fehlkonfiguration – mit Bezeichnung, ggf. CVE
  • Zeitlicher Ablauf: wann die Schwachstelle bekannt war, wann sie ausgenutzt wurde
  • Warum die Schwachstelle nicht früher geschlossen wurde: Prozess, Priorisierung, Ressourcen
  • Wie der Angreifer die Schwachstelle technisch ausgenutzt hat

Der Fortschrittsbericht: wenn der Vorfall nach 30 Tagen noch andauert

Ist der Vorfall 30 Tage nach der 72-Stunden-Meldung noch aktiv – etwa weil die Ransomware-Bereinigung noch läuft, eine APT-Gruppe noch im System aktiv ist oder die vollständige Systemwiederherstellung noch aussteht – kann kein vollständiger Abschlussbericht erstellt werden.

In diesem Fall verlangt §32 BSIG einen Fortschrittsbericht. Er tritt an die Stelle des Abschlussberichts und dokumentiert den aktuellen Stand der Bearbeitung. Der Abschlussbericht wird eingereicht, sobald der Vorfall endgültig abgeschlossen ist.

Wichtig: Das Fehlen eines Fortschrittsberichts zum 30-Tage-Zeitpunkt ist eine eigenständige Pflichtverletzung – auch wenn der Vorfall objektiv noch andauert. Der Fortschrittsbericht belegt, dass der Bearbeitungsprozess läuft. Er ist kein Schwächeeingeständnis, sondern eine Compliance-Anforderung.

Konsequenzen bei Fristversäumnis

§65 Abs. 2 Nr. 4 und Nr. 5 BSIG regeln die Ordnungswidrigkeiten. Der Tatbestand ist jeweils: eine Meldung „nicht, nicht richtig, nicht vollständig oder nicht rechtzeitig" einzureichen. Dieser Tatbestand gilt für jede Stufe der Kaskade unabhängig voneinander.

Bußgeldrahmen

  • Besonders wichtige Einrichtungen (§28 Abs. 1 BSIG): bis zu 10.000.000 EUR oder 2 % des weltweiten Jahresumsatzes – je nachdem, welcher Betrag höher ist.
  • Wichtige Einrichtungen (§28 Abs. 2 BSIG): bis zu 7.000.000 EUR oder 1,4 % des weltweiten Jahresumsatzes – je nachdem, welcher Betrag höher ist.

Drei häufig unterschätzte Punkte

  • Jede Stufe ist ein eigenständiger Tatbestand: Wer die 24-Stunden-Frist und die 72-Stunden-Frist verfehlt, hat nicht eine, sondern zwei eigenständige Ordnungswidrigkeiten begangen – jeweils mit dem vollen Bußgeldrahmen.
  • Technisch gutes Incident-Response mindert verfahrensrechtliche Verstöße nicht: Wer den Vorfall mustergültig bearbeitet, aber die Frühwarnung 3 Stunden zu spät eingereicht hat, hat trotzdem eine Ordnungswidrigkeit begangen. Der Ausgang des Incidents ist für den prozeduralen Verstoß irrelevant.
  • Management-Haftung nach §38 Abs. 2 BSIG: Die Geschäftsleitung haftet der Einrichtung gegenüber persönlich für fahrlässig verursachte BSIG-Verstöße. Diese Haftung tritt zur Haftung der Einrichtung als Bußgeldschuldnerin hinzu – sie ersetzt sie nicht.

Einordnung: Wo dieser Artikel in die Guide-Schritte passt

Dieser Artikel behandelt die Inhaltsanforderungen aller drei Meldestufen. Was er nicht behandelt:

  • Erheblichkeitsschwelle: Die Frage, ob ein Vorfall überhaupt meldepflichtig ist, behandelt Artikel A-07.
  • Forensische Methodik: Wie eine Ursachenanalyse belastbar dokumentiert wird und was BSI-Prüfer im Abschlussbericht prüfen, behandelt Artikel A-27.
  • Portal-Walkthrough: Die Schritt-für-Schritt-Anleitung zur Einreichung im BSI-Meldeportal behandelt Artikel B-10.

Im Guide-Schritt 4-2-2 erstellen Sie auf Basis der Inhaltsanforderungen aus diesem Artikel die Meldevorlagen für alle drei Stufen. Fertige Vorlagen für Frühwarnung, Vollmeldung und Abschlussbericht stehen im Leitfaden bereit.

Weiter im Leitfaden: Schritt 4-3 behandelt die Incident-Response-Übung. Artikel A-28 beschreibt, welche Übungsformate §30 Abs. 2 Nr. 6 BSIG verlangt und was dabei dokumentiert werden muss.

Dieser Artikel ersetzt keine Rechtsberatung. Für Fragen zur konkreten rechtlichen Einordnung Ihrer Situation wenden Sie sich an einen auf IT-Recht oder Cybersicherheitsrecht spezialisierten Anwalt.

Dieser Artikel ist Orientierung, keine Rechtsberatung. Prüfen Sie Betroffenheit, Fristen und Meldewege gegen die für Ihre Organisation geltende Regelung.

Zurück zur Wissensdatenbank