NISG 2026 und Ihre Software­lieferanten: wer was nachweisen muss

01Österreich im Herbst 2026: das NISG 2026 gilt

Die NIS-2-Richtlinie (öffnet externe Website) ist seit 16. Jänner 2023 in Kraft. Nach dem Zeitplan der Union hätten die Mitgliedstaaten ihre Umsetzung bis 17. Oktober 2024 beschließen und ab dem Folgetag anwenden sollen. Österreich hat diesen Termin nicht gehalten: Das Netz- und Informationssystemsicherheitsgesetz 2026 (öffnet externe Website), kundgemacht im BGBl. I Nr. 94/2025, ist mit 1. Oktober 2026 in Kraft getreten und hat das NISG 2018 abgelöst.

Mit demselben Tag hat das Bundesamt für Cybersicherheit (BCS) seine Arbeit aufgenommen. Es ist dem Bundesminister für Inneres unmittelbar nachgeordnet und die zuständige Behörde nach dem NISG 2026. Weil NIS-2 eine Richtlinie ist, bindet eine österreichische Einrichtung nicht der EU-Text, sondern dieses Gesetz. Wer auch Standorte oder Kunden in anderen Mitgliedstaaten hat, trifft dort auf eigene Gesetze, Behörden und Meldewege.

02Wesentliche und wichtige Einrichtungen

Die Richtlinie erfasst öffentliche und private Organisationen in den Sektoren ihres Anhangs I mit hoher Kritikalität (etwa Energie, Verkehr, Bankwesen, Finanzmarktinfrastrukturen, Gesundheit, Trink- und Abwasser, digitale Infrastruktur, Verwaltung von IKT-Diensten, öffentliche Verwaltung, Weltraum) und in den sonstigen kritischen Sektoren des Anhangs II (unter anderem Post- und Kurierdienste, Abfallbewirtschaftung, Chemie, Lebensmittel, verarbeitendes Gewerbe, digitale Anbieter, Forschung). In der Regel geht es um mittlere und große Organisationen; manche fallen unabhängig von ihrer Größe darunter, etwa Vertrauensdiensteanbieter, DNS-Diensteanbieter und Einrichtungen der Zentralregierung.

Für ein österreichisches Publikum heißt das: Netzbetreiber und Landesenergieversorger, Spitäler und Krankenanstalten-Träger, Banken, Verkehrsunternehmen und viele exportorientierte Industriebetriebe müssen prüfen, ob und wie sie erfasst sind. Bei der öffentlichen Verwaltung lässt die Richtlinie den Mitgliedstaaten Spielraum; maßgeblich ist, wie das NISG 2026 ihn nutzt.

• Wesentliche Einrichtungen: vor allem große Organisationen der Sektoren in Anhang I, dazu Einrichtungen, die unabhängig von ihrer Größe als wesentlich gelten. Die Aufsicht wird von sich aus tätig und kann Prüfungen und Kontrollen vor Ort umfassen.
• Wichtige Einrichtungen: alle übrigen erfassten Organisationen aus Anhang I und II. Hier setzt die Aufsicht nachträglich an, also erst dann, wenn es Hinweise auf Verstöße gibt.

Die Kernpflichten sind in beiden Gruppen gleich: Risikomanagement (Art. 21), Meldung von Vorfällen (Art. 23) und Verantwortung der Leitung (Art. 20). Unterschiede gibt es bei Aufsicht und Strafrahmen. Die Richtlinie verlangt, dass das nationale Recht für Verstöße gegen Art. 21 oder 23 Höchststrafen von mindestens 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes (wesentliche Einrichtungen) bzw. 7 Mio. Euro oder 1,4 % (wichtige Einrichtungen) vorsieht, jeweils der höhere Betrag. Ob und in welchem Umfang Geldbußen auch Stellen der öffentlichen Verwaltung treffen, entscheidet der Mitgliedstaat.

Fällt Ihr Softwarelieferant selbst unter das Gesetz?

