Fuer Kritis: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Bei kritischen Infrastrukturen geht es nicht nur um Datenverlust, Erpressung oder den Ausfall einzelner Systeme. Es geht um Versorgung, Verfuegbarkeit, physische Prozesse, regulatorische Pflichten und oft um direkte Auswirkungen auf Bevoelkerung, Lieferketten oder medizinische Versorgung. Genau deshalb funktioniert die Betrachtung einer Cyberversicherung fuer KRITIS nicht nach dem Muster eines normalen Unternehmensvertrags.

In klassischen IT-Umgebungen steht haeufig der Schutz von Endpunkten, Mailkonten, Fileservern und Cloud-Diensten im Vordergrund. In KRITIS-Umgebungen kommen andere Faktoren dazu: Segmentierung zwischen Office-IT und Prozessnetzen, Fernwartungszugaenge von Dienstleistern, Altanlagen mit langen Lebenszyklen, proprietaere Protokolle, Safety-Abhaengigkeiten und die Frage, wie ein Versicherer einen Betriebsausfall bewertet, wenn nicht nur Umsatz, sondern Versorgungssicherheit betroffen ist. Wer hier nur auf Standardfragen antwortet, ohne die technische Realitaet sauber abzubilden, produziert spaeter Deckungsluecken.

Besonders relevant ist die Trennung zwischen IT-Risiko und OT-Risiko. Viele Policen sind historisch aus dem IT-Kontext entstanden. Sie decken Forensik, Wiederherstellung, Krisenkommunikation und Haftungsfolgen oft gut ab, aber bei Eingriffen in Produktions- oder Steuerungsumgebungen wird es schnell kompliziert. Das gilt vor allem dann, wenn SCADA, SPS, Historian-Systeme, Fernwirkkomponenten oder industrielle Gateways betroffen sind. Wer in solchen Umgebungen arbeitet, sollte die Unterschiede zwischen Fuer Ot Umgebungen, Fuer Scada und Fuer Kritische Infrastruktur nicht als Marketingbegriffe sehen, sondern als Hinweis darauf, dass Risikobewertung und Vertragspruefung deutlich tiefer gehen muessen.

Ein weiterer Punkt: KRITIS-Betreiber haben selten homogene Landschaften. Typisch sind gewachsene Netze, mehrere Standorte, externe Betriebsfuehrung, Mischbetrieb aus Legacy und modernen Plattformen, Cloud-Anbindungen fuer Reporting oder Wartung und parallel dazu regulatorische Anforderungen. Deshalb ist die eigentliche Herausforderung nicht nur der Abschluss, sondern die belastbare Uebersetzung technischer Realitaet in versicherbare Aussagen. Genau an dieser Stelle passieren die meisten Fehler.

Wer eine Police fuer KRITIS bewertet, sollte immer vier Ebenen gleichzeitig betrachten: technische Angriffsoberflaeche, betriebliche Kritikalitaet, vertragliche Obliegenheiten und realen Incident-Workflow. Erst wenn diese Ebenen zusammenpassen, ist die Deckung im Ernstfall belastbar. Alles andere fuehrt zu Diskussionen im Schadenfall, wenn Zeit, Beweise und Handlungsoptionen bereits knapp sind.

Der Antrag ist bei KRITIS kein Verwaltungsakt, sondern eine technische Risikoerklaerung. Jede ungenaue Antwort kann spaeter relevant werden. Versicherer fragen oft nach MFA, Backup, Patchmanagement, Netzwerksegmentierung, Endpoint-Schutz, Incident-Response-Faehigkeit und externen Dienstleistern. In KRITIS-Umgebungen reicht es aber nicht, diese Punkte pauschal mit ja zu beantworten. Entscheidend ist, wo genau die Massnahme gilt, wo Ausnahmen bestehen und wie diese dokumentiert sind.

Ein typischer Fehler ist die Vermischung von Office-IT und Betriebsnetz. Wenn MFA fuer Microsoft-365-Konten aktiv ist, bedeutet das noch lange nicht, dass privilegierte Zugaenge in Jump-Hosts, Fernwartungsportalen oder Engineering-Workstations gleichwertig abgesichert sind. Aehnlich problematisch ist die Aussage, dass Backups vorhanden sind. Fuer den Versicherer ist relevant, ob Konfigurationen von Firewalls, Hypervisoren, Domain Controllern, Historian-Systemen, Rezepturen, SPS-Projekten und zentralen Managementsystemen versioniert, offline oder unveraenderbar gesichert und innerhalb definierter Zeiten wiederherstellbar sind. Genau hier unterscheiden sich robuste Umgebungen von Umgebungen mit Scheinsicherheit.

