Zum Inhalt springen
Legiscope
Menü
Cybersecurity

DORA Versicherungen Deutschland: BaFin 2026

DORA für Versicherer 2026: Geltungsbereich, BaFin-Meldungen, IKT-Risiken, Tests und Drittparteien anhand der geltenden EU-Regeln.

DORA gilt seit dem 17. Januar 2025 für viele Finanzunternehmen unmittelbar. Für deutsche Versicherer ist die Frage deshalb nicht mehr, ob eine Einführung irgendwann beginnt, sondern ob IKT-Risiken, Vorfälle, Tests und Dienstleister im laufenden Betrieb nachweisbar gesteuert werden. Bei Vermittlern und kleineren Einrichtungen ist zunächst der genaue Anwendungsbereich zu prüfen. Dieser Leitfaden erklärt die Entscheidungen für Versicherungsunternehmen unter deutscher Aufsicht und trennt die DORA-Pflichten von NIS2 und Datenschutz. Maßgeblich sind die Verordnung (EU) 2022/2554, ihre technischen Rechtsakte und die DORA-Seiten der BaFin.

Wer im Versicherungsbereich erfasst ist

Art. 2 DORA zählt Versicherungs- und Rückversicherungsunternehmen, bestimmte Versicherungs- und Rückversicherungsvermittler sowie Einrichtungen der betrieblichen Altersversorgung auf. Daraus folgt keine pauschale Pflicht für jeden Makler und jede Pensionskasse. Art. 2 Abs. 3 enthält ausdrücklich Ausnahmen, unter anderem für Vermittler, die Kleinst-, kleine oder mittlere Unternehmen im Sinne der Verordnung sind, sowie für bestimmte kleine Einrichtungen der betrieblichen Altersversorgung. Auch die Abgrenzung von Versicherungsunternehmen nach dem einschlägigen EU-Aufsichtsrecht ist zu beachten. Wer eine Gruppe mit mehreren Gesellschaften führt, sollte jede rechtliche Einheit anhand ihrer Zulassung und der Ausnahmen einzeln prüfen.

Die häufige Aussage „Vermittler mit mehr als 50 Beschäftigten unterliegen DORA“ ist falsch. Ein Vermittler kann mit 60 Beschäftigten noch ein mittleres Unternehmen im Sinne des Art. 3 sein; weitere Umsatz- und Bilanzkriterien sind relevant. Umgekehrt sollte eine Gruppe nicht allein auf die Zahl der Mitarbeitenden einer Vertriebsgesellschaft schauen. Die EIOPA-Fragen und Antworten zur Vermittlerausnahme erläutern den Grundsatz. Halten Sie die Einordnung mit Rechtsform, Tätigkeiten, Kennzahlen, Ausnahmetatbestand und Datum schriftlich fest. Aktualisieren Sie sie, wenn das Unternehmen wächst oder sich die Regulierung ändert.

Für ein erfasstes Unternehmen gilt der Verhältnismäßigkeitsgrundsatz, aber keine automatische Befreiung von Kernpflichten. DORA sieht in Art. 16 für ausdrücklich genannte Einrichtungen einen vereinfachten IKT-Risikomanagementrahmen vor, darunter kleine Einrichtungen der betrieblichen Altersversorgung, soweit sie nicht bereits nach Art. 2 ausgenommen sind. Gewöhnliche Versicherungs- und Rückversicherungsunternehmen gehören nicht allein wegen ihrer geringen Größe zu dieser Art.-16-Liste. Eine mögliche nationale Erweiterung für andere Rechtsträger ist getrennt anhand des geltenden VAG und der BaFin-Hinweise zu Art. 16 zu prüfen.

Die fünf Arbeitsfelder von DORA

Die Abgrenzung zwischen DORA und NIS2 für Finanzunternehmen ist bereits bei der Geltungsbereichsprüfung hilfreich. DORA bündelt IKT-Risikomanagement, Behandlung und Meldung schwerwiegender IKT-Vorfälle, Tests der digitalen operationalen Resilienz, Steuerung des IKT-Drittparteienrisikos und Informationsaustausch über Cyberbedrohungen. Der freiwillige Informationsaustausch ist kein Beleg dafür, dass alle anderen Teile freiwillig wären. Für die Geschäftsleitung ist die erste Aufgabe, Zuständigkeiten und Berichte über diese Felder zu verbinden. Der Leitfaden zum IKT-Risikomanagementrahmen vertieft die Organisation dieses ersten Feldes. Ein IKT-Risiko kann sonst im Dienstleisterregister als „bekannt“, im Notfallplan als „ungetestet“ und im Vorstandspapier als „geschlossen“ erscheinen.

