NIS2-Meldepflicht bei Kubernetes-Vorfällen: der Ablauf nach Stunden

TL;DR

1. Vier Stufen, nicht drei. Frühe Erstmeldung binnen 24 Stunden, Meldung binnen 72 Stunden, Zwischenmeldung auf Ersuchen des BSI, Abschlussmeldung spätestens einen Monat nach der 72-Stunden-Meldung (§ 32 Abs. 1 BSIG).
2. 24 und 72 Stunden laufen beide ab Kenntniserlangung, nicht kaskadierend. Die 72-Stunden-Frist beginnt nicht mit der Erstmeldung. Wer das falsch liest, verliert real 24 Stunden.
3. Auslöser ist nicht jeder Ausfall, sondern der erhebliche Sicherheitsvorfall nach § 2 Nr. 11 BSIG. Ein CrashLoopBackOff ist keiner. Ein ServiceAccount-Token, mit dem jemand erfolgreich API-Calls abgesetzt hat, kann einer sein.
4. Der Engpass ist nicht das Formular, sondern die Datenlage. In Stunde 2 brauchen Sie Eintrittszeitpunkt, Erkennungszeitpunkt und eine vermutete Ursache. Ohne Kubernetes-Audit-Logs haben Sie keine der drei Angaben — und das ist der häufigste Einzelfehler.

Das Problem: die Uhr läuft ab dem ersten Mitarbeiter, nicht ab der Eskalation

Die übliche Kette im Mittelstand: Etwas passiert, das Team analysiert, irgendwann eskaliert es zur IT-Leitung, die informiert die Geschäftsführung. Bis jemand über eine Meldung nachdenkt, ist die 24-Stunden-Frist in vielen Fällen bereits abgelaufen.

Das BSI legt den Startpunkt woanders. Auf seiner Seite zur NIS-2-Meldepflicht definiert es: "Mit 'Kenntniserlangung' ist der Zeitpunkt gemeint, an dem eine Mitarbeiterin oder ein Mitarbeiter der Einrichtung (innerhalb der Arbeitszeit) Kenntnis über einen erheblichen Sicherheitsvorfall erlangt."

Der Werkstudent, der um 22:30 Uhr einen fremden Cryptominer-Pod sieht, startet die Frist — nicht das Management-Meeting am nächsten Vormittag. Und das BSI schreibt zu den Fristen: "Die unten genannten Fristen sind Maximalzeiten, die nicht ausgereizt werden sollten."

Die vier Stufen im Wortlaut

§ 32 Abs. 1 Satz 1 BSIG verlangt Meldungen an die gemeinsame Meldestelle von BSI und Bundesamt für Bevölkerungsschutz und Katastrophenhilfe:

Nummer 1 — frühe Erstmeldung, spätestens 24 Stunden nach Kenntniserlangung. Inhalt laut Gesetz: die Angabe, "ob der Verdacht besteht, dass der erhebliche Sicherheitsvorfall auf rechtswidrige oder böswillige Handlungen zurückzuführen ist oder grenzüberschreitende Auswirkungen haben könnte". Das BSI-Formular fragt zusätzlich Einstufung, vorläufige Beschreibung der Störung, Eintritts- und Erkennungszeitpunkt, getroffene Maßnahmen und die Angabe ab, ob der Vorfall unter Kontrolle ist.

Nummer 2 — Meldung, spätestens 72 Stunden nach Kenntniserlangung. Sie bestätigt oder aktualisiert die Erstmeldung und enthält "eine erste Bewertung des erheblichen Sicherheitsvorfalls, einschließlich seines Schweregrads und seiner Auswirkungen, sowie gegebenenfalls die Kompromittierungsindikatoren". Das BSI nennt diese Stufe im Portal Folgemeldung.

Nummer 3 — Zwischenmeldung, nur auf Ersuchen des Bundesamtes. Keine gesetzliche Regelfrist. Nicht planbar, nur beantwortbar.

Nummer 4 — Abschlussmeldung, spätestens einen Monat nach Übermittlung der 72-Stunden-Meldung. Inhalt: ausführliche Beschreibung samt Schweregrad und Auswirkungen, Art der Bedrohung beziehungsweise zugrunde liegende Ursache, getroffene und laufende Abhilfemaßnahmen, gegebenenfalls grenzüberschreitende Auswirkungen. Dauert der Vorfall noch an, tritt nach § 32 Abs. 2 BSIG eine Fortschrittsmeldung an ihre Stelle.