In der Praxis sollten Antragsangaben immer mit internen Nachweisen hinterlegt werden. Dazu gehoeren Architekturdiagramme, Asset-Listen, Backup-Matrizen, Nachweise zu MFA-Rollout, Patchzyklen, Dienstleisterzugriffen und Incident-Runbooks. Wer diese Unterlagen nicht hat, sollte vor Antragstellung eine technische Bestandsaufnahme durchfuehren. Hilfreich sind dabei Themen wie Voraussetzungen, Sicherheitsanforderungen und Risikoanalyse, weil sie die Fragen strukturieren, die ein Versicherer spaeter ohnehin stellt.

• Jede Antwort im Antrag muss einem konkreten Geltungsbereich zugeordnet sein: gesamte Organisation, nur Office-IT, nur bestimmte Standorte oder nur einzelne Zonen.
• Jede Sicherheitsmassnahme braucht einen Nachweis: Richtlinie, technische Konfiguration, Monitoring oder Testprotokoll.
• Jede bekannte Ausnahme muss dokumentiert und mit Kompensationsmassnahmen versehen sein.

Besonders kritisch sind Aussagen zu Altanlagen. Viele KRITIS-Betreiber haben Systeme, die nicht kurzfristig patchbar sind oder deren Hersteller nur eingeschraenkte Security-Optionen bieten. Solche Systeme muessen nicht automatisch zum Ausschluss fuehren, aber sie duerfen nicht verschwiegen werden. Versicherer akzeptieren eher ein transparent beschriebenes Restrisiko mit Segmentierung, Monitoring und kontrolliertem Zugriff als eine unrealistische Vollschutzbehauptung, die im Incident sofort widerlegt wird.

Auch externe Betriebsfuehrung und Lieferketten gehoeren in den Antrag. Wenn Dienstleister privilegierte Zugaenge besitzen, Fernwartung ueber VPN oder Herstellerportale erfolgt oder kritische Komponenten nur durch Dritte administriert werden, ist das ein zentrales Risiko. Gerade bei KRITIS sind Lieferkettenangriffe und kompromittierte Fernwartungsketten realistische Szenarien. Wer das ignoriert, unterschaetzt die eigene Exponierung massiv.

Die Mindestanforderungen sind in den letzten Jahren deutlich gestiegen. Standardkontrollen wie Firewall, Endpoint-Schutz und regelmaessige Updates reichen fuer KRITIS nicht aus. Erwartet werden belastbare Identitaetskontrollen, segmentierte Netze, nachvollziehbare Admin-Prozesse, Logging, Wiederherstellbarkeit und ein Incident-Prozess, der nicht erst im Ernstfall erfunden wird. Wer sich mit Und Kritis oder Kritis Anforderungen beschaeftigt, sollte diese Anforderungen nicht als Checkliste lesen, sondern als Mindestniveau fuer Versicherbarkeit.

MFA ist dabei nur der Anfang. Relevant ist, ob MFA fuer alle extern erreichbaren Dienste, privilegierten Konten, VPN-Zugaenge, Cloud-Administrationskonten und Fernwartungsszenarien gilt. Ebenso wichtig ist, ob lokale Break-Glass-Konten existieren, wie diese geschuetzt werden und ob Servicekonten kontrolliert sind. In vielen Vorfaellen beginnt der Schaden nicht mit einem Zero-Day, sondern mit einem schwachen Identitaetsmodell, lateralem Zugriff und fehlender Segmentierung.

Bei Backup und Recovery zaehlt nicht die Anzahl der Sicherungen, sondern die Wiederanlaufrealitaet. Ein Versicherer will wissen, ob ein Ransomware-Fall nicht nur Daten, sondern auch Hypervisor, Managementserver, Authentifizierung, Backup-Kataloge und OT-nahe Systeme treffen kann. Wenn das Backup-System selbst in derselben Vertrauenszone liegt, ist die nominelle Sicherung oft wertlos. Deshalb sind Themen wie Backup Strategie, Disaster Recovery und Business Continuity bei KRITIS keine Nebenthemen, sondern Kern der Versicherbarkeit.

