Acht Tage bis zum NISG: Was jetzt zählt und was bis Jahresende reicht

Am 1. Oktober 2026 tritt das Netz- und Informationssystemsicherheitsgesetz 2026 in Kraft (§ 51 NISG 2026). Eine Übergangsfrist für die materiellen Pflichten gibt es nicht. Bisher war NIS2 für viele Unternehmen ein Projektthema mit offenem Ende. Ab nächster Woche ist es geltendes Recht, mit Meldepflichten, Behörde und Strafrahmen. Dieser Beitrag trennt das Dringende vom Wichtigen und ist so aufgebaut, dass sich jeder Abschnitt als Prüfliste weiterverwenden lässt.

1. Die Zeitachse: Was sofort gilt und was Zeit hat

Die häufigste Fehleinschätzung der letzten Wochen: "Wir haben ja bis Jahresende Zeit." Das stimmt nur für die Registrierung. Alles andere gilt ab dem ersten Tag.

Zwei Details, die in der Planung regelmäßig untergehen. Erstens: Die Frist für die Selbstdeklaration läuft ab Eintritt der Registrierungspflicht, nicht ab der tatsächlichen Registrierung. Wer sich im Oktober registriert, gewinnt nichts, wer bis Dezember wartet, verliert nichts. Zweitens: Meldungen gehen an das zuständige sektorspezifische CSIRT, ersatzweise an das nationale CSIRT (§ 34 Abs. 1), nicht an das Bundesamt für Cybersicherheit. Registrierung und Selbstdeklaration gehen dagegen direkt an die Behörde. Ein Notfallplan, der den falschen Adressaten nennt, kostet im Ernstfall genau die Stunden, die man nicht hat.

Die Meldestufen im Überblick: Frühwarnung unverzüglich, spätestens 24 Stunden ab Kenntnisnahme; Meldung mit erster Bewertung spätestens nach 72 Stunden; Abschlussbericht spätestens einen Monat nach der Meldung. Die Fristen laufen ab Kenntnisnahme. Wer im Unternehmen "Kenntnis" auslöst, sollte deshalb vorab festgelegt sein, sonst ist der Fristbeginn im Nachhinein nicht belegbar.

Realistisch betrachtet lässt sich in acht Tagen kein Risikomanagement aufbauen. Was sich herstellen lässt, ist Meldefähigkeit und ein dokumentierter Ausgangsstand. § 32 verlangt verhältnismäßige Maßnahmen, bemessen an Risikoexposition, Größe, Eintrittswahrscheinlichkeit und Schadenshöhe. Diese Abwägung schriftlich festzuhalten, samt Maßnahmenplan mit Terminen, ist am 1. Oktober mehr wert als eine halbfertige Richtlinie.

Prüfpunkte bis 1.10.2026

• Betroffenheitsprüfung dokumentiert: Anlage 1 oder 2, Art der Einrichtung, Größe nach § 25, Ergebnis mit Datum und Unterschrift
• Zuständiges CSIRT identifiziert, Kontaktwege im Notfallplan hinterlegt
• Festgelegt, wer die Kenntnisnahme auslöst und wer meldet, inklusive Vertretung
• Unternehmensspezifische Erheblichkeitskriterien nach § 35 definiert (Ausfalldauer je kritischem Dienst, Zahl betroffener Kunden, Schadenshöhe, Datenabfluss)
• Notfallkommunikation außerhalb der Produktivumgebung verfügbar
• Ausgangsstand zu § 32 Abs. 4 lit. a bis j erhoben, Maßnahmenplan von der Geschäftsführung beschlossen

2. Der unterschätzte Punkt: Das Gesetz erfasst die Einrichtung, nicht den Dienst

Die Betroffenheit wird über einen Dienst hergeleitet: Ein Unternehmen fällt unter eine Art der Einrichtung in Anlage 1 oder 2 und überschreitet die Größenschwellen. Viele ziehen daraus den Schluss, dass sich auch die Pflichten auf diesen Dienst beschränken. Das ist falsch.