§ 32 Abs. 1 Satz 2 BSIG lässt die Meldepflicht erst "ab Einrichtung des Meldewegs" greifen. Diese Bedingung ist erfüllt: Registrierte Einrichtungen melden im BSI-Portal, noch nicht registrierte über ein Online-Formular im Melde- und Informationsportal des BSI.

Abgrenzung: welche Cluster-Ereignisse die Kette auslösen

Es sind zwei Prüfungen, nicht eine.

Prüfung 1: Liegt überhaupt ein Sicherheitsvorfall vor? § 2 Nr. 40 BSIG definiert ihn als "ein Ereignis, das die Verfügbarkeit, Integrität oder Vertraulichkeit gespeicherter, übermittelter oder verarbeiteter Daten oder der Dienste [...] beeinträchtigt" — ursachenneutral. Ein Node-Ausfall, der Ihren Dienst kippt, fällt darunter, auch ohne Angreifer. "NIS2 ist nur für Hacker-Angriffe" ist falsch.

Prüfung 2: Ist er erheblich? Das ist der Filter. § 2 Nr. 11 BSIG verlangt schwerwiegende Betriebsstörungen oder finanzielle Verluste für die Einrichtung, oder erhebliche materielle beziehungsweise immaterielle Schäden bei Dritten. Zur Konkretisierung verweist das BSI auf die Durchführungsverordnung (EU) 2024/2690 vom 17. Oktober 2024. Für Cloud-, Rechenzentrums- und Managed-Service-Anbieter ist deren Artikel 3 verbindlich; für andere Sektoren könne laut BSI davon ausgegangen werden, dass ein erheblicher Vorfall vorliegt, wenn mindestens ein Kriterium des Artikels 3 Absatz 1 erfüllt ist.

Zwei Kriterien daraus treffen Kubernetes direkt:

• Artikel 3 Abs. 1 Buchstabe e: "es hat einen erfolgreichen, mutmaßlich böswilligen und unbefugten Zugriff auf Netz- und Informationssysteme gegeben, der geeignet ist, schwerwiegende Betriebsstörungen zu verursachen". Entscheidend sind drei Wörter: erfolgreich, böswillig, unbefugt.
• Artikel 3 Abs. 1 Buchstabe a: direkter finanzieller Verlust über 500.000 Euro oder 5 % des Vorjahres-Gesamtumsatzes — je nachdem, welcher Wert niedriger ist. Das "niedriger" wird oft überlesen: Bei 5 Millionen Euro Umsatz liegt die Schwelle bei 250.000 Euro, nicht bei 500.000. Ab 10 Millionen Euro Umsatz deckelt der Festbetrag auf 500.000 Euro.

Damit lässt sich die Abgrenzung konkret machen:

Den Artikel-4-Fall übersehen in der Praxis fast alle: Zwei Vorfälle innerhalb von sechs Monaten, dieselbe offensichtliche Ursache, zusammen über der Finanzschwelle — dann gelten sie als ein erheblicher Sicherheitsvorfall. Wer jeden Ausfall einzeln bewertet, kommt nie auf die Meldung.

Sind personenbezogene Daten abgeflossen, läuft parallel die 72-Stunden-Frist aus Art. 33 Abs. 1 DSGVO gegenüber der Datenschutzaufsicht. Zwei Meldungen, zwei Behörden, ein Sachverhalt.

Praxis: was in den ersten Stunden technisch passieren muss

Stunde 0 bis 1 — Zeitstempel und Beweislage sichern

Notieren Sie zuerst, wer wann was gesehen hat. Dieser Zeitstempel ist Ihr Fristbeginn und die einzige Angabe, die sich später nicht rekonstruieren lässt.

Dann: nicht aufräumen. Der Reflex kubectl delete pod vernichtet den Hauptbeweis. Isolieren statt löschen:

# Node aus dem Scheduling nehmen, Workload aber nicht verdrängen
kubectl cordon <node>

# Pod-Zustand und Ereignisse vor jeder Änderung wegschreiben
kubectl get pod <pod> -n <ns> -o yaml > evidence-pod-$(date +%FT%H%M%S).yaml
kubectl describe pod <pod> -n <ns> > evidence-describe-$(date +%FT%H%M%S).txt
kubectl logs <pod> -n <ns> --all-containers --timestamps > evidence-logs-$(date +%FT%H%M%S).log

Netzwerkseitig kappen Sie den Pod über eine Default-Deny-NetworkPolicy im betroffenen Namespace, statt ihn zu terminieren: Der Container läuft weiter, der Speicherinhalt bleibt, der Angreifer verliert die Verbindung.

