NIS2 Vorfallsmeldung in Österreich — die 24h/72h/30-Tage-Logik in der Praxis

Es passiert. Verschlüsselungs-Trojaner bei einem Tier-A-Dienstleister, der auf deine Systeme zugreift. Ein ungewöhnliches Login um 03:14 Uhr aus einem Land, in dem du keine Mitarbeitenden hast. Eine Lieferung von Daten an einen externen Empfänger, die niemand autorisiert hat. Die Stunden, die nun folgen, sind regulatorisch strukturiert: NIS2 verlangt eine dreistufige Meldepflicht — 24 Stunden Frühwarnung, 72 Stunden Vorfallsmeldung, 30 Tage Abschlussbericht. Wer diese Logik vorab durchgedacht hat, kommuniziert souverän; wer sie erst im Ernstfall liest, verliert Zeit, die nicht zu ersetzen ist.

Für österreichische Unternehmen ab 1. Oktober 2026 ist die Meldepflicht aus § 34 NISG 2026 verbindlich. Dieser Beitrag zeigt die drei Stufen im Detail, klärt, was als „erheblich” gilt und wer das entscheidet, und integriert die regulatorische Pflicht mit dem operativen Incident-Prozess nach ISO 27001/27002.

Drei Quellen, eine Meldepflicht

Die NIS2-Meldepflicht entsteht aus dem Zusammenspiel von drei regulatorischen Ebenen, ergänzt durch eine vierte aus dem ISMS-Standard:

• NIS2-Richtlinie (EU) 2022/2555, Artikel 23 → das Was und Warum. Politischer Rahmen für die Meldepflicht. Verlangt von wesentlichen und wichtigen Einrichtungen, „erhebliche Vorfälle” unverzüglich zu melden.
• NISG 2026 § 34 → die österreichische Umsetzung. Definiert die drei Meldestufen mit konkreten Fristen, benennt die zuständige Stelle (sektorspezifisches CSIRT, in dessen Ermangelung das nationale CSIRT) und regelt die Anschluss-Pflichten gegenüber den Empfängern der Dienste.
• NIS2-Durchführungsverordnung 2024/2690, Artikel 3 → wann ist ein Vorfall „erheblich”? Die DV definiert horizontale Schwellenwerte, ab denen ein Vorfall meldepflichtig wird, ergänzt durch sektorspezifische Kriterien in Artikel 5 bis 14 für die DV-Adressaten (DNS, Cloud, MSP, Vertrauensdienste etc.).
• ISO/IEC 27001:2022 und 27002:2022, Annex A.5.24 bis A.5.30 → wie der Incident-Prozess im ISMS organisiert wird. Sieben Controls vom Incident-Management-Plan über die Bewertung und Eskalation bis zur Beweissicherung und zur Wiederaufnahme der Geschäftstätigkeit.

Wer das Zusammenspiel kennt, sieht: NIS2 stellt die externe Meldepflicht — ISO 27001 organisiert den internen Prozess, der diese Pflicht überhaupt erst erfüllbar macht. Die Verzahnung mit dem Drittparteienmanagement ist eng: Wenn ein Lieferant einen Vorfall meldet, der die eigene Einrichtung betrifft, beginnt die 24-Stunden-Uhr für die eigene Meldung — die Lieferanten-Verträge müssen das antizipieren.

Die drei Meldestufen nach § 34 NISG 2026

§ 34 Abs. 2 NISG 2026 listet fünf Melde-Elemente — aus eigenem Antrieb fristauslösend sind davon drei: Frühwarnung, Vorfallsmeldung und Abschlussbericht. Zwischen- und Fortschrittsbericht greifen nur auf Ersuchen bzw. bei andauerndem Vorfall. Die folgende Tabelle bündelt alle fünf operativ:

Stufe	Frist	Empfänger	Mindest-Information
1. Frühwarnung	unverzüglich, in jedem Fall innerhalb 24 Stunden nach Kenntnisnahme	sektorspezifisches CSIRT, ersatzweise nationales CSIRT	ggf. Hinweis, ob Verdacht auf rechtswidrige und schuldhafte Handlungen besteht; ggf. Hinweis auf grenzüberschreitende Auswirkungen
2. Vorfallsmeldung	unverzüglich, in jedem Fall innerhalb 72 Stunden nach Kenntnisnahme	dasselbe CSIRT	aktualisierte Informationen aus Stufe 1; erste Bewertung des Schweregrads und der Auswirkungen; ggf. Kompromittierungs­indikatoren (IoCs)
3. Zwischenbericht	auf Ersuchen	CSIRT oder Cybersicherheitsbehörde	relevante Status­aktualisierungen
4. Abschlussbericht	spätestens einen Monat nach der Vorfallsmeldung (Stufe 2)	dasselbe CSIRT	ausführliche Beschreibung; Schweregrad + Auswirkungen; Art der Bedrohung + Ursachen; getroffene und laufende Abhilfemaßnahmen; ggf. grenzüberschreitende Auswirkungen
5. Fortschrittsbericht	wenn Vorfall bei Fälligkeit des Abschlussberichts noch andauert	dasselbe CSIRT	Status zur Bewältigung; finaler Abschlussbericht spätestens einen Monat nach Beendigung der Vorfallsbehandlung

Vertrauensdienste-Anbieter, deren Vorfall sich auf die Vertrauensdienste auswirkt, melden bereits in Stufe 2 innerhalb von 24 Stunden statt 72 Stunden (§ 34 Abs. 2 Schlussteil NISG 2026). Diese Sonderregel ist die einzige Verschärfung der Frist-Logik in der gesamten NISG-Berichtspflicht.

Wichtiger Punkt zur 24-Stunden-Frühwarnung: Sie ist kein detaillierter Bericht. Sie soll dem CSIRT ermöglichen, schnell zu reagieren — etwa um zu prüfen, ob es ein Muster gibt, das andere Einrichtungen warnt. Die operative Bewertung kommt mit Stufe 2. § 34 Absatz 4 NISG 2026 verpflichtet das CSIRT, innerhalb von 24 Stunden nach Eingang der Frühwarnung eine Antwort zu übermitteln — einschließlich erster Rückmeldung und, auf Ersuchen, operativer Beratung. Bei Verdacht auf strafrechtlich relevanten Hintergrund gibt das CSIRT zusätzlich Orientierungshilfen für die Meldung an Strafverfolgungsbehörden.

Was ist „erheblich”? Die Schwellenwerte aus Artikel 3 NIS2-DV

Die Meldepflicht greift nur bei einem erheblichen Vorfall — § 35 NISG 2026 und Artikel 3 NIS2-DV 2024/2690 definieren das Kriterium. Die Definition ist zweistufig: NISG § 35 nennt zwei Generalklauseln, die DV-Artikel 3 konkretisiert sie durch sieben Schwellenwerte.

§ 35 NISG 2026 — die zwei Generalklauseln: Ein Vorfall gilt als erheblich, wenn er

1. schwerwiegende Betriebsstörungen oder schwerwiegende finanzielle Verluste für die Einrichtung verursacht hat oder verursachen kann; oder
2. andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat oder beeinträchtigen kann.

Artikel 3 NIS2-DV — die horizontalen Schwellenwerte (gelten für DV-Adressaten, sind aber Auslegungs-Maßstab für die nationale Aufsicht auch bei anderen Einrichtungen):