Das Leitungsorgan trägt nach Art. 5 DORA die letztendliche Verantwortung für den IKT-Risikomanagementrahmen. Es muss Rollen, Verantwortlichkeiten, Budget und geeignete Leitlinien bestimmen und Kenntnisse aufrechterhalten. Es kann operative Arbeit übertragen, nicht die Verantwortung. Ein sinnvoller Vorstandsbericht zeigt kritische Geschäftsleistungen, wesentliche IKT-Abhängigkeiten, Vorfälle, offene Maßnahmen und den Stand von Wiederherstellungstests. Eine Liste aller Schwachstellen ohne geschäftlichen Bezug ist für diese Entscheidung kaum brauchbar.

IKT-Risiken an Versicherungsleistungen binden

Beginnen Sie bei Tätigkeiten, deren Ausfall Versicherte oder Vertrieb besonders treffen würde: Bestandführung, Schadenbearbeitung, Zahlungsverkehr, digitale Antragsstrecken und Kommunikation mit Vermittlern. Erfassen Sie die Anwendungen, Schnittstellen, Datenbestände und Dienstleister, von denen diese Leistungen abhängen. Dann lassen sich Ausfall, Datenverlust, unbefugter Zugriff und Konzentration bei einem Anbieter konkret bewerten. DORA verlangt einen dokumentierten Rahmen, Schutz, Erkennung, Reaktion, Wiederherstellung und laufende Verbesserung. Der DORA-Überblick für andere Finanzunternehmen zeigt ähnliche Bausteine in anderem Sektorkontext.

Ein Versicherer sollte für jede kritische Leistung Verantwortliche, tolerierbare Unterbrechung, technische Abhängigkeiten, Ersatzverfahren und Wiederanlaufnachweise dokumentieren. Diese Werte müssen zur tatsächlichen Betriebsfähigkeit passen. Wenn ein Schadenportal angeblich in wenigen Stunden wiederhergestellt werden kann, der letzte Restore-Test aber nie die Schnittstelle zum Bestandssystem umfasste, ist die Angabe nicht verifiziert. Planen Sie Übungen mit IT, Fachbereich, Kommunikation und Dienstleister. Halten Sie fest, welche Annahme scheiterte und wann die Korrektur erneut getestet wird.

Vorfälle klassifizieren und richtig melden

Nicht jeder IT-Alarm ist ein „schwerwiegender IKT-bezogener Vorfall“. Art. 18 DORA und die delegierte Verordnung (EU) 2024/1772 regeln die Klassifizierung. Entscheidend sind unter anderem betroffene Kunden oder Gegenparteien, Dauer, geografische Ausbreitung, Datenverluste, Kritikalität der betroffenen Dienste und wirtschaftliche Auswirkungen. Ein Vorfallteam muss die vorhandenen Fakten fortlaufend aktualisieren; eine erste unvollständige Einschätzung darf nicht zur dauerhaften Nichtmeldung werden.

Für als schwerwiegend klassifizierte Vorfälle gilt nach Art. 5 der delegierten Verordnung (EU) 2025/301 die Erstmeldung so früh wie möglich, spätestens innerhalb von vier Stunden nach Klassifizierung und grundsätzlich spätestens 24 Stunden nach Kenntniserlangung. Wird erst nach Ablauf dieser 24 Stunden als schwerwiegend klassifiziert, gilt die im Rechtsakt geregelte Sonderregel von vier Stunden ab Klassifizierung. Der Zwischenbericht folgt spätestens 72 Stunden nach der Erstmeldung, auch ohne Statusänderung; ein aktualisierter Zwischenbericht ist unter den dort genannten Umständen nötig. Der Abschlussbericht ist spätestens einen Monat nach dem Zwischenbericht beziehungsweise letzten aktualisierten Zwischenbericht fällig. Die Verordnung enthält differenzierte Regeln für Wochenenden, Feiertage und Verzögerungen. Eine Tabelle „4 Stunden / 72 Stunden / ein Monat ab Entdeckung“ verschweigt diese unterschiedlichen Anker und kann zu falschen Terminen führen.