Monitoring ist ein weiterer Punkt, der oft missverstanden wird. Ein SIEM oder SOC ist nur dann hilfreich, wenn relevante Datenquellen angebunden sind und Alarme in handlungsfaehige Prozesse muenden. In KRITIS-Umgebungen muessen mindestens Authentifizierungsereignisse, privilegierte Aktionen, VPN-Nutzung, Firewall-Logs, EDR-Telemetrie, Backup-Fehler, Cloud-Admin-Aktivitaeten und moeglichst auch OT-nahe Uebergangspunkte sichtbar sein. Ohne diese Sichtbarkeit wird Forensik teuer, langsam und unvollstaendig. Genau deshalb spielen Security Monitoring und Siem in Vertragspruefungen eine immer groessere Rolle.

Schliesslich wird auch Governance bewertet. Gibt es ein aktuelles Asset-Inventar? Sind Verantwortlichkeiten fuer IT, OT, Dienstleister und Krisenkommunikation definiert? Werden Schwachstellen priorisiert? Existieren dokumentierte Ausnahmen? In KRITIS-Umgebungen ist technische Reife ohne organisatorische Steuerung selten belastbar. Versicherer schauen deshalb zunehmend auf die Verbindung aus Technik, Betrieb und Compliance, etwa im Kontext von Nis2 oder Iso 27001.

Die groessten Missverstaendnisse entstehen dort, wo klassische Cyber-Policen auf OT-Realitaet treffen. In vielen KRITIS-Umgebungen existieren SCADA-Systeme, Fernwirkstationen, SPS, HMI, Historian-Server, industrielle Firewalls, serielle Gateways und Engineering-Stationen, die ueber Jahre gewachsen sind. Diese Systeme haben andere Wartungsfenster, andere Verfuegbarkeitsanforderungen und oft andere Herstellerlogiken als klassische IT. Wer sie im Antrag nur als Server oder Netzwerkkomponenten beschreibt, unterschlaegt den eigentlichen Risikokontext.

Fernwartung ist dabei ein Hauptproblem. Hersteller, Integratoren und Servicepartner benoetigen oft Zugriff auf Anlagen oder Teilnetze. In der Praxis sieht das dann so aus: VPN-Tunnel ohne strikte Zielbegrenzung, gemeinsam genutzte Dienstleisterkonten, fehlende Sitzungsaufzeichnung, unklare Freigabeprozesse und persistente Verbindungen, die nie sauber abgeschaltet werden. Kommt es ueber diesen Pfad zu einer Kompromittierung, stellt sich im Schadenfall sofort die Frage, ob angemessene Schutzmassnahmen vorhanden waren. Wer sich mit Fernwartung, Remote Zugriff und Fuer Vpn Umgebungen beschaeftigt, sollte diese Punkte als technische Mindestdisziplin verstehen.

Ein weiterer Schwachpunkt ist die Segmentierung. Viele Betreiber glauben, eine VLAN-Trennung oder eine einzelne Firewall zwischen Office und Produktion sei ausreichend. In realen Angriffen zeigt sich jedoch, dass flache Vertrauenszonen, zu breite Firewall-Regeln, gemeinsame Active-Directory-Abhaengigkeiten oder unkontrollierte Dateifreigaben den Uebergang in OT massiv erleichtern. Wenn dann noch Backup- oder Managementsysteme beide Welten beruehren, wird aus einem IT-Vorfall schnell ein Betriebsrisiko.

Auch die Frage nach Patchmanagement wird in OT oft falsch beantwortet. In IT bedeutet Patchmanagement meist ein regelmaessiger Zyklus. In OT bedeutet es haeufig: Herstellerfreigaben abwarten, Testfenster organisieren, Safety-Auswirkungen pruefen, Wartungsstillstaende koordinieren. Das ist legitim, aber nur dann versicherbar, wenn der Prozess dokumentiert ist und durch Kompensationsmassnahmen abgesichert wird. Dazu gehoeren Application Control, strikte Netzwerkpfade, Monitoring, eingeschraenkte Admin-Rechte und kontrollierte Datentraegerprozesse.

• Fernwartung nur ueber freigegebene Jump-Systeme mit MFA, Protokollierung und zeitlich begrenzter Freischaltung.
• Klare Trennung von Office-IT, DMZ, Leitwarte, Engineering und Anlagenzonen mit minimalen Kommunikationspfaden.
• Dokumentierte Ausnahmen fuer nicht patchbare Systeme inklusive Monitoring und kompensierender Kontrollen.