Stunde 1 bis 4 — die drei Fragen des Formulars beantworten

Die 24-Stunden-Meldung verlangt Eintrittszeitpunkt, Erkennungszeitpunkt und vermutete Ursache. Alle drei kommen aus dem Kubernetes-Audit-Log, nicht aus Anwendungslogs:

# Wer hat mit welchem Identity welche Verbs abgesetzt?
jq -r 'select(.user.username=="system:serviceaccount:<ns>:<sa>")
       | [.requestReceivedTimestamp, .verb, .objectRef.resource, .sourceIPs[0]]
       | @tsv' audit.log | sort | head -50

Wenn dieser Befehl nichts liefert, weil kein Audit-Log existiert, bleibt die Meldung eine Vermutung — und die Abschlussmeldung nach einem Monat wird zum Problem, weil sie eine Ursachenangabe verlangt.

Der Fehler, der die Meldung unmöglich macht

Kubernetes-Auditing ist standardmäßig aus. Ohne --audit-policy-file wird kein einziges Event geschrieben, ohne --audit-log-path gibt es kein Log-Backend. Bei den Managed-Angeboten ist es nicht besser:

• EKS: "By default, cluster control plane logs aren't sent to CloudWatch Logs." Jeder Log-Typ inklusive audit muss einzeln aktiviert werden.
• AKS: Ressourcenprotokolle werden zwar erzeugt, aber laut Microsoft-Dokumentation müssen Sie sie "an Azure Monitor-Protokolle weiterleiten, um sie zu speichern oder abzufragen" — ohne Diagnoseeinstellung mit den Kategorien kube-audit oder kube-audit-admin existiert nichts Abfragbares.
• GKE: Admin-Activity-Logs laufen immer und lassen sich nicht abschalten, Data-Access-Logs sind standardmäßig deaktiviert.

Und selbst mit aktiviertem Log-Backend ist das Fenster kleiner, als die Defaults suggerieren. Die kube-apiserver-Referenz nennt --audit-log-maxage=366, --audit-log-maxbackup=100 und --audit-log-maxsize=100 (MB). Es greift die zuerst erreichte Grenze: 100 Dateien à 100 MB sind rund 10 GB. Ein Cluster mit 2 GB Audit-Events pro Tag hat damit ein Rückblickfenster von fünf Tagen, nicht von 366.

Eine Aufbewahrungsdauer in Zahlen schreibt NIS2 nicht vor. Anhang Nr. 3.2.5 der DVO 2024/2690 verlangt, die Protokolle "für einen vorab festgelegten Zeitraum" zu führen, zu sichern und vor unbefugtem Zugriff oder Änderung zu schützen. Die operative Untergrenze folgt aus dem Verfahren: 72-Stunden-Meldung plus ein Monat bis zur Abschlussmeldung plus rückwirkende Ursachenanalyse. Wer unter 90 Tagen liegt, kann die vierte Stufe nicht sauber bedienen — das ist eine Ableitung aus dem Fristenregime, keine gesetzliche Zahl.

Wer entscheidet

Die Meldepflicht trifft die Einrichtung, nicht eine Person. Praktisch brauchen Sie drei Festlegungen vorab: wer die Erheblichkeit einschätzt, wer die Meldung freigibt, und wer nachts Zugang zum BSI-Portal hat. Der Zugang läuft zweistufig über "Mein Unternehmenskonto" und das BSI-Portal — das richtet niemand um 03:00 Uhr ein.

Die Geschäftsleitung ist nach § 38 Abs. 1 BSIG verpflichtet, die Maßnahmen nach § 30 "umzusetzen und ihre Umsetzung zu überwachen". Die schärfere Formulierung "billigen" steht nicht im BSIG, sondern in Art. 20 Abs. 1 der NIS-2-Richtlinie.

Die Zeitleiste

Fallstricke aus der Praxis

Die 72 Stunden werden ab der Erstmeldung gerechnet. Falsch. Beide Fristen laufen ab Kenntniserlangung. Wer die Erstmeldung nach 20 Stunden absetzt, hat für Stufe 2 noch 52 Stunden.

Es wird erst gemeldet, wenn der Sachverhalt sicher ist. Das BSI schreibt zur Erstmeldung, sie habe "den Charakter einer Frühwarnung", eine frühzeitige Meldung sei "ausdrücklich erwünscht, auch wenn zum Zeitpunkt der Abgabe noch Unsicherheiten bestehen". Korrekturen laufen über Folgemeldungen. Umgekehrt: Eine abgegebene Meldung "kann nachträglich nicht storniert oder zurückgezogen werden".