In Deutschland bezeichnet die BaFin sich als nationalen Melde-Hub für IKT-Vorfälle im Finanzsektor. Die Meldung erfolgt über das von ihr vorgesehene Verfahren. Daraus folgt keine automatische separate Meldung an EIOPA durch jedes Unternehmen. Das Verfahren sollte einen Stellvertreter, vorab geprüfte Zugänge, Vorlage und Übung umfassen. Der Leitfaden zur DORA-Vorfallmeldung kann die interne Triage vertiefen, sofern dessen Rechtsstand geprüft ist.

Wenn im selben Ereignis personenbezogene Daten betroffen sind, prüfen Sie zusätzlich Art. 33 und 34 DSGVO. Die Datenschutzmeldung hängt von einem Risiko für Rechte natürlicher Personen ab und folgt ihrer eigenen 72-Stunden-Regel ab Bekanntwerden. Ein DORA-Vorfall kann ohne Datenschutzverletzung vorliegen; eine Datenschutzverletzung kann auch unterhalb der DORA-Schwelle auftreten. Die Anleitung zur DSGVO-Datenpanne beschreibt diese zweite Entscheidung. Eine gemeinsame Sachverhaltsakte vermeidet Widersprüche, ersetzt aber keine getrennte rechtliche Prüfung.

Tests an Risiken und Wiederanlauf ausrichten

Art. 24 und 25 DORA verlangen ein Testprogramm, das digitale operationale Resilienz bewertet. Der geeignete Mix kann Schwachstellenanalysen, Szenariotests, End-to-End-Tests, Penetrationstests und andere Verfahren umfassen. Die gesetzliche Anforderung ist keine pauschale Pflicht, bei jedem Versicherer jedes Jahr Quellcode zu prüfen. Nach Art. 26 müssen nur von der zuständigen Behörde identifizierte Finanzunternehmen fortgeschrittene bedrohungsgeleitete Penetrationstests, sogenannte TLPT, durchführen. Der gesetzliche Grundrhythmus hierfür beträgt mindestens alle drei Jahre; Umfang und Verfahren hängen von der behördlichen Auswahl und den technischen Standards ab. Das BaFin-DORA-Portal verweist auf die einschlägigen Standards.

Ein Test ist wertvoll, wenn er eine Entscheidung ändert. Fragen Sie, ob ein Cloud-Ausfall, manipulierte Bestandsdaten oder ein kompromittierter Vermittlerzugang rechtzeitig erkannt würden; welche Ersatzverfahren funktionieren und welche Risiken offen bleiben. Dokumentieren Sie Befund, Priorität, Verantwortliche und Nachtest. Ein Zertifikat oder ein allgemeiner ISO-Bericht kann Hinweise liefern, belegt aber nicht automatisch die Erfüllung sämtlicher DORA-Anforderungen. Die BSI-Grundschutz-Methodik kann ein Baustein für bestehende Sicherheitsarbeit sein, ohne eine gesetzliche Gleichwertigkeit zu behaupten.

IKT-Drittdienstleister im Informationsregister erfassen

Art. 28 DORA verlangt die Steuerung von IKT-Drittparteienrisiken und ein Informationsregister zu vertraglichen Vereinbarungen über IKT-Dienstleistungen. Das Register ist mehr als eine Lieferantenliste: Es muss die Vertragsbeziehungen, Unternehmen, Funktionen und weitere vorgeschriebene Angaben in den technischen Vorlagen konsistent abbilden. Ermitteln Sie zunächst alle IKT-Leistungen, auch solche, die Fachbereiche direkt beziehen. Ordnen Sie zu, welche davon kritische oder wichtige Funktionen unterstützen. Die Durchführungsverordnung (EU) 2024/2956 enthält Vorlagen für das Register.

Für Verträge nennt Art. 30 DORA Mindestinhalte, unter anderem eine Beschreibung der Dienste, Standorte der Verarbeitung, Verfügbarkeit, Integrität, Unterstützung bei IKT-Vorfällen und Zugangs-, Prüf- und Kündigungsrechte. Bei Leistungen für kritische oder wichtige Funktionen kommen zusätzliche Anforderungen hinzu. Ein Art.-28-DSGVO-AVV ersetzt diese DORA-Klauseln nicht, auch wenn derselbe Cloud-Vertrag beide Bereiche betrifft. Die Exit-Strategie muss erklären, wie die Versicherungsleistung fortgeführt oder geordnet migriert wird. Bei einem großen Cloud-Anbieter kann ein zweiter Anbieter als Name auf einer Folie noch keine getestete Ausweichmöglichkeit sein.