Gerade in Bereichen wie Fuer Energieversorger, Fuer Industrieanlagen oder Fuer Produktionsnetzwerke entscheidet diese technische Sauberkeit darueber, ob ein Versicherer das Risiko als kontrollierbar oder als strukturell unsicher bewertet. Die Police ersetzt keine Segmentierung, keine Zugriffskontrolle und keine Recovery-Faehigkeit. Sie setzt sie voraus.

Viele Betreiber schauen zuerst auf die Deckungssumme. Das ist verstaendlich, aber nicht der entscheidende Punkt. Wichtiger ist, welche Ereignisse konkret gedeckt sind, welche Voraussetzungen gelten und welche Ausschluesse oder Sublimits im Vertrag versteckt sind. Bei KRITIS sind insbesondere Betriebsausfall, Wiederherstellung, externe Forensik, Krisenkommunikation, Rechtsberatung, Benachrichtigungspflichten, Haftungsfolgen und Kosten fuer Notmassnahmen relevant. Gleichzeitig muessen Grauzonen rund um OT, physische Auswirkungen, Lieferketten und staatlich beeinflusste Angriffe genau gelesen werden.

Ein klassischer Irrtum ist die Annahme, dass jeder digitale Vorfall automatisch als versicherter Cyber-Schaden gilt. Wenn ein Angriff zwar digital beginnt, aber zu physischen Folgen, Safety-Abschaltungen oder laengeren Produktionsstillstaenden fuehrt, kann die Abgrenzung zwischen Cyber, Sachschaden und Betriebsunterbrechung kompliziert werden. Deshalb muessen Betreiber nicht nur auf Leistungsumfang und Deckungssumme achten, sondern vor allem auf Ausschluesse und Kleingedrucktes.

Besonders sensibel sind Formulierungen zu grober Fahrlaessigkeit, bekannten Schwachstellen, nicht eingehaltenen Sicherheitszusagen und Obliegenheiten im Schadenfall. Wenn im Antrag MFA fuer privilegierte Zugaenge bestaetigt wurde, im Incident aber ein ungeschuetztes Admin-Konto missbraucht wird, ist die Diskussion vorprogrammiert. Gleiches gilt, wenn Backups zwar existieren, aber nicht wiederherstellbar sind oder wenn ein kritischer Dienstleisterzugang ohne Freigabeprozess offenstand.

Auch bei Ransomware und Erpressung lohnt sich ein genauer Blick. Manche Policen decken Incident Response und Wiederherstellung gut ab, begrenzen aber Zahlungen, Verhandlungsleistungen oder externe Spezialisten. Andere schliessen bestimmte Szenarien aus, wenn Mindestkontrollen nicht eingehalten wurden. Wer in KRITIS arbeitet, sollte deshalb Themen wie Deckt Ransomware, Deckt Betriebsausfall und Deckt Incident Response immer im Zusammenspiel lesen.

Ein weiterer Punkt sind Sublimits. Eine hohe Gesamtsumme hilft wenig, wenn fuer Forensik, PR, Rechtskosten oder Datenwiederherstellung nur begrenzte Teilbetraege vorgesehen sind. In KRITIS-Faellen koennen allein externe Spezialisten, Log-Auswertung, Anlagenanalyse und Wiederanlaufkoordination erhebliche Kosten verursachen. Deshalb muss die Police zur realen Incident-Oekonomie passen, nicht nur zur theoretischen Maximalsumme.

Im Ernstfall entscheidet nicht nur die Technik, sondern die Reihenfolge der Entscheidungen. KRITIS-Betreiber muessen gleichzeitig Versorgung sichern, Schaden begrenzen, regulatorische Pflichten beachten, Beweise erhalten und den Versicherer korrekt einbinden. Wer hier improvisiert, verliert Zeit und produziert spaeter Nachweisprobleme. Deshalb braucht jede Organisation einen abgestimmten Workflow, der Betrieb, Security, Management, Recht, Kommunikation und externe Partner zusammenbringt.

Der erste Fehler ist haeufig vorschnelles Aufraeumen. Systeme werden neu gestartet, Logdaten ueberschrieben, kompromittierte Konten geloescht oder Netzpfade geaendert, bevor Beweise gesichert sind. Das kann operativ nachvollziehbar sein, erschwert aber Forensik und Deckungspruefung. Der zweite Fehler ist das Gegenteil: zu langes Warten aus Angst vor Eskalation. In KRITIS-Umgebungen kann jede Stunde relevant sein, besonders wenn sich ein Vorfall von Office-IT in betriebsnahe Zonen bewegt.