Softwareentwicklung allein ist kein NIS-2-Sektor. Trotzdem kann ein Lieferant unmittelbar betroffen sein, denn Anhang I nennt Anbieter verwalteter Dienste und versteht darunter sehr viel: wer für Kunden IKT-Produkte, Netze, Infrastruktur oder Anwendungen installiert, verwaltet, betreibt oder wartet, ob vor Ort oder aus der Ferne. Ein mittleres oder größeres Softwarehaus, das Anwendungen seiner Kunden betreibt, kann also selbst eine Einrichtung im Sinn des Gesetzes sein, ebenso Cloud- und Rechenzentrumsanbieter. Für sie legt die Durchführungsverordnung (EU) 2024/2690 (öffnet externe Website) die technischen Anforderungen detailliert fest.

Häufiger erreicht das NISG 2026 den Lieferanten aber indirekt: Der Kunde muss seine Lieferkette absichern und reicht diese Pflicht über Vertragsklauseln, Fragebögen und Audits weiter. Für Softwareprodukte kommt der Cyber Resilience Act (öffnet externe Website) hinzu, die Verordnung (EU) 2024/2847. Seine Meldepflichten zu aktiv ausgenutzten Schwachstellen und schweren Vorfällen gelten seit 11. September 2026, die übrigen Pflichten ab 11. Dezember 2027.

03Zehn Mindest­maßnahmen nach Art. 21

Gefordert sind geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen nach einem gefahrenübergreifenden Ansatz. Sie orientieren sich am Stand der Technik und an einschlägigen europäischen und internationalen Normen und richten sich nach Risikoexposition, Größe der Einrichtung und der zu erwartenden Schwere von Vorfällen. Den Mindestumfang zählt die Richtlinie auf:

1. 01Konzepte für Risikoanalyse und Sicherheit der Informationssysteme;
2. 02Bewältigung von Sicherheitsvorfällen;
3. 03Aufrechterhaltung des Betriebs, also Backup-Management und Wiederherstellung nach einem Notfall, sowie Krisenmanagement;
4. 04Sicherheit der Lieferkette, einschließlich der Sicherheitsaspekte in den Beziehungen zu unmittelbaren Lieferanten und Diensteanbietern;
5. 05Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, samt Umgang mit Schwachstellen und deren Offenlegung;
6. 06Verfahren, mit denen die Wirksamkeit dieser Maßnahmen bewertet wird;
7. 07grundlegende Cyberhygiene und Schulungen zur Cybersicherheit;
8. 08Konzepte für Kryptografie und, wo sinnvoll, Verschlüsselung;
9. 09Personalsicherheit, Zugriffskontrolle und Verwaltung der Anlagen;
10. 10Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierung sowie, wo angebracht, gesicherte Sprach-, Video- und Textkommunikation und gesicherte Notfallkommunikation.

Für Lieferanten zählen vor allem die Punkte 4 und 5. Nach Art. 21 Abs. 3 berücksichtigt die Einrichtung die spezifischen Schwachstellen jedes unmittelbaren Lieferanten, die Qualität seiner Produkte und seiner Cybersicherheitspraxis und seine Verfahren für sichere Entwicklung. Ihr Auftraggeber schaut also darauf, wie Sie Software bauen, und nicht nur auf das Ergebnis.

04Die Geschäfts­leitung genehmigt, überwacht und haftet

Art. 20 verlangt, dass die Leitungsorgane wesentlicher und wichtiger Einrichtungen die Risikomanagementmaßnahmen genehmigen und ihre Umsetzung überwachen; für Verstöße können sie verantwortlich gemacht werden. Die Mitglieder der Leitung müssen Schulungen absolvieren, und auch für die Mitarbeitenden werden regelmäßige Schulungen empfohlen. Für öffentliche Stellen bleiben die nationalen Haftungsregeln für Behörden und Bedienstete unberührt.

Damit ändert sich das Gespräch mit dem Lieferanten. Ein Vorstand oder eine Geschäftsführung, die Maßnahmen genehmigen soll, will Belege, die sie nachvollziehen kann: welcher Lieferant welchen Dienst trägt, welche Risiken offen sind und was tatsächlich getestet wurde.