Die DORA-Prüfung von IKT-Dienstleistern und Exit-Plänen erläutert diese Vertrags- und Betriebsfrage genauer. Bewerten Sie Konzentration auf Ebene der tatsächlichen Leistung. Zwei unterschiedliche Softwaremarken können dieselbe Cloud-Infrastruktur verwenden. Fragen Sie deshalb nach wesentlichen Unterauftragnehmern und dem Ort kritischer Daten und Dienste. Eine Cloud-Dienstleistung ist zugleich nicht automatisch ein von den europäischen Behörden als „kritisch“ eingestufter IKT-Drittdienstleister; die BaFin-FAQ betont die Einzelfallentscheidung. Prüfen Sie Vertrag, technische Architektur und Übergangsplan zusammen.

BaFin, VAIT, NIS2 und Datenschutz auseinanderhalten

DORA ist das unmittelbar anwendbare Finanzsektor-Regelwerk. Frühere deutsche IT-Aufsichtspapiere wie VAIT sind für die betroffenen Themen nicht einfach als unveränderte Parallelpflicht weiterzuführen. Zugleich bleiben andere versicherungsaufsichtliche Vorgaben relevant, soweit sie nicht durch DORA ersetzt oder angepasst wurden. Die aktuelle BaFin-DORA-Seite erläutert Änderungen ihrer Verwaltungspraxis. Für jede interne Regel sollte klar sein, ob sie auf DORA, deutschem Aufsichtsrecht, Datenschutz oder freiwilligem Standard beruht. Das verhindert doppelte, widersprüchliche Kontrollkataloge.

Für ein Finanzunternehmen, das unter DORA und die entsprechenden NIS2-Umsetzungsregeln fällt, ist DORA nach Art. 1 Abs. 2 DORA der sektorspezifische Unionsrechtsakt im Sinne von Art. 4 NIS2. Die entsprechenden DORA-Pflichten für IKT-Risikomanagement und Meldung schwerwiegender IKT-Vorfälle treten deshalb an die Stelle der jeweiligen NIS2-Pflichten; ein zweites gleichartiges NIS2/BSIG-Meldeverfahren folgt daraus nicht automatisch. Nach Art. 19 Abs. 1 DORA kann nationales Recht eine zusätzliche Übermittlung von DORA-Meldungen an benannte Behörden oder CSIRTs vorsehen. Das ist anhand des tatsächlich geltenden deutschen Verfahrens zu prüfen, ebenso wie andere, eigenständige Pflichten. Die Kommissionsleitlinien zu Art. 4 NIS2 erläutern die Abgrenzung. Eine pauschale zusätzliche BSI-Registrierung jedes Versicherers lässt sich daraus nicht ableiten. Prüfen Sie die konkrete rechtliche Einheit und Tätigkeit. Der Überblick zur deutschen NIS2-Umsetzung betrifft den anderen Rechtsrahmen. Ebenso gelten die DSGVO-Sicherheitsanforderungen nach Art. 32 weiterhin für personenbezogene Daten. Ein gemeinsames Kontrollinventar kann dieselbe Maßnahme mehreren Pflichten zuordnen, muss aber die unterschiedlichen Meldewege getrennt halten.

Die DSGVO-Fragen einer Versicherung reichen über Cyberresilienz hinaus: Gesundheitsdaten, Versicherungsanträge, Schadendaten und Vermittlerzugriffe benötigen Rechtsgrundlagen, Informationspflichten und angemessene Löschung. Der DSGVO-Leitfaden für Versicherungen behandelt diese Verarbeitung. Für Vermittler, die wegen Art. 2 Abs. 3 DORA ausgenommen sind, bleiben die Datenschutzpflichten der Versicherungsvermittlung selbstverständlich relevant.

Ein nachvollziehbarer Umsetzungsplan

Erstens dokumentieren Sie den Geltungsbereich pro Rechtsträger. Zweitens benennen Sie kritische Versicherungsleistungen und ihre IKT-Abhängigkeiten. Drittens vergleichen Sie den vorhandenen Risikorahmen, Vorfallprozess, Testplan und Dienstleisterbestand mit DORA und den geltenden technischen Standards. Viertens priorisieren Sie Lücken nach möglicher Unterbrechung oder Schädigung, nicht nach der Zahl fehlender Formularfelder. Fünftens berichten Sie an die Geschäftsleitung mit Belegen für geschlossene und offene Maßnahmen. Dieser Ablauf ist ein Steuerungszyklus, kein einmaliges „DORA-Projekt“.

