Ein Cyberangriff beginnt selten mit vollständiger Klarheit.

Vielleicht meldet das EDR um 08:14 Uhr verdächtige Aktivitäten auf einem Server. Um 08:27 Uhr stellt die IT fest, dass mehrere Benutzerkonten kompromittiert sein könnten. Um 09:05 Uhr fällt ein wichtiger Dienst aus. Erst einige Stunden später wird deutlich, dass möglicherweise Daten abgeflossen sind.

Während die IT versucht, den Angriff einzudämmen, beginnt gleichzeitig eine zweite Herausforderung:

Müssen wir den Vorfall melden?

Und wenn ja:

Wann? An wen? Mit welchen Informationen?

Genau hier greifen die Meldepflichten nach NIS-2 beziehungsweise deren Umsetzung im deutschen BSI-Gesetz.

Besonders wichtige und wichtige Einrichtungen müssen erhebliche Sicherheitsvorfälle über den vorgesehenen Meldeweg melden.

Dabei folgt die Meldung keinem einmaligen „Formular abschicken und fertig“-Prinzip.

Vielmehr entsteht ein mehrstufiger Prozess:

Kenntnis → Erstmeldung → 72-Stunden-Meldung → gegebenenfalls Zwischenmeldung → Abschlussmeldung

Die entscheidende Herausforderung:

Die Uhr läuft bereits, während die technische Untersuchung häufig noch ganz am Anfang steht.

1. Nicht jeder Sicherheitsvorfall ist automatisch meldepflichtig

Eine wichtige Unterscheidung lautet:

Security Incident ≠ automatisch meldepflichtiger NIS-2-Vorfall

Ein einzelner mit Malware infizierter Arbeitsplatzrechner, den ein EDR-System sofort isoliert und der keine weiteren Auswirkungen verursacht, muss nicht zwangsläufig die Schwelle eines erheblichen Sicherheitsvorfalls erreichen.

Entscheidend ist die Erheblichkeit.

Nach dem deutschen BSI-Gesetz ist ein Sicherheitsvorfall insbesondere dann erheblich, wenn er schwerwiegende Betriebsstörungen oder finanzielle Verluste verursacht hat beziehungsweise verursachen kann oder andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat beziehungsweise beeinträchtigen kann.

Die erste Aufgabe lautet deshalb:

Vorfall erkennen → Erheblichkeit bewerten

2. Wann beginnt die Frist?

Dieser Punkt ist enorm wichtig.

Die Fristen orientieren sich an der Kenntniserlangung von einem erheblichen Sicherheitsvorfall.

Deshalb muss eine Organisation intern eindeutig regeln, wie ein möglicher Vorfall bewertet und eskaliert wird.

Ein Beispiel:

08:14
EDR erzeugt Alarm

08:20
SOC untersucht Alarm

08:43
Kompromittierung bestätigt

09:10
Auswirkungen auf kritischen Dienst festgestellt

09:25
Vorfall als erheblich bewertet

Eine solche Timeline muss nachvollziehbar dokumentiert werden.

Organisationen sollten die Bewertung nicht künstlich hinauszögern, um vermeintlich mehr Zeit für eine Meldung zu gewinnen.

Der Prozess muss vielmehr sicherstellen, dass mögliche erhebliche Vorfälle unverzüglich bewertet und eskaliert werden.

3. Die wichtigsten Fristen im Überblick

Für besonders wichtige und wichtige Einrichtungen sieht § 32 BSIG grundsätzlich mehrere Meldestufen vor.

Vereinfacht:

Kenntnis vom erheblichen
Sicherheitsvorfall
        │
        ├── spätestens 24 Stunden
        │        ↓
        │    frühe Erstmeldung
        │
        ├── spätestens 72 Stunden
        │        ↓
        │    Meldung des Vorfalls
        │
        ├── auf Ersuchen
        │        ↓
        │    Zwischenmeldung
        │
        └── spätestens 1 Monat
                 ↓
            Abschlussmeldung

Wichtig:

Die Monatsfrist für die Abschlussmeldung läuft nach der 72-Stunden-Meldung.

Ist der Vorfall zu diesem Zeitpunkt noch nicht abgeschlossen, ist stattdessen eine Fortschrittsmeldung vorgesehen; die Abschlussmeldung folgt nach der abschließenden Bearbeitung.