§ 32 bezieht sich, wie Art. 21 Abs. 1 NIS-2-RL, auf die Netz- und Informationssysteme, die die Einrichtung für ihren Betrieb oder für die Erbringung ihrer Dienste nutzt. Ein Maschinenbauer, der wegen seiner Fertigung unter Anlage 2 fällt, muss also nicht nur die Produktions-IT absichern, sondern auch Buchhaltung, Personalverwaltung, Vertrieb und Office-Umgebung. Die Meldepflicht knüpft dagegen an Auswirkungen auf die erbrachten Dienste an. Risikomanagement ist einrichtungsweit, die Meldung dienstbezogen. Diese Asymmetrie gehört in jedes Scoping-Dokument.

Dazu kommt die Größenberechnung. Partner- und verbundene Unternehmen werden eingerechnet, außer die Einrichtung ist hinsichtlich ihrer Netz- und Informationssysteme organisatorisch, technisch und operativ unabhängig (§ 25 Abs. 4). Diese Ausnahme ist eng. Gemeinsame Domäne, gemeinsame Identitätsverwaltung, geteiltes SOC oder zentrale IT-Beschaffung sprechen dagegen. Anders als in Deutschland kennt das NISG 2026 auch keine Ausnahme für vernachlässigbare oder rein konzerninterne Tätigkeiten.

Drei Konsequenzen für die Praxis:

Bestehendes ISMS. Zertifizierungsbereiche sind häufig auf ein Rechenzentrum, eine Produktlinie oder einen Standort zugeschnitten. Für das NISG reicht das nicht. Die Scope-Erweiterung sollte jetzt geplant werden, nicht erst vor der Selbstdeklaration.

Netzsegmentierung. Segmentierung ist eine gute Maßnahme, aber keine Grenze des Anwendungsbereichs. Wer das Produktionsnetz vom Büronetz trennt, reduziert Risiko und Auswirkungen eines Vorfalls. Aus dem Geltungsbereich des § 32 fällt das Büronetz dadurch nicht heraus.

Konzernstrukturen. Eine nicht erfasste Schwestergesellschaft ist nicht selbst verpflichtet. Nutzt sie aber dieselbe IT-Plattform wie die erfasste Einrichtung, ist diese Plattform Teil des Pflichtenkreises. Shared-Service-Gesellschaften und konzerninterne IT-Dienstleister sind eigens zu prüfen, weil sie selbst unter Anlage 1 fallen können.

Prüfpunkte

• Geltungsbereich des Risikomanagements auf die gesamte Einrichtung ausgelegt
• Abweichung zwischen ISMS-Scope und NISG-Pflichtenkreis dokumentiert, Erweiterung terminiert
• Gemeinsam genutzte Konzern-IT identifiziert und zugeordnet
• Falls § 25 Abs. 4 in Anspruch genommen wird: Trennung belastbar dokumentiert

3. Schulungspflicht der Leitungsorgane

§ 31 Abs. 2 NISG 2026 verpflichtet die Leitungsorgane zur Teilnahme an Cybersicherheitsschulungen, die spezifisch für sie gestaltet sind. Den Mitarbeitern sind regelmäßig entsprechende Schulungen anzubieten. Art. 20 Abs. 2 NIS-2-RL beschreibt das Ziel: ausreichende Kenntnisse, um Risiken und Managementpraktiken der Cybersicherheit zu erkennen und zu bewerten, samt deren Auswirkungen auf die erbrachten Dienste.

Wer geschult wird. Leitungsorgan sind natürliche Personen auf Ebene der Geschäftsführung oder des Vorstands. Prokuristen, der CISO und der Aufsichtsrat fallen nicht darunter. Es spricht nichts dagegen, sie einzubeziehen, die Pflicht erfüllen sie aber nicht an Stelle der Geschäftsführung.

