NIS2 24-Stunden-Meldepflicht: Das Engineering-Runbook, das du vor einem Vorfall bauen solltest

Die härteste Deadline in NIS2 ist kein Audit-Termin. Es ist die 24-Stunden-Uhr, die in dem Moment startet, in dem dein Team von einem erheblichen Sicherheitsvorfall Kenntnis erlangt. Die NIS2 Meldepflicht verlangt von wesentlichen und wichtigen Einrichtungen, innerhalb von 24 Stunden nach Kenntnisnahme eine Frühwarnung an das nationale CSIRT oder die zuständige Behörde zu übermitteln, innerhalb von 72 Stunden eine ausführlichere Vorfallsmeldung und innerhalb eines Monats einen Abschlussbericht. Teams, die erst herausfinden wollen, was als "erheblich" gilt, wer die Meldung abschickt und welches Portal zu nutzen ist, während die Produktion brennt, werden das Zeitfenster verpassen. Die Lösung ist unspektakulär: Baue das Runbook jetzt, solange nichts brennt.

Dieser Beitrag beschreibt dieses Runbook in fünf Teilen: Klassifizierung, Erkennung, Meldekette, Berichtsvorlagen und Übungen. Er setzt voraus, dass du bereits weißt, ob du in den Anwendungsbereich fällst. Falls nicht, starte mit unserem Überblick, was NIS2 für mittelgroße SaaS-Teams bedeutet, und komm danach zurück.

Was die NIS2-Meldefristen tatsächlich verlangen

Die Richtlinie definiert eine dreistufige Meldekaskade, und jede Stufe hat eine andere Aufgabe:

Stufe	Frist	Inhalt
Frühwarnung	24 Stunden ab Kenntnisnahme	Ob der Vorfall mutmaßlich auf rechtswidrige oder böswillige Handlungen zurückgeht und ob er grenzüberschreitende Auswirkungen haben könnte
Vorfallsmeldung	72 Stunden ab Kenntnisnahme	Erste Bewertung von Schweregrad und Auswirkungen, plus Kompromittierungsindikatoren, soweit verfügbar
Abschlussbericht	Ein Monat nach der Vorfallsmeldung	Ausführliche Beschreibung, Ursache, ergriffene Gegenmaßnahmen und grenzüberschreitende Auswirkungen

Zwei Details stolpern Engineering-Teams regelmäßig. Erstens: Die Uhr startet bei Kenntnisnahme, nicht bei Bestätigung. Wenn dein On-Call-Engineer am Samstag um 02:00 Uhr starke Hinweise auf einen Einbruch sieht, läuft das 24-Stunden-Fenster bereits. Zweitens: Die Frühwarnung ist bewusst leichtgewichtig. Die Behörden erwarten keine forensische Analyse in 24 Stunden, sondern einen kurzen, strukturierten Hinweis. Teams, die die Frist reißen, reißen sie meistens, weil niemand wusste, wer für den Versand verantwortlich ist, nicht weil die Analyse zu schwer war.

In Deutschland gehen Meldungen über das Online-Meldeportal an das BSI, und das nationale NIS2-Umsetzungsgesetz (NIS2UmsuCG) folgt dieser Kaskade. Andere Mitgliedstaaten benennen ihr eigenes CSIRT oder ihre eigene Behörde. Wenn du also Gesellschaften in mehreren Ländern betreibst, braucht dein Runbook eine Routing-Tabelle pro Land.

Schritt 1: Definiere, was "erheblich" bedeutet, bevor jemand müde und nervös ist

NIS2 verpflichtet dich, erhebliche Vorfälle zu melden: solche, die schwerwiegende Betriebsstörungen oder finanzielle Verluste verursachen oder verursachen können, oder die andere Parteien mit erheblichem materiellen oder immateriellen Schaden treffen. Diese Definition ist zu abstrakt, um sie um 03:00 Uhr anzuwenden. Übersetze sie in konkrete Schwellenwerte für dein Produkt, schriftlich fixiert und vorab freigegeben.

Eine praxistaugliche Klassifizierungsmatrix für ein B2B-SaaS sieht so aus:

• Melden (erheblich): Kundendaten bestätigt oder plausibel exfiltriert; kompletter Plattformausfall länger als deine veröffentlichte RTO; Ransomware oder destruktive Malware auf Produktionssystemen; Kompromittierung eines Signaturschlüssels, Identity Providers oder der CI/CD-Pipeline; ein Vorfall bei einem Zulieferer, der deinen Dienst für einen wesentlichen Teil der Kunden beeinträchtigt.
• Wahrscheinlich melden (an Entscheider eskalieren): Teilausfall eines Kernfeatures über mehrere Stunden; vermuteter, aber unbestätigter unbefugter Zugriff; bestätigt ausnutzbare Schwachstelle mit Hinweisen auf aktives Scanning.
• Nicht melden (intern verfolgen): fehlgeschlagene Angriffsversuche ohne Auswirkung, Fehlkonfiguration bei einem einzelnen Kunden, verschlechterte Performance innerhalb des SLA.