Ein belastbarer Ablauf beginnt mit der technischen Erstbewertung: Was ist betroffen, welche Konten wurden missbraucht, welche Systeme zeigen Anomalien, welche Zonen sind beruehrt, welche externen Verbindungen bestehen, welche Backups sind sicher, welche Betriebsprozesse sind kritisch? Parallel dazu muss die Eskalation an interne Entscheider und an die in der Police definierten Kontaktstellen erfolgen. Themen wie Schadensmeldung, Notfall Hotline und Incident Response Team sind deshalb keine Formalitaeten, sondern Teil der technischen Reaktionsfaehigkeit.

Wichtig ist die Trennung zwischen Eindämmung und Wiederherstellung. Zuerst muss der Angriffsweg verstanden oder zumindest begrenzt werden: kompromittierte Konten sperren, Fernwartung deaktivieren, betroffene Segmente isolieren, schadhafte Tasks oder Persistenzmechanismen identifizieren, Admin-Tokens invalidieren, bekannte IOCs in Monitoring und Firewall-Regeln uebernehmen. Erst danach sollte die Wiederherstellung starten. Wer zu frueh aus Backups zurueckspielt, ohne den Initialzugang zu schliessen, infiziert sich oft erneut.

1. Vorfall erkennen und technisch klassifizieren
2. Kritische Prozesse und Sicherheitslage parallel bewerten
3. Versicherer und definierte Notfallkontakte unverzueglich einbinden
4. Beweise sichern: Logs, Speicherabbilder, Konfigurationen, Netzwerkdaten
5. Eindämmung mit minimalem Einfluss auf kritische Versorgung umsetzen
6. Forensische Hypothesen bestaetigen oder verwerfen
7. Wiederherstellung priorisiert nach Kritikalitaet und Abhaengigkeiten
8. Nachweisfuehrung, Meldungen und Lessons Learned abschliessen

In KRITIS ist ausserdem die Kommunikationsdisziplin entscheidend. Technische Teams muessen sauber dokumentieren, welche Massnahmen wann und warum erfolgt sind. Management und Recht brauchen belastbare Lagebilder, keine Vermutungen. Der Versicherer benoetigt nachvollziehbare Fakten, um Dienstleister freizugeben, Kosten zu uebernehmen und Deckungsfragen nicht an formalen Fehlern scheitern zu lassen.

Die meisten Probleme entstehen nicht durch exotische Klauseln, sondern durch operative Widersprueche. Auf dem Papier ist die Umgebung abgesichert, in der Praxis existieren Ausnahmen, Schattenprozesse und Altlasten. Genau diese Luecke zwischen Dokument und Realitaet wird im Schadenfall sichtbar. Ein Versicherer muss nicht beweisen, dass jede Kontrolle perfekt war. Es reicht oft, dass wesentliche Zusagen objektiv nicht eingehalten wurden.

Ein haeufiger Fehler ist die unklare Verantwortlichkeit zwischen IT und OT. Niemand fuehlt sich fuer gemeinsame Zonen, Jump-Hosts, Historian-Anbindungen oder Dienstleisterzugriffe voll verantwortlich. Dadurch bleiben Kontrollen lueckenhaft. Ein weiterer Fehler ist die fehlende Pflege des Antragszustands. Nach Vertragsabschluss veraendert sich die Umgebung: neue Standorte, neue Fernwartungswege, Cloud-Anbindungen, Migrationsprojekte, Outsourcing. Wenn diese Aenderungen nicht bewertet und bei Bedarf gemeldet werden, driftet die Police vom realen Risiko weg.

Ebenso problematisch ist das Vertrauen in einzelne Produkte statt in Prozesse. Ein EDR-Agent, eine Firewall oder ein Backup-System loesen kein strukturelles Problem, wenn Admin-Rechte unkontrolliert sind, Logs nicht ausgewertet werden oder Wiederherstellung nie getestet wurde. Deshalb sind Seiten wie Und Edr, Und Firewall und Und Patchmanagement nur dann sinnvoll, wenn sie als Teil eines Gesamtmodells verstanden werden.

