NIS2-Meldefristen im Überblick: 24h, 72h, 1 Monat – was wann fällig ist

Freitagabend, 18:47 Uhr. Dein Admin bemerkt ungewöhnlichen Datenverkehr auf dem Backup-Server. Am Samstagmorgen bestätigt sich der Verdacht: Ransomware hat Teile eurer Infrastruktur verschlüsselt. Ab genau diesem Moment läuft die Uhr. 24 Stunden hast du Zeit für die erste Meldung ans BSI. Und das ist erst der Anfang.

Die NIS2-Richtlinie bringt ein dreistufiges Meldesystem mit, das deutlich strenger ist als alles, was deutsche Unternehmen bisher aus dem IT-Sicherheitsgesetz oder der DSGVO kennen. Wer die Fristen reißt, riskiert empfindliche Bußgelder. Wer sie kennt und vorbereitet ist, behält auch im Ernstfall die Kontrolle.

Für wen gelten die NIS2-Meldefristen?

Bevor wir in die Fristen einsteigen: Die Meldepflichten betreffen nicht jedes Unternehmen. NIS2 unterscheidet zwischen wesentlichen Einrichtungen (essential entities) und wichtigen Einrichtungen (important entities). Betroffen bist du, wenn dein Unternehmen in einem der 18 definierten Sektoren tätig ist und bestimmte Schwellenwerte bei Mitarbeiterzahl oder Umsatz überschreitet — die Details dazu findest du in der NIS2-Übersicht für den Mittelstand.

Für ein Unternehmen mit rund 100 Mitarbeitern in einem Sektor wie IT-Dienstleistungen, Fertigung oder Energieversorgung ist die Wahrscheinlichkeit hoch, als wichtige Einrichtung eingestuft zu werden. Die Meldefristen gelten für beide Kategorien identisch. Der Unterschied liegt bei den Bußgeldhöhen und der behördlichen Aufsichtsintensität.

Die drei Meldestufen im Detail

NIS2 verlangt bei einem erheblichen Sicherheitsvorfall drei aufeinander aufbauende Meldungen. Jede hat ihren eigenen Zweck, ihren eigenen Detailgrad und ihre eigene Frist.

Stufe 1: Erstmeldung (Frühwarnung) innerhalb von 24 Stunden

Die Erstmeldung ist bewusst niedrigschwellig gehalten. Du brauchst noch keine vollständige Analyse, keine Root-Cause-Ermittlung und keine abschließende Bewertung. Das BSI will in dieser Phase vor allem wissen, dass etwas passiert ist.

Was gemeldet werden muss:

• Dass ein erheblicher Sicherheitsvorfall vorliegt (oder der begründete Verdacht besteht)
• Ob der Vorfall vermutlich auf rechtswidrige oder böswillige Handlungen zurückgeht
• Ob eine grenzüberschreitende Auswirkung wahrscheinlich ist

Was du zu diesem Zeitpunkt nicht wissen musst:

• Den genauen Angriffsvektor
• Das vollständige Ausmaß des Schadens
• Die Identität der Angreifer

Die 24-Stunden-Frist klingt knapp, und das ist sie auch. Aber die Erstmeldung ist absichtlich als Frühwarnung konzipiert. Du meldest den Vorfall, damit das BSI frühzeitig andere potenziell betroffene Einrichtungen warnen kann. Denk daran wie an einen Feueralarm: Er muss schnell kommen, nicht detailliert.

Stufe 2: Bewertende Zwischenmeldung innerhalb von 72 Stunden

Nach drei Tagen erwartet das BSI eine deutlich substanziellere Meldung. Jetzt geht es um die erste fachliche Einschätzung des Vorfalls.

Was gemeldet werden muss:

• Aktualisierte Informationen aus der Erstmeldung
• Eine erste Bewertung des Vorfalls inklusive Schweregrad und Auswirkungen
• Die bekannten oder vermuteten Kompromittierungsindikatoren (Indicators of Compromise, IoCs)
• Art der Bedrohung oder Ursache, soweit bereits erkennbar