05Melde­pflichten: 24 Stunden, 72 Stunden, ein Monat

Erhebliche Sicherheitsvorfälle sind nach Art. 23 dem zuständigen CSIRT oder der Behörde zu melden; in Österreich regelt das NISG 2026, wohin und in welcher Form. Erheblich ist ein Vorfall, wenn er schwere Betriebsstörungen oder finanzielle Verluste für die Einrichtung verursacht hat oder verursachen kann, oder wenn er andere erheblich materiell oder immateriell schädigt. Die Meldung erfolgt in Stufen:

Wo es angebracht ist, informiert die Einrichtung zusätzlich die Empfänger ihrer Dienste unverzüglich über erhebliche Vorfälle, die diese Dienste beeinträchtigen können. Formulare und Meldewege legt das nationale Recht fest.

Die Frist beginnt, sobald die Einrichtung vom Vorfall weiß. Beginnt der Vorfall im System eines Lieferanten, schafft der Kunde die 24 Stunden nur, wenn der Lieferant ihn innerhalb weniger Stunden erkennt, einordnet und weitergibt. Erkennung, Protokollierung und ein vereinbarter Meldeweg sind deshalb Vertragsinhalt und keine reine Technikfrage.

06Was ein betroffener Kunde von seinem Software­lieferanten verlangt

In der Praxis wird Art. 21 zu einer Liste technischer Maßnahmen und Nachweise, die ein Lieferant vorlegen können sollte, ohne dafür erst ein Projekt aufzusetzen. Am häufigsten begegnen uns diese:

• Ein sicherer Entwicklungsprozess. Bedrohungsmodellierung bei größeren Änderungen, Code-Review durch Kolleginnen und Kollegen, automatisierte Sicherheitstests und Prüfung der Abhängigkeiten in der Pipeline, signierte Builds und eine Software-Stückliste (SBOM) je Release.
• Umgang mit Schwachstellen. Ein veröffentlichter Weg, Schwachstellen zu melden, nach Schweregrad vereinbarte Reaktionszeiten und eine Information an den Kunden, wenn seine Umgebung betroffen ist.
• Zugriffskontrolle für das Personal des Lieferanten. Persönliche Konten, Multi-Faktor-Authentifizierung, minimale Rechte, befristete erhöhte Berechtigungen und ein Protokoll jeder administrativen Handlung in der Umgebung des Kunden.
• Protokolle als Beweismittel. Sicherheitsrelevante Ereignisse mit verlässlichem Zeitstempel, für eine vereinbarte Dauer aufbewahrt und exportierbar, damit der Kunde die Fragen der Frühwarnung und des Abschlussberichts beantworten kann.
• Zusammenarbeit im Vorfall. Eine benannte Ansprechstelle und ein fixer Kanal, eine Meldezeit deutlich innerhalb der 24 Stunden des Kunden und Mitwirkung an der Ursachenanalyse.
• Betriebskontinuität und Wiederherstellung. Backups, deren Rücksicherung tatsächlich getestet ist, Wiederherstellungsziele, die zu denen des Kunden passen, und ein geübter Ablauf.
• Dokumentierte Lieferkette. Eine aktuelle Liste der Subunternehmer und Hosting-Standorte sowie der wichtigsten Fremdkomponenten und Dienste, von denen die Lösung abhängt.
• Ein Ausstiegsplan. Datenexport in brauchbaren Formaten, Dokumentation und Unterstützung bei der Übergabe, damit der Kunde den Lieferanten wechseln kann, ohne die Kontrolle über den Dienst zu verlieren.

Für reife Entwicklungsteams ist davon wenig neu. Neu ist, dass der Kunde es belegen können muss. Wie wir selbst als Lieferant arbeiten, einschließlich unseres nach ISO/IEC 27001 zertifizierten Informationssicherheits-Managementsystems, beschreiben wir unter Vertrauen und Compliance.

07Checkliste für Verträge und Vergabe­verfahren