Remediation vor Beweissicherung. Pod gelöscht, Node neu gebaut, Token rotiert — danach kann niemand mehr für die Abschlussmeldung eine Ursache angeben.

Die Logs sind da, aber niemand kommt ran. Wenn nur das Cloud-Team ohne Rufbereitschaft Leserechte auf den Log-Workspace hat, sind die Logs für die 24-Stunden-Meldung faktisch nicht vorhanden.

Jeder Vorfall wird isoliert bewertet. Art. 4 DVO 2024/2690 aggregiert wiederholte Vorfälle gleicher Ursache innerhalb von sechs Monaten. Ohne Vorfallregister fällt das nie auf.

Der Cloud-Provider meldet schon. Ihr Hyperscaler meldet allenfalls für sich selbst. Für Ihre Dienste sind Sie die Einrichtung im Sinne des BSIG.

FAQ

Ist ein Ausfall ohne Angreifer meldepflichtig? Möglich. § 2 Nr. 40 BSIG ist ursachenneutral, und § 30 Abs. 2 BSIG verlangt einen gefahrenübergreifenden Ansatz. Der Filter ist die Erheblichkeit, nicht die Frage, ob jemand angegriffen hat. Planmäßige Wartung ist nach Art. 3 Abs. 2 DVO ausdrücklich ausgenommen.

Wie lange müssen Kubernetes-Audit-Logs aufbewahrt werden? Eine gesetzliche Zahl existiert nicht. Die DVO verlangt einen "vorab festgelegten Zeitraum". Legen Sie ihn fest, dokumentieren Sie ihn, und leiten Sie ihn aus dem Fristenregime ab.

Was passiert bei einer verspäteten Meldung? Ein Verstoß gegen § 32 Abs. 1 Satz 1 BSIG ist eine Ordnungswidrigkeit nach § 65 Abs. 2 Nr. 4 BSIG, nach Abs. 5 Satz 1 Nr. 1 bewehrt mit bis zu zehn Millionen Euro bei besonders wichtigen und bis zu sieben Millionen Euro bei wichtigen Einrichtungen; ab 500 Millionen Euro Gesamtumsatz greifen stattdessen 2 % beziehungsweise 1,4 % des weltweiten Gesamtumsatzes. Veröffentlichte Bußgeldentscheidungen nach dem neuen BSIG sind uns nicht bekannt.

Wir sind registriert — reicht das? Nein. Die Registrierung nach § 33 BSIG ist ein einmaliger Verwaltungsakt. Maßnahmen nach § 30 und Meldepflichten nach § 32 laufen unabhängig davon dauerhaft.

Wo fangen wir an, wenn nichts davon steht? Bei den Audit-Logs. Danach RBAC — ein RBAC-Audit zeigt, welche ServiceAccounts einen Vorfall überhaupt zum erheblichen machen können.

Fazit

Die Meldekette selbst ist der überschaubare Teil: vier Stufen, von denen drei eine feste Frist haben. Scheitern lässt Unternehmen der Zustand des Clusters am Tag davor. Wer kein Audit-Logging betreibt, keine definierte Retention hat und keinen Portalzugang außerhalb der Bürozeiten, hält die 24-Stunden-Frist formal ein, gibt eine inhaltlich leere Meldung ab — und liefert einen Monat später keine Ursache.

Vier Vorbereitungsschritte: Audit-Policy aktivieren und Retention festlegen, Beweissicherung vor Remediation im Runbook verankern, Meldeberechtigung und Portalzugang benennen, Vorfallregister für den Wiederholungsfall führen.

Ob Ihr Cluster diese Voraussetzungen erfüllt, können Sie mit dem NIS2-Check selbst einschätzen. Wenn Sie den Betrieb inklusive Audit-Logging, Retention und Incident-Bereitschaft abgeben wollen, stehen die Leistungsumfänge unter Preise.

Hinweis: Dieser Artikel ist eine technische Einordnung der Meldepflichten aus Sicht des Kubernetes-Betriebs. Er ersetzt keine Rechtsberatung. Ob Ihr Unternehmen unter NIS2 fällt, ob ein konkreter Vorfall als erheblich im Sinne des § 2 Nr. 11 BSIG einzustufen ist und welche Fristen im Einzelfall gelten, ist eine rechtliche Bewertung, die eine Prüfung Ihres Sachverhalts voraussetzt. Rechtsstand der zitierten Vorschriften: 2. August 2026.