• (a) Direkter finanzieller Schaden über 500.000 Euro oder 5 % des gesamten Jahresumsatzes im vorangegangenen Geschäftsjahr (der niedrigere Wert)
• (b) Exfiltration von Geschäftsgeheimnissen im Sinne der Richtlinie (EU) 2016/943
• (c) Verursachung des Todes einer natürlichen Person
• (d) Verursachung einer erheblichen Beeinträchtigung der Gesundheit einer natürlichen Person
• (e) Erfolgreicher, vermutlich böswilliger und unbefugter Zugriff auf Netz- und Informationssysteme, der schwerwiegende Betriebsstörungen verursachen kann
• (f) Erfüllung der Kriterien aus Artikel 4 (wiederholte Vorfälle, siehe unten)
• (g) Erfüllung der Kriterien aus Artikel 5 bis 14 (sektorspezifisch — DNS, TLD, Cloud, Rechenzentren, CDN, MSP/MSSP, Online-Marktplätze, Online-Suchmaschinen, soziale Netzwerke, Vertrauensdienste)

Artikel 4 NIS2-DV — Wiederholte Vorfälle: Einzelne Vorfälle, die für sich nicht als erheblich gelten, werden zusammen als ein erheblicher Vorfall betrachtet, wenn sie (a) mindestens zweimal in 6 Monaten auftreten, (b) dieselbe erkennbare Grundursache haben, und (c) zusammen das Kriterium aus Artikel 3(1)(a) (500.000 € / 5 % Umsatz) erreichen. Diese Klausel verhindert, dass Wiederholungstäter-Vorfälle durch Salami-Taktik unter die Meldepflicht-Schwelle gedrückt werden.

Geplante Wartungsunterbrechungen sind nach Artikel 3(2) NIS2-DV ausdrücklich keine meldepflichtigen Vorfälle, sofern sie tatsächlich geplant und durch die Einrichtung selbst oder in ihrem Auftrag durchgeführt werden.

Wer entscheidet „erheblich” — die Eskalations-Logik im Unternehmen

Die Entscheidung, ob ein Vorfall die Meldepflicht-Schwelle erreicht, kann nicht erst am 23. Stundenende fallen. ISO 27001 Annex A liefert hier die operative Struktur: A.5.25 Assessment and decision on information security events verlangt, dass die Organisation Ereignisse bewertet und entscheidet, ob sie als Vorfälle einzustufen sind. Diese Bewertung muss in einem definierten Prozess passieren — mit klaren Rollen.

Eine dreistufige Eskalations-Logik hat sich in der Praxis bewährt:

Stufe 1 — Erstbewertung durch IT-Operations / SOC (Stunden 0–6 nach Erkennung). Triage: Welches Asset ist betroffen? Welche Daten? Welche Dienste? Gibt es Anzeichen für externes oder internes Handeln? Diese Bewertung ist faktenbezogen, noch keine Erheblichkeits-Einstufung.

Stufe 2 — Erheblichkeits-Prüfung durch CISO oder Sicherheits-Verantwortlichen (Stunden 6–18). Abgleich gegen die § 35 NISG-Generalklauseln und die DV-Artikel-3-Schwellen: Erreicht der finanzielle Schaden 500.000 € oder 5 % des Jahresumsatzes? Sind Geschäftsgeheimnisse betroffen? Gibt es Personenschäden? Liegt ein böswilliger unbefugter Zugriff vor? Diese Prüfung mündet in eine Empfehlung an die Geschäftsleitung.

Stufe 3 — Meldungs-Entscheidung durch die Geschäftsführung (vor Ablauf der 24-Stunden-Frist). Die formelle Entscheidung zur Meldung trifft die Geschäftsführung. Sie dokumentiert die Erheblichkeits-Einstufung und gibt die Frühwarnung frei. Diese Entscheidung gehört dokumentiert — auch und gerade, wenn das Ergebnis „nicht meldepflichtig” lautet, weil die Behörde die Begründung nachträglich nachvollziehen können muss.

Diese Dreistufigkeit schützt vor Verwaltungsstrafen und ist zugleich die operative Voraussetzung dafür, die 24-Stunden-Frist überhaupt zu schaffen. Wer erst im Vorfall klärt, wer welche Entscheidung treffen darf, verliert die ersten zwölf Stunden mit Verfahrensfragen.