Die 72-Stunden-Meldung ist das Herzstück des NIS2-Meldeprozesses. Hier zeigt sich, ob dein Incident-Response-Prozess funktioniert. Du brauchst zu diesem Zeitpunkt belastbare technische Daten: Welche Systeme sind betroffen? Welche Daten könnten abgeflossen sein? Welche Gegenmaßnahmen laufen bereits?

Für ein Unternehmen mit 100 Mitarbeitern bedeutet das konkret: Dein IT-Team oder dein externer Dienstleister muss innerhalb von drei Tagen eine forensische Erstanalyse liefern können. Wer erst im Ernstfall nach einem Incident-Response-Partner sucht, wird diese Frist kaum halten.

Stufe 3: Abschlussbericht innerhalb von einem Monat

Der Abschlussbericht ist die umfassende Aufarbeitung des Vorfalls. Hier wird detailliert dokumentiert, was passiert ist, warum es passiert ist und was das Unternehmen daraus gelernt hat.

Was gemeldet werden muss:

• Detaillierte Beschreibung des Vorfalls inkl. Schweregrad und Auswirkungen
• Art der Bedrohung oder Ursache (Root Cause)
• Ergriffene und laufende Abhilfemaßnahmen
• Gegebenenfalls grenzüberschreitende Auswirkungen

Falls die Untersuchung nach einem Monat noch läuft, reichst du statt des Abschlussberichts einen Fortschrittsbericht ein. Der finale Bericht folgt dann innerhalb eines Monats nach Abschluss der Vorfallsbehandlung.

Ab wann tickt die Uhr?

Einer der wichtigsten und gleichzeitig am häufigsten missverstandenen Punkte: Die Fristen beginnen ab Kenntnisnahme des erheblichen Sicherheitsvorfalls. Nicht ab dem Zeitpunkt, an dem der Angriff stattfand. Nicht ab dem Zeitpunkt, an dem der Vorstand informiert wurde. Sondern ab dem Moment, in dem das Unternehmen als Organisation Kenntnis erlangt.

Was bedeutet Kenntnisnahme konkret? Wenn dein Monitoring-System um 03:00 Uhr nachts einen Alarm auslöst und dein Security-Analyst diesen um 08:00 Uhr morgens sichtet und als erheblichen Vorfall einstuft, beginnt die Frist um 08:00 Uhr. Wenn aber der Alarm automatisch per E-Mail an den zuständigen Mitarbeiter ging und dieser die Mail erst am nächsten Tag liest, lässt sich argumentieren, dass die Kenntnis bereits mit dem Zugang der Information bestand.

Genau deshalb ist eine saubere Dokumentation der Ereigniskette so wichtig. Im Zweifelsfall musst du nachweisen können, wann du was wusstest. Ein lückenloses Incident-Log ist nicht optional, sondern deine Absicherung.

Was gilt als „erheblicher Sicherheitsvorfall"?

Nicht jeder IT-Vorfall löst die Meldepflicht aus. NIS2 definiert einen Sicherheitsvorfall als erheblich, wenn er:

• schwerwiegende Betriebsstörungen der Dienste verursacht hat oder verursachen kann,
• finanzielle Verluste für die betroffene Einrichtung nach sich zieht, oder
• andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden betrifft.

Für die Praxis heißt das: Ein fehlgeschlagener Phishing-Versuch ist kein meldepflichtiger Vorfall. Eine erfolgreiche Ransomware-Attacke, die eure Produktionssteuerung lahmlegt, definitiv schon. Zwischen diesen Extremen liegt eine Grauzone, die du im Vorfeld durch klare Bewertungskriterien in deinem Incident Response Plan adressieren solltest.

NIS2 vs. DSGVO: Wo liegen die Unterschiede?

Viele Unternehmen kennen bereits die Meldepflicht aus der DSGVO. Dort müssen Datenschutzverletzungen innerhalb von 72 Stunden an die zuständige Datenschutzbehörde gemeldet werden. Die NIS2-Meldefristen unterscheiden sich in mehreren wesentlichen Punkten:

Ein kritischer Punkt: Bei einem Ransomware-Angriff, der auch personenbezogene Daten betrifft, greifen beide Meldepflichten parallel. Du meldest an die Datenschutzbehörde nach DSGVO — siehe DSGVO-Datenpanne melden — und ans BSI nach NIS2. Die Fristen laufen unabhängig voneinander. Das macht die organisatorische Vorbereitung umso wichtiger, denn im Ernstfall zwei parallele Meldeprozesse gleichzeitig zu managen, erfordert klare Zuständigkeiten und vorbereitete Vorlagen.

Konsequenzen bei Fristversäumnis

Die NIS2-Richtlinie setzt auf abschreckende Sanktionen. Die Bußgeldrahmen orientieren sich bewusst am Modell der DSGVO und sollen sicherstellen, dass Unternehmen die Meldepflichten ernst nehmen.

Für wesentliche Einrichtungen:

• Bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes (je nachdem, welcher Betrag höher ist)

Für wichtige Einrichtungen:

• Bis zu 7 Mio. Euro oder 1,4 % des weltweiten Jahresumsatzes

Diese Beträge sind Obergrenzen. Die tatsächliche Höhe richtet sich nach der Schwere des Verstoßes, ob der Vorfall vorsätzlich oder fahrlässig war und welche Maßnahmen das Unternehmen zur Schadensbegrenzung ergriffen hat. Ein Unternehmen, das einen dokumentierten Incident-Response-Prozess hat, aber eine Frist um wenige Stunden reißt, wird anders behandelt als eines, das überhaupt keine Meldestruktur vorweisen kann.

Neben den Bußgeldern drohen weitere Konsequenzen:

• Persönliche Haftung der Geschäftsführung bei grober Fahrlässigkeit
• Öffentliche Bekanntmachung des Verstoßes durch die Aufsichtsbehörde
• Anordnungen zur Umsetzung konkreter Maßnahmen mit Fristsetzung
• Bei wesentlichen Einrichtungen: temporäre Aussetzung von Zertifizierungen oder Genehmigungen

Beispiel-Timeline: Ransomware-Angriff bei einem mittelständischen IT-Dienstleister

Lass uns die Meldefristen anhand eines konkreten Szenarios durchspielen. Die TechServ GmbH hat 95 Mitarbeiter, betreibt Managed-IT-Services für rund 40 Kunden und fällt als wichtige Einrichtung unter NIS2.

Tag 0, Freitag 18:47 Uhr

Das SIEM-System schlägt Alarm: Ungewöhnliche Verschlüsselungsaktivitäten auf dem Backup-Server. Der diensthabende Admin prüft den Alarm und eskaliert an die IT-Leitung.

Tag 0, Freitag 21:30 Uhr

Die IT-Leitung bestätigt nach erster Analyse: Ransomware hat den Backup-Server und zwei Fileserver verschlüsselt. Kundendaten sind potenziell betroffen. Ab jetzt laufen die Meldefristen.

Tag 1, Samstag 21:30 Uhr (24h-Frist)

Die TechServ GmbH reicht die Erstmeldung beim BSI ein:

• Ransomware-Befall bestätigt
• Vermutlich böswillige Handlung (externer Angriff)
• Grenzüberschreitende Auswirkung möglich (Kunden in Österreich)
• Erste Eindämmungsmaßnahmen eingeleitet (betroffene Systeme isoliert)

Tag 3, Montag 21:30 Uhr (72h-Frist)

Der externe Incident-Response-Dienstleister hat eine erste forensische Analyse abgeschlossen. Die Zwischenmeldung enthält:

• Angriffsvektor: kompromittiertes VPN-Konto eines Mitarbeiters (gestohlene Zugangsdaten aus einem früheren Datenleck)
• Betroffene Systeme: 3 Server, ca. 2 TB Daten verschlüsselt
• Schweregrad: hoch (Kundendaten betroffen, Dienstleistung eingeschränkt)
• IoCs: konkrete IP-Adressen, Ransomware-Variante identifiziert
• Gegenmaßnahmen: VPN-Reset, MFA-Rollout beschleunigt, saubere Backups identifiziert