4. Die frühe Erstmeldung innerhalb von 24 Stunden

Die erste Stufe ist eine frühe Erstmeldung.

Sie muss unverzüglich, spätestens jedoch innerhalb von 24 Stunden nach Kenntniserlangung von dem erheblichen Sicherheitsvorfall erfolgen.

Diese Meldung ist bewusst als frühe Meldung konzipiert.

Zu diesem Zeitpunkt muss die Organisation noch nicht sämtliche technischen Details kennen.

Das wäre bei komplexen Cyberangriffen häufig unmöglich.

Die frühe Erstmeldung soll insbesondere erkennen lassen, ob der Verdacht besteht, dass der Vorfall:

• auf rechtswidrige oder böswillige Handlungen zurückzuführen ist,
• oder grenzüberschreitende Auswirkungen haben könnte.

Die wichtigste Erkenntnis lautet deshalb:

Die 24-Stunden-Meldung ist keine fertige forensische Analyse.

Sie ist eine frühe Information über einen erheblichen Sicherheitsvorfall.

5. Was könnte in einer Erstmeldung stehen?

Ein vereinfachtes Beispiel:

Art des Vorfalls:
Verdacht auf Ransomware-Angriff

Kenntnis:
30.08.2026, 08:43 Uhr

Betroffene Systeme:
mehrere Clients und zentraler Fileserver

Aktuelle Auswirkungen:
eingeschränkter Zugriff auf zentrale Dateien

Vermutete Ursache:
wird untersucht

Böswillige Handlung:
Verdacht besteht

Grenzüberschreitende Auswirkungen:
aktuell nicht bekannt

Aktueller Status:
Incident Response läuft

Entscheidend ist nicht, jede offene Frage innerhalb von 24 Stunden abschließend zu beantworten.

Entscheidend ist, die bereits bekannten Informationen korrekt weiterzugeben.

Unbekannte Sachverhalte sollten als unbekannt beziehungsweise noch in Untersuchung gekennzeichnet werden.

6. Die 72-Stunden-Meldung

Spätestens innerhalb von 72 Stunden nach Kenntniserlangung muss eine weitere Meldung über den Sicherheitsvorfall erfolgen.

Dabei werden die Angaben aus der frühen Erstmeldung:

• bestätigt,
• aktualisiert,
• und erweitert.

Zusätzlich soll eine erste Bewertung des Vorfalls erfolgen.

Dazu gehören insbesondere:

• Schweregrad,
• Auswirkungen,
• gegebenenfalls Kompromittierungsindikatoren.

Innerhalb der ersten 72 Stunden sollte die Organisation deshalb bereits ein deutlich besseres Lagebild aufgebaut haben.

7. Indicators of Compromise in der Meldung

Wie bereits in Teil 14 beschrieben, können während eines Cyberangriffs sogenannte Indicators of Compromise (IoCs) identifiziert werden.

Beispiele:

IP-Adresse:
203.0.113.42

Domain:
malicious-example.invalid

SHA-256:
ABC123...

Dateiname:
update-service.exe

Solche Informationen können für die zuständigen Stellen wertvoll sein, weil möglicherweise auch andere Organisationen von derselben Angriffskampagne betroffen sind.

Natürlich sollten nur tatsächlich belastbare Erkenntnisse übermittelt werden.

8. Die Zwischenmeldung

Nach der 72-Stunden-Meldung kann das BSI eine Zwischenmeldung über relevante Statusaktualisierungen verlangen.

Das ist besonders bei länger andauernden oder komplexen Sicherheitsvorfällen sinnvoll.

Beispielsweise:

Tag 1
Ransomware erkannt

Tag 3
Umfang teilweise bekannt

Tag 5
weitere kompromittierte Systeme entdeckt

Tag 8
Hinweise auf Datenabfluss

Tag 12
Produktionssysteme wiederhergestellt

Die Sicherheitslage kann sich während eines Incident-Response-Prozesses erheblich verändern.

Die Zwischenmeldung sorgt dafür, dass relevante neue Erkenntnisse weitergegeben werden können.

9. Die Abschlussmeldung

Spätestens einen Monat nach Übermittlung der 72-Stunden-Meldung muss grundsätzlich die Abschlussmeldung erfolgen.

