NIS2-Meldefrist 24 Stunden – Wie ein SOC die Einhaltung sicherstellt

Freitagabend, 22:00 Uhr. Das IT-Team ist im Wochenende, die Büros sind leer. Auf einem File-Server beginnt eine Ransomware, Dateien zu verschlüsseln. Wer bemerkt den Vorfall? Wer bewertet, ob er meldepflichtig ist? Wer setzt die Erstmeldung an das BSI auf – und in welcher Form?

Seit dem 06.12.2025 ist die NIS2-Richtlinie über das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) im BSIG verankert. Sie verpflichtet betroffene Unternehmen, erhebliche Sicherheitsvorfälle innerhalb von 24 Stunden an das Bundesamt für Sicherheit in der Informationstechnik (BSI) zu melden. 24 Stunden klingen nach ausreichend Zeit – bis man sich vergegenwärtigt, was in diesem Zeitfenster alles geschehen muss: Erkennung, Bewertung, Klassifizierung, Eskalation, Dokumentation und formale Meldung.

Dieser Artikel zeigt, warum die 24-Stunden-Frist ohne vorbereitete Strukturen kaum einzuhalten ist – und wie ein Security Operations Center (SOC) den gesamten Meldeprozess operativ absichert.

Die NIS2-Meldefristen im Detail: Das 24-72-30-Modell

Die NIS2-Richtlinie sieht ein dreistufiges Meldemodell vor, das Unternehmen bei einem erheblichen Sicherheitsvorfall einhalten müssen.

Erstmeldung innerhalb von 24 Stunden

Die erste Meldung muss innerhalb von 24 Stunden nach Kenntniserlangung beim BSI eingehen. Sie enthält eine vorläufige Bewertung des Vorfalls: Art und Schwere der Störung, eine erste Einschätzung, ob der Vorfall durch eine böswillige Handlung verursacht wurde, sowie Angaben zu möglichen grenzüberschreitenden Auswirkungen. Auch die bereits ergriffenen Sofortmaßnahmen gehören in die Erstmeldung.

Folgemeldung innerhalb von 72 Stunden

Spätestens 72 Stunden nach der Erstmeldung ist eine ausführlichere Folgemeldung erforderlich. Sie umfasst eine detaillierte Ursachenanalyse, bekannte Indicators of Compromise (IOCs), Informationen zur Abstimmung mit Strafverfolgungsbehörden und eine Beschreibung der eingeleiteten Mitigationsmaßnahmen.

Abschlussbericht innerhalb eines Monats

Ein Monat nach dem Vorfall muss ein Abschlussbericht vorliegen. Dieser enthält eine vollständige Vorfallsbeschreibung, die Bewertung des Schweregrads, die ermittelte Grundursache sowie eine Dokumentation aller abgeschlossenen Behebungsmaßnahmen.

Meldewege und Verantwortlichkeiten

Die Meldung erfolgt über das Melde- und Informationsportal (MIP) des BSI. Dabei gilt ein wichtiges Prinzip: Schnelligkeit vor Vollständigkeit. Das BSI empfiehlt ausdrücklich, lieber frühzeitig mit unvollständigen Informationen zu melden als die Frist zu riskieren. Ergänzungen können in der Folgemeldung nachgereicht werden.

Dritte – etwa ein Managed SOC-Dienstleister – dürfen die Meldung im Auftrag des Unternehmens absetzen. Die Verantwortung für die fristgerechte Meldung bleibt jedoch beim betroffenen Unternehmen selbst.

Was ist ein "erheblicher Sicherheitsvorfall"?

Nicht jeder IT-Sicherheitsvorfall löst die Meldepflicht aus. Das NIS2UmsuCG definiert in §32 drei Kriterien, von denen mindestens eines erfüllt sein muss:

1. Schwerwiegende Betriebsstörung: Der Vorfall beeinträchtigt den Geschäftsbetrieb erheblich. Ein Beispiel: Ransomware legt die Produktion für 48 Stunden lahm.

2. Erhebliche finanzielle Verluste: Der Vorfall verursacht signifikante finanzielle Schäden. Ein Beispiel: Ein CEO-Fraud führt zu einer Überweisung von 500.000 Euro an ein betrügerisches Konto.

3. Schäden an Dritten: Andere natürliche oder juristische Personen werden geschädigt. Ein Beispiel: Ein Datenleak legt 50.000 Kundendatensätze offen.

Entscheidend ist dabei: Die Meldepflicht greift nicht erst, wenn der Schaden eingetreten ist. Es reicht aus, dass der Vorfall einen solchen Schaden verursachen kann. Potenzialschaden ist ausreichend.

Grenzfälle in der Praxis