Tag 30, drei Wochen nach Abschluss der Wiederherstellung

Der Abschlussbericht dokumentiert:

• Vollständige Angriffskette vom initialen Zugang bis zur Verschlüsselung
• Root Cause: fehlendes MFA auf dem VPN-Zugang, Passwort-Wiederverwendung durch einen Mitarbeiter
• Timeline der Wiederherstellung (7 Tage bis zum Normalbetrieb)
• Umgesetzte Maßnahmen: MFA für alle Remote-Zugänge, Passwort-Richtlinie verschärft, Network-Segmentierung überarbeitet, Offline-Backups eingeführt
• Schulungsmaßnahmen für Mitarbeiter

Parallel dazu hat die TechServ GmbH wegen der betroffenen Kundendaten (personenbezogene Daten darunter) innerhalb von 72 Stunden eine separate DSGVO-Meldung an die zuständige Landesdatenschutzbehörde eingereicht und die betroffenen Kunden informiert.

Praxistipps: So stellst du die Fristen organisatorisch sicher

Die Theorie ist das eine. Aber wie setzt du die Meldepflichten in einem Unternehmen mit 100 Mitarbeitern praktisch um, ohne einen eigenen Compliance-Stab zu betreiben?

1. Incident-Response-Plan mit Meldefristen verknüpfen

Dein Incident-Response-Plan sollte die Meldefristen als feste Meilensteine enthalten. Nicht als separate Checkliste, sondern direkt im Ablauf integriert. Wenn dein Plan den Schritt „Vorfall klassifizieren" enthält, muss unmittelbar danach „Meldepflicht prüfen und 24h-Frist starten" folgen.

2. Vorlagen vorbereiten

Im Ernstfall fehlt die Zeit, eine Meldung von Grund auf zu formulieren. Bereite für jede der drei Meldestufen eine Vorlage vor, die nur noch mit den fallspezifischen Details befüllt werden muss. Das BSI wird voraussichtlich standardisierte Meldeformulare bereitstellen. Bis dahin orientierst du dich an den Mindestanforderungen der NIS2-Richtlinie.

Eine gute Erstmeldungs-Vorlage enthält:

• Unternehmensdaten (vorausgefüllt)
• Kontaktperson für Rückfragen
• Zeitpunkt der Kenntnisnahme
• Kurzbeschreibung des Vorfalls (Freitext, 3-5 Sätze)
• Checkboxen: böswillige Handlung ja/nein, grenzüberschreitend ja/nein
• Eingeleitete Sofortmaßnahmen

3. Klare Rollen und Erreichbarkeit definieren

Wer meldet? Wer entscheidet, ob gemeldet werden muss? Wer liefert die technischen Informationen? Diese Fragen darfst du nicht erst im Ernstfall klären. Definiere mindestens drei Rollen:

• Incident Manager: Koordiniert die Vorfallsbehandlung und steuert den Meldeprozess
• Technischer Analyst: Liefert die forensischen Erkenntnisse für die Meldungen
• Meldeverantwortlicher: Erstellt die Meldungen und kommuniziert mit dem BSI

In einem 100-Personen-Unternehmen fallen diese Rollen oft auf zwei oder drei Personen zusammen. Das ist in Ordnung, solange die Zuständigkeiten klar dokumentiert sind und Vertreter benannt wurden. Denn Vorfälle halten sich nicht an Bürozeiten.

4. Erreichbarkeit außerhalb der Geschäftszeiten sicherstellen

Die 24-Stunden-Frist kennt kein Wochenende. Wenn dein Monitoring am Samstagabend einen Vorfall meldet, muss jemand handlungsfähig sein. Das heißt nicht, dass du eine 24/7-Bereitschaft aufbauen musst. Aber du brauchst eine Eskalationskette mit hinterlegten Mobilnummern und eine klare Regel, wer im Zweifel entscheidet.

5. Übungen durchführen