Der Abschnitt Meldewesen der NIS2-Geschäftsführer-Checkliste fragt diese Eskalations-Logik in vier Punkten ab — wer erkennt und bewertet, steht der Meldeprozess über alle drei Stufen, sind die Wege zur Behörde und zum CSIRT hinterlegt, wurde der Ablauf geübt.

Sicherer Meldekanal — wie meldest du konkret?

§ 34 Abs. 1 NISG 2026 benennt den Empfänger: das für die Einrichtung zuständige sektorspezifische CSIRT, in dessen Ermangelung das nationale CSIRT. Die CSIRT-Landschaft selbst regelt § 8 NISG 2026: Die Cybersicherheitsbehörde ermächtigt eine Einrichtung als nationales CSIRT (§ 8 Abs. 2) und kann bei Bedarf für jeden Sektor ein sektorspezifisches CSIRT ermächtigen (§ 8 Abs. 3) — solange für einen Sektor keines besteht, übernimmt das nationale CSIRT dessen Aufgaben. Fix gesetzt ist nur eines: Das bei der Behörde eingerichtete GovCERT ist sektorspezifisches CSIRT für die öffentliche Verwaltung (§ 8 Abs. 4). Übergangsweise nimmt das bisher nach dem NISG 2018 ermächtigte nationale CSIRT — CERT.at — die Aufgaben weiter wahr, längstens zwei Jahre ab Inkrafttreten (§ 51 Abs. 6 NISG 2026). Welche Stelle für die eigene Einrichtung aktuell zuständig ist, lässt sich jederzeit nachprüfen: Die Behörde muss jede Ermächtigung öffentlich kundmachen (§ 8 Abs. 5).

Drei Praxis-Punkte zum Meldekanal:

Sicherer Übermittlungsweg. Eine Vorfallsmeldung enthält in der Regel sensible Informationen — Kompromittierungsindikatoren, betroffene Systeme, ggf. personenbezogene Daten. Sie gehört nicht in eine ungesicherte E-Mail. Das CSIRT stellt sichere Übermittlungswege bereit (häufig PGP-verschlüsselte E-Mail oder ein Web-Portal). Diese Kanäle müssen vorab eingerichtet sein — der Versuch, im Vorfall einen PGP-Schlüssel auszutauschen, kostet Stunden.

Vorab-Kontaktaufnahme. Es lohnt sich, vor jedem möglichen Vorfall einen Erst-Kontakt zum zuständigen CSIRT herzustellen. Eine kurze Vorstellung der Einrichtung, ein Tausch der Sicherheits-Kontakte, eine Klärung des Übermittlungswegs. Im Ernstfall wird die Frühwarnung dann nicht an eine anonyme Stelle gerichtet, sondern an eine Person mit Kontext.

Definierter Sicherheits-Kontakt im eigenen Unternehmen. Im Vertrag mit Lieferanten und in der internen Eskalations-Logik (siehe Abschnitt zuvor) muss ein definierter Sicherheits-Kontakt benannt sein — keine generische E-Mail-Sammeladresse, keine „zuständige Stelle”. Die Person muss erreichbar sein (auch nachts und am Wochenende), die Vertretung muss geregelt sein.

Die Empfänger-Unterrichtung — wenn die Dienste beeinträchtigt sind

§ 34 Absatz 3 NISG 2026 erweitert die Meldepflicht um eine zweite Adresse: die Empfänger der eigenen Dienste. Wenn der Vorfall die Erbringung des Dienstes beeinträchtigt, muss die Einrichtung ihre Diensteempfänger unverzüglich über den erheblichen Cybersicherheitsvorfall unterrichten und, soweit möglich, Abhilfemaßnahmen mitteilen, die diese Empfänger ergreifen können.

Konkret: Wenn ein steirisches IT-Dienstleistungsunternehmen einen Vorfall hat, der seine Kunden-Backups kompromittieren könnte, muss es seine Kunden informieren. Der Hinweis muss klar genug sein, dass die Kunden eigene Schutzmaßnahmen ergreifen können (z. B. Passwörter wechseln, Alternative für Backup einrichten, eigene Behörden-Meldung machen, falls die Kunden ihrerseits NIS2-Einrichtungen sind).