Wer schult. Das Gesetz schreibt keine Qualifikation und keine Zertifizierung des Vortragenden vor. Sinnvoll ist jemand, der Technik, Regulatorik und Unternehmenssteuerung zusammenbringt und unabhängig genug ist, unbequeme Befunde auszusprechen. Ein interner CISO kann das leisten. Eine externe Person hat den Vorteil, dass die Geschäftsführung nicht die eigene Organisation bewertet.

In welchem Umfang. Das Gesetz nennt weder Stundenzahl noch Frist. Die Pflicht gilt ab 1. Oktober, einen Stichtag für die Absolvierung gibt es nicht. Wer die Schulung aber erst im nächsten Sommer ansetzt, steht bei einer Kontrolle ohne Nachweis da. Das ist ein Praxisargument, keine gesetzliche Frist. Eine allgemeine Awareness-Schulung für alle Mitarbeiter erfüllt die Pflicht nicht. Bewährt haben sich ein halber bis ganzer Tag zum Einstieg und eine jährliche Auffrischung, idealerweise ergänzt um eine Planspielübung zu einem realistischen Vorfall. Inhaltlich gehören dazu:

• Rechtsrahmen und persönliche Rolle der Geschäftsführung (§ 31 Abs. 1: sicherstellen und beaufsichtigen)
• Aktuelle Bedrohungslage mit Bezug zur eigenen Branche
• Die eigene Risikolage und die Ergebnisse der Risikoanalyse
• Wie man Risikomanagementmaßnahmen und Berichte des CISO kritisch bewertet
• Meldekette, Erheblichkeitsentscheidung und die eigene Rolle im Krisenfall
• Aufsichtsinstrumente und Sanktionen, einschließlich des vorübergehenden Tätigkeitsverbots für Leitungsorgane wesentlicher Einrichtungen (§ 39 Abs. 4 Z 2)

Zur Haftung ein Wort der Nüchternheit: Das NISG 2026 enthält keine eigene zivilrechtliche Haftungsnorm und keine Beweislastumkehr. Die Organhaftung richtet sich weiterhin nach § 25 GmbHG beziehungsweise § 84 AktG. Wer das Thema mit überzogenen Haftungsszenarien verkauft, schadet der Glaubwürdigkeit. Richtig ist aber: Wer im Schadensfall seine Sorgfalt belegen muss, braucht Dokumente.

Prüfpunkte

• Alle Mitglieder der Geschäftsführung namentlich erfasst, Schulungstermin festgelegt
• Teilnahmebestätigung mit Datum, Dauer, Vortragendem und Inhaltsübersicht
• Beschluss der Geschäftsführung über die Risikomanagementmaßnahmen protokolliert
• Berichtslinie des CISO an die Geschäftsführung mit festem Intervall
• Schulungsplan für Mitarbeiter mit Durchführungsnachweisen

4. Indirekte Betroffenheit über die Lieferkette

§ 32 Abs. 4 lit. d verlangt von betroffenen Einrichtungen Maßnahmen zur Sicherheit der Lieferkette, einschließlich der Beziehungen zu ihren unmittelbaren Anbietern und Dienstleistern. Art. 21 Abs. 3 NIS-2-RL präzisiert, dass dabei die spezifischen Schwachstellen jedes unmittelbaren Anbieters, die Qualität seiner Produkte und seine Cybersicherheitspraxis einschließlich sicherer Entwicklungsverfahren zu berücksichtigen sind.

Für Softwarehäuser, IT-Dienstleister und Zulieferer, die selbst nicht registrierungspflichtig sind, heißt das: Ab Oktober kommen die Fragebögen. Nicht weil das Gesetz sie verpflichtet, sondern weil ihre Kunden nachweisen müssen, dass sie ihre Lieferanten bewertet haben. Bei Softwareherstellern kommt lit. e hinzu, die Sicherheit bei Erwerb, Entwicklung und Wartung einschließlich Schwachstellenmanagement. Wer Software an eine erfasste Einrichtung liefert, wird nach Secure Development, Patchzyklen und dem Umgang mit gemeldeten Schwachstellen gefragt werden.