• Pauschale Ja-Antworten auf Sicherheitsfragen ohne technischen Geltungsbereich.
• Nicht dokumentierte Legacy-Systeme oder Herstellerzugriffe in kritischen Zonen.
• Backups ohne regelmaessige Restore-Tests fuer priorisierte Kernprozesse.
• Keine abgestimmte Incident-Kommunikation zwischen Betrieb, Recht und Versicherer.
• Vertragsabschluss ohne Pruefung von Sublimits, Ausschluessen und Obliegenheiten.

Aus Pentest- und Incident-Praxis ist bekannt, dass Angreifer selten den direktesten Weg waehlen. Sie nutzen den schwachen Rand: ein altes VPN, ein vergessenes Dienstleisterkonto, ein schlecht segmentiertes Admin-Netz, ein Backup-Server mit zu vielen Rechten oder eine Engineering-Workstation mit Internetzugang. Genau deshalb muss die Versicherungspruefung angriffsorientiert erfolgen. Nicht die Frage, ob eine Kontrolle existiert, sondern ob sie einen realistischen Angriffsweg wirksam unterbricht, ist entscheidend.

Wer KRITIS betreibt, sollte die Police deshalb mindestens jaehrlich gegen die aktuelle Architektur, die Incident-Erfahrungen, neue regulatorische Anforderungen und veraenderte Lieferketten spiegeln. Alles andere fuehrt dazu, dass der Vertrag formal aktuell, technisch aber veraltet ist.

Eine gute Vorbereitung reduziert Rueckfragen, beschleunigt den Abschluss und verbessert die Position im Schadenfall. Entscheidend ist nicht die Menge an Dokumenten, sondern ihre technische Aussagekraft. Ein PDF mit allgemeinen Richtlinien hilft wenig, wenn daraus nicht hervorgeht, welche Systeme betroffen sind, welche Ausnahmen bestehen und wie die Wirksamkeit geprueft wird.

Mindestens vorhanden sein sollten aktuelle Netz- und Zonenplaene, ein Asset-Inventar mit Kritikalitaet, eine Liste privilegierter Konten, ein Verzeichnis externer Dienstleisterzugaenge, Backup- und Restore-Nachweise, Patch- und Ausnahmeprozesse, Logging-Quellen, Incident-Runbooks und eine Uebersicht ueber kritische Abhaengigkeiten. In KRITIS-Umgebungen gehoeren ausserdem Wiederanlaufplaene fuer Kernprozesse dazu: Welche Systeme muessen in welcher Reihenfolge zurueckkommen, welche manuellen Ersatzverfahren existieren, welche Safety-Freigaben sind noetig, welche Hersteller muessen eingebunden werden?

Besonders wertvoll sind technische Tests. Ein Versicherer vertraut dokumentierten Restore-Tests, MFA-Rollout-Nachweisen, Segmentierungspruefungen und Incident-Uebungen deutlich mehr als allgemeinen Absichtserklaerungen. Deshalb sind Themen wie Penetrationstest, Vulnerability Management und Audit in KRITIS nicht nur Compliance-Instrumente, sondern versicherungsrelevante Belege.

Wichtig ist ausserdem die Nachweisfuehrung fuer Ausnahmen. Kein KRITIS-Betreiber hat eine perfekte Landschaft. Entscheidend ist, ob bekannte Schwachstellen kontrolliert werden. Wenn ein altes System nicht patchbar ist, muessen Segmentierung, Zugriffsbeschraenkung, Monitoring, Backup und Betriebsfreigabe dokumentiert sein. Wenn ein Hersteller nur ueber einen bestimmten Fernwartungsweg arbeiten kann, muessen Freigabeprozess, Zeitfenster, Protokollierung und Verantwortlichkeit nachvollziehbar sein.

Auch Kosten- und Schadensszenarien sollten intern vorbereitet werden. Wer die wahrscheinlichen Auswirkungen eines Ausfalls nicht kennt, kann weder Deckungssummen noch Sublimits sinnvoll bewerten. Gerade bei KRITIS lohnt sich ein Blick auf Kosten Kritis und Risiko Kritis, um technische und finanzielle Perspektive zusammenzubringen.

Ein sauberer Workflow beginnt nicht beim Versicherer, sondern intern. Zuerst muss klar sein, welche Systeme, Prozesse und Abhaengigkeiten wirklich kritisch sind. Danach folgt die technische Risikobewertung: Identitaeten, Fernzugriffe, Segmentierung, Backup, Monitoring, Schwachstellen, Dienstleister, Cloud-Anbindungen und OT-Schnittstellen. Erst auf dieser Basis laesst sich eine Police sinnvoll bewerten oder beantragen.

