Seit 1. Oktober 2026 gilt in Österreich das Netz- und Informationssystemsicherheitsgesetz 2026, die nationale Umsetzung der europäischen NIS2-Richtlinie. Bei Wasserverbänden, Abwasserbetreibern und Stadtwerken ist das Thema damit in der täglichen Arbeit angekommen. Lieferanten werden nach Vereinbarungen zur Informationssicherheit gefragt, bestehende Systeme werden neu bewertet. In diesen Gesprächen begegnen uns immer wieder zwei Annahmen: Eine Cloud-Lösung sei unter NIS2 nicht mehr vertretbar, und Open-Source-Software sei ein Sicherheitsrisiko. Beides steht so nicht im Gesetz.
Was NIS2 für Leitungsbetreiber bedeutet
Trinkwasser, Abwasser und Energie einschließlich Fernwärme gehören zu den Sektoren mit hoher Kritikalität. Erfasst ist ein Betreiber, wenn er mindestens ein mittleres Unternehmen ist: ab 50 Beschäftigten oder mit mehr als zehn Millionen Euro Jahresumsatz und Bilanzsumme (§ 25 NISG 2026). Gemeinden und Gemeindeverbände sind zwar vom Sektor der öffentlichen Verwaltung ausgenommen (§ 24 Abs. 3). Das betrifft aber nur die Verwaltung. Wer als Stadtwerk, Verband oder kommunale Gesellschaft Wasser liefert oder Abwasser behandelt, wird über diesen Sektor beurteilt. Maßgeblich ist der Rechtsträger, der die Leistung erbringt. Ob eine Einrichtung im Einzelfall betroffen ist, beantwortet die [FAQ der Wirtschaftskammer](https://www.wko.at/it-sicherheit/nis-faq) gut nachvollziehbar.
Für betroffene Einrichtungen laufen jetzt die ersten Fristen. Die Registrierung bei der Cybersicherheitsbehörde muss innerhalb von drei Monaten erfolgen, also bis Ende 2026 (§ 29). Innerhalb von zwölf Monaten danach folgt eine Selbstdeklaration der umgesetzten Maßnahmen, ausdrücklich auch zur Sicherheit der Lieferkette (§ 33). Erhebliche Vorfälle sind binnen 24 Stunden als Frühwarnung und binnen 72 Stunden als Meldung an das zuständige CSIRT zu melden (§ 34). Die Verantwortung liegt bei der Leitung: Sie muss die Umsetzung sicherstellen, beaufsichtigen und selbst an Cybersicherheitsschulungen teilnehmen (§ 31).
Der Kern des Gesetzes ist § 32. Er verlangt geeignete und verhältnismäßige Maßnahmen, die dem Stand der Technik und dem tatsächlichen Risiko entsprechen. Dazu zählen unter anderem Backup und Wiederherstellung, die Bewältigung von Vorfällen, Zugriffskontrolle, Multi-Faktor-Authentifizierung und die Sicherheit der Lieferkette. Ein GIS mit dem Leitungskataster ist Teil dieser Netz- und Informationssysteme. Der Anbieter, der es betreibt, ist Teil der Lieferkette.
Was im Gesetz nicht steht
Das NISG 2026 schreibt keine bestimmte Technologie vor. Es enthält weder ein Verbot von Cloud-Diensten noch eine Einschränkung für Open-Source-Software. Es verlangt etwas Anspruchsvolleres.
Ein Betreiber muss wissen, welche Systeme er einsetzt, wo seine Daten liegen, wer darauf zugreift und wie im Ernstfall reagiert wird.
Eine Auslagerung entbindet dabei nicht von der Verantwortung. Ein Server im eigenen Haus ist deshalb nicht automatisch sicherer als ein professionell betriebenes Rechenzentrum. Entscheidend ist, ob Updates, Sicherungen und Zugriffe nachweisbar geregelt sind.
Cloud-Anbieter sind übrigens selbst Adressaten des Gesetzes. Anbieter von Cloud-Computing-Diensten und Rechenzentren zählen zum Sektor digitale Infrastruktur und unterliegen ab der entsprechenden Größe denselben Risikomanagement- und Meldepflichten wie ein Versorger.
Open Source: prüfbar statt versprochen
§ 32 nennt für die Lieferkette zwei Punkte, die bei der Auswahl von Software besonders schwer wiegen: die Sicherheit der Entwicklungsprozesse des Anbieters und den Umgang mit Schwachstellen, einschließlich ihrer Offenlegung. Bei geschlossener Software muss ein Betreiber hier den Zusicherungen des Herstellers vertrauen. Bei Open Source kann er selbst nachsehen oder nachsehen lassen. Quellcode, Fehlerberichte und Sicherheitshinweise sind öffentlich. Die NIS2-Richtlinie sieht das ausdrücklich positiv und fordert die Mitgliedstaaten auf, den Einsatz zu fördern, gerade für kleinere Einrichtungen.
Nach Erwägungsgrund 52 tragen Open-Source-Werkzeuge zu mehr Offenheit bei. Sie erleichtern laut Richtlinie die Interoperabilität und verringern die Abhängigkeit von einzelnen Anbietern.
Wie das in der Praxis aussieht, hat die Schweiz 2025 gezeigt. Das Bundesamt für Cybersicherheit ließ QGIS Server und den Web-Client QWC2 im Rahmen eines Pilotprojekts gezielt auf Schwachstellen testen. Gefunden wurden sechs Lücken, zwei davon mit hohem Schweregrad. Alle relevanten Lücken waren innerhalb der vereinbarten Frist von 90 Tagen behoben. Der [Testbericht](https://www.bacs.admin.ch/de/25-ntc-oss-de) ist öffentlich, das Projekt verweist auf seiner [Sicherheitsseite](https://qgis.org/resources/support/security) selbst darauf. Ein solches Verfahren lässt sich bei geschlossener Software von außen weder anstoßen noch nachvollziehen.
Open Source ist dabei kein Sicherheitsmerkmal an sich. Offener Code schützt nur, wenn jemand die Updates zeitnah einspielt, den Betrieb überwacht und Verantwortung übernimmt. Die Frage verschiebt sich damit von der Lizenz zum Betrieb.
Cloud: entscheidend ist, wessen Cloud
Die Frage ist nicht, ob Cloud. Die Frage ist, wessen Cloud und unter welchem Recht.
Ein Serverstandort in der EU allein beantwortet sie nicht vollständig. Mitte 2025 erklärte der Rechtsdirektor von Microsoft Frankreich unter Eid vor dem französischen Senat, er könne nicht garantieren, dass Daten französischer Kunden nicht an US-Behörden übermittelt werden ([heise](https://heise.de/-10494789)). Hintergrund ist der US CLOUD Act, der US-Unternehmen unabhängig vom Speicherort zur Herausgabe verpflichten kann.
Für einen Versorger heißt das: Er sollte wissen, welcher Rechtsordnung sein Anbieter und dessen Unterauftragnehmer unterliegen. Das ist eine Frage, die sich mit einem Blick in den Vertrag und die Liste der Unterauftragnehmer beantworten lässt.
Die richtigen Fragen an Ihren GIS-Anbieter
Statt „Cloud oder nicht?“ und „Open Source oder nicht?“ helfen bei der Bewertung eines GIS-Anbieters konkrete Fragen. Ein Anbieter, der seinen Betrieb im Griff hat, kann sie schriftlich beantworten:
- Standort und Recht: Wo stehen die Server, und welcher Rechtsordnung unterliegen Anbieter und Rechenzentrum?
- Unterauftragnehmer: Wer ist am Betrieb beteiligt, und sitzt jemand davon außerhalb des EWR?
- Updates: In welchem Rhythmus werden Sicherheitsupdates eingespielt, und wie schnell bei kritischen Lücken?
- Vorfälle: Wer informiert Sie bei einem Vorfall, und wie schnell? Ihre eigene Frühwarnung ist nach spätestens 24 Stunden fällig.
- Zugriff: Wer beim Anbieter hat Zugriff auf Ihre Daten, und wie sind die Zugänge abgesichert?
- Sicherung: Wie oft wird gesichert, und wurde die Wiederherstellung schon einmal geprüft?
- Transparenz: Ist der Quellcode einsehbar, und gibt es einen geregelten Umgang mit gemeldeten Schwachstellen?
- Vertragsende: In welchem Format bekommen Sie Ihre Daten zurück, und wann werden sie beim Anbieter gelöscht?
Die letzte Frage wird häufig unterschätzt. Liegen Leitungsdaten in offenen Formaten wie GeoPackage oder PostGIS, kann ein Betreiber den Anbieter wechseln, ohne seinen Bestand neu aufbauen zu müssen. Diese Wechselmöglichkeit ist selbst ein Beitrag zur Ausfallsicherheit, wie ihn auch die Richtlinie mit der geringeren Abhängigkeit von einzelnen Anbietern beschreibt.
Einordnung
NIS2 macht Cybersicherheit zur Leitungsaufgabe und die Lieferkette zum Prüfgegenstand. Für die Wahl der GIS-Architektur ist das eine gute Nachricht. Die Entscheidung fällt nicht mehr nach Etiketten wie „Cloud“ oder „Open Source“, sondern nach nachweisbarem Betrieb. Offene Software und offene Formate erleichtern diesen Nachweis, weil sich vieles prüfen lässt, statt es glauben zu müssen.
*Dieser Beitrag gibt einen allgemeinen Überblick und ersetzt keine Rechtsberatung. Maßgeblich ist der Gesetzestext im [Rechtsinformationssystem des Bundes](https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20013065).*