Diese Empfänger-Unterrichtung ist kein Marketing-Akt und sollte nicht als solcher behandelt werden. Sie ist eine vertrauensbildende Maßnahme und gleichzeitig eine rechtliche Pflicht. Vorgehensweise und Formulierung sollten im Incident-Response-Plan vordefiniert sein.

Dokumentation während und nach dem Vorfall

ISO 27001 A.5.27 (Learning from incidents) und A.5.28 (Collection of evidence) verlangen, dass Wissen aus Vorfällen genutzt wird, um die Sicherheits-Maßnahmen zu verbessern, und dass Beweise nachvollziehbar erfasst werden. Für die NIS2-Compliance ist das nicht optional — der Abschlussbericht nach § 34 Abs. 2 Z 4 NISG 2026 verlangt eine ausführliche Beschreibung des Vorfalls, der Ursachen und der Abhilfemaßnahmen. Diese Information muss aus einer laufenden Dokumentation kommen, nicht aus nachträglicher Rekonstruktion.

Drei Dokumentations-Artefakte sind in der Vorfall-Bewältigung Pflicht:

Timeline-Protokoll. Wer hat wann was gemerkt, wer hat wann was entschieden, wer hat wann was gemeldet. Wird ab Minute eins der Vorfall-Bearbeitung geführt, idealerweise in einem dedizierten System (Ticket-Tool, Incident-Channel), nicht in ad-hoc-Chats, die später nicht mehr rekonstruierbar sind.

Beweissicherung nach A.5.28. Logfiles, System-Snapshots, Memory-Dumps der betroffenen Systeme — möglichst früh und in einer Weise, die forensisch verwertbar ist. Wenn der Vorfall strafrechtliche Relevanz haben könnte (was bei böswilligen unbefugten Zugriffen häufig der Fall ist), kommt es auf die Beweis­kette an. Hier hilft eine vorab definierte Liaison zu einer forensischen IT-Dienstleistung.

Lessons-Learned-Protokoll nach A.5.27. Nach Abschluss des Vorfalls: Was hat funktioniert? Was nicht? Welche Maßnahmen werden adressiert? Dieses Protokoll fließt in das ISMS-Review und ist Teil der jährlichen Management-Bewertung des ISMS. Es ist auch der Inhalt, der den Abschlussbericht an das CSIRT mit echter Substanz füllt.

Lieferanten-Meldekette — die Verzahnung mit § 32(4)(d)

Die NIS2-Meldepflicht der eigenen Einrichtung beginnt mit der Kenntnisnahme eines erheblichen Vorfalls — auch dann, wenn die Quelle der Kenntnisnahme ein Lieferant ist. Wenn ein Tier-A-Anbieter meldet, dass seine Systeme kompromittiert wurden und Daten der Auftraggebenden betroffen sein könnten, beginnt für den Auftraggeber ab diesem Moment die 24-Stunden-Uhr.

Die Konsequenz: Die Vertrags-Klauseln aus dem Drittparteienmanagement-Artikel — insbesondere die unverzügliche Meldepflicht der Lieferanten nach DV-Anhang 5.1.4(d) und ISO 27001 A.5.20 — sind die Grundlage dafür, dass die eigene Meldekette überhaupt rechtzeitig startet. Wenn der Lieferant erst eine Woche nach dem Vorfall meldet, ist die NIS2-Frühwarnung für den Auftraggeber rechnerisch unmöglich einzuhalten.

Praktisch heißt das: Im Audit der eigenen Meldepflicht-Compliance wird die Aufsichtsbehörde prüfen, wann die Kenntnisnahme stattgefunden hat. Dieser Zeitpunkt ist verteidigbar, wenn die Vertrags-Architektur und die Triage-Logik vorab dokumentiert sind. Er ist angreifbar, wenn die Information schon Tage vorher beim IT-Operations-Team lag und niemand sie zur Erheblichkeits-Prüfung weitergegeben hat.

