NIS2 lässt sich leicht als IT-Sicherheitsthema lesen. Dann geht es um Richtlinien, technische Maßnahmen, Meldestrukturen, Lieferkettensicherheit und Registrierungsfragen. All das ist wichtig. Für Stadtwerke reicht diese Sicht aber nicht aus.
Der eigentliche Reifegradtest beginnt dort, wo Cybersicherheit in den Fachprozessen ankommt: in Marktkommunikation, Netzbetrieb, Messstellenbetrieb, Lieferantensteuerung, Kundenservice, Abrechnung, Leitstelle, Krisenstab und Geschäftsleitung. Denn Sicherheitsvorfälle betreffen nicht nur Systeme. Sie betreffen die Fähigkeit, regulierte Energieprozesse trotz Störung zu verstehen, zu entscheiden und nachvollziehbar weiterzuführen.
Die EU-NIS2-Richtlinie spricht in Artikel 21 von technischen, operativen und organisatorischen Maßnahmen. Genau dieses Dreieck ist für Stadtwerke entscheidend. Technische Schutzmaßnahmen bleiben wirkungslos, wenn die Organisation nicht weiß, welche Fachprozesse kritisch sind. Organisatorische Vorgaben bleiben abstrakt, wenn sie nicht an echten Datenflüssen, Rollen und Störungsroutinen hängen. Operative Maßnahmen greifen zu spät, wenn sie nur im IT-Handbuch stehen.
Energie ist kein beliebiger Sektor
Die NIS2-Richtlinie nennt Energie in Anhang I als Sektor hoher Kritikalität. Dazu gehören in der europäischen Systematik unter anderem Elektrizitätsunternehmen, Verteilernetzbetreiber, Übertragungsnetzbetreiber, Erzeuger, bestimmte Strommarktakteure, Ladepunktbetreiber sowie Fernwärme und Fernkälte.
Für Stadtwerke heißt das nicht automatisch, dass jeder Betrieb in jeder Rolle gleich betroffen ist oder dieselben Pflichten trägt. Eine solche Einordnung kann nur anhand der konkreten Unternehmensrolle, Größe, Tätigkeiten, nationalen Umsetzung und einschlägigen Behördeninformationen geprüft werden. Der Punkt für die Praxis ist trotzdem klar: Energieversorgung, Netzbetrieb und energiewirtschaftliche Datenflüsse sind Teil einer kritischen Infrastruktur-Logik. Cybersicherheit wird damit zur Führungs- und Betriebsfrage.
Das BSI stellt mit der NIS-2-Betroffenheitsprüfung, Registrierungsinformationen und der #nis2know-Roadmap öffentliche Orientierung bereit. Schon die Struktur dieser Roadmap zeigt: Es geht nicht nur um ein einzelnes technisches Projekt, sondern um Analyse, Verantwortung, Ist-Zustand, Risikobewertung, Ressourcen, Umsetzung und Verstetigung.
Der Übersetzungsfehler: IT-Maßnahme ohne Fachprozess
Viele Organisationen beginnen bei Cybersicherheit mit naheliegenden Fragen:
- Welche Systeme müssen gehärtet werden?
- Welche Zugänge brauchen Mehrfaktor-Authentifizierung?
- Welche Backups sind vorhanden?
- Welche Dienstleister müssen geprüft werden?
- Welche Meldewege gelten bei einem Sicherheitsvorfall?
Diese Fragen sind richtig. Sie werden aber erst belastbar, wenn sie mit Fachprozessen verbunden sind. Ein Stadtwerk muss nicht nur wissen, ob ein System abgesichert ist. Es muss wissen, welcher energiewirtschaftliche Prozess ausfällt oder verfälscht wird, wenn dieses System nicht verfügbar, nicht vertrauenswürdig oder nur eingeschränkt nutzbar ist.
Beispiele:
- Wenn Marktkommunikation gestört ist, welche Wechsel-, Bilanzierungs- oder Stammdatenprozesse laufen weiter, welche nicht?
- Wenn Messdaten nicht plausibel eingehen, wer entscheidet über Ersatzwerte, Kundenkommunikation und Abrechnungsauswirkungen?
- Wenn eine Dienstleisterplattform ausfällt, welche Fachrollen erkennen das zuerst und welche Ausweichroutine ist dokumentiert?
- Wenn ein Netzbetriebs- oder Leitstellenprozess digital eingeschränkt ist, welche Entscheidungen können noch sicher getroffen werden?
- Wenn ein Sicherheitsvorfall gemeldet werden muss, welche fachlichen Auswirkungen sind bereits belegbar und wer darf sie freigeben?
Ohne diese Übersetzung bleibt NIS2 eine Compliance-Schicht neben dem Tagesgeschäft. Mit ihr wird NIS2 zu einem Betriebsmodell für Resilienz.
Marktkommunikation: Sicherheitsvorfall oder Prozessstörung?
Marktkommunikation ist ein gutes Beispiel für die neue Nähe von Cybersecurity und Fachprozess. Aus technischer Sicht geht es um Schnittstellen, Gateways, Nachrichtenformate, Zertifikate, Identitäten und Systemverfügbarkeit. Aus fachlicher Sicht geht es um Lieferantenwechsel, Stammdatenänderungen, Bilanzierung, Klärfälle, Fristen und Kundenstatus.
Ein Vorfall kann deshalb mehrere Gesichter haben. Eine technische Störung kann zunächst wie ein normaler MaKo-Fehler wirken. Ein Datenqualitätsproblem kann durch eine Schnittstellenstörung verschärft werden. Ein Dienstleisterausfall kann fachlich erst sichtbar werden, wenn Vorgänge fehlen, Statusmeldungen nicht eintreffen oder Klärfälle anwachsen.
Für den NIS2-Kontext reicht es nicht, diese Ereignisse getrennt zu betrachten. Stadtwerke brauchen ein gemeinsames Lagebild:
- Welche MaKo-Prozesse sind geschäfts- und versorgungskritisch?
- Welche Systeme und Dienstleister tragen diese Prozesse?
- Welche Fehlerbilder deuten auf einen Sicherheits- oder Integritätsvorfall hin?
- Welche Fachkennzahlen zeigen, dass ein technisches Problem betriebliche Wirkung entfaltet?
- Welche Informationen benötigt IT-Sicherheit, um die Lage korrekt einzuordnen?
- Welche Informationen benötigt der Fachbereich, um Kunden, Marktpartner und interne Entscheider nicht falsch zu informieren?
Die entscheidende Schnittstelle liegt also nicht nur zwischen Systemen. Sie liegt zwischen IT-Sicherheitslage und fachlicher Prozesslage.
Netzbetrieb und Leitstelle: Verfügbarkeit ist nur ein Teil der Wahrheit
Im Netzbetrieb wird Cybersicherheit häufig mit Verfügbarkeit verbunden. Das ist naheliegend: Systeme müssen funktionieren, Kommunikation muss stehen, Entscheidungsroutinen müssen auch im Störfall greifen.
Für die Praxis kommt ein zweiter Punkt hinzu: Vertrauenswürdigkeit. Wenn Daten, Meldungen oder Zustände nicht belastbar sind, reicht reine Verfügbarkeit nicht aus. Ein System kann erreichbar sein und trotzdem fachlich fragwürdig liefern. Umgekehrt kann ein System teilweise ausfallen, während der Betrieb mit bekannten Ersatzroutinen weiter steuerbar bleibt.
Daraus ergeben sich konkrete Fachfragen:
- Welche Netz- und Betriebsdaten sind für Entscheidungen zwingend, welche nur unterstützend?
- Welche Zustände müssen bei eingeschränkter Datenlage manuell plausibilisiert werden?
- Welche Rollen dürfen im Ereignisfall priorisieren, abschalten, wieder zuschalten oder eskalieren?
- Welche Kommunikationswege funktionieren, wenn zentrale digitale Kanäle gestört sind?
- Welche Nachweise werden benötigt, um Entscheidungen später erklären zu können?
NIS2 wird hier nicht dadurch greifbar, dass ein weiterer Maßnahmenkatalog abgearbeitet wird. Greifbar wird es, wenn Netzbetrieb, IT-Sicherheit und Krisenorganisation dieselben Ereignisfragen nutzen.
Messstellenbetrieb: Datenfluss, Steuerbarkeit und Nachvollziehbarkeit
Der Messstellenbetrieb verbindet technische Infrastruktur, Kundenschnittstelle, Marktrollen und Abrechnung. Damit ist er ein natürlicher Berührungspunkt für NIS2/KRITIS-Denken.
Besonders relevant sind drei Fragen:
- Datenfluss: Welche Messwerte, Stammdaten und Statusinformationen müssen wann und in welcher Qualität verfügbar sein?
- Steuerbarkeit: Welche Prozesse hängen an Steuerboxen, intelligenten Messsystemen, CLS-Kommunikation oder weiteren technischen Komponenten?
- Nachvollziehbarkeit: Wer kann später belegen, ob ein Wert, eine Steuerhandlung oder eine Systemmeldung korrekt, verzögert, ersetzt oder gestört war?
Diese Fragen sind nicht nur technisch. Sie berühren Kundenkommunikation, Abrechnung, Netzsteuerung, Dienstleisterverträge und interne Verantwortlichkeiten. Deshalb sollte Messstellenbetrieb nicht am Rand eines NIS2-Projekts stehen, sondern als eigener Fachprozess mit klaren Kontrollen betrachtet werden.
Lieferkette: Dienstleistersteuerung statt Zertifikatsablage
NIS2 betont auch die Sicherheit der Lieferkette. Für Stadtwerke ist das besonders relevant, weil viele energiewirtschaftliche Prozesse über Rechenzentren, IT-Dienstleister, Abrechnungspartner, Messdienstleister, Gateway-Administratoren, Softwareanbieter oder spezialisierte Plattformen laufen.
Die Gefahr liegt darin, Lieferkettensicherheit auf Dokumentenprüfung zu reduzieren: Zertifikat liegt vor, Vertrag ist abgelegt, Ansprechpartner ist bekannt. Das ist ein Anfang, aber noch keine operative Steuerbarkeit.
Für Fachprozesse braucht es zusätzlich:
- Welche Dienstleister sind für welche kritischen Prozessschritte verantwortlich?
- Welche Reaktionszeiten gelten bei Störung, Sicherheitsverdacht oder Datenintegritätsproblem?
- Welche Mindestinformationen muss der Dienstleister im Vorfall liefern?
- Welche Ausweichprozesse sind realistisch und geübt?
- Welche Fachbereiche müssen eingebunden werden, wenn ein Dienstleistervorfall regulatorische oder kundenseitige Auswirkungen hat?
- Welche Nachweise sind für Geschäftsleitung, Aufsicht, Audit oder Behörde nachvollziehbar?
Eine gute Lieferantenakte beantwortet deshalb nicht nur „Ist der Dienstleister geprüft?“. Sie beantwortet „Kann der Fachprozess bei einem Dienstleisterproblem geführt werden?“.
Incident-Kommunikation: Erst verstehen, dann melden und erklären
Sicherheitsvorfälle erzeugen Zeitdruck. Gleichzeitig sind vorschnelle Aussagen gefährlich. Gerade in der Energiewirtschaft müssen technische Lage, fachliche Wirkung, Kundenbezug, Marktpartnerwirkung und mögliche Meldepflichten sauber auseinandergehalten werden.
Ein hilfreiches Betriebsmodell unterscheidet vier Ebenen:
- Technische Lage: Welche Systeme, Zugänge, Daten oder Schnittstellen sind betroffen?
- Fachliche Wirkung: Welche Prozesse, Kunden, Marktrollen oder Betriebsentscheidungen sind betroffen?
- Externe Kommunikation: Was kann gegenüber Kunden, Marktpartnern, Dienstleistern, Behörden oder Öffentlichkeit belastbar gesagt werden?
- Nachweis und Lernen: Welche Entscheidungen, Zeiten, Datenstände und Maßnahmen werden dokumentiert?
Diese Ebenen sollten nicht erst im Ernstfall zusammengeführt werden. Sie gehören in Übungen, Bereitschaftsmodelle und Eskalationspläne. Ein IT-Sicherheitsvorfall wird sonst schnell zu einem Kommunikationsproblem, weil niemand sicher sagen kann, welche fachliche Bedeutung die technische Störung hat.
Ein Kontrollbild für Stadtwerke
Für die Übersetzung von NIS2 in Fachprozesse kann ein kompaktes Kontrollbild helfen. Es ersetzt keine Rechtsprüfung und keinen vollständigen ISMS-/KRITIS-Prozess. Es macht aber sichtbar, wo IT-Sicherheit und Fachbereich zusammenarbeiten müssen.
| Fachprozess | NIS2-/Cyber-Frage | Fachliche Leitfrage | Nachweis im Alltag |
|---|---|---|---|
| Marktkommunikation | Integrität und Verfügbarkeit von Nachrichten, Identitäten und Schnittstellen | Welche Vorgänge sind fachlich betroffen, wenn Nachrichten fehlen, verzögert sind oder falsch verarbeitet werden? | Klärfallauswertung, Statusmonitoring, Rollenmatrix, Dienstleister-SLA |
| Netzbetrieb | Betriebsfähigkeit bei eingeschränkter System- oder Datenlage | Welche Entscheidungen bleiben belastbar, wenn Daten fehlen oder Kommunikationswege gestört sind? | Notfallroutinen, Übungsprotokolle, Lagebildschema, Entscheidungsdokumentation |
| Messstellenbetrieb | Datenfluss, Steuerbarkeit und Nachvollziehbarkeit | Welche Werte, Steuerinformationen und Zustände sind kritisch für Abrechnung, Netzbetrieb und Kundenkommunikation? | Datenqualitätsberichte, Ersatzwertlogik, Störungstagebuch, Verantwortlichenliste |
| Lieferantensteuerung | Lieferkettenrisiko und Dienstleisterreaktion | Welche Dienstleister tragen welche kritischen Prozessschritte und welche Mindestinformationen liefern sie im Vorfall? | Lieferantenakte, Kontaktmatrix, Reaktionszeiten, Vorfall-Reporting |
| Incident-Kommunikation | Melde- und Kommunikationsfähigkeit | Wer darf technische Lage, fachliche Wirkung und externe Aussage freigeben? | Meldecheckliste, Freigabepfad, Kommunikationsbausteine, Nachbereitung |
| Geschäftsleitung | Verantwortung und Priorisierung | Welche Cyberrisiken gefährden Versorgung, Marktrolle, Kundenvertrauen oder regulatorische Pflichten? | Risiko-Heatmap, Maßnahmenstatus, Entscheidungsprotokolle, Ressourcenplanung |
Der Nutzen eines solchen Rasters liegt in der gemeinsamen Sprache. IT-Sicherheit sieht, welche Fachwirkung ein Risiko hat. Fachbereiche sehen, warum eine Sicherheitsmaßnahme nicht nur „IT-Aufwand“ ist. Geschäftsleitung sieht, welche Entscheidungen priorisiert werden müssen.
Vom Projekt zur Betriebsroutine
Die größte Schwäche vieler Compliance-Projekte ist ihr Projektcharakter. Es gibt Workshops, Maßnahmenlisten, Verantwortliche und Abschlussfolien. Danach kehrt der Alltag zurück.
NIS2 verlangt jedoch eine andere Logik: Verstetigung. Risiken, Systeme, Dienstleister, Prozesse und Bedrohungslagen ändern sich. Neue Marktprozesse, neue Messkonzepte, neue Steuerungsanforderungen, neue Cloud- oder Dienstleistermodelle verändern das Kontrollbild.
Für Stadtwerke ist deshalb entscheidend, NIS2 nicht als einmalige Ertüchtigung zu führen, sondern als wiederkehrende Betriebsroutine:
- Quartalsweise Prüfung kritischer Fachprozesse und zugehöriger Systeme,
- regelmäßige Auswertung von Störungen, Klärfällen und Sicherheitsereignissen,
- gemeinsame Übungen von IT, Fachbereich, Krisenstab und Dienstleistern,
- Aktualisierung von Rollen, Kontakten und Eskalationswegen,
- Nachweis, welche Maßnahmen umgesetzt, geprüft oder bewusst priorisiert wurden,
- klare Geschäftsleitungsbefassung bei wesentlichen Risiken und Ressourcenkonflikten.
Diese Routine muss nicht überkomplex sein. Sie muss nur ernsthaft genug sein, um im Ereignisfall zu tragen.
Fazit: NIS2 wird dort wirksam, wo Fachprozesse steuerbar werden
NIS2 ist kein Thema, das Stadtwerke an IT-Sicherheit delegieren können. Die Richtlinie adressiert technische, operative und organisatorische Maßnahmen. Genau deshalb muss sie in die Fachprozesse übersetzt werden.
Für die Energiewirtschaft heißt das: Marktkommunikation, Netzbetrieb, Messstellenbetrieb, Dienstleistersteuerung und Incident-Kommunikation brauchen ein gemeinsames Kontrollbild. Nicht jedes Stadtwerk ist gleich betroffen, und nicht jede Pflicht lässt sich ohne Einzelfallprüfung bestimmen. Aber jedes Stadtwerk kann heute klären, welche Prozesse kritisch sind, welche Daten und Dienstleister sie tragen und welche Routinen im Störfall greifen.
Der praktische Fortschritt liegt nicht in der nächsten abstrakten Sicherheitsfolie. Er liegt in einfachen, prüfbaren Antworten auf operative Fragen: Was ist betroffen? Wer entscheidet? Welche Daten sind belastbar? Was sagen wir wem? Wie weisen wir es nach?
Erst wenn diese Fragen im Alltag beantwortet werden können, wird Cybersicherheit zu dem, was NIS2 in der Energiewirtschaft eigentlich verlangt: Teil der Betriebsfähigkeit.