1. 01Lieferanten den Diensten zuordnen. Halten Sie fest, welcher Lieferant welchen erfassten Dienst trägt und wer Zugriff auf Ihre Systeme oder Daten hat.
2. 02Nach Kritikalität einstufen. Die strengsten Anforderungen gelten für Lieferanten, die kritische Systeme betreiben oder verändern können.
3. 03Maßnahmen in den Vertrag schreiben. Sicherheitsanforderungen, Meldezeit und Meldeweg bei Vorfällen, Umgang mit Schwachstellen, Protokollierung und Aufbewahrung, Prüf- oder Nachweisrechte, Regeln für Subunternehmer und Standorte. Bei öffentlichen Auftraggebern gehört das bereits in die Ausschreibungsunterlagen nach dem BVergG 2018.
4. 04Belege statt Erklärungen verlangen. Zertifikate samt Geltungsbereich, Testergebnisse, eine SBOM, das Datum des letzten Wiederherstellungstests.
5. 05Den Ausstieg vorab regeln. Rückgabe der Daten, Unterstützung beim Übergang und wie lange der Lieferant den Dienst in dieser Zeit weiterbetreibt.
6. 06Gemeinsam üben. Spielen Sie mit Ihren kritischen Lieferanten einen Vorfall durch, inklusive der Frühwarnung nach 24 Stunden.
7. 07Regelmäßig überprüfen. Lieferanten, Dienste und Bedrohungen ändern sich; ein Lieferantenverzeichnis, das nur einmal im Jahr gepflegt wird, ist die meiste Zeit veraltet.

08Die Details stehen im NISG 2026

Registrierung, Meldewege, Formulare, Zuständigkeiten und allfällige zusätzliche Anforderungen ergeben sich aus dem nationalen Gesetz, in Österreich also aus dem NISG 2026 und den Vorgaben des BCS. Fristen für die Registrierung entnehmen Sie bitte direkt dem Gesetzestext. Grundsätzlich unterliegt eine Einrichtung dem Mitgliedstaat ihrer Niederlassung. Art. 26 NIS-2 kennt Ausnahmen: Anbieter öffentlicher elektronischer Kommunikationsdienste unterliegen jedem Staat, in dem sie Dienste erbringen; Cloud-, Rechenzentrums- und Managed-Service-Anbieter und mehrere weitere digitale Anbieter dem Staat ihrer Hauptniederlassung; Einrichtungen der öffentlichen Verwaltung dem Staat, der sie errichtet hat.

09Worauf Sie in den nächsten Monaten achten sollten

• Die Umsetzung des NISG 2026 in der Praxis: Registrierung, Verordnungen und die Informationen des BCS.
• Den Vorschlag der Kommission für einen digitalen Omnibus (öffnet externe Website), COM(2025) 837 vom 19. November 2025. Danach sollen Meldungen nach NIS-2, DSGVO, DORA und weiteren Rechtsakten über eine gemeinsame, von der ENISA betriebene Meldestelle laufen. Im Oktober 2026 war das Verfahren im Europäischen Parlament (öffnet externe Website)) noch offen; bis zur Annahme und Anwendung bleiben die bisherigen Kanäle und Fristen.
• Koordinierte Risikobewertungen kritischer IKT-Lieferketten auf EU-Ebene nach Art. 22, die Einrichtungen bei der Wahl ihrer Lieferantenmaßnahmen berücksichtigen müssen.
• Den Zeitplan des Cyber Resilience Act für Softwareprodukte bis zur vollen Anwendung am 11. Dezember 2027.

Banken, Versicherungen und andere Finanzunternehmen folgen beim IKT-Risikomanagement, bei Vorfallmeldungen und bei der Aufsicht dem Digital Operational Resilience Act statt der NIS-2-Regeln; in Österreich ist dafür die FMA zuständig. Mehr dazu in unserem Beitrag zu DORA und IKT-Drittdienstleistern. Einen Überblick über NIS-2 und die zugehörigen Durchführungsrechtsakte gibt die Kommission auf ihrer Themenseite zur NIS-2-Richtlinie (öffnet externe Website).