Sanktionen bei Meldepflicht-Verletzung

§ 45 NISG 2026 listet die Verletzung der Meldepflichten ausdrücklich als Tatbestand. Konkret § 45 Abs. 1 Z 4: die versäumte Meldung erheblicher Vorfälle nach § 34 Abs. 1 und 2 samt den damit zusammenhängenden Berichtspflichten. Für wesentliche Einrichtungen droht eine Geldstrafe bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes (Klasse 1), für wichtige Einrichtungen bis zu 7 Millionen Euro oder 1,4 % (Klasse 2). Die Z 5 (versäumte Unterrichtung der Diensteempfänger nach § 34 Abs. 3) ist mit denselben Höchstgrenzen sanktioniert.

Realistisch ist die Geldstrafe bei vereinzelten Versäumnissen nicht das wahrscheinlichste Szenario — die Behörde wird stufenweise vorgehen, mit Anordnung und Behebungs-Frist nach § 39 NISG 2026 als ersten Schritten. Aber: Die Drohung ist real, und sie wirkt auf Aufsichtsräte und Eigentümer. Wie das Sanktionsregime des NISG 2026 im Detail aufgebaut ist und welche Hebel die Behörde sonst noch hat — von der Öffentlichmachung des Verstoßes bis zur vorübergehenden Untersagung von Leitungsaufgaben — ist Gegenstand des eigenen Beitrags.

Fazit — was die Geschäftsführung jetzt vorbereiten muss

Die NIS2-Meldepflicht ist eine Stressprüfung der eigenen Organisations-Reife. 24 Stunden Frühwarnung bedeuten: Triage-Prozess, Eskalations-Logik und Meldekanal müssen am Tag null funktionieren — Improvisation kostet Frist.

Vier konkrete Schritte für die Geschäftsführung in der Vorbereitung auf den 1. Oktober 2026:

1. Incident-Response-Plan auf NIS2-Meldekette anpassen — die drei Stufen (24h Frühwarnung, 72h Vorfallsmeldung, 30T Abschlussbericht) als Pflichtbestandteile einbauen, mit definierten Verantwortlichen pro Stufe. Eine Tabletop-Übung macht in 45 Minuten sichtbar, ob die 24-Stunden-Frist realistisch eingehalten werden kann.

2. CSIRT-Erstkontakt herstellen — das zuständige sektorspezifische CSIRT (oder das nationale CSIRT) identifizieren, einen Sicherheits-Kontakt benennen, sichere Übermittlungswege einrichten. Vor dem Ernstfall, nicht in ihm.

3. Interne Meldewege bis zum Arbeitsplatz durchziehen — die 24-Stunden-Frist beginnt mit der Kenntnisnahme, und die entsteht fast immer an einem Arbeitsplatz. Die Incident-Playbooks für KMU decken diesen ersten Schritt ab: pro Vorfallstyp eine A4-Seite mit Sofortmaßnahmen und Meldeweg, dazu ein Kontaktblatt für die eigenen Ansprechpersonen.

4. Erheblichkeits-Kriterien dokumentieren — die § 35 NISG-Generalklauseln und die DV-Artikel-3-Schwellenwerte in der internen Incident-Triage-Checkliste verankern. Dieser Schritt verhindert das größte Risiko: dass im Vorfall eine Stunde verloren geht, weil jemand nachsehen muss, ob 500.000 Euro oder 5 % des Umsatzes greift.

Ein strukturiertes NIS2-Beratungs-Mandat oder ein punktuelles Cyber Reality Check liefert die Vorbereitung in 4 bis 12 Wochen, je nach Reifegrad. Was im Auditfall zählt, sind nicht die Absichten, sondern die Belege — der Plan, das Dokument, die Übung, das geübte Verfahren. Und genau diese Belege wollen die Behörden nach dem 1. Oktober 2026 sehen.