Die Einordnung ist nicht immer eindeutig. Ein DDoS-Angriff, der den Webshop für zwei Stunden unerreichbar macht, wird in den meisten Fällen nicht als erheblicher Vorfall eingestuft. Ransomware auf Produktionssystemen hingegen ist fast immer meldepflichtig – unabhängig davon, ob die Verschlüsselung erfolgreich war oder frühzeitig gestoppt werden konnte.

Die BSI-Empfehlung für Grenzfälle ist eindeutig: Im Zweifelsfall melden.

Kenntniserlangung – der Moment, in dem die Uhr startet

Die 24-Stunden-Frist beginnt nicht mit dem Zeitpunkt des Angriffs, sondern mit dem Zeitpunkt der Kenntniserlangung – also dem Moment, in dem ein Mitarbeiter des Unternehmens den Vorfall erkennt oder davon erfährt.

Diese Unterscheidung hat erhebliche praktische Auswirkungen:

Ohne SOC erfolgt die Erkennung häufig erst Stunden oder Tage nach dem eigentlichen Eindringen. Ein Angreifer, der sich am Freitagabend Zugang verschafft, wird möglicherweise erst am Montagmorgen bemerkt – wenn die Verschlüsselung bereits abgeschlossen ist. Die 24-Stunden-Frist beginnt dann zwar erst am Montag, doch der Schaden ist bereits maximiert und die verbleibende Zeit für eine fundierte Erstmeldung knapp.

Mit internem IT-Team startet die Uhr formal erst innerhalb der Arbeitszeiten. An Wochenenden, Feiertagen und nachts erlangt niemand Kenntnis. Das schützt zwar vor Fristversäumnissen, löst aber das eigentliche Problem nicht: Der Vorfall bleibt unerkannt, der Schaden wächst.

Mit einem SOC – ob intern oder als Managed Service – erfolgt die Erkennung rund um die Uhr. Die Kenntniserlangung findet unmittelbar statt. Das bedeutet: Der Vorfall wird schneller eingedämmt, und das Unternehmen hat das volle 24-Stunden-Fenster für eine strukturierte Erstmeldung zur Verfügung. Mehr zu den grundsätzlichen Vorteilen eines SOC für die NIS2-Compliance finden Sie in unserem Artikel zu SOC und NIS2.

Warum 24 Stunden ohne SOC kaum einzuhalten sind

Unternehmen, die keinen strukturierten Sicherheitsbetrieb haben, stoßen bei der Einhaltung der 24-Stunden-Meldefrist auf fünf typische Hürden:

1. Keine 24/7-Erkennung. Die interne IT arbeitet in der Regel von 8 bis 17 Uhr. Cyberangriffe finden bevorzugt außerhalb dieser Zeiten statt – nachts, am Wochenende, an Feiertagen. Ohne kontinuierliches Monitoring bleibt der Vorfall bis zum nächsten Arbeitstag unentdeckt.

2. Fehlende Klassifizierungs-Kompetenz. Ist der Vorfall "erheblich" im Sinne des NIS2UmsuCG? Ohne Erfahrung in der Vorfallsbewertung und ohne klare Kriterien fällt diese Einschätzung schwer. Unsicherheit führt entweder zu verspäteten Meldungen oder zu unnötigen Meldungen bei geringfügigen Vorfällen.

3. Kein definierter Meldeprozess. Wer setzt die Meldung auf? Welche Informationen werden benötigt? Wer hat Zugang zum BSI-Portal? Ohne vorbereitete Abläufe geht wertvolle Zeit durch Ad-hoc-Abstimmung verloren.

4. Paralleler Incident Response. Ein kleines IT-Team muss den Vorfall gleichzeitig eindämmen und die formale Meldung vorbereiten. In der Praxis wird die Eindämmung priorisiert – die Meldung gerät in den Hintergrund.

5. Dokumentationslücken. Ohne zentralisiertes Logging und Monitoring fehlen die Daten, die für eine fundierte Erstmeldung erforderlich sind: Welche Systeme sind betroffen? Seit wann? Welche Nutzer? Welche Indikatoren deuten auf die Angriffsart hin?

Wie ein SOC die 24h-Meldefrist sicherstellt

Ein SOC adressiert jede dieser Hürden durch etablierte Prozesse, spezialisiertes Personal und technische Infrastruktur. Der operative Ablauf lässt sich in sieben Phasen gliedern.

Echtzeit-Erkennung durch SIEM und 24/7-Monitoring

Ein SOC aggregiert kontinuierlich Log-Daten aus allen relevanten Systemen: Firewalls, Endpunkte, Server, Cloud-Dienste, Identitätssysteme. Korrelationsregeln im SIEM (Security Information and Event Management) erkennen Anomalien in Echtzeit – etwa ungewöhnliche Verschlüsselungsaktivitäten, laterale Bewegungen im Netzwerk oder massenhafte fehlgeschlagene Anmeldeversuche.