Die Matrix muss eine einzelne entscheidungsbefugte Person (plus Stellvertretung) benennen, die einen Vorfall als erheblich klassifizieren darf. Unklarheit an dieser Stelle ist die häufigste Ursache für gerissene Fristen: Engineers diskutieren sechs Stunden im Channel über den Schweregrad, während die Uhr läuft. Gib einer Person die ausdrückliche Befugnis zu sagen "das ist meldepflichtig", und mache Über-Melden im Zweifel zum Standard. Eine zurückgezogene Meldung ist unangenehm; eine verspätete ist ein Compliance-Befund.

Schritt 2: Sorge dafür, dass die Erkennung einen belastbaren Zeitstempel liefert

Das 24-Stunden-Fenster wird ab Kenntnisnahme gemessen, also definiert dein Monitoring-Stack deine Deadline. Daraus folgen drei Engineering-Anforderungen:

Alerts müssen einen Menschen mit Befugnis erreichen. Ein kritischer Security-Alert, der in einem Dashboard landet, das niemand beobachtet, verzögert die Kenntnisnahme aus Sicht der Behörde nicht; er bedeutet nur, dass ihr Bescheid wusstet und langsam wart. Route sicherheitskritische Alerts (Authentifizierungsanomalien, Spitzen beim Datenabfluss, fehlgeschlagene Integritätsprüfungen, EDR-Detections) an eine On-Call-Rotation mit Paging, nicht an E-Mail.

Logge, was du für den 72-Stunden-Bericht brauchst. Die Vorfallsmeldung erwartet eine erste Bewertung von Schweregrad und Auswirkungen. Das geht nur, wenn Authentifizierungsereignisse, Admin-Aktionen, Datenzugriffe und Deployments zentral geloggt werden, mit einer Aufbewahrung, die lang genug ist, um eine Timeline zu rekonstruieren. Wenn dein Audit-Logging dünn ist, behebe das zuerst; es ist auch das, was Enterprise-Kunden im Procurement prüfen. Unsere Arbeit im Code Quality Consulting beginnt regelmäßig mit genau dieser Lücke, denn ein nicht auditierbares System kann keinen glaubwürdigen Vorfallsbericht liefern.

Halte den Moment der Kenntnisnahme explizit fest. Die erste reagierende Person sollte eine zeitgestempelte "Incident declared"-Nachricht im Incident-Channel posten. Diese eine Nachricht verankert jede folgende Frist und beseitigt jede spätere Diskussion darüber, wann die Uhr gestartet ist.

Schritt 3: Baue die Meldekette als Checkliste, nicht als Stammeswissen

Wenn die Klassifizierung "melden" sagt, muss der Weg zur Behörde mechanisch sein. Der Runbook-Abschnitt zur Meldung sollte wortwörtlich ausgeschrieben enthalten:

1. Wer meldet: benannte Person plus Stellvertretung (typischerweise CISO, CTO oder Geschäftsführung). Beide haben vorab angelegte Accounts im Meldeportal. Eine Portal-Registrierung während eines Vorfalls verschwendet Stunden, die du nicht hast.
2. Wohin: die exakte URL des BSI-Meldeportals (oder des Äquivalents deines Mitgliedstaats), plus Login-Voraussetzungen. Wenn ihr euch als wesentliche oder wichtige Einrichtung registriert habt, gehört die Registrierungsnummer ins Runbook.
3. Was: Die Frühwarnung braucht nur die mutmaßliche Ursache (böswillig oder nicht) und mögliche grenzüberschreitende Auswirkungen. Bereite das als zwei Fragen vor, die der Incident Commander beantwortet, nicht als Aufsatz.
4. Wer noch: Rechtsberatung, Datenschutzbeauftragte (eine Verletzung personenbezogener Daten löst zusätzlich die separate 72-Stunden-DSGVO-Meldung an die Datenschutzbehörde aus), betroffene Enterprise-Kunden gemäß Vertrag und dein Cyber-Versicherer. Liste Namen, Telefonnummern und die Reihenfolge der Anrufe.
5. Eskalation außerhalb der Geschäftszeiten: Der On-Call-Engineer muss die meldende Person um 03:00 Uhr an einem Feiertag erreichen können. Wenn dieser Weg nicht existiert, ist das Runbook Fiktion.

Schritt 4: Schreibe die Berichte vor

Jeden Bericht, den du vor einem Vorfall entwerfen kannst, solltest du vorab entwerfen. Halte drei Vorlagen im Repository direkt neben dem Runbook:

• Frühwarnungs-Vorlage: Name und Registrierungsnummer der Einrichtung, Ansprechperson, Startzeit des Vorfalls, mutmaßlich böswillige Ursache ja/nein/unbekannt, mögliche grenzüberschreitende Auswirkung ja/nein/unbekannt, eine Freitext-Zusammenfassung von einem Absatz.
• Vorlage für die 72-Stunden-Meldung: die Felder der Frühwarnung plus betroffene Dienste, geschätzte Anzahl betroffener Kunden, Schweregradbewertung, Kompromittierungsindikatoren und bisher ergriffene Gegenmaßnahmen.
• Skelett für den Abschlussbericht: Timeline-Tabelle, Ursachenabschnitt, umgesetzte und geplante Gegenmaßnahmen, Bewertung grenzüberschreitender Auswirkungen.

Vorbefüllbare Felder (Unternehmensdaten, Kontakte, Registrierungsnummer) sollten bereits ausgefüllt sein. Im Ernstfall füllt das Team vielleicht zehn Felder aus, statt unter Druck Prosa zu schreiben.

Schritt 5: Übe das Runbook zweimal im Jahr

Ein Runbook, das nie ausgeführt wurde, scheitert an irgendeiner banalen Stelle: ein abgelaufenes Portal-Passwort, eine geänderte Telefonnummer, eine Stellvertretung, die das Unternehmen verlassen hat. Führe zweimal im Jahr eine Tabletop-Übung durch. Wähle ein Szenario (Ransomware auf einem Worker-Node, geleakter API-Token mit bestätigtem Datenzugriff), starte einen Timer und gehe die Kette durch: Erkennung, Deklaration, Klassifizierung, Frühwarnung entworfen, Stakeholder informiert. Miss die Zeit bis zu einer einreichbaren Frühwarnung. Liegt sie in einer ruhigen Übung über vier Stunden, wird sie eine echte Samstagnacht nicht überstehen.

Übungen decken außerdem architektonische Schwächen auf, die kein Dokumenten-Review findet: blinde Flecken im Monitoring, Logs, die zu früh rotieren, Single Points of Failure in der Personenkette. Behandle die Ergebnisse wie Produktions-Bugs mit Verantwortlichen und Fristen. Wenn die Übung zeigt, dass deine Plattform die forensischen Daten für den 72-Stunden-Bericht nicht liefern kann, ist das ein Engineering-Projekt, und zwar eines, das sauber gescopt werden sollte; unsere Custom-Software-Development-Engagements umfassen oft genau diese Art von Observability- und Audit-Trail-Arbeit für regulierte SaaS-Produkte.

Häufig gestellte Fragen

Gilt die 24-Stunden-Frist auch an Wochenenden und Feiertagen? Ja. Die Richtlinie nimmt keine Rücksicht auf Geschäftszeiten. Deshalb ist der On-Call-Weg zur meldenden Person genauso wichtig wie die Vorlage.

Was, wenn wir melden und es sich als Fehlalarm herausstellt? Du kannst aktualisieren oder zurückziehen. Behörden in der ganzen EU haben signalisiert, dass eine in gutem Glauben abgegebene und später herabgestufte Frühwarnung deutlich besser ist als eine verspätete Meldung. Lege deine Schwellenwerte so aus, dass in der Frühwarnungsphase eher zu viel gemeldet wird.

Müssen wir in jedem Land melden, in dem wir Kunden haben? Du meldest an die Behörde des Mitgliedstaats, in dem ihr niedergelassen seid (für digitale Anbieter gelten die Regeln zur Hauptniederlassung). Grenzüberschreitende Auswirkung ist ein Feld im Bericht, kein Grund für zwanzig Meldungen. Wenn ihr separate Gesellschaften in mehreren Mitgliedstaaten betreibt, ordne im Runbook jede Gesellschaft ihrer Behörde zu.

Wir sind Zulieferer einer wesentlichen Einrichtung, aber selbst nicht im Anwendungsbereich. Können wir das ignorieren? Praktisch nein. Deine Kunden im Anwendungsbereich müssen Lieferkettenrisiken managen und werden Meldepflichten vertraglich an dich weiterreichen, oft mit Fenstern kürzer als 24 Stunden. Dasselbe Runbook erfüllt beide Zwecke. Sieh dir unseren Beitrag zu Supply-Chain-Security und NIS2-Readiness für die Zulieferer-Perspektive an.

Baue es, bevor du es brauchst

Das Muster hinter jedem Schritt ist dasselbe: Verlagere Entscheidungen, Registrierungen und Schreibarbeit aus dem Vorfall heraus in die ruhige Vorbereitung. Klassifizierungsschwellen, Portal-Accounts, Kontaktketten und Vorlagen kosten ein paar fokussierte Tage. Vorab erledigt, wird die 24-Stunden-Frühwarnung zur Checklisten-Übung. Improvisiert, wird sie zur zweiten Krise der Nacht.

Wenn du ein zweites Paar Augen auf deine Meldebereitschaft haben möchtest, vom Audit-Logging über die Erkennungsabdeckung bis zum Runbook selbst, schreib uns an hello@wolf-tech.io oder besuche wolf-tech.io. Wir helfen SaaS-Teams, regulatorische Fristen in Engineering-Checklisten zu verwandeln.