Aus Lieferantensicht lohnt es sich, die Fragebögen nicht einzeln zu beantworten, sondern ein Standardpaket vorzubereiten: eine strukturierte Selbstauskunft entlang § 32 Abs. 4 lit. a bis j, verfügbare Nachweise (ISO-27001-Zertifikat mit passendem Scope, Cyber Risk Rating, Pentest-Zusammenfassung) und eine vorformulierte Position zu Vertragsklauseln.

Zwei Argumente helfen bei überschießenden Anforderungen. Lit. d erfasst unmittelbare Anbieter, nicht die gesamte Tiefe der Lieferkette. Und der Verhältnismäßigkeitsgrundsatz des § 32 gilt auch für das, was ein Kunde von seinen Lieferanten verlangen muss. Anforderungen, die über die gesetzliche Pflicht des Auftraggebers hinausgehen, sind Verhandlungssache. Maßstab ist die Kritikalität des konkreten Dienstes, nicht die Größe des Lieferanten.

Für Softwarehäuser zusätzlich zu beachten: Der Cyber Resilience Act adressiert die Produkte, das NISG den Betrieb. Beide Regime laufen nebeneinander, mit unterschiedlichen Meldepflichten und Adressaten.

Prüfpunkte für Lieferanten

• Kundenliste auf NISG-betroffene Auftraggeber durchgesehen
• Standard-Selbstauskunft entlang § 32 Abs. 4 lit. a bis j vorbereitet
• Nachweise gesammelt und aktuell (Zertifikat, Rating, Berichte)
• Position zu Meldefristen, Auditrechten und Unterauftragnehmern festgelegt
• Eigene Meldefähigkeit gegenüber Kunden hergestellt, denn deren 24-Stunden-Frist hängt am Lieferanten

5. ISO 27001 als Abkürzung und ihre Grenzen

Ein zertifiziertes ISMS nach ISO/IEC 27001:2022 deckt den Maßnahmenkatalog des § 32 Abs. 4 weitgehend ab. Die Zuordnung ist gut nachvollziehbar: Risikoanalyse auf 6.1.2 und 6.1.3, Vorfallsbewältigung auf A.5.24 bis A.5.28, Betriebskontinuität auf A.5.29, A.5.30 und A.8.13, Lieferkette auf A.5.19 bis A.5.23, Wirksamkeitsbewertung auf 9.1 bis 9.3. Das Gesetz verlangt kein ISMS nach ISO 27001, aber es ist der pragmatischste Weg zur Nachweisfähigkeit. § 33 Abs. 2 lässt einschlägige Zertifikate ausdrücklich als Nachweis der operativen und organisatorischen Umsetzung zu.

Die Grenzen liegen an vier Stellen.

Der technische Nachweis. Ein Zertifikat belegt nach § 33 Abs. 2 nur den operativen und organisatorischen Teil. Die technische Umsetzung ist auf Aufforderung über einen Prüfbericht einer unabhängigen Stelle mit zugelassenen Prüfern nachzuweisen.

Die Durchführungsverordnung (EU) 2024/2690. Sie konkretisiert Art. 21 Abs. 2 NIS-2-RL, unmittelbar anwendbar ist sie auf digitale Infrastruktur, Verwaltung von IKT-Diensten (B2B) und Anbieter digitaler Dienste, also etwa Cloud- und Rechenzentrumsdienste, Managed Service und Managed Security Service Provider. Für andere Sektoren gilt sie nicht direkt. § 32 Abs. 5 NISG 2026 ermöglicht aber, solche Durchführungsakte sektorübergreifend anwendbar zu machen, und die Behörde wird sich beim Stand der Technik daran orientieren. Wer sie heute als Referenz für die Detailtiefe nutzt, liegt richtig. Wer sie als geltendes Recht für alle Sektoren darstellt, liegt falsch.