Diese ist wesentlich detaillierter.

Sie enthält insbesondere:

• ausführliche Beschreibung des Sicherheitsvorfalls,
• Schweregrad,
• Auswirkungen,
• Art der Bedrohung beziehungsweise wahrscheinliche Ursache,
• getroffene Abhilfemaßnahmen,
• laufende Abhilfemaßnahmen,
• gegebenenfalls grenzüberschreitende Auswirkungen.

Hier fließen die Ergebnisse aus Incident Response und Forensik zusammen.

10. Was passiert, wenn der Vorfall nach einem Monat noch läuft?

Große Cyberangriffe können deutlich länger als einen Monat dauern.

Vielleicht sind:

• forensische Untersuchungen noch nicht abgeschlossen,
• Systeme weiterhin in Wiederherstellung,
• Ursachen noch nicht vollständig geklärt,
• weitere Maßnahmen notwendig.

Dann wird nicht einfach eine vermeintlich endgültige Abschlussmeldung erstellt.

Ist der Sicherheitsvorfall zu diesem Zeitpunkt noch nicht abgeschlossen, ist eine Fortschrittsmeldung vorgesehen.

Nach Abschluss der Bearbeitung folgt anschließend die eigentliche Abschlussmeldung.

11. Zuständigkeit für die Meldung

Die Organisation sollte intern eindeutig festlegen:

Wer darf beziehungsweise muss eine NIS-2-Meldung auslösen und übermitteln?

Mögliche Beteiligte sind beispielsweise:

• Informationssicherheitsbeauftragter,
• CISO,
• Incident Manager,
• IT-Leitung,
• Geschäftsführung beziehungsweise Behördenleitung,
• Rechtsabteilung,
• Datenschutz.

Dabei sollte nicht jeder Beteiligte unabhängig Meldungen versenden.

Sinnvoll ist ein definierter Prozess.

Beispielsweise:

SOC / IT
   │
   ▼
Incident Manager
   │
   ▼
Informationssicherheit
   │
   ├── technische Bewertung
   ├── Erheblichkeit
   └── Meldepflicht
           │
           ▼
     Freigabeprozess
           │
           ▼
       Meldestelle

Der Freigabeprozess darf allerdings nicht so kompliziert sein, dass dadurch gesetzliche Fristen verpasst werden.

12. Der Meldeweg

In Deutschland stellt das BSI für die Registrierung und Meldung von Sicherheitsvorfällen das BSI-Portal bereit.

Die Organisation sollte diesen Zugang nicht erst einrichten, wenn gerade ein Ransomware-Angriff läuft.

Bereits vorher sollte geklärt werden:

• Ist die Einrichtung registriert?
• Wer besitzt Zugang?
• Wer darf Meldungen abgeben?
• Gibt es Stellvertreter?
• Funktioniert die Authentifizierung?
• Sind Kontaktdaten aktuell?

Ein vorbereiteter Meldeweg spart im Ernstfall wertvolle Zeit.

13. Meldung und Incident Response müssen parallel laufen

Ein häufiger Denkfehler wäre:

Angriff
  ↓
komplett untersuchen
  ↓
Problem beheben
  ↓
Meldung erstellen

Das funktioniert bei kurzen gesetzlichen Fristen nicht.

Stattdessen laufen mehrere Prozesse parallel:

              ┌── Eindämmung
              │
Incident ─────┼── Forensik
              │
              ├── Wiederherstellung
              │
              ├── Kommunikation
              │
              └── Meldeprozess

Deshalb müssen technische Incident Response und regulatorisches Meldewesen miteinander verzahnt sein.

14. Dokumentation beginnt in Minute eins

Eine der wichtigsten Grundlagen für eine korrekte Meldung ist eine saubere Incident-Timeline.

Beispielsweise:

08:14  EDR-Alarm

08:20  SOC beginnt Analyse

08:43  Kompromittierung bestätigt

09:10  erhebliche Betriebsstörung erkannt

09:25  Incident eskaliert

09:40  betroffene Systeme isoliert

10:15  Krisenteam aktiviert

11:30  Umfang weiter analysiert

Diese Dokumentation beantwortet später zentrale Fragen:

• Wann wurde der Vorfall erkannt?
• Wann wurde seine Erheblichkeit bekannt?
• Welche Systeme waren betroffen?
• Wann wurden welche Maßnahmen durchgeführt?
• Welche Informationen lagen zu welchem Zeitpunkt vor?

Das ist sowohl für Incident Response als auch für die Nachweisführung entscheidend.

15. Technische und regulatorische Dokumentation verbinden

Viele Informationen entstehen ohnehin während des Incident-Response-Prozesses.

Beispielsweise:

SIEM

liefert Zeitstempel und Ereignisse.

EDR

liefert Informationen zu kompromittierten Endpunkten.

Firewall

liefert Netzwerkverbindungen.

Forensik

liefert Ursache und Angriffspfad.

Service Management

liefert Informationen über Ausfälle.

Business Continuity

liefert Auswirkungen auf Geschäftsprozesse.

Diese Informationen sollten nicht in getrennten Silos verschwinden.

Ein zentrales Incident-Dossier kann die relevanten Informationen zusammenführen.

16. Beispiel 1: Malware auf einem einzelnen Client

Ein Mitarbeiter öffnet einen schädlichen E-Mail-Anhang.

Das EDR erkennt die Malware unmittelbar und isoliert den Rechner.

Es gibt:

• keine laterale Bewegung,
• keinen Datenabfluss,
• keinen Ausfall,
• keine erheblichen Auswirkungen.

Das Ereignis muss selbstverständlich intern behandelt und dokumentiert werden.

Es erreicht aber möglicherweise nicht die Schwelle eines erheblichen Sicherheitsvorfalls im Sinne der NIS-2-Meldepflicht.

Das Beispiel zeigt:

Nicht jeder Cybersecurity-Vorfall löst automatisch die NIS-2-Meldekette aus.

17. Beispiel 2: Ransomware legt zentrale Dienste lahm

Mehrere Server und Clients werden verschlüsselt.

Zentrale Dienste fallen aus.

Mitarbeiter können wichtige Geschäftsprozesse nicht mehr durchführen.

Die Wiederherstellung wird voraussichtlich mehrere Tage dauern.

Hier spricht vieles dafür, dass eine erhebliche Betriebsstörung vorliegt.

Der Prozess könnte deshalb beispielsweise lauten:

Ransomware erkannt
       │
       ▼
Erheblichkeit bestätigt
       │
       ├── Incident Response
       │
       └── NIS-2-Meldeprozess
                 │
                 ├── 24 h
                 ├── 72 h
                 ├── ggf. Zwischenmeldung
                 └── Abschlussmeldung

18. Beispiel 3: Kompromittierter Cloud-Dienst

Ein externer Cloud-Dienstleister meldet einen Sicherheitsvorfall.

Dadurch könnten Daten oder Dienste der eigenen Organisation betroffen sein.

Hier zeigt sich die Bedeutung der Lieferkettensicherheit.

Die Organisation muss prüfen:

• Sind eigene Dienste betroffen?
• Welche Auswirkungen bestehen?
• Liegt ein eigener erheblicher Sicherheitsvorfall vor?
• Welche Informationen liefert der Dienstleister?
• Welche Meldepflichten entstehen daraus?

Verträge mit Dienstleistern sollten deshalb klare Informations- und Eskalationswege für Sicherheitsvorfälle enthalten.

19. Beispiel 4: DDoS-Angriff

Ein Internetdienst wird durch einen massiven Distributed-Denial-of-Service-Angriff über Stunden erheblich beeinträchtigt.

Es wurden möglicherweise keine Daten gestohlen und keine Systeme dauerhaft kompromittiert.

Trotzdem kann ein erheblicher Sicherheitsvorfall vorliegen.

Denn NIS-2 betrachtet nicht ausschließlich Vertraulichkeit.

Auch die Verfügbarkeit von Diensten ist ein wesentlicher Bestandteil der Informationssicherheit.

20. Beispiel 5: Datenabfluss ohne Systemausfall

Ein Angreifer kompromittiert ein Benutzerkonto und kopiert erhebliche Datenmengen.

Die Systeme funktionieren weiterhin völlig normal.

Kein Server fällt aus.

Kein Bildschirm bleibt schwarz.

Kein Mitarbeiter bemerkt zunächst eine Störung.

Trotzdem kann der Vorfall erheblich sein.

Das zeigt:

Keine Betriebsunterbrechung bedeutet nicht automatisch keine Meldepflicht.

Auch erhebliche materielle oder immaterielle Schäden für andere Personen können relevant sein.

21. NIS-2 und DSGVO nicht verwechseln

Ein Cybervorfall kann mehrere gesetzliche Meldepflichten gleichzeitig auslösen.

Beispielsweise:

Cyberangriff
     │
     ├── NIS-2 / BSIG
     │
     ├── DSGVO
     │
     ├── branchenspezifische Pflichten
     │
     └── vertragliche Informationspflichten

Diese Pflichten besitzen unterschiedliche:

• Voraussetzungen,
• Empfänger,
• Inhalte,
• Fristen.

Eine NIS-2-Meldung ersetzt deshalb nicht automatisch eine gegebenenfalls erforderliche Datenschutzmeldung.

Organisationen sollten diese Prozesse miteinander koordinieren, aber rechtlich getrennt bewerten.

22. Kommunikation mit Betroffenen

Unter bestimmten Voraussetzungen kann auch die Information der Empfänger eines Dienstes relevant werden.

Das BSI kann bei einem erheblichen Sicherheitsvorfall insbesondere anordnen, dass Empfänger eines beeinträchtigten Dienstes informiert werden.

Bei bestimmten erheblichen Cyberbedrohungen bestehen darüber hinaus besondere Informationspflichten für bestimmte Sektoren.

Deshalb sollte der Incident-Response-Prozess auch eine Schnittstelle zur Krisenkommunikation besitzen.

23. Was nach einer Meldung passiert

Eine Meldung ist keine Einbahnstraße.

Nach § 36 BSIG übermittelt das BSI einer meldenden Einrichtung eine Eingangsbestätigung und kann auf Ersuchen Orientierungshilfen beziehungsweise operative Beratung zu Abhilfemaßnahmen anbieten.

Auch zusätzliche technische Unterstützung kann auf Ersuchen möglich sein.

Das unterstreicht einen wichtigen Punkt:

Die Meldestelle dient nicht ausschließlich der regulatorischen Kontrolle.

Die Informationen können auch zur Bewältigung von Cybervorfällen und zur Verbesserung des Lagebildes beitragen.

24. Typische Fehler bei NIS-2-Meldungen

Fehler 1: Zu lange auf vollständige Informationen warten

Die frühe Erstmeldung verlangt keine abgeschlossene Forensik.

Fehler 2: Niemand fühlt sich zuständig

Meldeverantwortlichkeiten müssen vor einem Vorfall festgelegt werden.

Fehler 3: Zugang zum Meldeportal fehlt

Registrierung und Berechtigungen gehören zur Vorbereitung.

Fehler 4: Keine Incident-Timeline

Ohne Zeitstempel wird später schwer nachvollziehbar, wann welche Erkenntnisse vorlagen.

Fehler 5: Technik und Meldeprozess arbeiten getrennt

Informationen aus SOC, IT und Forensik müssen den Meldeverantwortlichen erreichen.

Fehler 6: NIS-2 und DSGVO werden gleichgesetzt

Die jeweiligen Meldepflichten müssen separat geprüft werden.

Fehler 7: Die Abschlussmeldung wird vergessen

Die frühe Meldung ist nur der Beginn des Meldeprozesses.

25. Einen NIS-2-Meldeprozess vorbereiten

Ein interner Prozess könnte folgendermaßen aufgebaut sein:

Security Alert
      │
      ▼
Incident bestätigen
      │
      ▼
Erheblichkeit bewerten
      │
      ├── Nein → intern dokumentieren
      │
      └── Ja
           │
           ▼
     Meldeprozess starten
           │
           ├── 24-h-Erstmeldung
           │
           ├── 72-h-Meldung
           │
           ├── Zwischenmeldung
           │
           └── Abschlussmeldung

Dieser Ablauf sollte Teil des Incident-Response-Plans sein.

Praktische NIS-2-Checkliste für Meldepflichten

Vorbereitung

☐ Ist bekannt, ob die Organisation unter die relevanten NIS-2-Pflichten fällt?

☐ Ist die Einrichtung beim BSI registriert?

☐ Funktioniert der vorgesehene Meldeweg?

☐ Sind Meldeberechtigte und Stellvertreter festgelegt?

