Sicherheit ist kein
Zustand, sondern ein Betrieb.
Annex D beschreibt fünfzehn Angriffsflächen und ihre Verteidigung — konzeptionell. Was dort fehlt, ist die Betriebsebene: Wer testet, wer meldet, wer entscheidet um drei Uhr nachts, wer übt den Ernstfall. NIS-2 verlangt ab Oktober 2026 genau das. Dieses Annex beschreibt die operativen Verfahren, die eine Verwaltung braucht, um Sicherheit nicht zu behaupten, sondern nachzuweisen — mit zwölf überprüfbaren Anforderungen.
§ Y.0 · VorbemerkungKonzept und Betrieb.
Ein Sicherheitskonzept beschreibt, was gelten soll. Ein Sicherheitsbetrieb beweist, dass es gilt.
Zwischen beiden liegt die Lücke, in der die meisten dokumentierten Vorfälle stattfinden. Kaum eine betroffene Stelle hatte kein Sicherheitskonzept. Was fehlte, war regelmäßig eines von vier Dingen: ein funktionierender Meldeweg für gefundene Schwachstellen, eine geübte Reaktion, eine aktuelle Übersicht über eingesetzte Komponenten, oder jemand, der außerhalb der Bürozeiten entscheiden durfte.
Dieses Annex behandelt deshalb nicht Schutzziele, sondern Verfahren. Es fragt bei jedem Punkt: Wer tut was, in welcher Frist, mit welcher Befugnis, und woran erkennt man von außen, dass es geschieht.
Die Anschlussstellen im Korpus: Annex D liefert die Bedrohungsanalyse, Annex F die Architektur, Annex U § U.6 die Beweisbarkeits-Werkzeuge (reproduzierbare Builds, Software-Stückliste), Annex R den Rechtsrahmen der EU-Pflichten. Annex Y verbindet sie zur Betriebsordnung.
§ Y.1 · NIS-2 im VollzugWas ab Oktober 2026 gilt.
Die Richtlinie (EU) 2022/2555 (NIS-2) erweitert den Kreis der verpflichteten Einrichtungen erheblich und verschärft die Anforderungen. Für die öffentliche Verwaltung sind vier Punkte betrieblich entscheidend.
| Pflichtenbereich | Was das betrieblich bedeutet |
|---|---|
| Risikomanagement | Dokumentierte Maßnahmen, regelmäßig überprüft — nicht ein Konzept, sondern ein wiederkehrender Zyklus mit Nachweis |
| Meldepflichten | Gestufte Meldung erheblicher Vorfälle an die zuständige Stelle mit engen Fristen; erfordert eine erreichbare Meldestelle rund um die Uhr |
| Lieferkette | Sicherheitsanforderungen gelten auch gegenüber Dienstleistern und deren Vorlieferanten |
| Leitungsverantwortung | Die Leitungsebene ist für die Einhaltung verantwortlich und muss geschult sein; die Verantwortung ist nicht vollständig delegierbar |
Der letzte Punkt verbindet Annex Y unmittelbar mit dem Haftungsstrang des Korpus. NIS-2 verankert eine Leitungsverantwortung, die sich nicht durch Beauftragung eines Dienstleisters auflöst. Das ist genau die Richtung, die Annex H und das Arbeitspapier FORSCH-PROV0443 mit Z7 für die Zurechnung fordern — hier bereits geltendes Unionsrecht, wenn auch für einen anderen Regelungszweck.
NIS-2 löst das Zurechnungsproblem nicht, aber es zeigt, dass der Gesetzgeber Leitungsverantwortung für IT-Systeme bereits anordnen kann, wenn er will.
Die praktische Hürde für Gemeinden
Für eine Gemeinde mit 15.000 bis 25.000 Einwohnern — die Größenordnung des Pilots aus Annex J — sind diese Pflichten mit eigenem Personal nicht erfüllbar. Weder ist eine Rund-um-die-Uhr-Meldestelle darstellbar noch eine fortlaufende Lieferkettenprüfung.
Daraus folgt kein Ausnahmewunsch, sondern eine Organisationsentscheidung: Diese Funktionen gehören auf eine überörtliche Ebene, die sie für viele Stellen gemeinsam erbringt. Die naheliegende Bauform ist dieselbe wie in Annex W § W.7 für die Softwarepflege beschrieben — eine gemeinsam getragene Einrichtung mit eigenem Budget und klarer Verantwortung.
§ Y.2 · Schwachstellen findenTests und ihre Grenzen.
| Prüfform | Was sie leistet | Was sie nicht leistet | Turnus |
|---|---|---|---|
| Schwachstellen-Scan | findet bekannte Schwachstellen in eingesetzten Versionen | keine Logikfehler, keine Fehlkonfiguration von Berechtigungen | fortlaufend, automatisiert |
| Penetrationstest | prüft Ausnutzbarkeit in Kombination, findet Berechtigungs- und Logikfehler | Momentaufnahme; gilt nur für den getesteten Stand | jährlich und vor größeren Änderungen |
| Code-Prüfung | findet Fehler vor dem Betrieb, auch solche ohne bekannte Signatur | aufwendig, erfordert Zugang zum Quelltext | bei Entwicklung, bei Freigabe |
| Rote Übung | prüft Erkennung und Reaktion, nicht nur die Technik | teuer, erfordert Vorbereitung und Abstimmung | alle zwei bis drei Jahre |
Die entscheidende Einschränkung gilt für alle vier: Ein Test beweist die Abwesenheit gefundener Fehler, nicht die Abwesenheit von Fehlern. Ein Prüfbericht ohne Befunde ist deshalb kein gutes Zeichen, sondern ein Anlass, Umfang und Tiefe des Tests zu hinterfragen.
Der Test, der nichts prüfen darf
Ein wiederkehrendes Muster in öffentlichen Ausschreibungen: Penetrationstests werden mit engem Prüfumfang, kurzer Laufzeit und ohne Zugang zu Quelltext oder Dokumentation vergeben. Das Ergebnis ist ein Bericht, der formal die Pflicht erfüllt und inhaltlich wenig aussagt.
Der Test wird dann zur Nachweisproduktion statt zur Fehlersuche. Das ist teurer als kein Test, weil er zusätzlich Sicherheit suggeriert.
§ Y.3 · Schwachstellen meldenCVD und Bug-Bounty.
Die häufigste Art, wie eine Behörde von einer Schwachstelle erfährt, ist ein Hinweis von außen. Die zweithäufigste ist der Angriff.
Coordinated Vulnerability Disclosure (CVD) bezeichnet ein geordnetes Verfahren: Wer eine Schwachstelle findet, meldet sie an eine benannte Stelle; diese bestätigt den Eingang, behebt innerhalb einer vereinbarten Frist und veröffentlicht danach. Die Meldenden verzichten auf vorzeitige Veröffentlichung, die Stelle verzichtet auf rechtliche Schritte gegen gutgläubige Meldungen.
Warum Behörden das oft nicht haben
Drei Hindernisse treten regelmäßig auf. Erstens fehlt eine benannte Kontaktstelle — Meldungen laufen an eine allgemeine Adresse und versanden. Zweitens besteht Unsicherheit über die Rechtslage: Wer ein System testet, um eine Schwachstelle zu belegen, bewegt sich ohne ausdrückliche Erlaubnis in einem Graubereich. Drittens fehlt eine Zusage, dass gutgläubige Meldende nicht angezeigt werden.
Das dritte Hindernis ist das schwerwiegendste. Solange die Möglichkeit einer Strafanzeige im Raum steht, melden Findende entweder gar nicht oder anonym — und anonyme Meldungen sind schwerer zu verifizieren und nachzuverfolgen.
Safe-Harbour-Zusage als Teil der Meldestelle
Eine behördliche CVD-Regelung sollte ausdrücklich festhalten: Wer eine Schwachstelle nach den veröffentlichten Regeln meldet, ohne Daten abzuziehen, zu verändern oder zu veröffentlichen, wird von der betroffenen Stelle nicht angezeigt und nicht zivilrechtlich belangt.
Eine solche Zusage kann die materielle Rechtslage nicht ändern — Strafbarkeit richtet sich nach dem Gesetz, nicht nach der Erklärung einer Behörde. Sie beseitigt aber das praktisch entscheidende Risiko, weil die betroffene Stelle in der Regel die Anzeigeerstatterin wäre.
Bug-Bounty
Ein Bug-Bounty-Programm ergänzt CVD um eine Vergütung. Für die Verwaltung sprechen zwei Argumente dafür und zwei dagegen.
| Dafür | Dagegen |
|---|---|
| Bezahlung nach Befund statt nach Aufwand — Kosten entstehen nur bei Ergebnis | Haushaltsrecht ist auf Leistungsverträge ausgelegt, nicht auf Prämien an Unbekannte |
| erreicht Prüferinnen und Prüfer, die kein Dienstleister beschäftigt | erzeugt Bearbeitungslast: jede Meldung muss bewertet werden, auch die unbrauchbaren |
Die pragmatische Reihenfolge lautet deshalb: zuerst CVD mit Safe-Harbour, weil das nichts kostet und die Grundlage schafft. Bug-Bounty erst, wenn die Bearbeitungskapazität für Meldungen nachweislich besteht — sonst entsteht ein Programm, das Meldungen einwirbt und nicht bearbeitet.
§ Y.4 · VorfallsbearbeitungDie ersten 72 Stunden.
Die gestuften Meldefristen aus NIS-2 geben die Taktung vor. Betrieblich zerfällt die Bearbeitung in fünf Phasen mit jeweils eigener Entscheidungsfrage.
| Phase | Leitfrage | Wer entscheidet |
|---|---|---|
| 1 · Erkennen | Ist das ein Vorfall oder eine Störung? | Bereitschaft, nach dokumentierten Kriterien |
| 2 · Eindämmen | Abschalten oder weiterlaufen lassen? | benannte Person mit Abschaltbefugnis |
| 3 · Melden | Ist die Meldeschwelle erreicht? | Meldeverantwortliche, nach Kriterienkatalog |
| 4 · Beheben | Ursache oder Symptom? | Fachverantwortung mit Zeitbudget |
| 5 · Aufarbeiten | Was ändert sich strukturell? | Leitung, mit Veröffentlichungspflicht |
Die Abschaltbefugnis ist der kritische Punkt
In Phase 2 entscheidet sich, ob ein Vorfall begrenzt bleibt. Die Entscheidung muss oft innerhalb von Minuten fallen und hat erhebliche Folgen — ein abgeschaltetes Fachverfahren bedeutet, dass Menschen an diesem Tag keine Leistung bekommen.
Wenn diese Befugnis nicht vorab und namentlich zugewiesen ist, geschieht regelmäßig eines von zwei Dingen: Es wird zu spät abgeschaltet, weil niemand sich zuständig fühlt, oder es wird nicht abgeschaltet, weil die Rückfrage beim Vorgesetzten bis zum nächsten Morgen dauert.
Namentliche Abschaltbefugnis mit Rückendeckung
Für jedes Fachverfahren ist namentlich festzulegen, wer es abschalten darf, mit Vertretungsregelung und Erreichbarkeit außerhalb der Dienstzeit. Dazu gehört die ausdrückliche Feststellung, dass eine nachträglich als unnötig erkannte Abschaltung keine dienstrechtlichen Folgen hat.
Ohne diese zweite Hälfte wirkt die erste nicht. Wer für eine Fehlabschaltung belangt werden kann, für eine unterlassene aber nicht, wird im Zweifel nicht abschalten.
Aufarbeitung ohne Schuldzuweisung
Phase 5 entscheidet, ob aus einem Vorfall gelernt wird. Die in der Betriebspraxis bewährte Form ist die schuldfreie Nachbetrachtung: Es wird rekonstruiert, welche Bedingungen den Fehler ermöglicht haben, nicht wer ihn gemacht hat. Wo Aufarbeitung zur Schuldsuche wird, endet die Meldebereitschaft.
Das steht nur scheinbar im Widerspruch zur Haftungsforderung des Korpus. Annex H und Z7 zielen auf die Leitungsebene bei fortgesetztem Systemversagen, nicht auf die Person, die einen Fehler gemeldet hat. Die Unterscheidung ist zentral und muss in jeder Betriebsordnung ausdrücklich stehen.
§ Y.5 · Ransomware bei GemeindenDie reale Bedrohungslage.
Kommunale Verwaltungen sind in Europa seit Jahren regelmäßig von Verschlüsselungsangriffen betroffen. Das Muster ist über die dokumentierten Fälle hinweg ähnlich:
- Einstieg über Phishing, ein exponiertes Fernzugangssystem oder eine veraltete Komponente.
- Ausbreitung über flache Netzstrukturen und weitreichende Dienstkonten.
- Wirkung auf mehrere Fachverfahren gleichzeitig, weil sie dieselbe Infrastruktur teilen.
- Dauer von Wochen bis Monaten bis zur vollständigen Wiederherstellung.
- Folgeschaden vor allem durch Verfahrensstillstand, nicht durch das Lösegeld.
Für ein Konzept, das Verfahren digitalisiert, folgt daraus eine unbequeme Einsicht: Je mehr Verfahren digital laufen, desto größer ist die Wirkung eines Ausfalls. Das ist kein Argument gegen Digitalisierung, aber ein zwingendes Argument für drei Dinge.
Der dritte Punkt ist im Korpus bisher ausschließlich als Grundrecht begründet worden. Er hat eine zweite, davon unabhängige Rechtfertigung: Betriebssicherheit. Eine Verwaltung, die ein existenzrelevantes Verfahren nur noch digital abwickeln kann, hat im Ausfall keinen Notbetrieb. Das gehört in Annex C als zusätzliche Begründung und in Annex J als Bestandteil der Pilotkriterien.
§ Y.6 · LieferketteStückliste, Abhängigkeiten, Updatepflicht.
NIS-2 erstreckt die Sicherheitsanforderungen auf Dienstleister. Der Cyber Resilience Act verlangt für Produkte mit digitalen Elementen unter anderem Software-Stücklisten. Beides zusammen ergibt eine betriebliche Anforderung, die in der Beschaffung ansetzen muss.
| Frage | Nachweis | Ort |
|---|---|---|
| Woraus besteht die Software? | Software-Stückliste (SBOM), maschinenlesbar, bei jeder Lieferung aktualisiert | Vertragsbestandteil |
| Wie lange gibt es Sicherheitsupdates? | zugesagter Unterstützungszeitraum mit Enddatum | Vertragsbestandteil |
| Wie schnell werden Schwachstellen behoben? | Fristen nach Schweregrad, vertraglich vereinbart | Vertragsbestandteil |
| Was passiert, wenn der Anbieter ausfällt? | Hinterlegung des Quelltexts oder offene Lizenz | Vertragsbestandteil |
| Wer sind die Unterlieferanten? | Offenlegung wesentlicher Komponenten Dritter | Vertragsbestandteil |
Alle fünf Punkte sind vergaberechtlich zulässige Anforderungen und werden in der Praxis selten gestellt. Sie kosten in der Beschaffung nichts außer Sorgfalt und sind später nicht nachholbar.
Die Verbindung zu Annex U § U.1 ist direkt: Offener Quelltext beantwortet die Fragen eins, vier und fünf automatisch. Das ist kein ideologisches Argument für Open Source, sondern ein lieferkettenbezogenes.
§ Y.7 · ÜbenWarum Pläne ohne Übung nicht zählen.
Ein ungeübter Notfallplan ist ein Dokument über einen Notfallplan.
Drei Übungsformen mit unterschiedlichem Aufwand und Erkenntniswert:
| Form | Aufwand | Was sie aufdeckt | Turnus |
|---|---|---|---|
| Planbesprechung am Tisch | halber Tag, keine Technik | unklare Zuständigkeiten, fehlende Kontaktdaten, widersprüchliche Annahmen | halbjährlich |
| Wiederherstellungsübung | ein bis zwei Tage, Testumgebung | ob Datensicherungen tatsächlich zurückspielbar sind und wie lange es dauert | jährlich |
| Vollübung mit Ausfallszenario | mehrere Tage, Vorbereitung | Zusammenspiel von Technik, Organisation und Kommunikation unter Zeitdruck | alle zwei bis drei Jahre |
Die Planbesprechung hat das beste Verhältnis von Aufwand zu Erkenntnis und wird am seltensten gemacht. Sie deckt regelmäßig auf, dass die hinterlegten Rufnummern veraltet sind, dass zwei Stellen sich gegenseitig für zuständig halten, oder dass der Wiederanlaufplan eine Person voraussetzt, die nicht mehr im Haus ist.
Für den Pilot aus Annex J bedeutet das: Eine Planbesprechung gehört in die ersten drei Monate, eine Wiederherstellungsübung vor den Echtbetrieb. Beides ist mit dem vorgesehenen Budget darstellbar.
§ Y.8 · AnforderungenZwölf Punkte Y1 bis Y12.
| Nr. | Anforderung | Nachweis |
|---|---|---|
| Y1 | Benannte Meldestelle für Schwachstellen, öffentlich erreichbar | veröffentlichte Kontaktadresse und Verfahrensbeschreibung |
| Y2 | Safe-Harbour-Zusage für gutgläubige Meldungen | veröffentlichte Erklärung der betroffenen Stelle |
| Y3 | Eingangsbestätigung und Behebungsfrist nach Schweregrad | dokumentierte Fristen, Statistik über Einhaltung |
| Y4 | Namentliche Abschaltbefugnis je Fachverfahren, mit Vertretung und Erreichbarkeit | Dienstanweisung, halbjährlich aktualisiert |
| Y5 | Ausdrückliche Straffreistellung für nachträglich unnötige Abschaltungen | Bestandteil derselben Dienstanweisung |
| Y6 | Schuldfreie Aufarbeitung, getrennt von der Haftungsfrage der Leitungsebene | Verfahrensbeschreibung, veröffentlichte Berichte |
| Y7 | Netz- und Rechtetrennung zwischen Fachverfahren | Architekturdokumentation, Prüfbericht |
| Y8 | Wiederherstellung wird geübt, nicht angenommen | Protokoll der jährlichen Wiederherstellungsübung mit Zeitmessung |
| Y9 | Offline-Pfad auch als Rückfallebene im Ausfall ausgelegt | Notbetriebskonzept je existenzrelevantem Verfahren |
| Y10 | Software-Stückliste, Unterstützungszeitraum, Behebungsfristen und Quelltexthinterlegung als Vertragsbestandteil | Vertragsmuster, Vergabeunterlagen |
| Y11 | Prüfumfang und nicht geprüfte Bereiche im Testbericht ausgewiesen | Prüfbericht mit Umfangsabschnitt |
| Y12 | Planbesprechung halbjährlich, Vollübung alle zwei bis drei Jahre | Übungsprotokolle mit Feststellungen und Nachverfolgung |
Neun der zwölf Anforderungen kosten kein zusätzliches Budget, sondern eine Entscheidung und deren Dokumentation. Kostenrelevant sind Y7 (Architektur), Y8 (Übungsaufwand) und Y12 (Vollübung).
§ Y.9 · GrenzenWas dieses Annex nicht leistet.
Grenze 1 — keine technische Sicherheitsarchitektur
Dieses Annex beschreibt Verfahren, keine Schutzmaßnahmen. Es enthält keine Empfehlungen zu konkreten Produkten, Protokollen oder Konfigurationen. Dafür sind einschlägige technische Regelwerke heranzuziehen.
Grenze 2 — keine Rechtsberatung zur Meldepflicht
Die Darstellung der NIS-2-Pflichten ist eine Orientierung, keine Auslegung. Welche Einrichtung unter welche Kategorie fällt und welche Fristen konkret gelten, ist im Einzelfall nach dem Umsetzungsrecht zu beurteilen.
Grenze 3 — Safe-Harbour hat rechtliche Grenzen
Die in § Y.3 vorgeschlagene Zusage kann die Strafbarkeit nach materiellem Recht nicht beseitigen. Sie beseitigt das praktische Risiko, nicht das rechtliche. Eine belastbare Lösung erforderte eine gesetzliche Regelung, die hier nicht ausgearbeitet ist.
Grenze 4 — keine Vorfallsstatistik für Österreich
Die Beschreibung der Ransomware-Lage in § Y.5 beruht auf dem allgemein berichteten Muster, nicht auf einer eigenen Auswertung österreichischer Fälle. Eine belastbare Statistik kommunaler Vorfälle in Österreich ist nicht öffentlich verfügbar und wäre erhebenswert.
Grenze 5 — Bug-Bounty vergaberechtlich ungeprüft
Ob und wie ein Prämienprogramm mit dem österreichischen Haushalts- und Vergaberecht vereinbar ist, wurde hier nicht geprüft. Die in § Y.3 empfohlene Reihenfolge — erst CVD, dann Bounty — ist auch deshalb ratsam.
Grenze 6 — Zielkonflikt nur benannt, nicht gelöst
Zwischen der schuldfreien Aufarbeitung aus § Y.4 und der Haftungsforderung des Korpus besteht ein realer Zielkonflikt. Dieses Annex trennt beide nach Ebene (Meldende geschützt, Leitung verantwortlich). Ob diese Trennung in der Praxis hält, ist offen und wäre zu beobachten.