Bei Verdacht auf einen erheblichen Vorfall wird automatisch ein Alert ausgelöst. Da die Überwachung rund um die Uhr stattfindet, wird das Zeitfenster zwischen Angriffsbeginn und Erkennung auf ein Minimum reduziert – und die verfügbare Zeit für die Meldung maximiert.

Automatische Anreicherung von Vorfallsdaten

Bei jedem Alert werden relevante Kontextinformationen automatisch angereichert, bevor ein Analyst den Vorfall überhaupt sichtet:

• IP-Adressen werden mit Geolokation, Reputationsdaten und Threat-Intelligence-Feeds abgeglichen.
• File-Hashes werden gegen Malware-Datenbanken und bekannte Indicators of Compromise geprüft.
• Nutzer-IDs werden automatisch einer Abteilung, Rolle und dem letzten Login-Zeitpunkt zugeordnet.
• Nutzer-Berechtigungen werden aufgeschlüsselt: aktuelle Zugriffsrechte, privilegierte Accounts, kürzliche Rechteänderungen.

Der Effekt für die Meldefrist: Analysten müssen Informationen nicht manuell aus verschiedenen Systemen zusammensuchen. Die Erstbewertung erfolgt in Minuten statt in Stunden. Der Effekt für die Meldequalität: Die BSI-Erstmeldung enthält von Anfang an belastbare Daten zu betroffenen Systemen, beteiligten Nutzerkonten und technischen Indikatoren.

Automatisierte Vorfallsklassifizierung

Eine im SIEM hinterlegte Severity-Matrix ordnet jeden Vorfall automatisch einem Schweregrad zu. NIS2-spezifische Bewertungskriterien – Betriebsstörung, finanzielle Auswirkung, Drittschäden – sind als Regeln implementiert.

SOC-Analysten validieren die automatische Einschätzung, unterstützt durch die bereits angereicherten Kontextdaten. Das Ergebnis: Innerhalb weniger Minuten steht fest, ob eine Meldepflicht vorliegt.

Incident Response Playbooks mit integrierten Melde-Workflows

Für jeden Vorfallstyp – Ransomware, Data Breach, DDoS, Advanced Persistent Threat – existiert ein dokumentiertes Playbook. Der Meldeprozess ist fester Bestandteil jedes Playbooks, nicht ein separater Arbeitsschritt, der vergessen werden kann.

Diese Playbooks enthalten vorausgefüllte Meldeformulare und Textbausteine für das BSI-Portal. Checklisten stellen sicher, dass alle Pflichtangaben der Erstmeldung berücksichtigt werden: Art des Vorfalls, betroffene Systeme, Verdacht auf böswillige Handlung, grenzüberschreitende Auswirkungen, ergriffene Sofortmaßnahmen.

Eskalationsmatrix und Kommunikationskette

Ein SOC arbeitet mit einer definierten Eskalationsmatrix: Wer wird wann informiert, über welchen Kanal, mit welcher Reaktionszeit? Ein typischer Ablauf:

• SOC erkennt Vorfall → 30 Minuten Analyse und Anreicherung
• Eskalation an CISO → innerhalb von 1 Stunde nach Erkennung
• Erstmeldung vorbereitet → innerhalb von 2 Stunden nach Erkennung

Die Erreichbarkeit aller Beteiligten ist auch außerhalb der Geschäftszeiten sichergestellt. Stellvertreterregelungen sind dokumentiert und getestet. Es gibt keinen Moment, in dem die Eskalation an einer nicht erreichbaren Person scheitert.

Parallele Arbeit: Eindämmen und Melden gleichzeitig

Bei einem erheblichen Vorfall teilt sich das SOC-Team: Das Incident Response Team konzentriert sich auf die Eindämmung – Systeme isolieren, kompromittierte Accounts sperren, forensische Sicherung einleiten. Parallel bereitet das Reporting Team die BSI-Meldung vor.

Diese Arbeitsteilung stellt sicher, dass die Meldung nicht durch laufende technische Maßnahmen verzögert wird. Das BSI-Prinzip "Schnelligkeit vor Vollständigkeit" wird so operativ umgesetzt: Die Erstmeldung geht raus, während die Eindämmung parallel weiterläuft.

Unterstützung bei Folgemeldung und Abschlussbericht

Ab der ersten Minute des Vorfalls dokumentiert das SOC lückenlos: Timeline der Ereignisse, ergriffene Maßnahmen, identifizierte IOCs, betroffene Systeme und Nutzer. Diese Dokumentation bildet die Grundlage für die 72-Stunden-Folgemeldung mit detaillierter Ursachenanalyse sowie für den Abschlussbericht nach einem Monat, der die Grundursache, alle Behebungsmaßnahmen und Lessons Learned enthält.

Praxisbeispiel: SOC-gestützter Meldeprozess bei einem Ransomware-Vorfall