Die inhaltliche Tiefe. An mehreren Stellen ist die Verordnung konkreter als Annex A. Beispiele aus der Praxis:

• Multi-Faktor-Authentifizierung: Annex A verlangt sichere Authentifizierung (A.8.5), das NISG nennt in lit. j ausdrücklich Multi-Faktor- oder kontinuierliche Authentifizierung. Ausnahmen brauchen eine Begründung und kompensierende Maßnahmen.
• Gesicherte Notfallkommunikation: In vielen ISMS fehlt sie, weil die Kommunikationsmittel im Ernstfall Teil der kompromittierten Umgebung sind.
• Betriebskontinuität: Die Verordnung verlangt getestete Wiederherstellung und Krisenmanagement mit deutlich mehr Detail als A.5.29 und A.5.30. Ein Backup ohne dokumentierten Restore-Test ist kein Nachweis.
• Erheblichkeit: Für die erfassten Sektoren legt die Verordnung Schwellenwerte für erhebliche Vorfälle fest. ISO 27001 kennt nichts Vergleichbares. Für andere Sektoren taugen die Schwellen als Orientierung bei der eigenen Kriterienbildung.
• Überprüfungsintervalle: Die Verordnung nennt konkrete Intervalle für die Überprüfung von Richtlinien und Maßnahmen, wo ISO 27001 "geplante Abstände" genügen lässt.

Die Verfahrenspflichten. Registrierung, Meldung an das CSIRT, Selbstdeklaration und die Schulung der Leitungsorgane sind keine Controls, sondern eigenständige gesetzliche Pflichten. Sie gehören in die ISMS-Dokumentation, entstehen aber nicht automatisch aus ihr.

Prüfpunkte für ISMS-Betreiber

• Mapping § 32 Abs. 4 lit. a bis j auf Anwendbarkeitserklärung erstellt
• Scope gegen den Pflichtenkreis der gesamten Einrichtung abgeglichen
• MFA-Abdeckung je Systemklasse erhoben, Ausnahmen begründet
• Notfallkommunikation außerhalb der Produktivumgebung vorhanden und getestet
• Durchführungsverordnung (EU) 2024/2690 als Referenz in die Gap-Analyse einbezogen
• Verfahrenspflichten (Registrierung, Meldung, Selbstdeklaration, Leitungsschulung) als eigene Prozesse im ISMS verankert

Was in dieser Woche noch zu tun ist

Acht Tage reichen nicht für ein fertiges Sicherheitsprogramm, aber sie reichen für drei Dinge: Meldefähigkeit herstellen, den Ausgangsstand ehrlich dokumentieren und einen Maßnahmenplan von der Geschäftsführung beschließen lassen. Mehr erwartet am 1. Oktober niemand, der die Rechtslage kennt. Die Registrierung hat bis Jahresende Zeit, die Selbstdeklaration bis Herbst 2027. Für beide gilt: Eine ehrliche Darstellung mit Maßnahmenplan ist der bessere Weg als Beschönigung, denn § 45 Abs. 1 ahndet nicht umgesetzte Maßnahmen nur, soweit der Umstand der Behörde nicht allein aus der Selbstdeklaration bekannt wurde. Eine wissentlich falsche Angabe fällt dagegen unter § 45 Abs. 4.

Form und Kanal der Registrierung sowie Details der Selbstdeklaration werden per Verordnung festgelegt. Vor dem Stichtag lohnt ein Blick auf nis.gv.at.

Transparenzhinweis: Dieser Beitrag wurde unter Einsatz vonClaude Opus 5.5 erstellt, inhaltlich geprüft und redaktionell verantwortet von Michael Mrak, Mrak Consulting e.U.