Der zweite Schritt ist die Uebersetzung in versicherungsrelevante Aussagen. Dabei muessen technische Begriffe in belastbare Vertragslogik ueberfuehrt werden. Beispiel: Nicht nur „MFA vorhanden“, sondern „MFA fuer alle externen und privilegierten Zugaenge, ausgenommen dokumentierte Break-Glass-Konten im Tresorverfahren“. Nicht nur „Backups vorhanden“, sondern „taegliche Sicherung kritischer Systeme, unveraenderbare Kopien, quartalsweise Restore-Tests fuer priorisierte Kernservices“. Diese Praezision verhindert spaetere Interpretationskonflikte.

Danach folgt die Vertragspruefung gegen reale Szenarien. Sinnvoll ist ein Tabletop-Ansatz: Was passiert bei kompromittiertem Dienstleisterzugang? Was bei Ransomware im Active Directory? Was bei Ausfall des Historian? Was bei Missbrauch eines Cloud-Admin-Kontos? Was bei gleichzeitiger Stoerung von IT und OT-DMZ? Wenn die Police in diesen Szenarien unklare Antworten liefert, ist sie fuer KRITIS nicht sauber genug. Themen wie Bei It Notfall, Bei Ransomware und Bei Cloud Ausfall helfen, solche Szenarien strukturiert zu denken.

Der vierte Schritt ist die laufende Pflege. Jede relevante Architekturveraenderung muss gegen die Police gespiegelt werden: neue Fernwartungsloesung, neue Cloud-Plattform, neue Tochtergesellschaft, neue Leitwarte, neues Outsourcing, neue Backup-Architektur. In KRITIS ist Stillstand selten, auch wenn Anlagen lange laufen. Die Vertragsrealitaet muss deshalb mit der Betriebsrealitaet synchron bleiben.

Ein praxistauglicher Workflow verbindet Security, Betrieb, Einkauf, Recht und Management. Security liefert die technische Wahrheit, Betrieb die Kritikalitaet, Recht die Melde- und Haftungsperspektive, Einkauf die Vertragssteuerung und Management die Priorisierung. Fehlt eine dieser Rollen, entstehen blinde Flecken. Genau deshalb ist Cyberversicherung in KRITIS kein isoliertes Versicherungsthema, sondern Teil der gesamten Resilienzsteuerung.

Eine gute Cyberversicherung fuer KRITIS ist kein Ersatz fuer Security und auch kein Freifahrtschein fuer gewachsene Risiken. Sie ist ein Instrument zur finanziellen und operativen Stabilisierung, wenn ein Vorfall trotz Schutzmassnahmen eintritt. Damit das funktioniert, muessen Antrag, Sicherheitsniveau, Vertragsbedingungen und Incident-Workflow zusammenpassen.

Die beste Ausgangslage entsteht dort, wo technische Realitaet offen dokumentiert ist: bekannte Schwachstellen, Legacy-Systeme, Dienstleisterzugriffe, OT-Abhaengigkeiten, Wiederanlaufzeiten und organisatorische Grenzen. Versicherer koennen mit transparenten Risiken arbeiten, wenn diese kontrolliert und nachvollziehbar beschrieben sind. Problematisch wird es erst, wenn Hochglanzformulierungen auf operative Luecken treffen.

Fuer KRITIS-Betreiber bedeutet das konkret: keine pauschalen Antworten, keine ungetesteten Backups, keine unkontrollierte Fernwartung, keine unklaren Admin-Modelle und keine Police ohne Szenario-Pruefung. Wer diese Punkte sauber bearbeitet, verbessert nicht nur die Versicherbarkeit, sondern auch die reale Widerstandsfaehigkeit gegen Angriffe. Das gilt besonders in Umgebungen mit Fuer Ot Umgebungen, Fuer Industrial Iot und Fuer Smart Factory, in denen digitale und physische Auswirkungen eng verbunden sind.

Am Ende ist die entscheidende Frage nicht, ob eine Police existiert, sondern ob sie unter realen Bedingungen traegt. Das laesst sich nur durch technische Tiefe, ehrliche Bestandsaufnahme und geuebte Workflows beantworten. Genau dort trennt sich formale Absicherung von echter Resilienz.