Ein besonders nützlicher Probelauf verbindet drei Teams. Simulieren Sie einen Ausfall des Dienstleisters für die Schadenbearbeitung. Die IT beurteilt Ursache und Wiederherstellung, der Fachbereich beschreibt Auswirkungen auf Versicherte und Fristen, Compliance klassifiziert den Vorfall und prüft Meldungen. Einkauf und Dienstleistermanagement liefern Verträge, Ansprechpartner und Exit-Option. Das Ergebnis soll zeigen, welche Informationen fehlen, wie schnell sie verfügbar sind und welche Entscheidung bei unklarer Faktenlage getroffen wird. Die DORA-Compliance-Software-Übersicht kann Fragen an Werkzeuge liefern; eine bestimmte Produktfunktion wird hier nicht vorausgesetzt.

Welche Nachweise in einer Prüfung überzeugen

Ein DORA-Kontrollinventar sollte auf aktuelle Entscheidungen verweisen, nicht nur auf Richtlinientitel. Für eine kritische Schadenanwendung gehören etwa die fachliche Kritikalitätsentscheidung, das technische Abhängigkeitsbild, der letzte Wiederanlauftest, offene Schwachstellen und der Vertrag mit dem wichtigsten IKT-Dienstleister zusammen. Ein Prüfer muss erkennen können, welche Leistung bei welchem Ausfall betroffen wäre und wer die verbleibenden Risiken akzeptiert hat. Wenn fünf Abteilungen unterschiedliche Versionsstände verwenden, ist die Governance noch nicht belastbar.

Wählen Sie für eine interne Stichprobe zwei wesentliche Prozesse. Vergleichen Sie Inventar, CMDB, Dienstleisterregister und Notfallplan. Stimmen Namen und Verantwortliche überein? Ist eine ausgelagerte Schnittstelle tatsächlich in der Testübung berücksichtigt? Enthält der Vertrag die Unterstützung bei Vorfällen, die das Betriebsteam voraussetzt? Halten Sie Abweichungen als Maßnahmen mit Termin und Nachtest fest. Diese Prüfung verbessert die Resilienz unmittelbar und vermeidet eine bloße Dokumentensammlung.

Für ein Vorstandsberichtswesen reichen wenige Indikatoren, wenn sie Entscheidungen ermöglichen: unerprobte Wiederanlaufpfade, überfällige kritische Maßnahmen, nicht geklärte Konzentrationsrisiken und die Zeit bis zur Klassifizierung eines Vorfalls. Vergleichen Sie diese Angaben mit realen Übungen und Ereignissen. Eine niedrige Zahl gemeldeter Vorfälle ist für sich kein Beweis guter Erkennung; sie kann ebenso eine Lücke im Eingangskanal bedeuten. Fragen Sie deshalb regelmäßig, ob Mitarbeitende und Dienstleister einen möglichen Vorfall überhaupt schnell melden können.

Häufige Fragen

Gilt DORA für jeden Versicherungsmakler?

Nein. Art. 2 Abs. 3 DORA nimmt Versicherungs-, Rückversicherungs- und Nebenvermittler aus, wenn sie Kleinst-, kleine oder mittlere Unternehmen im Sinne der Verordnung sind. Die genaue Einordnung hängt von Mitarbeiterzahl und Finanzkennzahlen sowie der rechtlichen Einheit ab. Für nicht ausgenommene Vermittler sind die zuständige Aufsicht und die konkreten Pflichten gesondert zu bestimmen.

Muss jeder Versicherer einen TLPT durchführen?

Nein. Das fortgeschrittene bedrohungsgeleitete Testen nach Art. 26 betrifft Finanzunternehmen, die die zuständige Behörde nach den gesetzlichen Kriterien identifiziert. Alle erfassten Unternehmen brauchen ein angemessenes Testprogramm; dessen Inhalt richtet sich nach Risiko und anwendbaren Vorschriften.

Wann beginnt die Frist für die DORA-Erstmeldung?

Nach der Klassifizierung als schwerwiegender IKT-Vorfall läuft die Vier-Stunden-Grenze. Hinzu kommt grundsätzlich eine Grenze von 24 Stunden ab Kenntnis des Vorfalls. Für späte Klassifizierung, Feiertage und Verzögerungen enthält die delegierte Verordnung (EU) 2025/301 zusätzliche Regeln. Dokumentieren Sie daher Kenntniszeitpunkt und Klassifizierungsentscheidung getrennt.