Der folgende Ablauf zeigt, wie ein SOC die 24-Stunden-Meldefrist bei einem Ransomware-Vorfall operativ einhält:

• 22:07 – Das SIEM erkennt ungewöhnliche Verschlüsselungsaktivität auf einem File-Server und löst einen Alert aus.
• 22:08 – Automatische Anreicherung: Betroffene IP-Adressen, die zugehörige Nutzer-ID, das Berechtigungslevel des Nutzers und die File-Hashes der ausgeführten Prozesse werden gegen Threat-Intelligence-Feeds abgeglichen.
• 22:12 – Ein SOC-Analyst bestätigt anhand der angereicherten Kontextdaten: Ransomware auf dem File-Server, der betroffene Nutzer verfügt über Administratorrechte.
• 22:15 – Sofortmaßnahme: Das betroffene Netzwerksegment wird isoliert, der kompromittierte Account gesperrt.
• 22:20 – Klassifizierung: Erheblicher Sicherheitsvorfall (Betriebsstörung und Datengefährdung). Meldepflicht liegt vor.
• 22:25 – Eskalation an den CISO per Telefon.
• 22:40 – Erstmeldung im BSI-Portal vorbereitet, alle Pflichtangaben ausgefüllt.
• 23:00 – Erstmeldung abgesetzt – weniger als eine Stunde nach Erkennung.
• 23:00–06:00 – Parallele Eindämmung und forensische Sicherung durch das Incident Response Team.
• Nächster Tag, 10:00 – Status-Update an die Geschäftsführung mit aktuellem Lagebild.
• Tag 3 – Folgemeldung an das BSI mit IOCs und detaillierter Ursachenanalyse.
• Tag 28 – Abschlussbericht mit vollständiger Vorfallsdokumentation und Lessons Learned.

Von der Erkennung bis zur Erstmeldung vergingen 53 Minuten. Ohne SOC wäre der Vorfall frühestens am Montagmorgen bemerkt worden – mit entsprechend weniger Zeit für eine strukturierte Reaktion.

Checkliste: Ist Ihr Unternehmen auf die 24h-Meldefrist vorbereitet?

Die folgenden zehn Punkte helfen bei der Einschätzung, ob Ihr Unternehmen die NIS2-Meldefrist operativ einhalten kann:

• 24/7-Monitoring der IT-Infrastruktur ist aktiv.
• Ein SIEM mit aktuellen Korrelationsregeln ist im Einsatz.
• Incident Response Playbooks mit integrierten Melde-Workflows sind dokumentiert.
• Eine Eskalationsmatrix mit Erreichbarkeiten aller Beteiligten ist definiert.
• Der Meldeweg zum BSI ist eingerichtet (Portal-Zugang, Ansprechpartner).
• Meldeformular-Templates für die Erstmeldung sind vorbereitet.
• Verantwortlichkeiten für die Meldung und Stellvertreterregelungen sind festgelegt.
• Regelmäßige Übungen und Simulationen des Meldeprozesses finden statt.
• Falls ein Managed SOC eingesetzt wird: Der Dienstleister ist autorisiert und in den Meldeprozess eingebunden.
• Die Dokumentation der Vorfallsbehandlung erfolgt automatisiert ab der ersten Minute.

Jeder Punkt, der nicht mit "Ja" beantwortet werden kann, stellt ein Risiko für die fristgerechte Meldung dar.

Fazit: Die 24h-Meldefrist ist machbar – mit den richtigen Strukturen

Die 24-Stunden-Meldefrist der NIS2-Richtlinie ist anspruchsvoll, aber umsetzbar. Voraussetzung ist, dass Unternehmen die notwendigen Prozesse, Verantwortlichkeiten und technischen Kapazitäten im Vorfeld etablieren – nicht erst beim ersten meldepflichtigen Vorfall.

Ein Security Operations Center – ob intern aufgebaut oder als Managed Service bezogen – ist dabei der operative Schlüssel. Es stellt die 24/7-Erkennung sicher, liefert die Datengrundlage für fundierte Erstmeldungen und ermöglicht die parallele Bearbeitung von Eindämmung und Meldung.

Besonders für kleine und mittelständische Unternehmen bietet ein Managed SOC den Vorteil, spezialisierte Expertise und durchgehende Überwachung zu erhalten, ohne eigenes Fachpersonal rund um die Uhr vorhalten zu müssen. Die Investition in vorbereitete Meldeprozesse zahlt sich nicht erst im Ernstfall aus – sie reduziert auch das Haftungsrisiko der Geschäftsleitung, die nach NIS2 persönlich für die Einhaltung der Meldepflichten verantwortlich ist.

Gerne beraten wir Sie zur operativen Umsetzung der NIS2-Meldepflichten und zur Einbindung eines Managed SOC in Ihren Meldeprozess.