Einmal pro Jahr solltest du eine Meldeübung durchspielen. Nicht als theoretische Tischübung, sondern möglichst realistisch: Szenario auswürfeln, Erstmeldung unter Zeitdruck ausfüllen, Zwischenmeldung mit fiktiven forensischen Daten erstellen. So erkennst du Lücken in deinem Prozess, bevor der Ernstfall sie aufdeckt.

6. Externe Partner vorab einbinden

Falls du einen externen Incident-Response-Dienstleister nutzt (oder nutzen willst), kläre die vertraglichen Rahmenbedingungen im Voraus. Vereinbare Reaktionszeiten, die zu deinen Meldefristen passen. Wenn dein Dienstleister 48 Stunden braucht, um mit der forensischen Analyse zu beginnen, wirst du die 72-Stunden-Meldung nicht mit belastbaren Daten füllen können.

7. Dokumentation vom ersten Moment an

Führe ab dem ersten Verdachtsmoment ein Incident-Log. Jede Erkenntnis, jede Maßnahme, jede Entscheidung wird mit Zeitstempel dokumentiert. In ISMS Lite laufen die drei Countdown-Timer für 24h, 72h und 30 Tage automatisch mit, sobald du einen Vorfall als potenziell erheblich markierst. Dieses Log ist die Grundlage für alle drei Meldungen und den Nachweis, dass du die Fristen eingehalten hast. Im Ernstfall vergisst man schneller Details, als man denkt.

Was bedeutet das für dein ISMS?

Die NIS2-Meldefristen sind nicht isoliert zu betrachten. Sie sind ein Baustein in einem größeren System. Wenn dein Unternehmen bereits ein ISMS nach ISO 27001 betreibt, hast du mit dem Incident-Management-Prozess (A.5.24-A.5.28) eine gute Grundlage. Du musst diesen Prozess allerdings um die spezifischen NIS2-Anforderungen ergänzen: die dreistufige Meldepflicht, die konkreten Fristen und die Kommunikation mit dem BSI.

Falls du noch kein formalisiertes ISMS hast, sind die Meldefristen ein starkes Argument, eines aufzubauen. Denn ohne strukturiertes Incident Management wirst du im Ernstfall improvisieren müssen. Und Improvisation und 24-Stunden-Fristen vertragen sich schlecht.

Die gute Nachricht: Du brauchst kein Enterprise-ISMS mit hunderten Seiten Dokumentation. Ein schlankes, auf deine Unternehmensgröße zugeschnittenes System, das die wesentlichen Prozesse abdeckt, reicht aus. Entscheidend ist, dass der Incident-Response-Prozess gelebt wird und die Meldefristen darin fest verankert sind.

Fazit: Vorbereitung schlägt Geschwindigkeit

Die NIS2-Meldefristen sind anspruchsvoll, aber sie sind machbar. Die 24-Stunden-Erstmeldung verlangt keine perfekte Analyse, sondern eine schnelle Frühwarnung. Die 72-Stunden-Zwischenmeldung setzt voraus, dass du forensisch handlungsfähig bist. Und der Abschlussbericht nach einem Monat gibt dir genug Zeit für eine gründliche Aufarbeitung.

Der eigentliche Schlüssel liegt nicht darin, im Ernstfall besonders schnell zu sein. Er liegt darin, vorher die richtigen Strukturen geschaffen zu haben. Ein vorbereiteter Incident-Response-Prozess, Meldevorlagen in der Schublade, klare Rollen und geübte Abläufe machen den Unterschied zwischen kontrollierter Krisenbewältigung und hektischem Chaos.

Weiterführende Artikel

• NIS2-Erstmeldung ans BSI: Inhalt, Fristen und Vorlage
• Sicherheitsvorfall erkennen, bewerten und melden – der komplette Ablauf
• Incident Response Plan erstellen: Vorlage und Praxisbeispiel
• NIS2-Bußgelder: Wer haftet und wie hoch sind die Strafen?
• NIS2 für den Mittelstand: Was du wissen musst und was jetzt zu tun ist

Fang heute an. Nicht mit dem perfekten Prozess, sondern mit einem funktionierenden. Die erste Meldeübung zeigt dir, wo du stehst. Alles Weitere ist Iteration.