☐ Sind Kontaktdaten aktuell?

Bewertung

☐ Gibt es Kriterien für erhebliche Sicherheitsvorfälle?

☐ Ist geregelt, wer die Erheblichkeit bewertet?

☐ Kann die Bewertung auch außerhalb der Geschäftszeiten erfolgen?

☐ Wird der Zeitpunkt der Kenntniserlangung dokumentiert?

24-Stunden-Meldung

☐ Kann kurzfristig eine frühe Erstmeldung erstellt werden?

☐ Kann eine mögliche böswillige Handlung bewertet werden?

☐ Können mögliche grenzüberschreitende Auswirkungen eingeschätzt werden?

☐ Werden unbekannte Sachverhalte eindeutig als noch ungeklärt gekennzeichnet?

72-Stunden-Meldung

☐ Können die Angaben der Erstmeldung aktualisiert werden?

☐ Ist eine erste Bewertung des Schweregrads möglich?

☐ Sind Auswirkungen dokumentiert?

☐ Können vorhandene IoCs bereitgestellt werden?

Zwischen- und Fortschrittsmeldungen

☐ Können relevante neue Erkenntnisse kurzfristig aufbereitet werden?

☐ Ist geregelt, wer auf Rückfragen beziehungsweise Ersuchen des BSI reagiert?

☐ Ist eine Fortschrittsmeldung vorbereitet, falls der Vorfall nach einem Monat noch nicht abgeschlossen ist?

Abschlussmeldung

☐ Ist der Vorfall ausführlich dokumentiert?

☐ Ist die wahrscheinliche Ursache bekannt?

☐ Sind Auswirkungen beschrieben?

☐ Sind getroffene Abhilfemaßnahmen dokumentiert?

☐ Sind noch laufende Maßnahmen aufgeführt?

☐ Wurden gegebenenfalls grenzüberschreitende Auswirkungen bewertet?

Dokumentation

☐ Existiert eine vollständige Incident-Timeline?

☐ Werden Entscheidungen nachvollziehbar dokumentiert?

☐ Werden übermittelte Meldungen archiviert?

☐ Werden Änderungen zwischen den Meldestufen nachvollziehbar festgehalten?

☐ Werden Lessons Learned anschließend in Prozesse übernommen?

Die NIS-2-Meldepflicht macht aus Incident Response zusätzlich einen zeitkritischen regulatorischen Prozess.

Besonders wichtige und wichtige Einrichtungen können bei erheblichen Sicherheitsvorfällen nicht warten, bis eine mehrwöchige forensische Untersuchung abgeschlossen ist.

Die Meldekette beginnt früh.

Spätestens innerhalb von 24 Stunden erfolgt die frühe Erstmeldung.

Spätestens innerhalb von 72 Stunden folgt eine ausführlichere Meldung mit einer ersten Bewertung.

Auf Ersuchen können Zwischenmeldungen erforderlich werden.

Spätestens einen Monat nach der 72-Stunden-Meldung folgt grundsätzlich die Abschlussmeldung beziehungsweise bei einem noch laufenden Vorfall zunächst eine Fortschrittsmeldung.

Das funktioniert nur, wenn Incident Response und regulatorisches Meldewesen bereits vor einem Angriff miteinander verbunden wurden.

Zuständigkeiten müssen feststehen.

Der Meldeweg muss funktionieren.

Stellvertreter müssen vorhanden sein.

Technische Informationen müssen schnell verfügbar sein.

Und der gesamte Vorfall muss von Beginn an nachvollziehbar dokumentiert werden.

Die entscheidende Erkenntnis lautet:

Eine 24-Stunden-Frist beginnt nicht erst dann, wenn alle Antworten vorliegen.

Gerade deshalb muss eine Organisation vorbereitet sein, auch mit einem zunächst unvollständigen Lagebild strukturiert und belastbar zu melden.

Der ideale Prozess lautet:

Erkennen → Bewerten → Dokumentieren → Melden → Aktualisieren → Untersuchen → Abschließen → Lernen

Damit wird die NIS-2-Meldung nicht zu einem hektisch zusammengestellten Formular während einer ohnehin laufenden Cyberkrise, sondern zu einem vorbereiteten Bestandteil des Incident-Response-Prozesses.