Reicht ein DSGVO-Auftragsverarbeitungsvertrag für die Cloud?

Nicht zwingend. Art. 28 DSGVO und Art. 30 DORA verfolgen unterschiedliche Zwecke und enthalten unterschiedliche Vertragsanforderungen. Prüfen Sie beide Regelwerke anhand der tatsächlichen Cloud-Leistung und ergänzen Sie Vertrag, Kontrolle und Exit-Plan entsprechend.

Fazit

DORA verlangt für erfasste Versicherungsunternehmen eine laufende, von der Geschäftsleitung getragene Steuerung digitaler Abhängigkeiten. Der erste Schritt ist die richtige Einordnung des Rechtsträgers; danach zählen funktionierende Risiko-, Vorfall-, Test- und Dienstleisterprozesse. Meldefristen beginnen an unterschiedlichen Ereignissen, und fortgeschrittene Tests betreffen ausgewählte Unternehmen. Die offiziellen Rechtsakte und die BaFin-Verfahren gehören in jede aktuelle Arbeitsanweisung.

L
Verfasst von
Legiscope
Legiscope

Diesen Leitfaden in die Praxis umsetzen

Erfahren Sie, wie Legiscope Datenschutzverzeichnisse, Quellen und prüfungsgesteuerte Arbeit verbindet.

Individuelle Demo buchen
Weiterlesen

Ähnliche Artikel

01Cybersecurity

DORA Zahlungsdienstleister & FinTech 2026

In einem Satz. Zahlungsdienstleister, E-Geld-Institute und FinTech-Unternehmen unter PSD2/PSD3 fallen vollständig unter DORA (VO (EU) 2022/2554) seit 17. Januar 2025 — mit harmonisierten…

26. Juni 2026
02Cybersecurity

Beste NIS2-Compliance-Software 2026 (Deutschland)

Welche NIS2-Compliance-Software passt für deutsche Unternehmen? Kurzantwort: eine Plattform, die vier Dinge nachweisbar abbildet — die Registrierung bei der zuständigen Behörde (in Deutschland dem…

6. Juli 2026
03Cybersecurity

NIS2 24h-Meldepflicht BSI: Praxis 2026

In einem Satz. NIS2 etabliert eine dreistufige Meldekaskade an das BSI: Frühwarnmeldung binnen 24 Stunden ab Verdacht, Vollmeldung binnen 72 Stunden, Abschlussbericht binnen 1 Monat — zusätzlich zur…

26. Juni 2026
04Cybersecurity

NIS2 Bußgelder Deutschland: Sanktionen und BSI-Durchsetzung

In einem Satz. Das deutsche NIS2UmsuCG führt ein dreigeteiltes Sanktionsregime ein — wesentliche Einrichtungen bis €10 Mio. oder 2% Weltumsatz, wichtige Einrichtungen bis €7 Mio. oder 1,4%…

3. Juni 2026
05Cybersecurity

NIS2 DNS Cloud: Digitale Infrastruktur 2026

In einem Satz. Digitale-Infrastruktur-Anbieter — DNS, TLD-Registries, Rechenzentren, CDN, Cloud-Computing, Vertrauensdienste, B2B-Kommunikation — fallen unter NIS2 als wesentliche oder wichtige…

26. Juni 2026
06Cybersecurity

NIS2 Energie: Stadtwerke Deutschland 2026

In einem Satz. Stromversorger und Stadtwerke fallen unter NIS2 in Deutschland als wesentliche Einrichtungen (Anlage 1 BSIG-NIS2UmsuCG, Sektor Energie) — Pflichten umfassen Risikomanagement,…

26. Juni 2026
07Cybersecurity

NIS2 Geschäftsführer-Haftung: Persönliche Haftung

In einem Satz. Das NIS2-Umsetzungsgesetz (BSIG-NIS2UmsuCG) etabliert in § 38 eine explizite persönliche Haftung von Geschäftsführung und Vorstand für die Genehmigung, Überwachung und Schulung im…

26. Juni 2026
08Cybersecurity

NIS2 Krankenhäuser: Gesundheit Deutschland 2026

In einem Satz. Krankenhäuser und Gesundheitsdienstleister sind unter NIS2 als wesentliche Einrichtungen klassifiziert (Anlage 1 BSIG-NIS2UmsuCG, Sektor Gesundheit) — mit besonders strengen Pflichten…

26. Juni 2026