RI Wiki - Benutzerbeiträge [de]

Cyber Security Act (CSA)/de

2025-06-04T03:23:28Z

FuzzyBot: Übernehme Bearbeitung einer neuen Version der Quellseite

<languages/>
'''Änderung durch'''{{Infobox Rechtsakt (EU)|Typ=Verordnung|Jahr=2025|Nummer=37|Vertrag=EU|EWR=ja|Titel=Verordnung (EU) 2025/37 des Europäischen Parlaments und des Rates vom 19. Dezember 2024 zur Änderung der Verordnung (EU) 2019/881 im Hinblick auf verwaltete Sicherheitsdienste|Kurztitel=Cyber Security Act/Rechtsakt zur Cybersicherheit|Bezeichnung=CSA|Rechtsmaterie=Binnenmarkt, Cybersicherheit|Grundlage=AEUV, insbesondere {{Art.|114|AEUV|dejure|}}|Fundstelle=ABl L 2025/37, 1|Anzuwenden=4. Februar 2025|Gültig=anwendbar}}

'''Ursprungsrechtsakt'''

{{Infobox Rechtsakt (EU)|Typ=Verordnung|Jahr=2019|Nummer=881|Vertrag=EU|EWR=ja|Titel=Verordnung (EU) 2019/881 des Europäischen Parlaments und des Rates vom 17. April 2019 über die ENISA (Agentur der Europäischen Union für Cybersicherheit) und über die Zertifizierung der Cybersicherheit von Informations- und Kommunikationstechnik und zur Aufhebung der Verordnung (EU) Nr. 526/2013|Kurztitel=Cyber Security Act/Rechtsakt zur Cybersicherheit|Bezeichnung=CSA|Rechtsmaterie=Binnenmarkt, Cybersicherheit|Grundlage=AEUV, insbesondere {{Art.|114|AEUV|dejure|}}
|Fundstelle=ABl L 2019/151, 15|Anzuwenden=27. Juni 2019|Gültig=anwendbar}}

== Einführung ==

Die Verordnung (EU) 2019/881 (Cybersecurity Act bzw. CSA), die im Juni 2019 in Kraft trat, verfolgte zwei Hauptziele: Zum einen stärkte es die Position der EU-Agentur für Cybersicherheit (ENISA), indem es ihr ein dauerhaftes Mandat erteilte und ihre Aufgaben sowie Ressourcen erweiterte. Zum anderen führte es einen EU-weiten Zertifizierungsrahmen für Cybersicherheit ein, der einheitliche Standards für IKT-Produkte, -Dienste und -Prozesse in der gesamten EU etablieren sollte.

Die Novelle 2025 zum Cyber Security Act<ref>https://eur-lex.europa.eu/eli/reg/2025/37/oj</ref>, die am 4. Februar 2025 in Kraft tritt, baut auf der ursprünglichen Verordnung auf und führt mehrere Neuerungen ein.

== Zentrale Inhalte ==

=== Rolle und Kompetenzen der Europäischen Agentur für Netz- und Informationssicherheit ([https://www.enisa.europa.eu/ ENISA):] (Artikel 4-45 CSA): ===

* Die ENISA erhält ein dauerhaftes Mandat als Kompetenzzentrum für Cybersicherheit in der EU.
* Ihre Aufgaben umfassen nun Beratung, Unterstützung und Förderung der EU-Politik im Bereich Cybersicherheit.
* Sie soll Stellungnahmen abgeben, Leitlinien herausgeben und zu Themen wie Risikomanagement und Meldung von Sicherheitsvorfällen beraten
* Entwicklung und Verwaltung des europäischen Rahmens für die Cybersicherheitszertifizierung von IKT-Produkten, -Diensten und -Prozessen

=== Einführung eines EU-weiten Zertifizierungssystems (Artikel 46-65 CSA) ===

Der zweite Kernbereich ist die Schaffung eines einheitlichen Zertifizierungsrahmens für Cybersicherheit:

* Es wird ein EU-weites Zertifizierungssystem für Produkte, Dienstleistungen und Prozesse der Informations- und Kommunikationstechnologie eingeführt.
* Die ENISA ist für den Aufbau und die Pflege dieses Zertifizierungsrahmens zuständig.
* Das System legt einheitliche Anforderungen und Bewertungskriterien für Cybersicherheit in der gesamten EU fest.
* Zertifikate bescheinigen die Erfüllung bestimmter Sicherheitsanforderungen und stufen die Vertrauenswürdigkeit als "niedrig", "mittel" oder "hoch" ein.

==== Cybersecurity-Zertifizierungsschema für ICT-Produkte der Europäischen Union (EU CC-Schema) ====

Die Europäische Kommission hat im Jänner 2024 die Durchführungsverordnung für das EU-Zertifizierungssystem für Cybersicherheit nach Common Criteria (EUCC) angenommen,<ref>https://eur-lex.europa.eu/eli/reg_impl/2024/482/oj</ref> welcher auf dem [https://www.sogis.eu/ SO-GIS] Schema basiert. Das EUCC-System basiert auf Freiwilligkeit und ermöglicht es IKT-Anbietern, die einen Zuverlässigkeitsnachweis erbringen wollen, ein EU-weit einheitliches Bewertungsverfahren zu durchlaufen, um IKT-Produkte wie technologische Komponenten (Chips, Smartcards), Hardware und Software zu zertifizieren. Es schlägt zwei Sicherheitsstufen vor, die sich nach dem Risiko richten, das mit der beabsichtigten Verwendung des Produkts, der Dienstleistung oder des Prozesses verbunden ist, und zwar in Bezug auf die Wahrscheinlichkeit und die Auswirkungen eines Unfalls. Das EUCC ist damit das erste europäische Zertifizierungsschema und wird am 27. Februar 2025 in Geltung treten.<ref>https://www.bundeskanzleramt.gv.at/themen/cybersicherheit/nationale-behoerde-fuer-cybersicherheitszertifizierung/common-criteria-eucc.html</ref>

Die ENISA arbeitet derzeit an zwei weiteren Zertifizierungssystemen für Cybersicherheit, [https://www.enisa.europa.eu/publications/eucs-cloud-service-scheme EUCS für Cloud-Dienste] und [https://www.enisa.europa.eu/topics/critical-information-infrastructures-and-services/telecoms/5g EU5G] für 5G-Sicherheit.

=== Novelle 2025: Cybersicherheitszertifizierung für "Verwaltete Sicherheitsdienste"<ref>https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:52023PC0208</ref> <ref>https://www.consilium.europa.eu/en/press/press-releases/2024/12/02/cybersecurity-package-council-adopts-new-laws-to-strengthen-cybersecurity-capacities-in-the-eu/pdf/</ref> ===

Mit dem Vorschlag wird eine Begriffsbestimmung für „verwaltete Sicherheitsdienste“ eingeführt, die an die Begriffsbestimmung für „Anbieter verwalteter Sicherheitsdienste“ in der NIS-2-Richtlinie angelehnt ist. Verwaltete Sicherheitsdienste sind Dienste, die in der Durchführung oder Unterstützung von Tätigkeiten im Zusammenhang mit dem Cybersicherheitsrisikomanagement ihrer Kund*innen bestehen (Art. 1 Abs. 2 CSA-N). Außerdem wird ein neuer Artikel 51a über die Sicherheitsziele der europäischen Systeme für die Cybersicherheitszertifizierung eingefügt, die auf verwaltete Sicherheitsdienste abgestimmt sind. Auf dieser Basis kann die EU-Kommission einen delegierten Rechtsakt für ein Zertifizierungsschema für verwaltete Sicherheitsdienste annehmen.

== Strafen/sonstige Konsequenzen ==

Art 65 CSA hält Mitgliedsstaaten an wirksame, verhältnismäßige und abschreckende Sanktionen bei Verstößen gegen EU Cybersicherheitsschemata zu erlassen.

== Synergien ==

=== CSA ===

* Der CSA zielt darauf ab, einheitliche Rahmenbedingungen für die Cybersicherheitszertifizierung in der EU zu schaffen, indem er freiwillige Zertifizierungsschemata etabliert. Diese dienen dazu, das Vertrauen in digitale Produkte, Dienstleistungen und Prozesse zu stärken. Die EU-Agentur für Cybersicherheit (ENISA) spielt eine zentrale Rolle bei der Entwicklung dieser Schemata.

=== CRA ===

* Der CRA legt Cybersicherheitsanforderungen für Produkte mit digitalen Elementen fest, um ein Mindestmaß an Sicherheit in der gesamten EU zu gewährleisten. Bestimmte Produkte müssen einer verpflichtenden Zertifizierung unterzogen werden.

Vorliegende CSA-Zertifizierungsschemata können in bestimmten Bereichen verwendet werden, um die Einhaltung Anforderungen des CRA zu belegen.

== Einzelnachweise ==

Network and Information Security Directive (NIS2-RL)/de

2025-06-04T02:20:40Z

FuzzyBot: Übernehme Bearbeitung einer neuen Version der Quellseite

<languages/>
{{Infobox Rechtsakt (EU)|Typ=Richtlinie|Jahr=2022|Nummer=2555|Vertrag=EU|EWR=ja|Titel=Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union, zur Änderung der Verordnung (EU) Nr. 910/2014 und der Richtlinie (EU) 2018/1972 sowie zur Aufhebung der Richtlinie (EU) 2016/1148|Kurztitel=NIS-2-Richtlinie|Bezeichnung=NIS2-RL|Rechtsmaterie=Binnenmarkt, Cybersicherheit|Grundlage=AEUV, insbesondere {{Art.|114|AEUV|dejure|}}
|Fundstelle=ABl L 2022/333, 80|Anzuwenden=17. Oktober 2024 (Umsetzung, Fristverletzung)|Gültig=umsetzung}}

== Kurzübersicht ==

{| class="wikitable"
!Ziele
!Anwendungsbereich
!Inhalt<ref>https://www.nis.gv.at/nis-2-richtlinie.html</ref>
!Synergie
!Konsequenzen
|-
|Aufbau von Cybersicherheitskapazitäten (ErwGr 1 NIS2-RL)
|Anhang I (Sektoren mit hoher Kritikalität)
|Pflicht für alle MS, nationale Cybersicherheitsstrategien zu verabschieden (<abbr>Art</abbr> 7 NIS2-RL)
|Datenschutzmanagementsystem
|Wesentliche Einrichtungen: Bußgelder mit Höchstbetrag von mindestens 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes
|-
|Schaffung eines hohen gemeinsamen Cybersicherheitsniveaus
(Art 1 NIS2-RL)
|Anhang II (Sonstige kritische Sektoren) soweit sie Obergrenzen nach <abbr>Art</abbr> 2 <abbr>Abs</abbr> 1 des Anhangs der Empfehlung 2003/361/EG überschreiten
|Pflicht für alle MS, diverse Zuständigkeiten zu regeln
Aufsichts- und Durchsetzungspflichten für die MS (<abbr>Art</abbr> 31 ff NIS2-RL)
|Sicherheit der Verarbeitung (Art 32 DSGVO)
|Für wichtige Einrichtungen (also alle anderen Einrichtungen die in den Anwendungsbereich der
NIS2-RL fallen) beträgt das höchstmögliche Bußgeld mindestens 7 Mio. Euro oder 1,4 % des weltweiten Jahresumsatzes.

Für beide gilt der jeweils höhere Betrag.
|-
|Eindämmung von Bedrohungen in Schlüsselsektoren (ErwGr 1 NIS2-RL)
|Ist von den MS bis zum 17. Oktober 2024 umzusetzen (nicht erfolgt)
|Pflichten in Bezug auf das Cybersicherheitsrisikomanagement (<abbr>Art</abbr> 20 ff NIS2-RL) sowie Berichtspflichten (<abbr>Art</abbr> 23 NIS2-RL) für betroffene Einrichtungen
|Verschwiegenheitsklauseln
|Behördliche Anweisungen und Anordnungen. Auch Anordnung der Aussetzung der Tätigkeit ist möglich. (Art 32 NIS2-RL)
|-
|
|
|Vorschriften und Pflichten zum Austausch von Cybersicherheitsinformationen (<abbr>Art</abbr> 29 ff NIS2-RL)
|
|Leitungsorgane können persönlich haften (Art 20 NIS2-RL)
|}

== Einführung ==

Die Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union<ref>Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union, zur Änderung der Verordnung (EU) Nr. 910/2014 und der Richtlinie (EU) 2018/1972 sowie zur Aufhebung der Richtlinie (EU) 2016/1148, ABl L 333/80 vom 27.12.2022</ref> (kurz: „NIS2-RL“) ist die Nachfolgeregelung der ersten Cybersicherheitsrichtlinie der Europäischen Union<ref>''Richtlinie (EU) 2016/1148 des Europäischen Parlaments und des Rates vom 6. Juli 2016 über Maßnahmen zur Gewährleistung eines hohen gemeinsamen Sicherheitsniveaus von Netz- und Informationssystemen in der Union,'' ABl. L 194/1 vom 19. Juli 2016</ref> („NIS-RL“).

Bereits durch die erste NIS-RL und deren nationale Umsetzung im NISG wurden bestimmte Unternehmen zu Cybersicherheitsmaßnahmen verpflichtet. Mit der Nachfolgeregelung, der NIS2-RL, wird der '''Anwendungsbereich''' deutlich erweitert, um auch große Teile der bisher nicht erfassten Unternehmen zu bedarfsgerechten Sicherheitsmaßnahmen zu verpflichten. Darüber hinaus werden insbesondere konkrete Vorgaben für ein '''Meldesystem''' bei Sicherheitsvorfällen gemacht und neue '''Haftungstatbestände''' geschaffen. Die NIS-RL wurde in Österreich im Netz- und Informationssystemsicherheitsgesetz (kurz: „NISG“) umgesetzt, das derzeit (Stand: Oktober 2024) zur Umsetzung der NIS2<ref>Netz- und Informationssystemsicherheitsgesetz 2024 – NISG 2024; Telekommunikationsgesetz, Gesundheitstelematikgesetz, Änderung (326/ME)

https://www.parlament.gv.at/gegenstand/XXVII/ME/326</ref> novelliert wird. Daneben ist die Durchführungsverordnung (EU) 2024/2690<ref>Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024 mit Durchführungsbestimmungen zur Richtlinie (EU) 2022/2555 im Hinblick auf die technischen und methodischen Anforderungen der Risikomanagementmaßnahmen im Bereich der Cybersicherheit und die Präzisierung der Fälle, in denen ein Sicherheitsvorfall in Bezug auf DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste, Anbieter verwalteter Sicherheitsdienste, Anbieter von Online-Marktplätzen, Online-Suchmaschinen und Plattformen für Dienste sozialer Netzwerke und Vertrauensdiensteanbieter als erheblich gilt.

https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402690</ref> beachtlich.

Die NIS2-RL zielt darauf ab, eine robuste, dem risikobasierten Ansatz folgende '''Sicherheitsinfrastruktur''' für die EU zu schaffen. Der Fokus liegt nicht darauf, jedes Einzelgerät abzusichern, sondern die Resilienz wesentlicher und wichtiger Einrichtungen zu gewährleisten.

Der Nationalrat konnte in einer im Juli 2024 abgehaltenen Sitzung zwar eine einfache Mehrheit für das Umsetzungsgesetz (NISG-E) erreichen, da das Gesetz jedoch Verfassungsbestimmungen enthält, bedarf es einer breiteren Zweidrittelmehrheit welche nicht erreicht werden konnte. Hauptgrund für die Absage der Opposition war die Ansiedelung der nationalen Cybersicherheitsbehörde beim Innenministerium.<ref>https://www.parlament.gv.at/aktuelles/pk/jahr_2024/pk0785</ref> Die Autoren erwarten keine wesentlichen Änderungen der unstrittigen Regelungspunkte in allfälligen Folgeentwürfen weshalb im Folgenden auf den Regelungsinhalten des vorliegenden Entwurfs (Netz- und Informationssystemsicherheitsgesetz 2024 – NISG 2024; Telekommunikationsgesetz, Gesundheitstelematikgesetz, Änderung (326/ME)<ref>Bundesgesetz, mit dem ein Bundesgesetz zur Gewährleistung eines hohen Cybersicherheitsniveaus von Netz- und Informationssystemen (Netz- und Informationssystemsicherheitsgesetz 2024 – NISG 2024) erlassen wird und das Telekommunikationsgesetz 2021 und das Gesundheitstelematikgesetz 2012 geändert werden.https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621118.pdf</ref> - im Folgenden '''NISG''') aufgebaut wird.

== Anwendungsbereich ==

=== NIS2-Richtlinie ===

==== Persönlicher/Sachlicher Anwendungsbereich ====

In den Anwendungsbereich können öffentliche oder private Einrichtungen fallen. Die NIS2-RL unterscheidet grundsätzlich zwischen dem '''größenabhängigen''' (Art 2 Abs 1 NIS2-RL) und dem '''größenunabhängigen''' (Art 2 Abs 3 NIS2-RL) Anwendungsbereich.

====== Größenabhängiger Anwendungsbereich ======

Um den größenabhängigen Geltungsbereich zu definieren, setzt die NIS2-RL zunächst an der [[Special:MyLanguage/Size-Cap-Rule|Size-Cap-Rule]] an.

Hiernach gilt die NIS2-RL für Einrichtungen

* welche mehr als 50 Mitarbeitende beschäftigen
* oder mehr als 10 Mio Euro Jahresumsatz<ref>Die Berechnung der Größenschwellen für Unternehmen nach der EU-Empfehlung 2003/361/EG ist nicht einfach. Sie berücksichtigt auch indirekte Verbindungen und Vertragsbeziehungen, wie bei verbundenen Unternehmen oder Tochtergesellschaften. Besonders bei großen Konzernen ist es ratsam, jeden Fall einzeln zu prüfen. Die Europäische Kommission hat zwar eine ausführliche Anleitung zur Berechnung veröffentlicht, aber es ist trotzdem empfehlenswert, professionelle rechtliche Beratung einzuholen. Dies gilt besonders für Unternehmen mit komplexen Strukturen, um zu klären, ob die NIS2-Richtlinie für sie gilt: https://op.europa.eu/de/publication-detail/-/publication/79c0ce87-f4dc-11e6-8a35-01aa75ed71a1</ref> erzielen.

Kumulativ muss die Tätigkeit der Einrichtung in den '''Anhang I''' oder '''II''' der NIS2-RL fallen.

* ''Anhang I'' nennt etwa folgende Einrichtungen:

Energie | Verkehr | Bankwesen | Finanzmarktinfrastrukturen | Gesundheitswesen | Trinkwasser | Abwasser | Digitale Infrastruktur | Verwaltung von IKT-Diensten (Business-to-Business) | öffentliche Verwaltung | Weltraum

* ''Anhang II nennt etwa folgende Einrichtungen:''

Post- und Kurierdienste | Abfallbewirtschaftung | Produktion, Herstellung und Handel mit chemischen Stoffen | Produktion, Verarbeitung und Vertrieb von Lebensmitteln | Verarbeitendes Gewerbe | Herstellung von Waren | Anbieter digitaler Dienste | Forschung

====== Größenunabhängiger Anwendungsbereich ======

Gemäß <abbr>Art</abbr> 2 und <abbr>Art</abbr> 3 der NIS2-RL können Einrichtungen auch unabhängig von der Größe und der "Size-Cap-Rule" in den Anwendungsbereich der NIS2-RL fallen.

Folgende Tätigkeiten sind hiervon umfasst:

Gemäß Art 2 Abs 2 lit a NIS2-RL Dienste von;

* Anbietern von öffentlichen elektronischen Kommunikationsnetzen oder von öffentlich zugänglichen elektronischen Kommunikationsdiensten
* Vertrauensdiensteanbietern
* Namenregistern der Domäne oberster Stufe und Domänennamensystem-Diensteanbietern.

Gemäß Art 2 Abs 2 lit b bis f iVm Art 3 Abs 1 lit e NIS2-RL

* Dienste, welche die Aufrechterhaltung kritischer gesellschaftlicher oder wirtschaftlicher Tätigkeiten unerlässlich sind
* Dienste, deren Störung sich wesentlich auf die öffentliche Ordnung, die öffentliche Sicherheit oder die öffentliche Gesundheit auswirken könnte
* Dienste, deren Störung zu einem wesentlichen Systemrisiko führen könnte, insbesondere in Sektoren, in denen eine solche Störung grenzüberschreitende Auswirkungen haben könnte
* Einrichtungen, welche aufgrund der besonderen Bedeutung, die sie auf nationaler oder regionaler Ebene für den betreffenden Sektor oder die betreffende Art des Dienstes oder für andere voneinander abhängige Sektoren in dem Mitgliedstaat hat, kritisch ist
* Bestimmte Einrichtungen der öffentlichen Verwaltung
Gemäß Art 2 Abs 3 und 4 NIS2-RL

* Einrichtungen, welche nach der [[Special:MyLanguage/Critical Entities‘ Resilience Directive (CER)|Richtlinie für Resilienz kritischer Einrichtungen (CER-RL)]] als kritisch eingestuft wurden
* Domänennamenregistrierungsdienste

====== Wesentliche und Wichtige Einrichtungen ======

Im Anwendungsbereich der Richtlinie stehende Einrichtungen werden durch Art 3 NIS2-RL in wesentliche und wichtige Einrichtungen eingeteilt.

'''Wesentliche''' '''Einrichtungen''' unterstehen einer proaktiven und reaktiven Aufsicht (<abbr>Art</abbr> 32 NIS2-RL).

'''Wichtige Einrichtungen''' unterliegen nur einer reaktiven Aufsicht (<abbr>Art</abbr> 33 NIS2-RL).<ref>https://www.nis.gv.at/nis-2-richtlinie.html</ref>

Daneben gelten verschiedene Sanktionsregime.

==== Territorialer Anwendungsbereich ====

Einrichtungen, die in der EU ansässig sind oder ihre Dienste in der EU erbringen (Art 2 NIS2-RL).

=== Nationaler Umsetzungsentwurf (NISG) ===

[[Datei:Nis ii wichtige einrichtungen ri.png|mini|Wichtige Einrichtungen - CC BY 4.0]]

==== Persönlicher/Sachlicher Anwendungsbereich ====

Regelungsgegenstand des NISG sind gemäß § 2 NISG wesentliche und wichtige Einrichtungen in den definierten Sektoren. Die Sektoren entsprechen denen der NIS2-RL und werden durch die Definition von '''Teilsektoren''' in den Anlagen 1<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_1 https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621120.pdf</ref> und 2<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_2 https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621121.pdf</ref> zum NISG ergänzt.

Eine "'''Einrichtung'''" iSd NISG ist gemäß § 3 Abs 10 NISG "eine natürliche Person oder nach dem an ihrem Sitz geltenden nationalen Recht geschaffene und anerkannte juristische Person oder eingetragene Personengesellschaft, die in eigenem Namen Rechte ausüben und Pflichten unterliegen kann".

Anstelle eines zweistufigen Vorgehens, wie es in Art 2 und 3 der NIS-2-Richtlinie vorgesehen ist, ist für die Einstufung als wesentliche oder wichtige Einrichtung nach diesem Bundesgesetz '''ausschließlich''' § 24 NISG maßgeblich. Auch hier wird unterschieden zwischen Anlagen, die erst ab einer bestimmten Größe in den Anwendungsbereich fallen, und solchen, bei denen dies nicht der Fall ist.

====== Größenabhängiger Anwendungsbereich ======

[[Datei:Nis ii wesentliche einrichtungen ri.png|mini|Wesentliche Einrichtungen - CC BY 4.0]][[Special:MyLanguage/Großes oder mittleres Unternehmen iSd NISG|Große oder mittlere Unternehmen]]
, die in den in den Anlagen 1 und 2 NISG genannten Sektoren tätig sind, gelten jedenfalls als wichtige Einrichtungen im Sinne des § 42 Abs 2 NISG.

Eine '''Teilmenge''' dieser Einrichtungen wird in § 24 Abs 1 NISG als wesentliche Einrichtung qualifiziert.

Von der Möglichkeit, bei der Umsetzung der NIS2-RL die bisherigen „Betreiber wesentlicher Dienste“ pauschal als wesentliche Einrichtungen einzustufen, oder Gemeinden und Bildungseinrichtungen in den Anwendungsbereich aufzunehmen, wurde abgesehen.<ref>ErlRV 326/ME XXVII. GP https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621119.pdf</ref>

====== Größenunabhängiger Anwendungsbereich ======

Unabhängig von der Größe der Einrichtung gelten gemäß § 24 Abs 1 Z 1 NISG qualifizierte Vertrauensdiensteanbieter, Namenregister der Domäne oberster Stufe (TLD Namenregister), Domänennamensystem-Diensteanbieter, Einrichtungen im Sektor der öffentlichen Verwaltung auf Bundesebene, Einrichtungen, die von der Cybersicherheitsbehörde als wesentliche Einrichtung eingestuft wurden (§ 26 Abs 1) sowie Einrichtungen, die als kritische Einrichtungen iSd Richtlinie (EU) 2022/2557 ([[Special:MyLanguage/Critical Entities‘ Resilience Directive (CER)|CER-RL]]) ermittelt wurden gelten als wesentliche Einrichtungen.

Darüber hinaus fallen öffentliche Stellen unter die in § 25 Abs 3 NISG genannten Kriterien. Vereinfacht ausgedrückt sind dies Bundes- und Landeseinrichtungen ohne gewerblichen Auftrag, deren Entscheidungen individuelle Rechte im grenzüberschreitenden Verkehr berühren.

====== Ausnahmen ======

Einrichtungen welche aufgrund sektorspezifischer unionsrechtlicher Rechtsakte verpflichtet sind, entweder eigene Risikomanagementmaßnahmen zu ergreifen oder erhebliche Cybersicherheitsvorfälle zu melden, hiernach zumindest ein gleichwertiges Cybersicherheitsniveau gewährleisten müssen, und die Gleichwertigkeit per Verordnung festgestellt wurde (§ 27 NISG). Das könnte etwa auf Einrichtungen zutreffen welche der [[Special:MyLanguage/Digital Operational Resilienec Act (DORA)|DORA]] unterworfen sind.

Einrichtungen im Sektor der öffentlichen Verwaltung, deren Tätigkeiten überwiegend in den Bereichen nationale Sicherheit, öffentliche Sicherheit, militärische Landesverteidigung oder Strafverfolgung ausgeübt werden sowie Einrichtungen des Universitäts-, Hochschul- und Schulwesens, Einrichtungen der Gerichtsbarkeit, Einrichtungen der Gesetzgebung, einschließlich der Parlamentsdirektion sowie der Österreichische Nationalbank gelten nicht als wesentliche oder wichtige Einrichtungen (§ 24 Abs 6 NISG).

====== Abgrenzungen ======

Einrichtungen, welche nicht unmittelbar in den Anwendungsbereich fallen, können im Rahmen vertraglicher Konstruktionen mit erfassten Einrichtungen zur Einhaltung der NIS2-RL verpflichtet werden. In diesen Fall sollte geprüft werden für welche Teile die Bestimmungen der so verpflichteten Einrichtung gelten sollten.

==== Territorialer Anwendungsbereich ====

Wesentliche und wichtige Einrichtungen sowie Einrichtungen, die Domänennamen-Registrierungsdienste erbringen, unterliegen den Bestimmungen dieses Hauptstücks nur hinsichtlich jener Niederlassungen, die sich in Österreich befinden (§ 28 NISG).

Abweichende Regelungen gelten für Anbieter öffentlicher Kommunikationsnetze, Anbieter öffentlich zugänglicher elektronischer Kommunikationsdienste, DNS-Diensteanbieter, TLD-Namenregister, Einrichtungen, die Domänennamen-Registrierungsdienste erbringen, Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter von verwalteten Diensten, Anbieter von verwalteten Sicherheitsdiensten sowie Anbieter von Online-Marktplätzen, Online-Suchmaschinen oder Plattformen für Dienste sozialer Netzwerke.

Siehe im Detail § 28 NISG.

====== Zeitlicher Anwendungsbereich ======

Die NIS2-RL ist zum aktuellen Bearbeitungszeitpunkt noch nicht in nationales österreichisches Recht umgesetzt worden.

== Zentrale Inhalte ==

=== Risikomanagementmaßnahmen ===

==== NIS2 Richtlinie ====

Bei der Regulierung von Risikomanagement-Maßnahmen wird ein risikobasierter Ansatz verfolgt, der die Verhältnismäßigkeit berücksichtigt.<ref>https://www.handelsverband.at/fileadmin/content/Presse_Publikationen/Presseaussendungen/2024/03_Mar/2024-03_HV_NIS2-Leitfaden_extra.pdf</ref> Das bedeutet, dass Unternehmen bei der Implementierung von Sicherheitsmaßnahmen folgende Faktoren beachten müssen:

* Den aktuellen Stand der Technik
* Die Kosten für die Einrichtung der Maßnahmen
* Die Größe der Einrichtung
* Die Wahrscheinlichkeit von Sicherheitsrisiken
* Weitere individuelle Faktoren

Die NIS2-RL definiert in Art 21 Absatz 2 zehn konkrete '''Maßnahmen und Mindeststandards''', deren Implementierung nationale Gesetzgeber fordern müssen.

Diese umfassen:

* Richtlinien zur Risikoanalyse und Informationssystemsicherheit
* Vorfallbehandlung
* Geschäftskontinuität
* Lieferkettenmanagement
* Richtlinien und Verfahren zur Bewertung der Wirksamkeit von Cybersicherheitsmaßnahmen
* Verwendung von Kryptografie und Verschlüsselung
* Personalsicherheit
* Zugriffskontrollen und Vermögensverwaltung
* Schulungen zur Cybersicherheit
* Sicherheit bei der Anschaffung
* Entwicklung und Wartung von Netzwerk- und Informationssystemen
* Gesicherte Authentifizierung und Kommunikation

==== Nationaler Umsetzungsentwurf (NISG) ====

Mit § 32 NISG wird Art 21 NIS2-RL umgesetzt.

§ 32 Abs 1 NISG verweist auf Anlage 3<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_3 https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621122.pdf</ref> zum Gesetz, welches eine mit Blick auf Art 21 NIS2-RL verfeinerte Liste an umzusetzenden Maßnahmen enthält. Hierbei hat sicher der Gesetzgeber stark an Ausarbeitungen auf europäischer Ebene im Rahmen der [https://digital-strategy.ec.europa.eu/de/policies/nis-cooperation-group NIS-Kooperationsgruppe] angelehnt.<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_2 https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621121.pdf S 33</ref> Gefordert werden organisatorische, technische und operative Maßnahmen.<ref>Als Beispiel für eine organisatorsiche Maßnahme nennen die Erwägungsgründe eine in Kraft gesetze Richtlinie. Unter einer technischen Maßnahme werden Firewalls verstanden, das Vorsehen einer fachkundigen Betriebsmannschaft ist eine operative Maßnahme.

326/ME XXVII. GP - Ministerialentwurf - Anlage_2 https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621121.pdf S 33</ref>

§ 32 Abs 2 NISG legt den betroffenen Einrichtungen auf, ein dem bestehenden Risiko angemessenes Sicherheitsniveau der Netz- und Informationssysteme zu gewährleisten, was den risikobasierten Ansatz bei der Umsetzung von Risikomanagementmaßnahmen unterstreicht.

Bei der Umsetzung von Risikomanagementmaßnahmen sind zu berücksichtigen:

* Der Stand der Technik (§ 32 Abs 2 Z 1 lit a NISG)
* Einschlägige nationale, europäische und internationale Normen (zB VO (EU) 1025/2012)
* Best-Practices (bewährte Verfahren und Methoden)

Die Kosten für die Umsetzung der Maßnahmen sollen in einem angemessenen Verhältnis zu den Risiken stehen, denen das betreffende Netz- und Informationssystem ausgesetzt ist (§ 32 Abs 2 Z 1 lit b NISG).<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_2 https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621121.pdf S 34</ref> Es sollen keine unverhältnismäßigen finanziellen und administrativen Belastungen entstehen.

Die Maßnahmen sollen auf einem gefahrenübergreifenden Ansatz beruhen und sowohl die '''Cybersicherheit''' als auch die '''physische Sicherheit''' berücksichtigen (§ 32 Abs 2 Z 2 NISG).

Dies umfasst:

* Schutz vor Systemfehlern, menschlichen Fehlern, böswilligen Handlungen und natürlichen Phänomenen
* Sicherheit des Personals
* Angemessene Zugangskontrollkonzepte

Besonderer Fokus liegt auf dem Risikomanagement in der Lieferkette (§ 32 Abs 2 Z 3 NISG):

* Bewertung von Schwachstellen bei Lieferanten und Anbietern
* Berücksichtigung der Gesamtqualität und Widerstandsfähigkeit von Produkten und Diensten
* Überprüfung der Cybersicherheitsverfahren und Entwicklungsprozesse von Lieferanten

Einrichtungen müssen Risiken und Abhängigkeiten in Beziehungen zu Dienstleistern identifizieren, bewerten und behandeln.

Prüfgegenstand sind Produkte und Dienste unmittelbarer Lieferanten und Anbieter. Soweit ein Produkt oder Dienst stark auf Subdienstleistern aufbaut, müssen diese notwendigerweise auch in den Prüfumfang fallen. Die Regelungen sind sowohl bei der Auswahl neuer Lieferanten oder Dienstleister als auch bei bestehenden vertraglichen Vereinbarungen zu beachten.<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_2 https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621121.pdf S 34</ref>

Einrichtungen können verpflichtet werden, der Cybersicherheitsbehörde eine Liste der implementierten Risikomanagementmaßnahmen zu übermitteln. Einrichtungen können verpflichtet werden, eine Prüfung durch eine unabhängige Stelle nachzuweisen, deren Prüfbericht durch ein Leitungsorgan zu zeichnen ist. Für wichtige Einrichtungengilt dies nur unter bestimmten Voraussetzungen (§ 33 NISG).

=== Governance-Verpflichtung und Haftung der Leitungsorgane ===

==== NIS2-Richtlinie ====

Die NIS2-RL führt spezifische Governance-Verpflichtungen ein, die sich auf die Leitungs- und Führungsebene beziehen und deren aktive Rolle unterstreicht.

Zu den Hauptaspekten gehören:

* Verantwortlichkeit: Die Unternehmensleitung (zB Vorstand, Geschäftsführung) ist für die Billigung und Überwachung der Umsetzung von Risikomanagement-Verpflichtungen verantwortlich.
* Persönliche Haftung: Bei Verstößen gegen diese Verpflichtungen können Leitungsorgane persönlich zur Verantwortung gezogen werden.
* Schulungspflicht: Leitungsorgane sind verpflichtet, an Cybersicherheitsschulungen teilzunehmen und diese auch ihren Mitarbeitenden anzubieten.
* Kompetenzerweiterung: Ziel der Schulungen ist es, ausreichende Kenntnisse und Fähigkeiten zur Erkennung und Bewertung von Cybersicherheitsrisiken sowie entsprechende Managementpraktiken zu vermitteln.
* Präventiver Ansatz: Durch die Stärkung der Kompetenzen auf Leitungsebene soll Gefahren im Bereich der Cybersicherheit vorgebeugt werden.

==== Nationaler Umsetzungsentwurf (NISG) ====

===== Begriff Leitungsorgan =====

Der Begriff "Leitungsorgans" beschreibe eine oder mehrere natürliche Personen welche nach Gesetz, Satzung oder Vertrag zur Führung der Geschäfte einer Einrichtung oder innerhalb der Einrichtung zur Überwachung der Geschäftsführung berufen sind (§ 3 Abs 1 Z 11 NISG). Einrichtung und Leitungsorgan können eine Personeneinheit bilden, so etwa ein*e Bundesminister*in.<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_2 https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621121.pdf S 6</ref> Die Definition zielt darauf ab, die tatsächliche Leitungs- und Geschäftsführungsebene zu erfassen (grundsätzlich Vorstand, Geschäftsführer*in oder Aufsichtsrat). Vertretungsbefugnis etabliert sohin kein Leitungsorgan.<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_2 https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621121.pdf S 7</ref>

===== Pflichten des Leitungsorgans =====

Das NISG legt den Leitungsorganen von wesentlichen und wichtigen Einrichtungen mehrere Pflichten auf:

* '''Implementierung von Maßnahmen''': Leitungsorgane müssen die Cybersicherheitsmaßnahmen ihrer Einrichtung genehmigen.<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_2 https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621121.pdf S 33</ref>

* '''Aufsicht über die Umsetzung''': Leitungsorgane sind verpflichtet, die Umsetzung der Cybersicherheitsmaßnahmen zu beaufsichtigen. Sie müssen sicherstellen, dass die beschlossenen Maßnahmen effektiv implementiert und eingehalten werden.<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_2 https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621121.pdf S 33</ref> Die Leitungsorgane müssen dafür Sorge tragen, dass Cybersicherheitsmaßnahmen ihrer Einrichtung sohin regelmäßig geprüft und aktuell gehalten werden. Es liegt in der Verantwortung der Leitungsorgane, ausreichende Ressourcen für die Umsetzung der erforderlichen Cybersicherheitsmaßnahmen bereitzustellen. Dies umfasst sowohl finanzielle als auch personelle Ressourcen. Die Verantwortung für die Ressourcenbereitstellung wird dahingehend konkretisiert, dass Leitungsorgane einen detaillierten Plan für die Zuweisung von finanziellen und personellen Ressourcen zur Cybersicherheit erstellen und regelmäßig aktualisieren müssen. Die Leitungsorgane sind für die Überwachung und Steuerung der Cybersicherheitsrisiken ihrer Einrichtung verantwortlich. Sie müssen sicherstellen, dass angemessene Risikobeurteilungen durchgeführt und entsprechende Maßnahmen ergriffen werden. Die Risikomanagementpflicht wird dahingehend konkretisiert, dass Leitungsorgane eine umfassende und detaillierte Bewertung der Cybersicherheitsrisiken ihrer Einrichtung durchführen müssen. Dies beinhaltet die Identifizierung kritischer Systeme und Prozesse sowie die Einschätzung potenzieller Auswirkungen von Cybervorfällen. Die Leitungsorgane müssen aktiv in die Entwicklung und regelmäßige Überprüfung von Notfallplänen für Cybervorfälle eingebunden sein. Sie tragen die Verantwortung für die Genehmigung dieser Pläne und müssen sicherstellen, dass diese regelmäßig getestet werden.
* '''Schulungen''': Leitungsorgane müssen an Schulungen zur Cybersicherheit teilnehmen, um sich Wissen und Fähigkeiten Bereich der Cybersicherheit anzueignen. Die Einrichtung hat dafür Sorge zu tragen, dass Mitarbeitende ausreichende Kenntnisse und Fähigkeiten zur Erkennung und Bewertung von Risiken sowie gegebenenfalls Managementpraktiken im Bereich der Cybersicherheit und deren Auswirkungen auf die von der Einrichtung erbrachten Dienste erwerben.
* '''Rechenschaftspflicht''': Die Leitungsorgane tragen die Verantwortung für die Einhaltung der Cybersicherheitsverpflichtungen ihrer Einrichtung. Eine Verletzung dieser Pflichten hat die schadenersatzrechtliche Haftung für schuldhaft verursachten Schaden, der der Einrichtung dadurch entstanden ist, zur Folge,<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_2 <nowiki>https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621121.pdf</nowiki> S 33</ref> sofern nicht ohnehin eine Haftung nach dem Organhaftpflichtgesetz (OrgHG), BGBl 181/1967 besteht.
* '''Ressourcenbereitstellung''': Durch diese Pflichten und Verantwortlichkeiten soll sichergestellt werden, dass Cybersicherheit als strategische Priorität auf höchster Managementebene verankert wird und die notwendige Aufmerksamkeit und Unterstützung erhält.

=== Meldeverpflichtungen ===

==== NIS2-Richtlinie ====

Die NIS2-RL sieht verschiedene Meldepflichten für Sicherheitsvorfälle vor, die entweder 24 Stunden, 72 Stunden oder einen Monat betragen. Die Fristen sind grundsätzlich als Höchstfristen angelegt, in den meisten Fällen wird eine unverzügliche Meldung gefordert.

* Innerhalb von '''24 Stunden''' nach Kenntnisnahme eines erheblichen Sicherheitsvorfalls muss eine Frühwarnung an die zuständige nationale Behörde erfolgen. Diese soll Informationen darüber enthalten, ob kriminelle Hintergründe vermutet werden oder grenzüberschreitende Auswirkungen zu befürchten sind.
* Nach '''72 Stunden''' ist ein ausführlicherer Bericht fällig, der aktuelle Informationen, eine erste Bewertung, die Auswirkungen und gegebenenfalls Kompromittierungsindikatoren enthält.
* Innerhalb eines '''Monats''' nach der ersten Meldung muss ein Abschlussbericht übermittelt werden. Dieser soll eine detaillierte Beschreibung des Vorfalls, seine Klassifizierung, Schweregrad und Auswirkungen, sowie die getroffenen Abhilfemaßnahmen und mögliche grenzüberschreitende Auswirkungen umfassen.
Neben diesen Verpflichtungen zur Meldung besteht auch die Möglichkeit, in Bezug auf Sicherheitsvorfälle, Cyberbedrohungen und Beinahe-Vorfälle '''freiwillig Meldung''' an das CSIRT zu erstatten. Diese Option steht auch nicht wichtigen und nicht wesentlichen Einrichtungen zur Verfügung. Solche freiwilligen Meldungen können auch anonym erfolgen.

==== Nationaler Umsetzungsentwurf (NISG) ====

===== Meldung von Vorfällen an CSIRT =====

Meldepflichten werden durch §§ 34, 35, 37 NISG umgesetzt.

§ 34 Abs 1 NISG regelt die grundsätzliche Pflicht wesentlicher und wichtiger Einrichtungen dem für sie zuständigen sektorenspezifischen CSIRT, andernfalls dem nationalen CSIRT, unverzüglich jeden erheblichen Cybersicherheitsvorfall (§ 35) zu melden. Eine [https://www.nis.gv.at/fragen-und-antworten/computer-notfallteams.html Liste der CSIRTS iSd NISG] unterhält aktuell das Bundeskanzleramt.

Die Meldung unverzüglich, spätestens jedoch '''binnen 24 Stunden''' als Frühwarnung erfolgen, gefolgt von einer detaillierteren Meldung '''innerhalb von 72 Stunden''' und einem Abschlussbericht innerhalb '''eines Monats''' nach der Meldung. Sofern einen Monats nach der Meldung der Cybersicherheitsvorfall noch andauert, ist der Abschlussbericht als Fortschrittsbericht zu formulieren und der Abschlussbericht einen Monat nach Bewältigung des Cybersicherheitsvorfalls zu übermitteln.

====== Inhalte der Meldungen: ======

* '''Frühwarnung''': Angabe ob der Verdacht besteht, dass der erhebliche Cybersicherheitsvorfall auf rechtswidrige und schuldhafte Handlungen zurückzuführen ist oder grenzüberschreitende Auswirkungen haben könnte
* '''Meldung''': Aktualisierung der Frühwarnung und erste Bewertung des erheblichen Cybersicherheitsvorfalls (Schweregrads und seiner Auswirkungen, sowie gegebenenfalls der Kompromittierungsindikatoren)
* '''Abschlussbericht''': Ausführliche Beschreibung des Cybersicherheitsvorfalls, einschließlich seines Schweregrads und seiner Auswirkungen, Angaben zur Art der Bedrohung und zugrundeliegender Ursachen, die wahrscheinlich den Cybersicherheitsvorfall ausgelöst hat; Angaben zu den getroffenen und laufenden Abhilfemaßnahmen; gegebenenfalls die grenzüberschreitenden Auswirkungen des Cybersicherheitsvorfalls.

Weiterleitungen einer Alarmierung an den Betreiber stellt keine Meldung (freiwillig oder verpflichtend) eines Cybersicherheitsvorfalls iSd § 34 NISG dar.<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_2 <nowiki>https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621121.pdf</nowiki> S 21</ref>

===== Meldung von Vorfällen an Betroffene =====

Soweit ein erheblicher Cybersicherheitsvorfall die Erbringung des jeweiligen Dienstes der betroffenen Einrichtung beeinträchtigt, unterrichtet die Einrichtung die Empfänger ihrer Dienste unverzüglich über diesen erheblichen Cybersicherheitsvorfall und teilt, soweit möglich, alle Maßnahmen oder Abhilfemaßnahmen mit, die diese Empfänger als Reaktion auf diese Bedrohung ergreifen können.

====== Erheblicher Cybersicherheitsvorfall ======

Ein Cybersicherheitsvorfall gilt nach § 35 NISG als erheblich, wenn der Sicherheitsvorfall:

* Schwerwiegende Betriebsstörungen der erbrachten Dienste oder schwerwiegende finanzielle Verluste für die betreffende Einrichtung verursacht hat oder verursachen kann

'''oder'''

* andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat oder beeinträchtigen kann. Zudem sind die betroffenen Netz- und Informationssysteme und deren Bedeutung für die Erbringung der Dienste der jeweiligen Einrichtung, die Schwere und die technischen Merkmale der Cyberbedrohung und sämtliche zugrundeliegende Schwachstellen, die ausgenutzt werden, sowie die Erfahrungen der Einrichtung mit ähnlichen Vorfällen zu berücksichtigen.

Folgende weitere Kriterien sind in § 35 Abs 2 und 3 NISG beschrieben:

* Ausmaß der Abhängigkeit;
* die möglichen Auswirkungen von Cybersicherheitsvorfälle;
* Marktanteil der jeweiligen Einrichtung mit Bezug auf den betroffenen Dienst;
* das betroffene geografische Gebiet;
* unternehmens- und sektorspezifischen Faktoren.
* Soweit vorhanden: Verordnung der*des Bundesminister(s)*in für Inneres kann weitere Kriterien normieren.

Eine gewisse Auslegungshilfe bietet auch [https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX%3A32022L2555 ErwGr 101 NIS2-RL].

Daneben definiert die [https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402690 Durchführungsverordnung (EU) 2024/2690] für bestimmte Einrichtungen was als erheblicher Sicherheitsvorfall zu qualifizieren ist.

== Fallbeispiel ==

Das Unternehmen NisExperts AG ist ein Anbieter von IT-Diensten mit Sitz in der Steiermark, beschäftigt 66 Mitarbeitende und erzielt eine Jahresbilanzsumme von neun Millionen Euro. NisExperts AG betreibt mehrere Rechenzentren, in welchen die IT-Infrastruktur für mehrere österreichische Krankenhäuser und das Netzleitsystem eines wichtigen steirischen Netzbetreibers untergebracht ist. Freitagnachmittag um 16:00 Uhr registriert das Security Operations Center (SOC) von NisExperts AG eine ungewöhnlich hohe Anzahl von Anfragen, die gegen die Firewalls eines Rechenzentrums gerichtet sind. Nach einer Analyse stellt sich heraus, dass es sich um eine DDoS-Attacke (Distributed Denial of Service) handelt, die eine zentrale Plattform des Unternehmens ins Visier nimmt.

Die Angreifer*innen setzen sogenannte Botnets ein, um die Ressourcen des Rechenzentrums zu überlasten. Trotz bestehender DDoS-Abwehrmaßnahmen gelingt es den Angreifer*innen, die Last zeitweise so hoch zu treiben, dass folgende Auswirkungen auftreten:

* Zwischen 17:00 Uhr und 20:00 Uhr kommt es zu wiederholten Ausfällen eines zentralen Zugriffsdienstes, der von Kunden genutzt wird, um Anwendungen in auszuführen.
* Kunden berichten von Verbindungsabbrüchen, langsamen Ladezeiten und der Unfähigkeit, kritische Daten zu verarbeiten und müssen Notfallpläne aktivieren.

'''Anwendungsbereich:'''

Gemäß § 24 Abs 2 NISG gelten Einrichtungen welche ein mittleres Unternehmen das in einem Sektor mit hoher Kritikalität gemäß den Anlagen 1 und 2 zum NISG tätig ist betriben als wichtige Einrichtungen. Eine Einrichtung gilt gemäß § 25 NISG unter anderem als „mittleres Unternehmen“, wenn sie zumindest 50 Mitarbeitende beschäftigt. Die NisExperts AG beschäftigt mehr als 50 Mitarbeitende und ist in einem Sektor mit hoher Kritikalität (Digitale Infrastruktur - Rechenzentrumsdienste) gemäß Z 8 Anlage 1 NISG tätig. Ob der Kund*innenstruktur könnte sich eine Störung des von der Einrichtung erbrachten Dienstes wesentlich auf die öffentliche Ordnung und die öffentliche Gesundheit auswirken, das bewirkt aber für sich keine Qualifizierung als "wesentliche Einrichtung". Die NisExperts AG ist sohin als wichtige Einrichtung iSd NISG zu qualifizieren.

'''Meldung:'''

Wichtige Einrichtungen haben gemäß § 34 NISG dem für sie zuständigen CSIRT, andernfalls dem nationalen CSIRT, unverzüglich jeden erheblichen Cybersicherheitsvorfall zu melden. Bei der Beurteilung, ob ein Cybersicherheitsvorfall als erheblich im Sinne des einzustufen ist, sind gemäß § 35 Abs 2 lit b NISG unter anderem die möglichen Auswirkungen auf die öffentliche Ordnung und Sicherheit und die öffentliche Gesundheit oder die Gesundheit der Bevölkerung oder eines großen Personenkreises zu berücksichtigen. Da die NisExperts AG ein kritischer Dienstleister für mehrere Krankenhäuser und der Ausfall die Aktivierung von Notfallplänen bedingt hat liegt wohl ein erheblicher Sicherheitsvorfall iSd § 35 NISG vor. Gemäß Art 8 [https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=OJ:L_202402690 Durchführungsverordnung (EU) 2024/2690] liegt ein erheblicher Sicherheitsvorfall dann vor, wenn Verfügbarkeit eines Rechenzentrumsdienstes eines vom Anbieter betriebenen Rechenzentrums ist für eine Dauer von mehr als einer Stunde eingeschränkt. Das liegt vor, weshalb jedenfalls ein erheblicher Sicherheitsvorfall vorliegt. In Ermangelung eines sektoralen CSIRT setzt NisExperts AG gemäß § 34 NISG folgende Meldungen an das nationale CSIRT (cert.at) ab.

'''Erstmeldung innerhalb von 24 Stunden:'''

* '''Inhalt:''' Beschreibung des Vorfalls, erste Bewertung der Auswirkungen auf Verfügbarkeit und Integrität, und die initial ergriffenen Maßnahmen.
* '''Technische Details:''' Einschätzung der Angriffsart (DDoS), betroffene Systeme und die mögliche Angriffsquelle.

'''Aktualisierung innerhalb von 72 Stunden:'''

* '''Vertiefte Analyse:''' Klärung der Ursachen, präzise Darstellung der Schäden und der geplanten weiteren Schritte zur Eindämmung und Wiederherstellung.
* '''Bewertung der Auswirkungen:''' Spezifikation der Kundengruppen und ihrer Ausfälle.

'''Abschlussbericht innerhalb eines Monats:'''

* '''Ergebnisse:''' Dokumentation des gesamten Incident-Management-Prozesses.
* '''Lessons Learned:''' Empfohlene Präventionsmaßnahmen und zukünftige Strategien.

== Synergien ==

=== Meldepflichten ===

Die Meldepflichten der Datenschutz-Grundverordnung (DSGVO) und der NIS2-RL überschneiden sich, da beide Regelwerke Anforderungen an die Meldung von Sicherheitsvorfällen oder Datenschutzverletzungen enthalten, allerdings mit unterschiedlichen Schwerpunkten. Hier sind die wesentlichen Punkte, in denen sich die Meldepflichten beider Regelwerke überschneiden und voneinander unterscheiden:

====== Art der betroffenen Daten ======

* DSGVO: Nur relevant, wenn personenbezogene Daten kompromittiert werden (zB unbefugter Zugriff, Verlust oder Diebstahl von Daten).
* NIS2: Relevanz auch für Vorfälle, die die Verfügbarkeit, Integrität und Vertraulichkeit von Systemen betreffen, unabhängig davon, ob personenbezogene Daten betroffen sind. Es geht also um die Sicherstellung der allgemeinen IT-Sicherheit.

====== Bedingungen für die Meldung ======

* DSGVO: Eine Meldung ist erforderlich, wenn die Datenschutzverletzung ein Risiko für die Rechte und Freiheiten natürlicher Personen darstellt.
* NIS2-RL: Meldepflichten gelten bei signifikanten Vorfällen, die wesentliche Auswirkungen auf die Bereitstellung essenzieller Dienste haben könnten. Die Beurteilung eines Vorfalls als signifikant erfolgt auf Basis von Faktoren wie der Anzahl betroffener Nutzer*innen, der Dauer des Vorfalls und des verursachten wirtschaftlichen Schadens.

====== Überschneidungen ======

* Beide Regelwerke verlangen Meldungen bei Vorfällen, die die Vertraulichkeit, Integrität oder Verfügbarkeit betreffen.
* Bei Sicherheitsvorfällen, die sowohl IT-Systeme als auch personenbezogene Daten betreffen, kann eine doppelte Meldepflicht bestehen: einmal an die zuständige Datenschutzbehörde (DSGVO) und einmal an die Cybersicherheitsbehörde (NIS2).
* Bei Betreibern wesentlicher Dienste, die personenbezogene Daten verarbeiten, könnten somit Vorfälle unter beide Regelungen fallen, was bedeutet, dass sowohl die Datenschutzverletzung als auch der Sicherheitsvorfall gemeldet werden müssen.

Die Meldepflichten der DSGVO und der NIS2-RL überschneiden sich in Fällen, in denen personenbezogene Daten durch Sicherheitsvorfälle gefährdet sind.

=== Risikomanagement ===

Die Risikomanagementanforderungen der Datenschutz-Grundverordnung (DSGVO) und der NIS2-RL überschneiden sich in bestimmten Bereichen, insbesondere wenn es um den Schutz von Daten und IT-Systemen geht. Beide Regelwerke erfordern von Organisationen, dass sie Maßnahmen zum Schutz von Informationen und zur Risikominimierung implementieren, allerdings mit unterschiedlichen Schwerpunkten. Hier sind die wichtigsten Überschneidungen und Unterschiede der Risikomanagementanforderungen:

* DSGVO: Der Fokus liegt auf dem Schutz personenbezogener Daten und den Rechten natürlicher Personen. Risikomanagement unter der DSGVO zielt darauf ab, das Risiko für die Rechte und Freiheiten von Einzelpersonen, die durch die Verarbeitung ihrer personenbezogenen Daten betroffen sind, zu minimieren.
* NIS2-RL: Die NIS2-RL konzentriert sich auf die Cybersicherheit und den Schutz der Netz- und Informationssysteme in kritischen Sektoren (zB Energie, Gesundheit, Verkehr). Risikomanagement hier zielt darauf ab, die Resilienz von IT-Systemen und kritischen Infrastrukturen gegen Cyberbedrohungen zu stärken.

====== Risikobasierter Ansatz ======

Beide Regelwerke verlangen von den betroffenen Unternehmen, dass sie risikobasierte Ansätze verfolgen, um Sicherheitsmaßnahmen zu planen und umzusetzen.

* DSGVO: Die DSGVO verpflichtet Unternehmen dazu, angemessene technische und organisatorische Maßnahmen zu ergreifen, die dem Risiko für die Rechte und Freiheiten natürlicher Personen angemessen sind. Dies bedeutet, dass Unternehmen die potenziellen Risiken für personenbezogene Daten bewerten und basierend darauf Schutzmaßnahmen wie Verschlüsselung, Pseudonymisierung, Zugriffskontrollen und Datensicherungen implementieren. (Art 24, 32 DSGVO)
* NIS2-RL: NIS2-RL verlangt von Unternehmen, ein Risikomanagement für ihre Netz- und Informationssysteme zu betreiben, das sich an den potenziellen Cyberrisiken orientiert. Es geht um die Gewährleistung der Verfügbarkeit, Integrität und Vertraulichkeit von Systemen und Informationen. Organisationen müssen Maßnahmen wie Netzwerksicherheitskontrollen, Bedrohungserkennungssysteme und Notfallpläne implementieren. (Art 21 NIS2-RL)

====== Konkrete Sicherheitsmaßnahmen ======

* DSGVO: Die DSGVO fordert spezifische Sicherheitsmaßnahmen für den Schutz personenbezogener Daten, einschließlich der Pseudonymisierung und Verschlüsselung, und verlangt, dass Unternehmen Maßnahmen zur Wiederherstellung der Datenverfügbarkeit nach einem physischen oder technischen Vorfall haben (Art 32 DSGVO). Die Anforderungen zielen direkt auf den Schutz von personenbezogenen Daten ab.
* NIS2: Die NIS2-RL legt Wert auf Cybersicherheitsmaßnahmen und operative Resilienz. Hierzu gehören Maßnahmen zur Sicherung der Netzwerk- und Informationssysteme gegen Bedrohungen, die Implementierung von Überwachungssystemen zur Bedrohungserkennung und die Sicherstellung von Redundanzen und Kontinuität der Dienste. Diese Maßnahmen sind breiter gefasst und betreffen nicht nur personenbezogene Daten, sondern die gesamte IT-Infrastruktur eines Unternehmens.

====== Risikobewertung und Dokumentation ======

* DSGVO: Unternehmen sind verpflichtet, eine Datenschutz-Folgenabschätzung (DSFA) durchzuführen, wenn die Datenverarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten der betroffenen Personen darstellt. Dies umfasst eine detaillierte Bewertung der Risiken und die Implementierung von Maßnahmen zur Risikominimierung. (Art 35 DSGVO)
* NIS2-RL: Organisationen müssen regelmäßig eine Risikobewertung ihrer Netz- und Informationssysteme durchführen, um potenzielle Cybersicherheitsrisiken zu identifizieren und entsprechend darauf zu reagieren. Diese Risikobewertungen müssen umfassender sein, da sie alle potenziellen Risiken für die kritischen IT-Infrastrukturen eines Unternehmens berücksichtigen.

====== Betroffene Unternehmen ======

* DSGVO: Jedes Unternehmen, das personenbezogene Daten verarbeitet, ist verpflichtet, entsprechende Sicherheitsmaßnahmen und ein Risikomanagement zu implementieren. Hierbei handelt es sich um eine breite Anforderung, die nahezu alle Organisationen betrifft.
* NIS2-RL: Die NIS2-RL gilt nur für Betreiber wesentlicher und wichtiger Dienste in kritischen Sektoren, wie Energieversorgung, Verkehr, Banken und Gesundheitswesen. Das Risikomanagement richtet sich hier primär an Organisationen, die für die Sicherheit von Infrastrukturen von großer Bedeutung verantwortlich sind.

====== Technische und organisatorische Maßnahmen ======

Beide Regelwerke fordern angemessene technische und organisatorische Maßnahmen, um Risiken zu minimieren, jedoch mit unterschiedlichen Schwerpunkten:

* DSGVO: Der Fokus liegt auf dem Schutz der Vertraulichkeit, Integrität und Verfügbarkeit von personenbezogenen Daten. Unternehmen müssen Maßnahmen ergreifen, um unbefugten Zugriff auf Daten zu verhindern, Datensicherheit sicherzustellen und Maßnahmen zur Datenwiederherstellung bei Zwischenfällen zu implementieren.
* NIS2-RL: Hier liegt der Fokus auf dem Schutz der IT-Systeme selbst, mit besonderem Augenmerk auf der Gewährleistung der Dienstverfügbarkeit und der Widerstandsfähigkeit gegen Cyberangriffe. Dies beinhaltet auch regelmäßige Sicherheitsüberprüfungen, Schwachstellenmanagement und Notfallmaßnahmen.

====== Überschneidungen ======

* Risikobewertung: Beide Regelungen verlangen eine risikobasierte Einschätzung und eine darauf basierende Umsetzung von Schutzmaßnahmen. Das Risikomanagement in beiden Fällen erfordert die Identifizierung potenzieller Bedrohungen und Schwachstellen sowie die Implementierung geeigneter Maßnahmen.
* Sicherheitsmaßnahmen: Technische und organisatorische Maßnahmen zur Minimierung von Risiken für IT-Systeme und Datenverarbeitung sind in beiden Regelwerken gefordert, insbesondere Maßnahmen zur Gewährleistung von Vertraulichkeit, Integrität und Verfügbarkeit.
* Dokumentationspflichten: Sowohl die DSGVO als auch die NIS2-RL fordern eine umfassende Dokumentation der Sicherheitsmaßnahmen und Risikobewertungen, um im Falle von Prüfungen oder Vorfällen nachweisen zu können, dass die Anforderungen erfüllt wurden.

Die Risikomanagementanforderungen der DSGVO und NIS2-RL überschneiden sich in Bezug auf die Notwendigkeit, Risiken zu bewerten und angemessene Schutzmaßnahmen zu implementieren, insbesondere wenn personenbezogene Daten durch Sicherheitsvorfälle oder Cyberangriffe bedroht sind. Unternehmen, die sowohl unter die DSGVO als auch unter NIS2 fallen, müssen ihre Risikomanagementstrategien so gestalten, dass sie beiden Regelwerken gerecht werden. Während die DSGVO den Schutz von personenbezogenen Daten betont, legt NIS2 den Fokus auf die Resilienz der IT-Systeme und die allgemeine Cybersicherheit. Dennoch ist eine Schnittmenge der Risiken in beiden Bereichen einschlägig. So ist es zu prüfen, ob in einem Bereich erhobene Risiken auch im anderen Bereich relevant sein können.

== Sanktionen ==

=== NIS2-Richtlinie ===

Die Höhe der Bußgelder unterscheidet sich je nach Einstufung des Unternehmens:

* Sanktionen für wesentliche Einrichtungen: Wesentliche Einrichtungen müssen bei Verstößen mit Bußgeldern von bis zu 10 Millionen Euro oder 2% des weltweiten Jahresumsatzes rechnen, je nachdem, welcher Betrag höher ist.
* Sanktionen für wichtige Einrichtungen: Für wichtige Einrichtungen beträgt das maximale Bußgeld bis zu 7 Millionen Euro oder 1,4% des weltweiten Jahresumsatzes, wobei auch hier der höhere Betrag maßgeblich ist.
Neben den Geldstrafen kann die zuständige Behörde weitere Schritte einleiten:

* Erteilung verbindlicher Anweisungen zur Einhaltung der Richtlinie
* Vorübergehende Aussetzung der Geschäftstätigkeit bei Nichtbefolgung von Anweisungen
* Temporäres Tätigkeitsverbot für Personen in Leitungsfunktionen
* Leitungsorgane von Unternehmen, wie Vorstände oder Geschäftsführer*innen, können persönlich für die Einhaltung der Cybersicherheitsmaßnahmen haftbar gemacht werden.

=== Nationaler Umsetzungsentwurf (NISG) ===

Wird der Cybersicherheitsbehörde im Zuge ihrer Aufsicht erkennbar, dass eine wesentliche oder wichtige Einrichtung ihren Verpflichtungen nach diesem Bundesgesetz nicht nachkommt hat diese entsprechend § 39 Abs 1 bis 4 vorzugehen.

Die Einrichtung ist zunächst darauf hinzuweisen, bestimmte spezifische Umsetzungsmaßnahmen oder Adaptierungen im Bereich konkreter Risikomanagementmaßnahmen und bezüglich der Einhaltung von Berichtspflichten oder sonstigen Pflichten zu treffen.

Wird dem nicht nachgekommen, hat dies zur Folge, dass die angeordnete Maßnahme, wie etwa die (vollständige) Umsetzung jeweiliger Risikomanagementmaßnahmen durch die Cybersicherheitsbehörde mit Bescheid angeordnet werden.

Kommt eine wesentliche Einrichtung dem Bescheid nicht fristgerecht und nachweislich nach, ist die Cybersicherheitsbehörde befugt,

* zuständige Behörden zu ersuchen, die Zertifizierung oder Genehmigung für einen Teil oder alle von der Einrichtung erbrachten einschlägigen Dienste (einschließlich der Cybersicherheitszertifizierung gemäß Art 58 der Verordnung (EU) 2019/881) oder Tätigkeiten vorübergehend auszusetzen

oder

* einem Leitungsorgan der Einrichtung mit Bescheid untersagen, seine Leitungsaufgaben in dieser wesentlichen Einrichtung wahrzunehmen. Dieser Bescheid ist in einer allgemeinen Weise zu veröffentlichen, die geeignet erscheint, einen möglichst weiten Personenkreis zu erreichen.

==== Private Einrichtungen ====

§ 45 Abs 1 bis 3 NISG enthält einen Katalog an Verwaltungsübertretungen welche folgendermaßen zu sanktionieren sind:

* Verwaltungsübertretung wesentlicher Einrichtung: Geldstrafe in Höhe von bis zu 10 000 000 EUR oder bis zu 2 % des gesamten weltweiten im vorangegangenen Geschäftsjahr getätigten Umsatzes des Unternehmens, dem die wesentliche Einrichtung angehört, je nachdem, welcher Betrag höher ist.

* Verwaltungsübertretung wichtiger Einrichtung: Geldstrafe in Höhe von bis zu 7 000 000 EUR oder bis zu 1,4 % des gesamten weltweiten im vorangegangenen Geschäftsjahr getätigten Umsatzes des Unternehmens, dem die wichtige Einrichtung angehört, je nachdem, welcher Betrag höher ist.

§ 45 Abs 4 NISG enthält einen zusätzlichen Katalog an Verwaltungsübertretungen (insb. Missachtung von Duldungs und Dokumentationspflichten) welche folgendermaßen zu sanktionieren sind:

* Geldstrafe bis zu 50 000 EUR und im Wiederholungsfall bis zu 100 000 EUR .

==== Öffentliche Einrichtungen ====

§ 46 NISG sieht die Anzeige der Nichteinhaltung bei zuständiger Bezirksverwaltungsbehörde durch Bundesminister*in für Inneres und Feststellung der Rechtswidrigkeit durch Bezirksverwaltungsbehörde vor. Entsprechende Feststellungsbescheide sind zu veröffentlichen, als diese keine Gefahr für die öffentliche Ordnung oder Sicherheit darstellt. Der Sanktionscharakter dieser Bestimmung soll in dem durch die Veröffentlichung entstehenden öffentlichen und politischen Druck auf die jeweilige Behörde zum Ausdruck kommen.<ref>326/ME XXVII. GP - Ministerialentwurf - Anlage_2 <nowiki>https://www.parlament.gv.at/dokument/XXVII/ME/326/fname_1621121.pdf</nowiki> S 42</ref>

== Weiterführende Literatur ==

=== Überblicksartikel ===

* ''Burgstaller'', Aktuelle Ereignisse und Entwicklungen zum Informationsrecht, ZIIR 2023/140/2.
* ''Gutbrunner'', Pflichten aus der NIS-2-RL, LexisNexis, 05/2024.
* ''Hessel/Callewaert/Schneider'', Die NIS-2-Richtlinie aus Unternehmensperspektive, RDi 2024, 208.
* ''Löffler'', NIS-2. Ein Überblick, dako 2024, 76.
* ''Pollirer'', Checkliste NIS-2, dako 2024, 43.
* ''Schmidt'', Neue europäische Anforderungen im Cybersicherheitsrecht - die NIS2-Richtlinie im Überblick, KuR 2023, 705.
* ''Stadler/Drolz'', Cyberregeln treffen auch Lieferanten, Der Standard 2024/18/01.
* ''Staffler'', Morgendämmerung der EU-Cybersicherheit-Compliance, JSt 2023/328/4.
* ''Tretzmüller'', Die Umsetzung des NIS-Gesetzes, Report 2019, https://www.kt.at/wp-content/uploads/2019/09/31-Kommentar-Tretzm%C3%BCller_Energie-Report-Sept-2019.pdf.

=== Schwerpunktartikel ===

* ''Dittrich,'' IT-Sicherheit und Krisenresilienz bei Energieversorgern und Energieanlagen MMR 2022, 1039.
* ''Knyrim/Briegl'', NIS-2: die Anwendung im Konzern, Dako 2024/39.
* ''Neuwirth'', Vom "wesentlichen Dienst" zur "wesentlichen" beziehungsweise "wichtigen" Einrichtung - und weitere ausgewählte Aspekte zur NIS-2-Richtlinie, jusIT 2024/2/5.
* ''Reiter'', Die NIS2-Richtlinie: Von Cybersicherheit und Haftung, Medien und Recht 2023/188/4.
* ''Reiter/Heidinger/Gstrein'', Die NIS2-Richtlinie: Von Cybersicherheit und Haftung, MR 2023, 188.
* ''Schiefer/Wieser'', NIS-2-RL. Wer trägt die Verantwortung im Unternehmen? ecolex 2023/568.
* ''Wegmann'', Too much of a good thing? Erweiterung und Verschärfung von Cybersicherheitsplichten durch die NIS2-Richtlinie, BB 2023, 835.
* ''Werner'', Anwendbarkeit der NIS-2 im chemischen Sektor, DSB 2024, 175.

=== Einführungswerke ===

* ''Kipker'', Textsammlung Cybersecurity (2023).

=== Sammelwerke ===

* ''Anderl'' (Hrsg), #Cybercrime. Handbuch für die Praxis (2023)
* ''Ditttrich/Dochow/Ippach'' (Hrsg), Rechtshandbuch Cybersicherheit im Gesundheitswesen (2024).
* ''Hornung/Schallbruch'' (Hrsg), IT-Sicherheitsrecht. Praxishandbuch2 (2024, iE).
* ''Kipker'' (Hrsg), Cybersecurity. Rechtshandbuch2 (2023).

=== Kommentare ===

* ''Anderl/Heußler/Mayer/Müller'', Netz- und Informationssystemsicherheitsgesetz NISG (2019) [zum Stand der ersten NIS-RL]

== Einzelnachweise ==

Cyber Resilience Act (CRA)/de

2025-06-04T00:49:19Z

FuzzyBot: Übernehme Bearbeitung einer neuen Version der Quellseite

<languages/>
{{Infobox Rechtsakt (EU)|Typ=Verordnung|Jahr=2024|Nummer=2847|Vertrag=EU|EWR=ja|Titel=Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen und zur Änderung der Verordnungen (EU) Nr. 168/2013 und (EU) 2019/1020 und der Richtlinie (EU) 2020/1828|Kurztitel=Cyber Resilience Act/Cyberresilienz-Verordnung|Bezeichnung=CRA|Rechtsmaterie=Binnenmarkt, Cybersicherheit|Grundlage=AEUV, insbesondere {{Art.|114|AEUV|dejure|}}
|Fundstelle=ABl L 2024/2847, 1|Anzuwenden=11. Dezember 2027 (mit Ausnahmen)|Gültig=inkraft}}

== Kurzübersicht ==

{| class="wikitable"
!Ziele
!Anwendungsbereich
!Inhalt<ref>https://www.nis.gv.at/nis-2-richtlinie.html</ref>
!Synergie
!Konsequenzen
|-
|Schwachstellen bei Produkten eindämmen.
|Sachlich: Produkte mit digitalen Elementen (Hard- oder Softwareprodukte) deren
Verwendung Datenverbindung mit einem Gerät oder Netz einschließt
|Angemessenes Sicherheitsniveau von Produkten, Absenz bekannter Schwachstellen
|
|Verstoß gegen Art 13 und 14 CRA; bis zu 15.000.000 € oder von bis zu 2,5 % des weltweit erzielten Vorjahresumsatzes.
|-
|Sicherheit während des gesamten Lebenszyklus eines Produkts sicherstellen.
|Persönlich: Hersteller, Händler und Einführer
|Versetzung in den Werkszustand muss (grundsätzlich) möglich sein.
|Sicherheit der Verarbeitung (Art 32 DSGVO), Technikgestaltung und Voreinstellung (Art 25 DSGVO)
|Verstoß gegen übrige Pflichten; bis zu 10.000.000 € oder 2 % des weltweit erzielten Vorjahresumsatzes
|-
|Bedingungen schaffen, die es den Nutzer*innen ermöglichen Cybersicherheit zu berücksichtigen.
|
|Sicherheitsbewertungen je nach Sicherheitsklasse
|Anforderungen der KI-VO (Art 6 iVm 15) für Hochrisiko-KI-Systeme
|Mangelhafte Auskünfte; bis zu 5.000.000 EUR oder 1 % des Vorjahresumsatzes
|-
|
|
|
|
|
|}

== Einführung ==

Der Cyber Resilience Act (CRA) folgt dem Ziel der Erhöhung der Cybersicherheit mit einheitlichen Cybersicherheitsanforderungen bei Produkten mit digitalen Elementen, vor allem bei Hard- und Software. Der CRA gibt vor, dass künftig '''alle vernetzen Produkte''' '''das''' '''CE-Kennzeichen''' tragen müssen. Das CE-Kennzeichen vermittelt nach außen, dass das vernetzte Produkt einen hinreichenden Schutz vor Cybergefahren gewährleistet.<ref>https://www.bmi.bund.de/SharedDocs/pressemitteilungen/DE/2024/10/cyber-resilience-act.html</ref>

Hersteller, Händler und Importeure werden gegenüber ihren Kund*innen gezwungen transparent aufzuzeigen, wie sicher ihre Produkte sind, Schwachstellen bekannt zu geben und dafür zu sorgen, dass diese beseitigt werden. Darüber hinaus müssen oben genannte Akteure gewährleisten, dass ihre Produkte über deren gesamten Lebenszyklus sicher vor Cyberangriffen sind.

== Anwendungsbereich ==

==== Sachlicher Anwendungsbereich ====

Die Verordnung gilt für Produkte mit digitalen Elementen (Hard- oder Softwareprodukte, und deren Datenfernverarbeitungslösungen, welche getrennt in Verkehr gebracht werden), deren bestimmungsgemäße oder vernünftigerweise vorhersehbare Verwendung eine direkte oder indirekte logische oder physische Datenverbindung mit einem Gerät oder Netz einschließt.

'''Physische Datenverbindungen''' sind jene, welche zwischen elektronischen Informationssystemen oder Komponenten hergestellt werden und physisch oder optisch greifbar sind.

'''Logische Verbindungen''' sind virtuelle Darstellungen einer Datenverbindung, welche über eine Softwareschnittstelle hergestellt werden.

====== Ausnahmen (Art 1 CRA): ======

# Produkte, die sektorspezifischen Regelungen unterliegen: Medizinprodukte | In-vitro-Diagnostika | Kraftfahrzeuge | Zivilluftfahrt | Schiffsausrüstungen
# Grundsätzlich überall dort wo sektorale Regeln einen gleichwertigen oder höheren Standard fordern.
# Identische Ersatzteile
# Produkte für Zwecke der nationalen Sicherheit oder Verteidigung oder für Produkte, die speziell für die Verarbeitung von Verschlusssachen bestimmt sind.

'''Beispiele:''' Vernetzte Kühlschränke oder Thermostate, Laptops, Smartphones, Tablets, Smart Watches

====== Spezialfall Open Source Software ======

Freie und quelloffene Softwareprodukte („Open-Source“), die außerhalb einer Geschäftstätigkeit entwickelt oder bereitgestellt werden, sind nicht verpflichtet.<ref>ErwGr 18 CRA-E: Finally, for the purposes of this Regulation, the development of products with digital elements qualifying as '''free and open-source software by not-for-profit organisations should not be considered to be a commercial activity provided that the organisation is set up in such a way that ensures that all earnings after costs are used to achieve not-for-profit objectives'''. This Regulation does not apply to natural or legal persons who contribute with source code to products with digital elements qualifying as free and open-source software that are not under their responsibility
</ref> Ein explizite Ausnahme wurde nicht aufgenommen, die Ausnahme ergibt sich implizit aus der Definition der "Geschäftstätigkeit" und wird ErwGr 18 CRA weiter präzisiert.

Produkte, die Open-Source-Produkte enthalten und in den Anwendungsbereich des CRA fallen, fallen als Ganzes - einschließlich der enthaltenen Open-Source-Produkte - in den Anwendungsbereich des CRA.

==== Persönlicher Anwendungsbereich ====

Betroffene Akteure sind primär Hersteller, Händler, Einführer von Produkten mit digitalen Elementen (Importeure) sowie Open-Source Stewards.

'''Hersteller''' ist, wer Produkte mit digitalen Elementen entwickelt, herstellt oder diese konzipiert und die Herstellung und Entwicklung beauftragt und jene Produkte unter ihrem Namen oder Markennamen vermarktet unentgeltlich oder monetarisiert (Art 3 Z 13 CRA).

'''Händler''' ist, wer Teil der Lieferkette ist und ein Produkt mit digitalen Elementen auf dem Unionsmarkt bereitstellt, ohne die Eigenschaften der Ware zu verändern. Hersteller und Einführer sind ausgenommen (Art 3 Z 17 CRA).

'''Importeur''' ist, wer ein Produkt mit digitalen Elementen einer außerhalb der Union befindende Person, Organisation oder Behörde erstmals am Unionsmarkt in Verkehr bringt (Art 3 Z 16 CRA).

'''Open-Source Steward''' ist eine juristische Person bei der es sich nicht um einen Hersteller handelt, die den Zweck oder das Ziel hat, die Entwicklung spezifischer Produkte mit digitalen Elementen, die als freie und quelloffene Software gelten und für kommerzielle Tätigkeiten bestimmt sind, systematisch und nachhaltig zu unterstützen, und die die Vermarktbarkeit dieser Produkte sicherstellt.“ (Art 3 Z 14 CRA).

Die Definition lässt eine Klassifizierung aufgrund objektiver Gesichtspunkte durch Außenstehende nur eingeschränkt zu. So wird es bei der Qualifizierung eher darauf ankommen ob die juristische Person im Rahmen der internen Zielsetzung eine Open-Source-Stewardship für ein Produkts annimmt. Nach Art 25 kann die Kommission durch delegierte Rechtsakte Sicherheitsbescheinigungen für Open Source Software erlassen, diesbezüglich sind Stand Oktober 2024 keine Details bekannt. Art 9 CRA sieht vor, dass die „Open Source Community“ als Stakeholder bei der Durchführung der Verordnung von der Kommission zu konsultieren ist. So sind neben den wirtschaftlichen Vorteilen des Stwardships auch konkrete Gestaltungsmöglichkeiten verbrieft.

Beispiele hierfür sind:

* Stiftungen, die bestimmte Open-Source Projekte unterstützen
* Unternehmen, die Open-Source für den eigenen Gebrauch entwickeln, aber öffentlich zugänglich machen
* Gemeinnützige Organisationen, die Open-Source entwickeln

==== Territorialer Anwendungsbereich ====

Gegenstand der Regelung ist die Bereitstellung eines Produkts mit digitalen Elementen auf dem Unionsmarkt.

== Wesentliche Pflichten: ==

==== Hersteller ====

Gem Art 13 Abs 1 müssen Hersteller gewährleisten, dass die Eigenschaften ihrer Hard- und Softwareprodukte '''Mindestsicherheitsanforderungen''' bei Konzeption, Entwicklung und Herstellung erfüllen. Hierbei Ist Annex I Teil I beachtlich, welcher auf die Schaffung eines angemessenen Sicherheitsniveaus abzielt.

Gem Art 13 Abs 8 stellen Hersteller beim Inverkehrbringen eines Produkts mit digitalen Elementen und während des Unterstützungszeitraums sicher, dass '''Schwachstellen''' dieses Produkts, einschließlich seiner Komponenten, wirksam und im Einklang mit den in Annex I Teil II festgelegten grundlegenden Anforderungen behandelt werden.

Gem Art 13 Abs 18 sind die '''Informationen''' des Annex II zu erteilen.

In Art 14 legt der CRA verschiedene '''Meldepflichten''' für Hersteller von Hard- und Softwareprodukten fest. Aktiv ausgenutzte Schwachstellen sind an die Agentur der Europäischen Union für Cybersicherheit (ENISA) zu melden:

* Frühwarnung innerhalb von 24 Stunden
* Benachrichtigung nach 72 Stunden
* Abschlussbericht innerhalb 14 Tage nach Behebung der Schwachstelle

Art 23 verpflichtet zur Führung einer umfassenden '''technischen Dokumentation'''. Diese Dokumentation muss nicht nur eine allgemeine Beschreibung des Produkts und seiner beabsichtigten Verwendung enthalten, sondern auch detaillierte Informationen zu den Aspekten des Produktdesigns, der Produktentwicklung und der Produktherstellung. Zudem ist eine gründliche Bewertung der Cybersicherheitsrisiken über den gesamten Lebenszyklus des Produkts erforderlich. Ein weiterer wichtiger Bestandteil der Dokumentation ist die Beschreibung der Verfahren zur '''Schwachstellenbehandlung'''. Hierzu gehören Informationen über das Design und die Entwicklung des Produkts, die gegebenenfalls durch Abbildungen, Schemata oder eine Beschreibung der Systemarchitektur ergänzt werden. Darüber hinaus muss ein Konzept für die koordinierte Offenlegung von Schwachstellen sowie Spezifikationen zu Herstellungs- und Überwachungsprozessen samt Validierung dokumentiert werden.

==== Händler ====

Ehe sie ein Hard- oder Softwareprodukt auf dem EU-Markt bereitstellen, müssen Händler gem Art 19 CRA sicherstellen:

* dass das Produkt ordnungsgemäß mit einer CE-Kennzeichnung versehen ist
* dass die EU-Konformitätserklärung vorhanden ist
* dass die Mindestinformation des Herstellers bzw. des Importeurs vorhanden ist
* dass ausführliche Anleitungen für Nutzer*innen vorhanden sind

Liegt aufgrund einer Schwachstelle ein '''erhebliches Cybersicherheitsrisiko''' vor, müssen Händler unverzüglich die Marktüberwachungsbehörden der Mitgliedstaaten unterrichten, in denen sie das Produkt vertreiben.

Wird bekannt, dass ein Hersteller seine '''Betriebstätigkeit einstellt''', müssen Händler die zuständigen Marktüberwachungsbehörden hiervon unterrichten.

==== Importeur ====

Importeure müssen vor dem Inverkehrbringen eines Produkts aktiv sicherstellen, dass:

* Der Hersteller eine Konformitätsbewertung durchgeführt hat
* Die erforderliche technische Dokumentation vorhanden ist
* Das Produkt die CE-Kennzeichnung trägt
* Eine Bedienungsanleitung und relevante Informationen beiliegen

Importeure müssen ihren Namen, eingetragenen Handelsnamen oder eingetragene Marke sowie ihre Kontaktadresse auf dem Produkt oder dessen Verpackung angeben.

Liegt aufgrund einer Schwachstelle ein erhebliches Cybersicherheitsrisiko vor, müssen Importeure unverzüglich die Marktüberwachungsbehörden der Mitgliedstaaten unterrichten, in denen sie das Produkt vertreiben.

==== Open-Source Steward (Verwalter quelloffener Software) ====

Open Source Software Stewards sollen einer passgenauen und milderen Regulierung unterliegen sollen als klassische kommerzielle Hersteller (ErwGr 19 CRA). Sie dürfen (eigenständig) keine CE-Kennzeichnung auf den Produkten mit digitalen Elementen anzubringen, deren Entwicklung sie unterstützen. (EG 20 CRA)

Art 24 CRA sieht folgende Pflichten vor:

* Dokumentierte Cybersicherheitsrichtlinie umsetzen, welche die sichere Entwicklung von Produkten, Umgang, Dokumentation, Behandlung und Behebung von Sicherheitslücken und den Austausch von Informationen über entdeckte Sicherheitslücken innerhalb der Open-Source-Gemeinschaft fördert (Art. 24 Abs. 1 CRA)
* Auf Ersuchen der Marktüberwachungsbehörden mit diesen zusammenarbeiten, um Cybersicherheitsrisiken zu mindern und auf begründeten Antrag die Cybersicherheitsrichtlinie zur Verfügung stellen (Art. 24 Abs. 2 CRA)

Die Meldepflichten des Art 14 Abs 1 CRA gelten insoweit, als Open-Source Stewards an der Entwicklung der Produkte mit digitalen Elementen beteiligt sind. Die Meldepflichten der Art 14 Abs 3 und 8 CRA gelten soweit Netz- und Informationssysteme betroffen sind, welche für die Entwicklung solcher Produkte bereitgestellt werden.

== Kategorisierung von Produkten und Pflichten ==

[[Datei:CRA Zertifizierungen ri.png|mini|Zertifizierungsschemata des Cyber Resilience Act - CC BY 4.0]]
Der CRA unterscheidet zwischen der „Standardkategorie“, wichtigen Produkten Klasse I und Klasse II, sowie kritischen Produkten.

==== Standardkategorie (Art. 2 CRA) ====

Zertifizierungsschema:

* Bei Standardprodukten kann der Hersteller von Hard- und Softwareprodukten die Konformitätsbewertung selbst auf der Grundlage eines internen Kontrollverfahrens gemäß Modul A durchführen.
* Alternativ können auch die Zertifizierungsschemata der Module B+C, oder Modul H freiwillig durchgeführt werden (Art 21 Abs 1 CRA)

==== Wichtige Produkte Klasse I (Art 7 CRA iVm Annex III Class I) ====

Beispiele:
* Passwortmanager
* Identitäts- und Zugangsmanagementsysteme
* Produkte mit digitalen Elementen, die eine VPN-Funktion haben
* Browser
* Antiviren-Programme
* SIEM-Tools (Security Information and Event Management)
* Public-Key-Infrastruktur und Aussteller digitaler Zertifikate
* Mikroprozessoren mit sicherheitsrelevanten Funktionalitäten (CPUs)
* Mikrocontroller mit sicherheitsrelevanten Funktionalitäten (MCUs)
Zertifizierungsschema:

* Harmonisierte EU-Zertifizierungsstandards können auf Produkte dieser Klasse angewendet werden (Art 32 Abs. 3 lit c iVm Art 27 Abs 9 CRA). Zwar eliminiert Art 27 Abs 9 CRA die Verpflichtung des Herstellers zur Durchführung einer Konformitätsbewertung durch einen Dritten bei Anwendung des EU-Zertifizierungsstandards Vertrauenswürdigkeitsstufe „mittel“ doch sieht diese Zertifizierungsstufe eine Überprüfung durch Dritte vor (vgl. Art 53 Cybersecurity Act).
* Sind diese nicht vorhanden, hat eine unabhängige Zertifizierung nach Modul B+C oder Modul H zu erfolgen (Art 32 Abs 2 lit a und b iVm Art 27 Abs 9 CRA).

==== Wichtige Produkte Klasse II (Art 7 CRA iVm Annex III Class II) ====

Beispiele:
* Firewalls
* Hypervisor / Containervirtualisierungssysteme
* Manipulationsgeschützte Mikroprozessoren (CPUs)
* Manipulationsgeschützte Mikrocontroller (MCUs)
Zertifizierungsschema:

* Harmonisierte EU-Zertifizierungsstandards können auf Produkte dieser Klasse angewendet werden (Art 32 Abs. 3 lit c iVm Art 27 Abs 9 CRA). ErwGr 92 CRA folgend sollte bei der Konformitätsbewertung wichtiger Produkte der Klasse II immer eine dritte Partei involviert sein. Zwar eliminiert Art 27 Abs 9 CRA die Verpflichtung des Herstellers zur Durchführung einer Konformitätsbewertung durch einen Dritten bei Anwendung des EU-Zertifizierungsstandards Vertrauenswürdigkeitsstufe „mittel“ doch sieht diese Zertifizierungsstufe eine Überprüfung durch Dritte vor (vgl. Art 53 Cybersecurity Act).
* Allenfalls hat eine unabhängige Zertifizierung nach Modul B+C oder Modul H zu erfolgen (Art 32 Abs 3 lit a und b iVm Art 27 Abs 9 CRA).

==== Kritische Produkte (Art 8 CRA iVm Annex III iVm Annex IV) ====

Beispiele:

# Hardware Security Modules (HSMs)
# Smart Meter
# Smartcards

Zertifizierungsschema:

* Soweit durch die EU-Kommission gemäß Art 8 Abs 1 CRA vorgegeben, können harmonisierte EU-Zertifizierungsstandards auf Produkte dieser Klasse angewendet werden (Art 32 Abs 4 lit a iVm Art 8 Abs 1 CRA)
* Sind diese nicht vorhanden, hat eine unabhängige Zertifizierung nach harmonisierten EU-Zertifizierungsstandards, Modul B+C oder Modul H zu erfolgen (Art 32 Abs. 4 lit b iVm Art 32 Abs 3 CRA)

== Synergien ==

====== [[Special:MyLanguage/Artificial Intelligence Act (AIA)|Artificial Intelligence Act (KI Verordnung)]] ======

* Für Hochrisiko-KI-Systeme, die gleichzeitig unter den CRA fallen, gibt es eine spezielle Regelung: Die Cybersicherheitsanforderungen des Art 15 AI Act gelten als erfüllt, wenn alle Vorgaben des CRA eingehalten und soweit sie durch das Konformitätsbewertungsverfahren abgedeckt sind. Die Konformität wird gemäß Art 12 Abs 1 lit c CRA nur soweit bescheinigt als die Anforderungen des Konformitätsverfahrens die Anforderungen des Art 15 AI Act abdecken. Wo dies der Fall ist, muss jedoch im Einzelfall geprüft werden.

====== DSGVO ======

* Sowohl Art 32 DSGVO als auch Art 13 CRA verfolgen einen risikobasierten Ansatz. Die zu ergreifenden Maßnahmen sollen dem Risiko angemessen sein und verschiedene Faktoren berücksichtigen. Annex I Abs 1 CRA fordert ein angemessenes Sicherheitsniveau. Dies trifft auch auf Art 32 DSGVO zu, anders als Annex I Abs 1 CRA erwähnt dieser aber auch explizit, dass bei der Betrachtung insbesondere auch die Implementierungskosten einzubeziehen sind.

== Konsequenzen/Strafen ==

Gemäß Art 52 Abs 1 CRA haben die MS Vorschriften über Sanktionen zu erlassen, die bei Verstößen der Wirtschaftsakteure gegen diese Verordnung zu verhängen sind und treffen die zur Durchsetzung erforderlichen Maßnahmen.

Die Höhe der '''Geldbußen''' ist in Art 64 Abs 2 – 5 CRA geregelt. Bei Nichteinhaltung der Anforderungen in Anhang I oder bei Verstößen gegen die Pflichten des Herstellers in Art 13 und 14 CRA sind Geldbußen von bis zu 15.000.000 € oder von bis zu 2,5 % des gesamten weltweit erzielten Vorjahresumsatzes zu verhängen.

Bei Verstößen gegen die übrigen Pflichten des CRA können Geldbußen von bis zu 10.000.000 € oder 2 % des weltweit erzielten Vorjahresumsatzes verhängt werden.

Die Erteilung unrichtiger, unvollständiger oder irreführender Auskünfte an notifizierte Stellen und Marktüberwachungsbehörden in Beantwortung einer Aufforderung wird mit Geldbußen bis zu 5.000.000 EUR oder bis zu 1 % des gesamten weltweit erzielten Vorjahresumsatzes bestraft.

Die Aufsicht über Open-Source-Stewards obliegt gemäß Art 52 Z 3 CRA den Marktüberwachungsbehörden, diese können nach Art 64 Z 10 lit b CRA keine Geldbußen verhängen.

== Weiterführende Literatur ==

=== Überblicksartikel ===

*''Erdelt'', Meldepflichten des Cyber Resilience Acts, ZfPC 2024, 176.
* ''Piltz/Weiß/Zwerschke'', Der Vorschlag für einen Cyber Resilience Act aus Sicht der DSGVO, CR 2023, 289.
* ''Poncza'', Der Entwurf des Cyber Resilience Act, ZfPC 2023, 44.
* ''Ruttloff/Wagner/Stilz'', Der Entwurf des Cyber Resilience Act (CRA) und seine Auswirkungen auf das Gewährleistungs- und Produkthaftungsrecht, BB 2024, 1603.
* ''Schöttle'', Cyber Resilience Act, Produkthaftungsrichtlinie und andere Baustellen für die Open Source Communities, ZfPC 2023, 215.
* ''Siglmüller'', Cyber Resilience Act und Digital Operational Resilience Act. Lässt sich IT-Sicherheit rechtlich erzwingen? ZfPC 2023, 221.
* ''Voigt/Falk'', Der Cyber Resilience Act, MMR 2023, 88.
* ''Wiebe/Daelen'', Der Cyber Resilience Act aus produktsicherheitsrechtlicher Perspektive, EuZW 2023, 257.
* ''Zußner'', Das Inverkehrbringen von Produkten mit digitalen Elementen nach dem Vorschlag der EU-Kommission für eine Verordnung über horizontale Cybersicherheitsanforderungen, ALJ 2022, 180.

=== Kommentare ===

* ''Heckmann/Paschke'', CRA. Cyber Resilience Act (2025, iE).

== Einzelnachweise ==

Cyber Solidarity Act/de

2025-06-03T22:21:14Z

FuzzyBot: Übernehme Bearbeitung einer neuen Version der Quellseite

<languages/>
{{Infobox Rechtsakt (EU)|Typ=Verordnung|Jahr=2025|Nummer=38|Vertrag=EU|EWR=ja|Titel=Verordnung (EU) 2025/38 des Europäischen Parlaments und des Rates vom 19. Dezember 2024 über Maßnahmen zur Stärkung der Solidarität und der Kapazitäten in der Union für die Erkennung von, Vorsorge für und Bewältigung von Cyberbedrohungen und Sicherheitsvorfällen und zur Änderung der Verordnung (EU) 2021/694|Kurztitel=Cyber Solidarity Act|Bezeichnung=|Rechtsmaterie=Binnenmarkt, Cybersicherheit|Grundlage=AEUV, insbesondere {{Art.|173|AEUV|dejure|}}
Abs 3 und {{Art.|322|AEUV|dejure|}} Abs 1 lit a|Fundstelle=ABl L 2025/38, 1|Anzuwenden=4. Februar 2025|Gültig=anwendbar}}

== Einführung ==

Die Verordnung (EU) 2025/38 (Cyber Solidarity Act)<ref>https://eur-lex.europa.eu/eli/reg/2025/38/oj</ref> ist eine Vorstoß der EU um bedeutende und groß angelegte Bedrohungen und Angriffe im Bereich der Cybersicherheit zu erkennen, sich darauf vorzubereiten und darauf zu reagieren. Der Rechtsakt umfasst ein europäisches Warnsystem für Cybersicherheit, das aus EU-weit miteinander verbundenen Sicherheitsoperationszentren besteht, sowie einen umfassenden Mechanismus für Cybersicherheitsnotfälle, um die Widerstandsfähigkeit der EU im Cyberbereich zu verbessern.<ref>European Commission: The EU Cyber Solidarity Act https://digital-strategy.ec.europa.eu/en/policies/cyber-solidarity 08.08.2024</ref>

== Anwendungsbereich ==

Der Cyber Solidarity Act verweist auf Art. 6 Abs. 38 [[Special:MyLanguage/Network and Information Security Directive (NIS II-RL)|NIS II-Richtlinie]] (Art. 2 Abs 4. CSA) sowie Tätigkeiten der Einrichtung in den '''Anhang I''' oder '''II''' der NIS2-RL, welche als kritisch bzw. hochkritische Sektoren bezeichnet werden. (Art. 2 Abs 5. CSA)

Ein allgemeiner Verweis auf Art 3 NIS II-RL ist nicht vorhanden, weshalb gerade der größenunabhängige Anwendungsbereich der NIS2 II-RL im Grundbegriff nciht erfasst ist. Im Hinblick auf die Inanspruchnahme von Unterstützung aus der EU-Cybersicherheitsreserve sind Entitäten in Art. 14 Abs. 2 CSA aber doch wieder erwähnt. Systematisch wird damit der rechtspolitisch fragwürdige Eindruck erweckt, dass die Stellen des Art. 3 NIS-II-RL nur in diesem engen Rahmen vom CSA erfasst sind und z.B. nicht am Cybersecurity Shield teilnehmen sollen.

== Zentrale Inhalte ==

=== Europäischer Cybersicherheitsschild ===

Das European Cyber Shield besteht aus einer pan-europäischen Infrastruktur von Nationalen Sicherheitsoperationszentren (National SOCs) und Grenzüberschreitenden Sicherheitsoperationszentren (Cross-border SOCs). Die SOCs sind miteinander vernetzt und bilden eine EU-weite Infrastruktur zur Cybersicherheit.

==== Funktionsweise ====

Das European Cyber Shield operiert folgendermaßen (Art 3 CSA):

# Erkennung von Cyberbedrohungen und -vorfällen durch die vernetzten SOCs
# Analyse der gesammelten Daten mithilfe von KI und Datenanalyse
# Ausgabe von grenzüberschreitenden Warnungen bei identifizierten Bedrohungen
# Ermöglichung einer schnelleren und effizienteren Reaktion auf größere Cybervorfälle durch Behörden und relevante Einrichtungen

Verpflichtungen zur Bereitstellung von Daten durch Entitäten oder zur Regelungen des Verhältnisses zu den Bestimmungen der DSGVO sind nicht erkennbar. Der Enschluss mehrerer Institution Daten über Cyberbedrohungen zu teilen ist freiwillig und vertrauensbasiert. Wenn Mitgliedstaaten vom System profitieren möächten, haben sie die in diesem Zusammenhang in Frage kommenden Institutionen so attraktiv wie möglich zu gestalten.

=== Prüfung kritischer Einrichtungen auf potenzielle Schwachstellen ===

Die koordinierten Bereitschaftstests dienen dazu, potenzielle Schwachstellen in kritischen Infrastrukturen zu identifizieren, die diese anfällig für Cyberbedrohungen machen könnten. Die Tests werden koordiniert durchgeführt, um die Cybersicherheitsbereitschaft der ausgewählten Einrichtungen zu überprüfen. Dabei werden gemäß Art. 2 Abs 9. iVm Art 11 CSA Potenzielle Schwachstellen identifiziert, die Reaktionsfähigkeit auf Cyberbedrohungen getestet, Verbesserungspotenziale geprüft. Nachdem keine Mitwirkungspflichten der Entitäten normiert sind, dürfte die Mitwirkung an den Prüfungen seitens der geprüften Entitäten freiwillig sein.

== Synergien ==

===== Risikomanagement in der Cybersicherheit =====

=== CSA ===

* Stärkt die Fähigkeit der EU, auf große Cyberangriffe zu reagieren, indem es ein Netzwerk von nationalen und grenzüberschreitenden Sicherheitsoperationszentren (SOC) fördert und die Zusammenarbeit bei Cyberkrisen stärkt. Über das vorgesehene Netzwerks von SOCs, sollten Bedrohungsdaten in Echtzeit ausgetauscht werden.

=== NIS2-RL ===

* Verlangt von Organisationen aus kritischen Sektoren, robuste Cybersicherheitsmaßnahmen einzuführen, um die Resilienz gegenüber Cyberbedrohungen zu erhöhen.

'''Synergie''' Die verstärkte Sicherheitsinfrastruktur (z. B. durch SOCs) unterstützt Unternehmen und öffentliche Einrichtungen dabei, die unter NIS-II RL geforderten Standards besser einzuhalten, insbesondere durch frühzeitige Erkennung von Bedrohungen und Informationsaustausch.

== Konsequenzen/Strafen ==

Der CSA enthält keine Sanktionsmechanismen.

== Weiterführende Literatur ==

== Einzelnachweise ==

Digital Operational Resilienec Act (DORA)/de

2025-06-03T15:42:12Z

FuzzyBot: Übernehme Bearbeitung einer neuen Version der Quellseite

<languages/>
{{Infobox Rechtsakt (EU)|Typ=Verordnung|Jahr=2022|Nummer=2554|Vertrag=EU|EWR=ja|Titel=Verordnung (EU) 2022/2554 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über die digitale operationale Resilienz im Finanzsektor und zur Änderung der Verordnungen (EG) Nr. 1060/2009, (EU) Nr. 648/2012, (EU) Nr. 600/2014, (EU) Nr. 909/2014 und (EU) 2016/1011|Kurztitel=Digital Operational Resilienec Act|Bezeichnung=DORA|Rechtsmaterie=Binnenmarkt, Cybersicherheit|Grundlage=AEUV, insbesondere {{Art.|114|AEUV|dejure|}}
|Fundstelle=ABl L 2022/333, 1|Anzuwenden=17. Januar 2025|Gültig=anwendbar}}

== Kurzübersicht ==

{| class="wikitable"
|+
!Ziele
!Anwendungsbereich
!Inhalt
!Synergie
!Konsequenzen
|-
|Operationale Resilienz im Finanzsektor stärken
|Finanzunternehmen
|Management von IKT-Risiken und Vorfällen
|NIS2-RL
|National festgelegte Verwaltungsstrafen gegen Finanzunternehmen<ref>DORA-Vollzugsgesetz (DORA-VG) https://www.parlament.gv.at/gegenstand/XXVII/I/2596.</ref>
|-
|
|IKT-Dienstleister
|Prüfung digitaler Betriebsstbilität
|DSGVO
|Geldstrafe von bis zu 1 % des durchschnittlichen täglichen weltweiten Umsatzes gegen Drittdienstleister
|-
|
|
|Lieferkettenmanagement
|
|Veröffentlichung von Strafen
|-
|
|
|Informationsaustausch
|
|
|}

== Einführung ==

Die DORA-Verordnung (Digital Operational Resilience Act) ist eine umfassende Regelung zur digitalen Resilienz, die speziell für den '''Finanzsektor''' der Europäischen Union entwickelt wurde. Sie ergänzt bestehende Regelungen und baut auf bekannten Konzepten wie Informationssicherheit, Datenschutz und Risikomanagement auf, um die Widerstandsfähigkeit gegenüber IKT-Risiken zu stärken.

Gleichzeitig mit DORA wurde die Richtlinie 2022/2556 hinsichtlich der digitalen operationalen Resilienz im Finanzsektor („'''DORA-RL'''“)<ref>RL (E) 2022/2556 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 zur Änderung der Richtlinien 2009/65/EG, 2009/138/EG, 2011/61/EU, 2013/36/EU, 2014/59/EU, 2014/65/EU, (EU) 2015/2366 und (EU) 2016/2341 hinsichtlich der digitalen operationalen Resilienz im Finanzsektor, ABl L 2022/333, 153.</ref> sowie Richtlinie (EU) 2022/2557 über die [[Special:MyLanguage/Critical Entities‘ Resilience Directive (CER)|Resilienz kritischer Einrichtungen]], welche einzelne Anpassungen von mehreren Richtlinien, vorsieht, erlassen. Die ab dem 17. 1. 2025 anwendbare DORA-RL muss von den EU-Mitgliedstaaten in nationales Recht umgesetzt werden.

Die '''Delegierte Verordnung''' (EU) 2024/1774 vom 13. März 2024 ergänzt die DORA zusätzlich.

Im Verhältnis zur NIS2-RL nimmt DORA eine besondere Stellung ein, da sie gemäß ErwGr 16 DORA als lex specialis gilt und somit Vorrang vor NIS2-RL hat. Diese Vorrangstellung von DORA bedeutet, dass für Finanzunternehmen primär die DORA-Vorschriften maßgeblich sind. In Bereichen, in denen NIS2-RL spezifischere Regelungen als DORA vorsieht, gelten diese NIS2-Vorschriften ergänzend zu DORA. Die Implementierung von DORA und Umsetzungsgesetzgebung zu NIS2 hat auch Auswirkungen auf nationale Regularien und Anforderungsvorgaben. Bestehende nationale Vorschriften (Oktober 2024 ist die NIS2-RL in Österreich noch nicht umgesetzt), sie diese beachtlich.

== Anwendungsbereich ==

==== Persönlicher / Sachlicher Anwendungsbereich ====

DORA ist auf in Art 2 Abs 1 lit a bis t DORA angeführte Tätigkeitsbereiche (sog. „'''Finanzunternehmen'''“) anwendbar. Hierzu zählen (a) Kreditinstitute, (b) Zahlungsinstitute, einschließlich gemäß der Richtlinie (EU) 2015/2366 ausgenommene Zahlungsinstitute, (c) Kontoinformationsdienstleister, (d) E-Geld-Institute, einschließlich gemäß der Richtlinie 2009/110/EG ausgenommene E-Geld-Institute, (e) Wertpapierfirmen, (f) Anbieter von Krypto-Dienstleistungen, die gemäß der sogenannten „Verordnung über Märkte von Krypto-Werten“ zugelassen sind, und Emittenten wertreferenzierter Token, (g) Zentralverwahrer, (h) zentrale Gegenparteien, (i) Handelsplätze, (j) Transaktionsregister, (k) Verwalter alternativer Investmentfonds, (l) Verwaltungsgesellschaften, (m) Datenbereitstellungsdienste, (n) Versicherungs- und Rückversicherungsunternehmen, (o) Versicherungsvermittler, Rückversicherungsvermittler und Versicherungsvermittler in Nebentätigkeit, (p) Einrichtungen der betrieblichen Altersversorgung, (q) Ratingagenturen, (r) Administratoren kritischer Referenzwerte, (s) Schwarmfinanzierungsdienstleister und (t) Verbriefungsregister.

Darüber hinaus sind Unternehmen erfasst, die IT-Leistungen an Finanzunternehmen erbringen (sog. „IKT-Drittdienstleister“), wie etwa Cloud-Anbieter.

'''Ausnahmen'''

Außerhalb des Anwendungsbereichs stehen zudem gemäß Art 2 Abs 3 (a) Verwalter alternativer Investmentfonds im Sinne von Art 3 Abs 2 der Richtlinie 2011/61/EU, (b) Versicherungs- und Rückversicherungsunternehmen im Sinne von Art 4 der Richtlinie 2009/138/EG, (c) Einrichtungen der betrieblichen Altersversorgung, die Altersversorgungssysteme mit insgesamt weniger als 15 Versorgungsanwärtern betreiben, (d) gemäß den Artikeln 2 und 3 der Richtlinie 2014/65/EU ausgenommene natürliche oder juristische Personen, (e) Versicherungsvermittler, Rückversicherungsvermittler und Versicherungsvermittler in Nebentätigkeit, bei denen es sich um Kleinstunternehmen oder kleine oder mittlere Unternehmen handelt, sowie (f) Postgiroämter im Sinne von Art 2 Abs 5 Z 3 der Richtlinie 2013/36/EU.

Weitreichende Ausnahmen von den Verpflichtungen bestehen für Kleinstunternehmen (dh Finanzunternehmen, die weniger als zehn Personen beschäftigen und deren Jahresumsatz bzw. -bilanzsumme 2 Mio EUR nicht überschreitet).

DORA betrifft '''alle Finanzinstitute''', wenn sie in den Anwendungsbereich fallen, unabhängig von ihrer Größe oder Struktur. Eine Einschränkung des Scopes auf lokaler Ebene ist nicht möglich. Die Begriffsdefinitionen, zB "kritische Dienste" und "wesentliche Dienste", können nicht modifiziert werden. Wenn ein Unternehmen betroffen ist, dann in seiner Gesamtheit, einschließlich etwaiger Tochtergesellschaften oder Nebentätigkeiten (theoretisch auch der Betriebskindergärten).

==== Territorialer Anwendungsbereich ====

Der territoriale Anwendungsbereich des DORA umfasst primär alle Finanzunternehmen und relevante IKT-Dienstleister, die in der Europäischen Union tätig sind. Zusätzlich zu den in der EU ansässigen Finanzunternehmen und IKT-Dienstleistern betrifft DORA auch Niederlassungen und Tochtergesellschaften von EU-Finanzunternehmen, die sich außerhalb der Union befinden, sofern diese Niederlassungen und Tochtergesellschaften Dienstleistungen in die EU erbringen. So soll die operationelle Resilienz des Finanzsektors in der gesamten Union sichergestellt werden, auch bei Abhängigkeiten von globalen Anbietern oder internationalen Tochtergesellschaften.

== Zentrale Inhalte ==

=== Management von IKT-Risiken und Vorfällen ===

==== IKT-Risiken ====

Nach dem DORA sind Finanzunternehmen verpflichtet, einen umfassenden internen '''Governance- und Kontrollrahmen''' für das Management von Informations- und Kommunikationstechnologie-Risiken (IKT-Risiken) zu etablieren. Dieser Rahmen muss regelmäßig überprüft und dokumentiert werden, wobei für Kleinstunternehmen lediglich eine regelmäßige Überprüfung ausreicht. Ziel ist es, IKT-Risiken wirksam zu begegnen. Die spezifischen Anforderungen an das IKT-Risikomanagement sind in Art 5 Abs 2 DORA festgelegt. Die Verantwortung für die Definition, Genehmigung und Überwachung des IKT-Risikomanagements liegt beim '''Leitungsorgan''' des jeweiligen Finanzunternehmens, das auch für die Umsetzung der Maßnahmen verantwortlich ist. Finanzunternehmen, die nicht als Kleinstunternehmen eingestuft sind, haben zusätzlich eine unabhängige Kontrollfunktion einzurichten, um die Überwachung und das Management von IKT-Risiken sicherzustellen.

Ein zentraler Aspekt des DORA ist die Verantwortung des Leitungsorgans (zB Vorstand) für die digitale Resilienz. Das Business Continuity Management (BCM) ist dabei das wichtigste Einfallstor für die operative Umsetzung dieser Verantwortung. DORA fordert, dass das Leitungsorgan selbst die notwendigen Sachkenntnisse besitzen muss und die nicht mehr rigoros delegieren darf. Dies könnte zu strukturellen Veränderungen in der Unternehmensführung führen, zB durch die Einbindung eines CIO oder CTO auf Vorstandsebene.

==== IKT-bezogene Vorfälle ====

Darüber hinaus müssen Finanzunternehmen Prozesse etablieren, die sicherstellen, dass IKT-bezogene Vorfälle frühzeitig erkannt, behandelt, klassifiziert und gemeldet werden. Besonders '''schwerwiegende''' IKT-Vorfälle, die nach den Kriterien des Art 18 Abs 1 DORA als solche einzustufen sind, müssen den zuständigen Aufsichtsbehörden in einem dreistufigen Verfahren gemeldet werden. In Fällen, in denen schwerwiegende IKT-Vorfälle die finanziellen Interessen der Kund*innen betreffen, müssen die Finanzunternehmen ihre Kund*innen unverzüglich nach Kenntnis des Vorfalls informieren. Cyberbedrohungen, die gemäß Art 18 Abs 2 DORA als '''erheblich''' einzustufen sind, müssen ebenfalls erfasst werden und können auf freiwilliger Basis gemeldet werden.

Zur Unterstützung der Finanzunternehmen bei der Umsetzung dieser Anforderungen haben die Europäischen Aufsichtsbehörden mehrere technische Regulierungsstandards veröffentlicht. Diese umfassen ua Vorgaben zur Festlegung der Tools, Methoden, Prozesse und Richtlinien für das IKT-Risikomanagement sowie vereinfachte Risikomanagement-Rahmen für Kleinstunternehmen. Weitere RTS spezifizieren die Kriterien für die Klassifizierung von IKT-Vorfällen und Cyberbedrohungen, sowie die Wesentlichkeitsschwellen und Anforderungen an die Meldungen schwerwiegender Vorfälle. Meldung und Einstufung über IKT-bezogene Vorfälle ist mithilfe der harmonisierten '''Standardvorlagen''' durchzuführen.<ref>''European Banking Authority'', Joint Technical Standards on major incident reporting, https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/joint-technical-standards-major-incident-reporting (abgerufen 22. 1. 2025).</ref> Die zuständigen Behörden, an die gemeldet werden muss, unterscheiden sich von denen der NIS2-RL. Eine klare Festlegung und unternehmensinterne Kommunikation der Meldepflichten und der empfangenden Stellen ist wichtig.

=== Prüfung digitaler Betriebsstabilität ===

Bedeutende Finanzunternehmen haben verpflichtend so '''Threat Led Penetration Tests''' durchzuführen. Diese – auch in der Produktionsumgebung durchgeführten – Tests zielen auf die Kern-IT-Systeme des Unternehmens ab. So können Verpflichtete Schwächen, Mängel und Lücken in der digitalen operationellen Resilienz zu identifizieren und unverzüglich Korrekturmaßnahmen zu ergreifen. Die Tests müssen von unabhängigen Parteien durchgeführt werden, um eine objektive Bewertung sicherzustellen. Dabei sind die Tests mindestens einmal jährlich bei den IKT-Systemen oder Anwendungen durchzuführen, die kritische oder wichtige Funktionen unterstützen. Hierbei wird darauf geachtet, dass die Resilienz in diesen Schlüsselbereichen kontinuierlich sichergestellt wird.

DORA spezifiziert in Art 25 Abs 1 verschiedene Arten von Tests, die in Betracht gezogen werden können, darunter Simulationen, Red Teaming oder Penetrationstests. Zusätzlich sind bestimmte Finanzunternehmen nach Art 26 DORA verpflichtet, mindestens alle drei Jahre '''Threat-Led Penetration Tests''' (TLPT) durchzuführen, bei denen gezielt realistische Bedrohungsszenarien simuliert werden. Diese Tests sollen sicherstellen, dass Schwachstellen, die durch herkömmliche Sicherheitsmaßnahmen nicht entdeckt werden, aufgedeckt werden.

Die spezifischen Anforderungen und Elemente dieser TLPT sind in den von den Europäischen Aufsichtsbehörden (EBA, ESMA und EIOPA (zusammen die „ESA“)) veröffentlichten technischen Regulierungsstandards (RTS) festgelegt. Die konkrete Methodik, die für diese Tests gemäß DORA anzuwenden ist, beruht auf dem Rahmenwerk TIBER-EU (Threat Intelligence-Based Ethical Red Teaming“) welcher in Österreich durch [https://www.fma.gv.at/tiber-at/ TIBER-AT] umgesetzt wird.

=== Lieferkettenmanagement ===

DORA stellt klare Anforderungen an das Management des IKT-Drittparteienrisikos und die vertraglichen Vereinbarungen mit IKT-Drittdienstleistern, die von Finanzunternehmen beachtet werden müssen. Mit Ausnahme von Kleinstunternehmen haben Finanzunternehmen die Pflicht, eine Strategie zum Management des IKT-Drittparteienrisikos zu entwickeln und regelmäßig zu überprüfen. Diese Strategie umfasst Leitlinien für die Nutzung von IKT-Drittdienstleistungen, die dazu dienen, das Risiko, das durch externe Dienstleister entsteht, effektiv zu steuern. Die Europäische Aufsichtsbehörde (ESA) hat hierzu technische Regulierungsstandards (RTS) veröffentlicht, welche den detaillierten Inhalt dieser Leitlinien spezifizieren.<ref>https://www.eba.europa.eu/publications-and-media/press-releases/esas-published-second-batch-policy-products-under-dora</ref>

==== Informationsregister ====

Ein wesentlicher Bestandteil der Anforderungen ist, dass Finanzunternehmen ein stets aktuelles Informationsregister führen müssen, welches Informationen zu allen ausgelagerten IKT-Prozessen enthält. Dieses Register beinhaltet die entsprechenden vertraglichen Vereinbarungen sowie die Einordnung der Prozesse als kritisch oder nicht kritisch. Auf Anfrage müssen diese Informationen den zuständigen Behörden zur Verfügung gestellt werden. Außerdem müssen Finanzunternehmen jährlich Bericht erstatten über die Anzahl neuer Vereinbarungen mit IKT-Drittdienstleistern, die bereitgestellten Dienstleistungen und Funktionen sowie über die Art der vertraglichen Vereinbarungen. Finanzunternehmen sind außerdem verpflichtet, geplante neue Vereinbarungen bezüglich kritischer Funktionen oder Veränderungen des Status einer Funktion als „kritisch“ den Behörden zeitnah zu melden.

==== Verträge ====

Vor Abschluss eines Vertrags mit einem IKT-Drittdienstleister müssen Finanzunternehmen eine Risikoanalyse durchführen, die die Kriterien von Art 28 Abs 4 und 5 DORA berücksichtigt. Während der Vertragsverhandlungen müssen sie sicherstellen, dass Audit-Frequenzen und zu prüfende Bereiche festgelegt werden, um die Kontrolle über kritische Systeme zu wahren. Des Weiteren sind vertragliche Kündigungsrechte sowie angemessene Ausstiegsstrategien für den Fall einer Beendigung der Vertragsbeziehung festzulegen, insbesondere bei kritischen oder wichtigen Funktionen.

'''Praxistipp:''' Mittelständische Unternehmen sollten Musterverträge vorbereiten, um die Anforderungen an Drittdienstleister klar zu regeln. Viele KMUs verfügen nicht über zentrale Vertragswerke, was die Umsetzung erschwert.

Darüber hinaus sieht DORA in Art 30 spezielle Vertragsbedingungen für die Vergabe von Unteraufträgen durch IKT-Drittdienstleister vor, welche ebenfalls in den technischen Standards der ESA spezifiziert sind. Diese Vorschriften regeln unter anderem die Zulässigkeit der Unterauftragsvergabe sowie die dafür geltenden Kriterien. IKT-Dienstleister fallen vollständig unter den DORA.

==== Überwachung ====

Die Überwachung von IKT-Drittdienstleistern erfolgt durch die ESA, welche nach Art 31 Abs 2 DORA die Drittdienstleister als „kritisch“ einstufen können. Für jeden als kritisch eingestuften IKT-Drittdienstleister wird eine federführende Überwachungsbehörde ernannt, die über weitreichende Befugnisse verfügt. Dazu zählen das Recht auf Informationsanforderungen, Inspektionen und das Aussprechen von Empfehlungen hinsichtlich der Sicherheitsanforderungen und der Unterauftragsvergabe. IKT-Drittdienstleistern können auch zentral geprüft werden . Es stellt sich die Frage, welche Behörde in Österreich diese Prüfungen durchführen wird (evtl. Finanzmarktaufsicht, FMA).

'''Praxistipp:''' Sofern zentrale Prüfungen großer IKT-Dienstleister erfolgen, können sich Unternehmen auf diese Prüfungsergebnisse verlassen und eigene dezentrale Prüfungen minimalhalten.

=== Informationsaustausch ===

Die Vorgaben des DORA ermöglichen es Finanzunternehmen, Informationen und Erkenntnisse über Cyberbedrohungen untereinander – innerhalb vertrauenswürdiger Gemeinschaften und unter Wahrung der Vertraulichkeit potenziell sensibler Informationen – auszutauschen. Dies trägt zur Schärfung des Bewusstseins bei und verstärkt die Fähigkeit, reale informations- und kommunikationstechnologische Vorfälle zu verhindern bzw. deren Auswirkungen wirksamer einzudämmen. Dieser Informationsaustausch wird durch DORA ermöglicht und erfolgt freiwillig. Bei Teilnahme oder Beendigung einer solchen Vereinbarung, erfolgt eine diesbezügliche Meldung an die FMA.<ref>''FMA'', DORA – Informationsaustausch und Notfallübungen, https://www.fma.gv.at/querschnittsthemen/dora/dora-informationsaustausch-und-notfalluebungen/ (abgerufen 22. 1. 2025).</ref>

== Fallbeispiele ==

* Anwendungsbereich: Eine Bank kauft das Core-Banking-System von einem externen Dienstleister ein und verwaltet nur das Vertragsmanagement. Hier muss die Bank dennoch sicherstellen, dass die Anforderungen des DORA erfüllt werden, sowohl hinsichtlich des Risikomanagements als auch des Lieferkettenmanagements.

* In Unternehmen mit einer zentralisierten IT-Governance, wie zB Holding-Strukturen, stellt sich die Frage, wie die Governance optimal gestaltet und eingebunden werden kann. Hierzu müssen zentrale Weisungen klar formuliert und durchgesetzt werden. Dies betrifft sowohl operative Einheiten als auch die Gesamtorganisation.

== Synergien ==

===== Datenschutz =====

* Datenschutz und Informationssicherheit sind eng miteinander verknüpfte Konzepte, die gemeinsam gedacht werden müssen. Jede Maßnahme, wie zB Monitoring und Logging, muss auch in Bezug auf Datenschutzanforderungen betrachtet werden. Art 88 der DSGVO betont den Schutz der Würde des Menschen am Arbeitsplatz, was insbesondere bei eingriffsintensiven Technologien wie KI-gestütztem Anomalie-Monitoring relevant ist. Der Einsatz von KI-Systemen zur Erkennung und Meldung von Anomalien nimmt zu, was potenziell tiefere Eingriffe in den Datenschutz von Mitarbeiter*innendaten bedeutet. Dies muss im Sinne der DSGVO und DORA sorgfältig abgewogen werden.
* Normen wie ISO 27001 und ÖNORM A 2017:2023:06:01 vereinen Datenschutz und Datensicherheit und ist ein geeigneter Anknüpfungspunkt für die Umsetzung von DORA. Sie können konzeptionell in Verbindung mit den entsprechenden DORA-Normen als Umsetzungsstruktur integriert werden.

===== NIS2-RL =====

Die unter DORA entwickelten Regulatory Technical Standards (RTS) und Implementing Technical Standards (ITS) bieten wertvolle Ansatzpunkte für die Umsetzung der NIS2-RL:

'''Risikomanagement''': Die RTS zu IKT-Risikomanagement unter DORA können als Vorlage für die Implementierung ähnlicher Frameworks unter NIS-II dienen.

'''Incident Reporting''': Die ITS zu Meldepflichten bei schwerwiegenden Vorfällen bieten standardisierte Vorlagen, die auch für NIS2-pflichtige Unternehmen adaptierbar sind.

'''Drittanbieter-Management''': DORA's RTS zur Nutzung von IKT-Diensten und Unterauftragsvergabe können als Best Practices für das Lieferkettenrisikomanagement unter NIS2 genutzt werden.

'''Penetrationstests''': Der RTS zu Threat-Led Penetration Tests (TLPT) unter DORA bietet detaillierte Vorgaben, die auch für kritische Infrastrukturen im Rahmen von NIS-II relevant sind.

* [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1774 RTS zum IKT-Risikomanagement (Art 15, Art. 16 Abs 3)]
* [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1772 RTS zur Klassifizierung von IKT-bezogenen Vorfällen (Art 18 Abs 3)]
* [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1773 RTS zu vertraglichen Vereinbarungen mit IKT-Drittdienstleistern (Art. 28.10)]
* [https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2956 ITS zum Informationsregister (Art. 29 Abs 9)]

* [https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024-33_-_Final_report_on_the_draft_RTS_and_ITS_on_incident_reporting.pdf RTS zur Meldung größerer IKT-bezogener Vorfälle und erheblicher Cyber-Bedrohungen (Art 20a)]
* [https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024-33_-_Final_report_on_the_draft_RTS_and_ITS_on_incident_reporting.pdf ITS zur Meldung größerer IKT-bezogener Vorfälle und erheblicher Cyber-Bedrohungen (Art 20b)]
* [https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024-29_-_Final_report_DORA_RTS_on_TLPT.pdf RTS zum Threat-Led Penetration Testing (Art 26 Abs 11)]
* [https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024-35_-_Final_report_on_RTS_on_harmonisation_of_conditions_for_OVS_conduct.pdf RTS für die Harmonisierung von Überwachungstätigkeiten (Art 41 Abs 1)]
* [https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024_54_-_Final_Report_RTS_on_JET.pdf RTS zur Festlegung der Kriterien für die Zusammensetzung des Joint Examination Teams (Art 41 Abs 1c)]

* [https://www.eiopa.europa.eu/publications/joint-final-report-draft-rts-subcontracting-ict-services-supporting-critical-or-important-functions_en?prefLang=de RTS zur Unterauftragsvergabe an IKT-Drittparteien (Art 30 Abs 5)]

== Konsequenzen/Strafen ==

=== Bußgelder ===

DORA sieht strenge '''Bußgelder''' und Strafen für Verstöße vor, um die digitale Betriebsstabilität im Finanzsektor zu gewährleisten:

* Finanzinstitute: National determiniert, in Österreich bis 500.000 oder bis zu 1% des weltweiten Jahresumsatzes (DORA-Vollzugsgesetz - DORA-VG)
* Kritische IKT-Drittanbieter: Bis zu 1% des weltweiten Jahresumsatzes

=== Administrative Maßnahmen ===

* Lizenzentzug oder -aussetzung (Art 50)
* Verpflichtende Korrekturmaßnahmen (Art 50)

=== Strafrechtliche Konsequenzen ===

* Mögliche strafrechtliche Verfolgung von Führungskräften bei grober Fahrlässigkeit (Art 11)
* Nationale Bestimmungen können Haftstrafen vorsehen (Art 52)

== Weiterführende Literatur ==

* ''Siglmüller'', Cyber Resilience Act und Digital Operational Resilience Act - Lässt sich IT-Sicherheit rechtlich erzwingen?, ZfPC 2023, 221.
* ''Škorjanc'', Digital Operational Resilience Act, ÖBA 2023, 658.

== Einzelnachweise ==

<references />

Critical Entities‘ Resilience Directive (CER)/de

2025-06-03T13:42:18Z

FuzzyBot: Übernehme Bearbeitung einer neuen Version der Quellseite

<languages/>
{{Infobox Rechtsakt (EU)|Typ=Richtlinie|Jahr=2022|Nummer=2557|Vertrag=EU|EWR=ja|Titel=Richtlinie (EU) 2022/2557 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über die Resilienz kritischer Einrichtungen und zur Aufhebung der Richtlinie 2008/114/EG des Rates|Kurztitel=Critical Entities‘ Resilience Directive/EU-Resilienz-Richtlinie|Bezeichnung=CER-RL|Rechtsmaterie=Binnenmarkt, Cybersicherheit|Grundlage=AEUV, insbesondere {{Art.|114|AEUV|dejure|}}
|Fundstelle=ABl L 2022/333, 164|Anzuwenden=17. Oktober 2024 (Umsetzung, Fristverletzung)|Gültig=umsetzung}}

== Kurzübersicht ==

{| class="wikitable"
|+
!Anwendungsbereich
!Zentrale Inhalte
!Synergien
!Strafen/Konsequenzen
!
|-
|kritische Einrichtungen (Unternehmen, die wesentliche Dienste erbringen)
|Verabschiedung einer Strategie für die Resilienz kritischer Einrichtungen (Art 4 CER-RL) durch MS
|Sonderregelung Behördenzuständigkeit (DORA-Behörde) in Bezug auf das Bankwesen und Finanzmarktinfrastrukturen (Art 9 Abs 1 CER-RL)
|Aufsichtsbefugnisse der Behörden (Vor-Ort-Kontrolle, externe Aufsichtsmaßnahme, Audits) (Art 21 CER-RL)
|
|-
|kritische Infrastruktur (für Erbringung eines wesentlichen Dienstes erforderlich)
|Risikobewertung der Einrichtungen durch MS (Art 5 CER-RL)
|Die Identität der nach CER-RL ermittelten kritischen Einrichtungen ist auch der für [[Special:MyLanguage/Network and Information Security Directive (NIS II-RL)|NIS-2-RL]] zuständigen Behörde mitzuteilen (Art 6 Abs 4 CER-RL).
|Informationszugangsrechte (Art 21 CER-RL)
|
|-
|Zeitlich: Umsetzungsfrist bis 17. Oktober 2024
|Ermittlung kritischer Einrichtungen durch MS (Art 6 CER-RL)
|Sonderzuständigkeit (NIS-2-Behörde) in Bezug auf Digitale Infrastruktur (Art 9 Abs 1 CER-RL).
|Anweisung, konkrete Maßnahmen zu ergreifen, um Verstöße zu beheben (Art 21 CER-RL)
|
|-
|Ausnahmen: Bankwesen Finanzmarktinfrastruktur, Digitale Infrastruktur
|Risikobewertung durch kritische Einrichtung selbst (Art 12 CER-RL)
|Zusammenarbeit/Informationsaustausch in Bezug auf Cybersicherheitsrisiken, Cyberbedrohungen und Cybersicherheitsvorfällen mit der NIS-2-Behörde (Art 9 Abs 6 CER-RL).
|Geldstrafen bis zu 50 000 Euro, im Wiederholungsfall bis zu 100 000 Euro, bei fehlender Bekanntgabe einer Kontaktstelle/Ansprechperson oder die fehlende Übermittlung der Risikoanalyse oder des Resilienzplans (§ 22 Abs 1 RKEG-G)
|
|-
|
|Ergreifung von Resilienzmaßnahmen (Art 13 CER-RL)
|Die Gruppe für die Resilienz kritischer Einrichtungen hat mindestens einmal jährlich gemeinsam mit der Kooperationsgruppe nach der [[Special:MyLanguage/Network and Information Security Directive (NIS II-RL)|NIS 2-RL]] zu tagen (Art 19 Abs 5 CER-RL).
|Geldstrafe bis zu 7 Mio Euro bei Nichtumsetzung einer mit Bescheid angeordneten Maßnahmen nach Feststellung, dass die Anforderungen an die Risikoanalyse bzw an die Resilienzmaßnahmen nicht oder nicht vollständig erfüllt werden, bzw Verstöße gegen die Meldepflichten (§ 22 Abs 2 RKEG-Entwurf).
|
|-
|
|Zuverlässigketisprüfungen (Art 14 CER-RL)
|
|
|
|-
|
|Meldepflichten für Sicherheitsvorfälle (Art 15 CER-RL)
|
|
|
|}

== Einführung ==

Durch die CER-RL soll die '''Resilienz''',<ref>Nach Art 2 Z 2 CER-RL bezeichnet „Resilienz“ die Fähigkeit einer kritischen Einrichtung, einen Sicherheitsvorfall zu verhindern, sich davor zu schützen, darauf zu reagieren, einen solchen abzuwehren, die Folgen eines solchen Vorfalls zu begrenzen, einen Sicherheitsvorfall aufzufangen, zu bewältigen und sich von einem solchen Vorfall zu erholen (vgl § 3 Z 2 RKEG-Entwurf).</ref> das heißt die Widerstandsfähigkeit, kritischer Einrichtungen gegen '''Sicherheitsvorfälle'''<ref>„Sicherheitsvorfall“ bezeichnet nach Art 2 Z 3 CER-RL ein Ereignis, das die Erbringung eines wesentlichen Dienstes erheblich stört oder stören könnte, einschließlich einer Beeinträchtigung der nationalen Systeme zur Wahrung der Rechtsstaatlichkeit.

Abweichend spricht § 2 Z 3 des Entwurfes für das RKEG von einem "Ereignis, das die Erbringung eines wesentlichen Dienstes erheblich stört oder stören könnte, einschließlich einer Beeinträchtigung der verfassungsrechtlichen Grundprinzipien".</ref> verbessert werden, wobei nicht nur "digitale", sondern auch "analoge" Gefahren erfasst sind.<ref>''Škorjanc'', Der neue acquis communautaire des europäischen IT-Sicherheitsrechts, ecolex 2023, 881.</ref> So spricht ErwGr 3 von einer "dynamische Bedrohungslage" , dh "die sich wandelnde hybride und terroristische Bedrohungen sowie wachsende gegenseitige Abhängigkeiten zwischen Infrastrukturen und Sektoren". Weiters bestünde "ein erhöhtes physisches Risiko im Zusammenhang mit Naturkatastrophen und dem Klimawandel". Neben der Resilienz kritischer Einrichtungen soll ihre Fähigkeit zur Erbringung von Diensten im Binnenmarkt, die für die Aufrechterhaltung wichtiger gesellschaftlicher Funktionen oder wirtschaftlicher Tätigkeiten unerlässlich sind, verbessert werden (Art 1 Abs 1 lit a, b CER-RL).

ErwGr 20 stellt fest, dass Gefahren für die Sicherheit von Netz- und Informationssystemen unterschiedliche Ursachen haben können, weshalb in der CER-RL ein „gefahrenübergreifender“ Ansatz angewandt wird, der die Resilienz von Netz- und Informationssystemen sowie die physischen Komponenten und das physische Umfeld dieser Systeme umfasst.
{| class="wikitable"
|+
!Hinweis:
|-
|Ein erster Entwurf für ein nationales Umsetzungsgesetz der CER-RL wurde, deutlich nach Ende der Umsetzungsfrist, unter dem Titel "Resilienz kritischer Einrichtungen-Gesetz" (im folgenden '''RKEG-Entwurf)''' im Dezember 2024 im Parlament in Begutachtung gegeben.<ref>''Parlament Österreich'', Resilienz kritischer Einrichtungen-Gesetz – RKEG (1/ME), https://www.parlament.gv.at/gegenstand/XXVIII/ME/1?selectedStage=100 (abgerufen 22. 1. 2025).</ref>
Die Begutachtungsfrist endete mit 14. Jänner 2025.
Derzeit ist dieser Gesetzgebungsprozess noch nicht abgeschlossen.
|}

== Anwendungsbereich ==

Die für die RL zentrale „'''kritische Einrichtung'''“ ist eine öffentliche oder private Einrichtung, die ein Mitgliedstaat (MS) als einer der Kategorien in der dritten Spalte der Tabelle im Anhang angehörend eingestuft hat (Art 2 Z 1 CER-RL). Es handelt sich dabei im wesentlichen um Unternehmen, die "'''wesentliche Dienste'''", dh Dienste, die für die Aufrechterhaltung wichtiger gesellschaftlicher Funktionen, wichtiger wirtschaftlicher Tätigkeiten, der öffentlichen Gesundheit und Sicherheit oder der Erhaltung der Umwelt von entscheidender Bedeutung sind (Art 2 Z 5 CER-RL.<ref name=":0">MwN ''Eisenmenger'', Ein neuer Rechtsrahmen für Kritische Infrastrukturen (KRITIS) - unter Berücksichtigung der EU-Resilienz-Richtlinie, NVwZ 2023, 1203 (1204).</ref>

Der Begriff der "'''kritischen Infrastruktur'''" ist hingegen anlagenbezogen zu verstehen.<ref name=":0" /> Es handelt sich dabei um "Objekte, Anlagen, Ausrüstung, Netze oder Systeme oder Teile eines Objekts, einer Anlage, Ausrüstung, eines Netzes oder eines Systems, die für die Erbringung eines wesentlichen Dienstes erforderlich sind" (Art 2 Z 4 CER-RL, vgl § 2 Z 5 RKEG-Entwurf).

Der Entwurf für das RKEG verweist bei der Definition des Anwendungsbereiches lapidar auf kritische Einrichtungen nach den im Anhang der CER-RL genannten Sektoren (§ 2 Abs 1 RKEG-Entwurf).

=== Zeitlicher Anwendungsbereich ===

Die für die Umsetzung der CER-RL erforderlichen Vorschriften sind bis zum 17. Oktober 2024 zu erlassen und zu veröffentlichen. Diese Vorschriften sind dann ab dem 18. Oktober 2024 anzuwenden (Art 26 CER-RL).

'''Ausnahmen'''

Art 11 CER-RL und Kapitel III (Art 12-16 CER-RL), IV (Art 17-18 CER-RL) und VI (Art 21-22 CER-RL) gelten nicht für gewisse kritische Einrichtungen in den Sektoren '''Bankwesen''', '''Finanzmarktinfrastrukturen''' und '''Digitale Infrastruktur''', wobei die MS nationale Vorschriften erlassen oder beibehalten können (Art 8 CER-RL).
{| class="wikitable"
|+
!Hinweis:
|-
|Das RKEG gilt nicht für den Bereich der Gerichtbarkeit sowie der Gesetzgebung und die Österreichische Nationalbank (§ 1 Abs 3 RKEG-Entwurf).
|}
Um Überschneidungen zu vermeiden finden die Bestimmungen der CER-RL keine Anwendung, wenn kritische Einrichtungen gemäß den Bestimmungen sektorspezifischer Rechtsakte der Union Maßnahmen zur Verbesserung ihrer Resilienz ergreifen müssen und diese Anforderungen von den Mitgliedstaaten den entsprechenden Verpflichtungen aus dieser Richtlinie '''als zumindest gleichwertig anerkannt sind''' (Art 1 Abs 3 CER-RL).

In Umsetzung dieser Bestimmung hat der*die Bundesminister*in für Inneres auf der Homepage der*des Minister(s)*in über gleichwertige Bestimmungen und das Ausmaß der Gleichwertigkeit zu informieren (§ 18 Abs 1 RKEG-Entwurf).

== Zentrale Inhalte ==

=== Nationaler Rahmen für die Resilienz kritischer Einrichtungen ===

==== Strategien für die Resilienz kritischer Einrichtungen (Art 4 CER-RL) ====

Jeder MS hat (nach einer Konsultation) spätestens am 17. Januar 2026 eine Strategie zur Verbesserung der Resilienz kritischer Einrichtungen zu verabschieden.

In dieser Strategie sind die '''strategischen Ziele und politischen Maßnahmen''' festgelegt, mit denen ein hohes Resilienzniveau von kritischen Einrichtungen erreicht und aufrechterhalten werden soll.

Die '''Mindestelemente''' dieser Strategie sind dabei:

* strategische Ziele und Prioritäten zur Verbesserung der Gesamtresilienz kritischer Einrichtungen unter Berücksichtigung grenzüberschreitender und sektorübergreifender Abhängigkeiten und gegenseitiger Abhängigkeiten
* einen Steuerungsrahmen zur Verwirklichung der strategischen Ziele und Prioritäten, einschließlich einer Beschreibung der Aufgaben und Zuständigkeiten der jeweiligen Behörden, kritischen Einrichtungen und sonstigen an der Umsetzung der Strategie beteiligten Akteure
* eine Beschreibung der Maßnahmen, die zur Verbesserung der Gesamtresilienz kritischer Einrichtungen erforderlich sind, einschließlich einer Beschreibung der Risikobewertung (Artikel 5 CER-RL)
* eine Beschreibung des Verfahrens zur Ermittlung kritischer Einrichtungen
* eine Beschreibung des Prozesses zur Unterstützung kritischer Einrichtungen, einschließlich Maßnahmen zur Verbesserung der Zusammenarbeit zwischen dem öffentlichen Sektor einerseits und dem privaten Sektor und öffentlichen und privaten Einrichtungen andererseits;
* eine Liste der wichtigsten Behörden und entsprechenden Interessenvertretern, die an der Umsetzung der Strategie beteiligt sind
* einen politischen Rahmen für die Koordinierung zwischen den zuständigen Behörden und den gemäß der NIS-2-RL zuständigen Behörden für die Zwecke des Informationsaustauschs über Cybersicherheitsrisiken, Cyberbedrohungen und Cybersicherheitsvorfälle und über nicht cyberbezogene Risiken, Bedrohungen und Sicherheitsvorfälle sowie die Wahrnehmung von Aufsichtsaufgaben
* eine Beschreibung der bereits bestehenden Maßnahmen zur Erleichterung der Umsetzung von Verpflichtungen gemäß Kapitel III CER-RL (Art 12 ff CER-RL) durch kleine und mittlere Unternehmen, die von den betreffenden MS als kritische Einrichtungen eingestuft wurden.

Die MS haben diese Strategie (nach Konsultation) mindestens alle vier Jahre zu '''aktualisieren'''. Die Strategien und Aktualisierungen sind dabei innerhalb von drei Monaten nach Verabschiedung der Kommission '''mitzuteilen'''.

Nach § 9 RKEG-Entwurf wird diese Strategie von dem*der Bundesminister*in für Inneres für die Bundesregierung vorbereitet und ist, wenn sie beschlossen ist, innerhalb von drei Monaten an den Nationalrat zu übermitteln.

==== Risikobewertung durch die MS (Art 5 CER-RL) ====

Die Kommission hat die Befugnis delegierte Rechtsakte zu erlassen, um die CER-RL durch eine nicht erschöpfende Liste wesentlicher Dienste in den im Anhang genannten Sektoren und Teilsektoren zu ergänzen. Diese Liste ist von den zuständigen Behörden für die Zwecke einer Risikobewertung, die bis zum 17. Januar 2026 je nach Bedarf, mindestens aber alle vier Jahre, durchgeführt werden muss, zu verwenden (Art 5 Abs 1 CER-RL).

Diese Auflistung ist mit der delegierten '''VO 2023/2450'''<ref>Delegierte VO (EU) 2023/2450 der Kommission vom 25. Juli 2023 zur Ergänzung der Richtlinie (EU) 2022/2557 des Europäischen Parlaments und des Rates durch eine Liste wesentlicher Dienste, ABl L 2023/2450, 1. </ref> erfolgt.

Die zuständigen Behörden verwenden diese Risikobewertungen, um kritische Einrichtungen zu ermitteln und diese bei der Ergreifung von Maßnahmen zu unterstützen.

Bei Risikobewertungen durch MS müssen die entsprechenden natürlichen und vom Menschen verursachten Risiken berücksichtigt werden.<ref>Darunter solche sektorübergreifender oder grenzüberschreitender Art, Unfälle, Naturkatastrophen, gesundheitliche Notlagen, sowie hybride Bedrohungen oder andere feindliche Bedrohungen, einschließlich terroristischer Straftaten.</ref>

Die MS haben bei der Durchführung der Risikobewertung mindestens folgende Aspekte zu berücksichtigen (Art 5 Abs 2 CER-RL):

* '''allgemeine Risikobewertung''' (nach Artikel 6 Absatz 1 des Beschlusses Nr. 1313/2013/EU)
* sonstige entsprechende '''Risikobewertungen''', die im Einklang mit den Anforderungen der entsprechenden sektorspezifischen Rechtsakte der Union, durchgeführt werden
* die entsprechenden Risiken, die sich aus dem '''Ausmaß der Abhängigkeit''' zwischen den im Anhang genannten Sektoren ergeben, sowie die Auswirkungen, die eine in einem Sektor auftretende erhebliche Störung auf andere Sektoren haben kann, darunter alle wesentlichen Risiken für die Bürger*innen und den Binnenmarkt;
* sämtliche '''gemeldeten Informationen''' über Sicherheitsvorfälle (nach Art 15 CER-RL)

Die MS haben die entsprechenden Elemente der Risikobewertungen den kritischen Einrichtungen, gegebenenfalls über ihre zentralen Anlaufstellen, '''zur Verfügung zu stellen'''. Die MS haben außerdem sicherzustellen, dass die den kritischen Einrichtungen zur Verfügung gestellten Informationen ihnen bei der Durchführung ihrer Risikobewertungen (Artikel 12 CER-RL) und beim Ergreifen von Maßnahmen zur Gewährleistung ihrer Resilienz (Artikel 13 CER-RL) unterstützen (Art 5 Abs 3 CER-RL).

Innerhalb von drei Monaten nach Durchführung einer solchen Risikobewertung durch MS hat ein MS der Kommission entsprechende Informationen über die ermittelten Arten von Risiken und die Ergebnisse dieser Risikobewertungen zu '''übermitteln''', aufgeschlüsselt nach den im Anhang genannten Sektoren und Teilsektoren (Art 5 Abs 4 CER-RL).

Art 5 CER-RL wird dabei primär durch § 10 RKEG-Entwurf zur "'''Risikoanalyse'''<ref>"'Risikoanalyse' [ist] der gesamte Prozess zur Bestimmung der Art und des Ausmaßes eines Risikos, bei dem potenzielle Bedrohungen, Schwachstellen oder Gefahren für kritische Einrichtungen, die zu einem Sicherheitsvorfall führen können, ermittelt und analysiert und die durch den Sicherheitsvorfall verursachten potenziellen Verluste oder Störungen bei der Erbringung eines wesentlichen Dienstes samt Eintrittswahrscheinlichkeit bewertet werden; im Zuge dieser Risikoanalyse werden sämtliche aus natürlichen Ursachen herrührenden oder vom Menschen verursachten Risiken, die zu einem Sicherheitsvorfall führen können, berücksichtigt" (§ 3 Z 8 RKEG-Entwurf). </ref> durch den*die Bundesminister*in für Inneres umgesetzt.

==== Ermittlung kritischer Einrichtungen (Art 6 CER-RL) ====

Jeder MS muss bis 17. Juli 2025 die kritischen Einrichtungen '''ermitteln''' (Art 6 Abs 1 CER-RL).

Bei der Ermittlung hat er die Ergebnisse der Risikobewertung durch die MS und seine Strategie zu berücksichtigen. Art 6 Abs 2 CER-RL listet drei Kriterien für die Ermittlung:

* die Einrichtung erbringt einen/mehrere wesentliche Dienste
* die Einrichtung ist im Hoheitsgebiet des MS tätig und ihre kritische Infrastruktur befindet sich dort
* ein Sicherheitsvorfall würde eine erhebliche Störung bei der Erbringung eines oder mehrerer wesentlicher Dienste bewirken durch die Einrichtung oder von abhängigen Einrichtungen bewirken

Dabei hat jeder MS eine Liste der kritischen Einrichtungen zu erstellen und die kritischen Einrichtungen innerhalb eines Monats nach der Ermittlung über diese Einstufung und ihre Verpflichtungen zu '''informieren''' (Art 6 Abs 3 CER-RL). Die Identität dieser Einrichtungen ist auch der für [[Special:MyLanguage/Network and Information Security Directive (NIS II-RL)|NIS-2-RL]] zuständigen Behörde mitzuteilen (Art 6 Abs 4 CER-RL).

Die Liste ist dabei mindestens alle vier Jahre zu überprüfen und gegebenenfalls zu aktualisieren (Art 6 Abs 5 CER-RL).

In Umsetzung bestimmt § 11 Abs 1 RKEG-Entwurf, dass der*die Bundesminister*in für Inneres in den im Anhang der CER-RL angeführten Kategorien von Einrichtungen der gelisteten Sektoren und Teilsektoren Einrichtungen bescheidmäßig als kritisch einzustufen hat, wenn

* sie im Inland tätig sind
* sich deren kritische Infrastruktur im Inland befindet
* sie zumindest einen wesentlichen Dienst erbringen und
* ein Sicherheitsvorfall eintreten könnte.
{| class="wikitable"
|+
!Hinweis:
|-
|In Bezug auf den in Anhang Z 9 CER-RL genannten Sektor "'''öffentliche Verwaltung'''" (vgl Art 2 Z 10 CER-RL) sieht § 12 RKEG-Entwurf eine Sonderbestimmung für die Ermittlung von kritischen Einrichtungen im Sektor öffentliche Verwaltung vor, die sich ausschließlich an die Bundesverwaltung richtet.
|}

==== Erhebliche Störung (Art 7 CER-RL) ====

Bei der Bestimmung des '''Ausmaßes einer Störung''' haben die MS die folgenden Kriterien zu berücksichtigen:

* die '''Zahl der Nutzer*innen''', die den von der betreffenden Einrichtung erbrachten wesentlichen Dienst in Anspruch nehmen
* das '''Ausmaß der Abhängigkeit''' anderer im Anhang festgelegten Sektoren und Teilsektoren von dem betreffenden wesentlichen Dienst
* die '''möglichen Auswirkungen''' von Sicherheitsvorfällen — hinsichtlich Ausmaß und Dauer — auf wirtschaftliche und gesellschaftliche Tätigkeiten, die Umwelt, die öffentliche Ordnung und Sicherheit oder die Gesundheit der Bevölkerung
* den '''Marktanteil''' der Einrichtung auf dem Markt für wesentliche Dienste oder für die betreffenden wesentlichen Dienste
* das '''geografische Gebiet''', das von einem Sicherheitsvorfall betroffen sein könnte, einschließlich etwaiger grenzüberschreitender Auswirkungen, unter Berücksichtigung der Schwachstellen, die mit dem Grad der Isolierung bestimmter Arten geografischer Gebiete<ref>Zum Beispiel Inselregionen, abgelegene Regionen oder Berggebiete.</ref> verbunden sind
* die '''Bedeutung der Einrichtung''' für die Aufrechterhaltung des wesentlichen Dienstes in ausreichendem Umfang, unter Berücksichtigung der Verfügbarkeit von alternativen Mitteln für die Erbringung des betreffenden wesentlichen Dienstes

Jeder MS hat der Kommission nach der Ermittlung der kritischen Einrichtungen (Art 6 Abs 1 CER-RL) unverzüglich folgende Informationen zu '''übermitteln''':

* die Liste der wesentlichen Dienste in jenem MS, wenn es dort zusätzliche wesentliche Dienste im Vergleich zu der in Artikel 5 Absatz 1 genannten Liste wesentlicher Dienste gibt
* die Zahl der ermittelten kritischen Einrichtungen für jeden im Anhang festgelegten Sektor und Teilsektor und für jeden wesentlichen Dienst
* alle Schwellenwerte, die zur Spezifizierung eines oder mehrerer der oben genannten Kriterien angewandt werden

Abschließend haben die MS die oben genannten Informationen im '''Bedarfsfall''', mindestens jedoch alle vier Jahre, zu übermitteln.

Im Umsetzungsgesetz wird der*die Bundesminister*in für Inneres dazu verpflichtet, durch Verordnung nähere Regelungen zur Beurteilung festlegen, wann ein Sicherheitsvorfall die erhebliche Störung bei der Erbringung der wesentlichen Dienste bewirken würde (§ 11 Abs 2 RKEG-Entwurf).

=== Resilienz kritischer Einrichtungen ===

==== Risikobewertungen durch kritische Einrichtungen (Art 12 CER-RL) ====

MS haben sicherzustellen, dass kritische Einrichtungen

* innerhalb von neun Monaten nach Erhalt einer Mitteilung gem Art 6 Abs 3 CER-RL und
* anschließend im Bedarfsfall, mindestens jedoch alle vier Jahre,

eine '''Risikobewertung''' auf der Grundlage der Risikobewertungen durch MS und anderer entsprechender Informationsquellen durchführen, um alle entsprechenden Risiken zu bewerten, die die Erbringung ihrer wesentlichen Dienste stören könnten.

Die Bewertung hat allen entsprechenden natürlichen und vom Menschen verursachten Risiken Rechnung zu tragen, die zu einem '''Sicherheitsvorfall''' führen könnten.<ref>Einschließlich grenzüberschreitender oder sektorübergreifender Risiken, Unfällen, Naturkatastrophen, gesundheitlicher Notlagen und hybriden Bedrohungen und anderen feindlichen Bedrohungen, einschließlich terroristischer Straftaten.</ref>

Sie hat dem Ausmaß der '''Abhängigkeit''' anderer im Anhang festgelegten Sektoren von dem wesentlichen Dienst, der von der kritischen Einrichtung erbracht wird, und dem Ausmaß der Abhängigkeit der kritischen Einrichtung von den wesentlichen Diensten, der von anderen Einrichtungen in anderen Sektoren erbracht wird, Rechnung zu tragen.

Dieser Artikel wird durch § 14 RKEG-Entwurf in nationales Recht umgesetzt, wobei die Risikoanalyse an den*die Bundesminister*in für Inneres zu übermitteln ist.

==== Resilienzmaßnahmen kritischer Einrichtungen (Art 13 CER-RL) ====

Die kritischen Einrichtungen haben auf Grundlage der beiden Risikobewertungen geeignete und verhältnismäßige technische, sicherheitsbezogene und organisatorische Maßnahmen zur Gewährleistung ihrer Resilienz zu ergreifen (Art 13 Abs 1 CER-RL).

Darunter fallen Maßnahmen, die erforderlich sind, um

* das Auftreten von '''Sicherheitsvorfällen zu''' '''verhindern'''
* einen angemessenen '''physischen Schutz ihrer Räumlichkeiten und kritischen Infrastrukturen''' zu gewährleisten (zB Zäune, Sperren, Überwachung der Umgebung, Detektionsgeräte, Zugangskontrolle)
* auf '''Sicherheitsvorfälle zu reagieren''', sie '''abzuwehren''' und die Folgen solcher Vorfälle zu '''begrenzen''' (bspw Umsetzung von Risiko- und Krisenmanagementverfahren und -protokollen)
* nach Sicherheitsvorfällen die '''Wiederherstellung zu gewährleisten''' (zB Maßnahmen zur Aufrechterhalten des Betriebs; Ermittlung alternativer Lieferketten)
* ein angemessenes '''Sicherheitsmanagement hinsichtlich der Mitarbeitenden''' zu gewährleisten (bspw Festlegung von Kategorien von Personal, das kritische Funktionen wahrnimmt; Zugangsrechten; Zuverlässigkeitsprüfungen)
* das entsprechende Personal für diese Maßnahmen unter gebührender Berücksichtigung von Schulungen, Informationsmaterial und Übungen zu '''sensibilisieren'''
Die Kommission wird dabei '''Leitlinien''' erlassen, die diese Maßnahmen weiter konkretisieren (Art 13 Abs 5 CER-RL). Ebenso wird die Kommission Durchführungsrechtsakte erlassen, um die '''technischen und methodischen Spezifikationen''' für die Anwendung der Maßnahmen festzulegen (Art 13 Abs 6 CER-RL).

Die kritischen Einrichtungen müssen dabei über einen '''Resilienzplan''' oder ein gleichwertiges Dokument, in dem diese Maßnahmen beschrieben werden, verfügen und diesen anwenden (Art 13 Abs 2 CER-RL).

Als Ansprechpartner*in für die Behörden müssen die kritischen Einrichtungen auch eine*n '''Verbindungsbeauftragte*n''' oder eine Person mit vergleichbarer Aufgabenstellung benennen (Art 13 Abs 3 CER-RL).

Auf Ersuchen des MS und mit Zustimmung der kritischen Einrichtung kann die Kommission auch Beratungsmissionen (Art 18 CER-RL) organisieren, um die kritische Einrichtung im Hinblick auf die Erfüllung ihrer Verpflichtungen zu beraten (Art 13 Abs 4 CER-RL).

Dieser Artikel wird durch § 15 RKEG-Entwurf umgesetzt. Resilienzmaßnahmen sind erstmalig innerhalb von zehn Monaten nach bescheidmäßiger Einstufung zu treffen und in einem Resilienzplan darzulegen.

==== Zuverlässigkeitsüberprüfungen (Art 14 CER-RL) ====

Kritische Einrichtungen können in hinreichend begründeten Fällen und unter Berücksichtigung der Risikobewertung durch MS Anträge auf '''Zuverlässigkeitsprüfungen''' (Art 14 Abs 1 CER-RL) von Personen stellen, die

* '''sensible Funktionen''' oder/zugunsten der kritischen Einrichtung innehaben
* berechtigt sind, über direkten '''Zugriff/Fernzugriff''' auf Räumlichkeiten, Informationen oder Kontrollsysteme zu verfügen
* für die '''Besetzung von Positionen''', die unter die beiden oben genannten Kriterien fallen, in Betracht gezogen werden

Diese Anträge müssen innerhalb eines angemessenen Zeitrahmens geprüft und bearbeitet werden. Zuverlässigkeitsprüfungen müssen '''verhältnismäßige und auf das Notwendige beschränkt''' sein, dh ausschließlich zur Bewertung eines potenziellen Sicherheitsrisikos durchgeführt werden (Art 14 Abs 2 CER-RL).

Die Zuverlässigkeitsprüfungen müssen sich dabei mindestens der '''Identität der Person''', die einer Prüfung unterzogen wird, vergewissern und eine '''Strafregisterprüfung''' der Person in Bezug auf Straftaten, die für eine spezifische Position relevant sind, enthalten (Art 14 Abs 3 CER-RL).

Diese Bestimmung wird durch § 16 RKEG-Entwurf umgesetzt, der insbesondere die dafür notwendige Datenverarbeitung ausführlich konkretisiert (§ 16 Abs 2, 3 RKEG-Entwurf). Auch werden weitere Aspekte, die bei der Überprüfung zu berücksichtigen sind konkretisiert, bspw ob eine rechtkräftige Verurteilung für eine mit Vorsatz begangene gerichtliche strafbare Handlung vorliegt, ein Strafverfahren anhängig ist, gegen die Person ein Waffenverbot vorliegt oder ob die Person ein Naheverhältnis zu einer extremistischen oder terroristischen Gruppierung hat (§ 16 Abs 5 RKEG-Entwurf).

==== Meldung von Sicherheitsvorfällen (Art 15 CER-RL) ====

Kritische Einrichtungen haben der zuständigen Behörde Sicherheitsvorfälle, die die Erbringung wesentlicher Dienste erheblich stören oder erheblich stören könnten, unverzüglich zu '''melden''' (Art 15 Abs 1 CER-RL).

Eine '''erste Meldung''' ist dabei prinzipiell bis spätestens 24 Stunden, nachdem sich die Einrichtung eines Sicherheitsvorfalls bewusst geworden ist, zu übermitteln. Ein '''ausführlicher Bericht''' hat (gegebenenfalls) spätestens ein Monat danach zu folgen.

Die Erheblichkeit einer Störung wird dabei ua anhand der folgenden Parameter bestimmt:

* die Anzahl und der Anteil der von der Störung betroffenen '''Nutzer*innen'''
* die '''Dauer''' der Störung
* das betroffene geographische '''Gebiet'''

Hat ein Sicherheitsvorfall erhebliche Auswirkungen auf die '''Kontinuität''' der Erbringung wesentlicher Dienste für oder '''in sechs oder mehr MS''' oder könnte er solche Auswirkungen haben, so haben die zuständigen Behörden diesen Sicherheitsvorfall der Kommission zu melden.

Die Meldungen müssen '''sämtliche verfügbaren Informationen''' enthalten, die erforderlich sind, damit die zuständige Behörde Art, Ursache und mögliche Folgen des Sicherheitsvorfalls nachvollziehen und ermitteln kann (Art 15 Abs 2 CER-RL).

Auf der Grundlage dieser Information unterrichtet die entsprechende zuständige Behörde über die zentrale Anlaufstelle die '''zentralen Anlaufstellen''' anderer betroffener MS, sofern der Sicherheitsvorfall erhebliche Auswirkungen auf kritische Einrichtungen und die Aufrechterhaltung der Erbringung wesentlicher Dienste an einen oder mehrere andere MS oder in einem oder mehreren anderen MS hat oder haben könnte (Art 15 Abs 3 CER-RL).

So bald wie möglich nach einer Meldung übermittelt die betreffende zuständige Behörde der betreffenden kritischen Einrichtung '''sachdienliche Folgeinformationen''', unter anderem Informationen, die die wirksame Reaktion dieser kritischen Einrichtung auf den betreffenden Sicherheitsvorfall unterstützen könnten (Art 15 Abs 4 CER-RL).

Diese Meldepflichten werden durch § 17 RKEG-Entwurf in nationales Recht umgesetzt.

Die MS '''informieren die Öffentlichkeit''', wenn sie zu der Ansicht gelangen, dass dies im öffentlichen Interesse liegen würde (Art 15 Abs 4 CER-RL).

§ 8 Abs 1 RKEG-Entwurf konkretisiert diese Veröffentlichung von Sicherheitsvorfällen, die nach Anhörung der von einem Sicherheitsvorfall betroffenen kritischen Einrichtung erfolgen kann, um die Öffentlichkeit über Sicherheitsvorfälle zu unterrichten, sofern die Sensibilisierung der Öffentlichkeit zur Verhütung oder zur Bewältigung von Sicherheitsvorfällen erforderlich ist oder die Offenlegung des Sicherheitsvorfalls auf sonstige Weise im öffentlichen Interesse liegt.

=== Kritische Einrichtungen, die von besonderer Bedeutung für Europa sind ===

==== Ermittlung kritischer Einrichtungen, die von besonderer Bedeutung für Europa sind (Art 17 CER-RL) ====

Wenn folgende Kriterien erfüllt werden, gilt eine Einrichtung als kritische Einrichtung von besonderer Bedeutung für Europa (Art 17 Abs 1 CER-RL):

* wenn sie als '''kritische Einrichtung''' gem Art 6 Abs 1 CER-RL eingestuft wurde
* wenn sie für/in '''sechs oder mehr''' MS dieselben/ähnliche wesentliche Dienste erbringt
* '''gemeldet''' wurde (siehe dazu unterhalb zu Art 17 Abs 3 CER-RL).
Nach der Mitteilung über die Einstufung als kritische Einrichtung (Art 6 Abs 3 CER-RL) hat die Einrichtung die Behörde zu '''informieren''', wenn sie wesentliche Dienste für/in sechs oder mehr MS erbringt (welche wesentlichen Dienste in/für welche[n] MS). Die Identität solcher Einrichtungen ist auch der Kommission mitzuteilen. Die Kommission '''konsultiert''' betreffend der Einschätzung, ob es sich bei den Diensten, um wesentliche Dienste handelt, die zuständige Behörde, die die kritische Einrichtung ermittelt hat, die zuständige Behörde anderer betroffenen MS sowie die betreffende kritische Einrichtung. (Art 17 Abs 2 CER-RL).

Wird auf der Grundlage der Konsultation festgestellt, dass die kritische Einrichtung für/in sechs oder mehr MS wesentliche Dienste erbringt, so wird der kritischen Einrichtung '''mitgeteilt''', dass sie als kritische Einrichtung von besonderer Bedeutung für Europa gilt. Die Einrichtung wird auch über ihre Verpflichtungen informiert (Art 17 Abs 3 CER-RL).

Diese Bestimmung wird durch § 19 RKEG-Entwurf in nationales Recht umgesetzt.

==== Beratungsmissionen (Art 18 CER-RL) ====

Auf '''Antrag eines MS''', der eine kritische Einrichtung als kritische Einrichtung von besonderer Bedeutung für Europa ermittelt hat, organisiert die Kommission eine Beratungsmission. Diese dient zur Bewertung der Maßnahmen, die ergriffen wurden, um den Verpflichtungen gem Art 12-16 CER-RL nachzukommen (Art 18 Abs 1 CER-RL).

Unter Zustimmung des MS, der eine kritische Einrichtung als kritische Einrichtung von besonderer Bedeutung für Europa ermittelt hat, kann eine solche Beratungsmission auch aus '''eigenem Entschluss''' '''der Kommission''' oder '''Antrag''' '''eines/mehrerer MS''', für den/die der wesentliche Dienst erbracht wird (Art 18 Abs 2 CER-RL).

Der MS, der eine kritische Einrichtung von besonderer Bedeutung für Europa als kritische Einrichtung ermittelt hat, stellt der Kommission auf ihren Antrag bzw Antrag eines oder mehrerer MS Folgendes zur Verfügung (Art 18 Abs 3 CER-RL):

* die entsprechenden Teile der '''Risikobewertung''' durch kritische Einrichtungen
* eine Auflistung der ergriffenen '''Resilienzmaßnahmen''' gem Art 13 CER-RL
* '''Aufsichts- oder Durchsetzungsmaßnahmen''', die die zuständige Behörde gem Art 21, 22 CEr-RL ergriffen hat (inklusive Bewertung der Einhaltung der Vorschriften, erteilte Anordnungen)
Die Beratungsmission erstattet innerhalb von drei Monaten nach Abschluss über die Ergebnisse '''Bericht''' an die Kommission, den MS der eine kritische Einrichtung von besonderer Bedeutung für Europa als kritische Einrichtung ermittelt hat, und die MS, für die/in denen der wesentliche Dienst erbracht wird (Art 18 Abs 4 CER-RL).

Dieser Bericht wird von den MS, für die der wesentliche Dienst erbracht wird, analysiert. Die MS '''beraten''' (erforderlichenfalls) die Kommission in Bezug auf die Frage, ob die betreffende kritische Einrichtung von besonderer Bedeutung für Europa ihren Verpflichtungen erfüllt und welche Maßnahmen ergriffen werden könnten, um die Resilienz zu verbessern.

Die Kommission teilt auf Grundlage dieser Ratschläge dem MS, der eine kritische Einrichtung von besonderer Bedeutung für Europa als kritische Einrichtung ermittelt hat, den MS, für die/in denen der wesentliche Dienst erbracht wird, und der betreffenden kritischen Einrichtung ihre '''Stellungnahme''' zur Frage, ob die kritische Einrichtung ihre Verpflichtungen erfüllt bzw welche Maßnahmen ergriffen werden könnten, um die Resilienz zu verbessern, mit.

Der MS, er eine kritische Einrichtung von besonderer Bedeutung für Europa als kritische Einrichtung ermittelt hat, stellt sicher, dass der Stellungnahme von der zuständigen Behörde und der kritischen Einrichtung (gebührend) '''Rechnung getragen wird''' und '''unterrichtet''' Kommission und andere MS, für die/in denen der wesentliche Dienst erbracht wird, über die ergriffenen Maßnahmen.

Eine Beratungsmission '''setzt sich dabei'''

* aus Sachverständigen der MS, in dem sich die kritische Einrichtung von besonderer Bedeutung für Europa befindet
* aus Sachverständigen der MS, für die/in denen der wesentliche Dienst erbracht wird
* Vertreter*innen der Kommission

'''zusammen'''.

Diese MS können Kandidat*innen '''vorschlagen''', die an einer Beratungsmission teilnehmen sollen. Die Kommission wählt nach Absprache mit dem MS, der eine kritische Einrichtung von besonderer Bedeutung für Europa als kritische Einrichtung ermittelt hat, die Mitglieder jeder Beratungsmission nach Maßgabe ihrer '''fachlichen Eignung''' und, soweit möglich, unter Gewährleistung einer '''geografisch ausgewogenen Vertretung''' aus allen diesen MS aus und ernennt sie (Art 18 Abs 5 CER-RL).

Die Beratungsmission wird dabei in Zukunft noch durch einen '''Durchführungsrechtsakt''' der Kommission konkretisiert (Art 18 Abs 6 CER-RL).

Dabei muss von den MS sichergestellt werden, dass die kritischen Einrichtungen von besonderer Bedeutung für Europa den Beratungsmissionen '''Zugang zu'''

* Informationen
* Systemen und
* Anlagen

im Zusammenhang mit der Erbringung ihrer wesentlichen Dienste gewähren, die zur Durchführung der betreffenden Beratungsmission erforderlich sind (Art 18 Abs 7 CER-RL).

Bei der Organisation sind Berichte über etwaige Inspektionen gem

* Verordnung (EG) 725/2004 des Europäischen Parlaments und des Rates vom 31. März 2004 zur Erhöhung der Gefahrenabwehr auf Schiffen und in Hafenanlagen
* Verordnung (EG) 300/2008 des Europäischen Parlaments und des Rates vom 11. März 2008 über gemeinsame Vorschriften für die Sicherheit in der Zivilluftfahrt und zur Aufhebung der Verordnung (EG) 2320/2002
* sowie über Überwachung gem Richtlinie 2005/65/EG des Europäischen Parlaments und des Rates vom 26. Oktober 2005 zur Erhöhung der Gefahrenabwehr in Häfen
die die Kommission durchgeführt hat, zu '''berücksichtigen''' (Art 18 Abs 9 CER-RL).

Die Kommission '''unterrichtet''' die Gruppe für die Resilienz kritischer Einrichtungen über die Organisation einer Beratungsmission (Art 18 Abs 10 CER-RL).

Diese Bestimmung wird durch § 19 Abs 3, 4 RKEG-Entwurf in nationales Recht umgesetzt.

== Behördenstruktur ==

=== Zuständige Behörden (Art 9 CER-RL) ===

Die MS haben dabei eine oder mehrere nationale zuständige Behörden zu benennen bzw einzurichten. Als Sonderregelung sind in Bezug auf das Bankwesen und Finanzmarktinfrastrukturen (grundsätzlich) die nach DORA bestimmte Behörde zuständig, in Bezug auf Digitale Infrastruktur die nach NIS-2 zuständige Behörde (Art 9 Abs 1 CER-RL). Die Behörden haben sich dabei mit anderen nationalen Behörden (bspw Katastrophenschutz, Strafverfolgung, Datenschutzbehörde), kritischen Einrichtungen und interessierten Parteien zu konsultieren und zusammenzuarbeiten (Art 9 Abs 5 CER-RL). In Bezug auf Cybersicherheitsrisiken, Cyberbedrohungen und Cybersicherheitsvorfällen etc ist eine Zusammenarbeit und ein Informationsaustausch mit der NIS-2-Behörde vorgesehen (Art 9 Abs 6 CER-RL).
{| class="wikitable"
|+
!Hinweis:
|-
|Zuständige Behörde und zugleich zentrale Anlaufstelle ist nach dem RKEG-Entwurf der*die Bundesminister*in für Inneres, wobei die Landespolizeidirektion mit der Durchführung einzelner Aufgaben beauftragt werden kann (§ 4 Abs 1, 3, 4 RKEG-Entwurf).

|}

=== Zentrale Anlaufstelle (Art 9 CER-RL) ===

Daneben haben MS eine '''zentrale Anlaufstelle''', die als Verbindungsstelle zur Gewährleistung der grenzüberschreitenden Zusammenarbeit fungiert, zu benennen oder einzurichten (Art 9 Abs 2 CER-RL). Diese zentralen Anlaufstellen haben der Kommission und der Gruppe für die Resilienz kritischer Einrichtungen alle zwei Jahre einen '''zusammenfassenden Bericht''' über die eingegangen Meldungen vorzulegen (Art 9 Abs 3 CER-RL).

Nach § 4 Abs 4 RKEG-Entwurf ist der*die Bundesminister*in für Inneres die zentrale Anlaufstelle.

=== Unterstützung (Art 10 CER-RL) ===

Über Kooperation der Behörden mit den kritischen Richtungen und dem freiwilligen Informationsaustausch zwischen kritischen Einrichtungen hinaus haben die MS kritische Einrichtungen auch bei der Verbesserung ihrer Resilienz zu '''unterstützen''' (zB Leitfäden, Methoden, Übungen, Beratung, Schulungen, etc) (Art 10 CER-RL).

Diese Bestimmung wird durch § 13 RKEG-Entwurf umgesetzt.

=== Gruppe für die Resilienz kritischer Einrichtungen (Art 19 CER-RL) ===

Zur '''Unterstützung''' der Kommission und zur Erleichterung der '''Zusammenarbeit''' zwischen den MS bzw den '''Informationsaustausch''' wird eine sog Gruppe für die Resilienz kritischer Einrichtungen eingesetzt (Art 19 Abs 1 CER-RL).

Die Gruppe setzt sich aus '''Vertreter*innen''' der MS und der '''Kommission''', deren Vertreter*in den Vorsitz führt, zusammen. Wenn es für die Erfüllung ihrer Aufgaben relevant ist, kann die Gruppe entsprechende '''Interessenvertreter*innen''' zur Teilnahme einladen. Auf Ersuchen des Europäischen Parlaments können '''Sachverständige des Parlaments''' zur Teilnahme an den Sitzungen eingeladen werden (Art 19 Abs 2 CER-RL).

Die Gruppe hat dabei eine Reihe von '''Aufgaben''' (Art 19 Abs 3 CER-RL):

* Unterstützung der Kommission bei der Unterstützung der MS beim Ausbau ihrer Kapazitäten in Hinblick auf die Resilienz kritischer Einrichtungen
* Analyse der Strategien zur Ermittlung bewährter Verfahren
* Erleichterung des Austauschs bewährter Verfahren (Ermittlung kritischer Einrichtungen, grenzüberschreitende/sektorübergreifende Abhängigkeiten, Risiken, Sicherheitsvorfälle)
* Mitwirkung an Dokumenten über die Resilienz auf Unionsebene
* Mitwirkung an der Ausarbeitung von Leitlinien über erhebliche Störungen (Art 7 Abs 3 CER-RL) und Resilienzmaßnahmen (Art 13 Abs 5 CER-RL) und delegierten Rechtsakten/Durchführungsrechtsakten
* Analyse von zusammenfassenden Berichten der zentralen Anlaufstellen (Art 9 Abs 3 CER-RL)
* Austausch von bewährten Verfahren in Bezug auf die Meldung von Sicherheitsvorfällen (Art 15 CER-RL)
* Erörterung der zusammenfassenden Berichte der Beratungsmission (Art 18 Abs 10 CER-RL)
* Austausch von Informationen und bewährten Verfahren (Innovation, Forschung und Entwicklung im Zusammenhang mit der Resilienz kritischer Einrichtungen)
* Informationsaustausch zu Fragen, die die Resilienz kritischer Einrichtungen betreffen, mit den entsprechenden Organen, Einrichtungen und sonstigen Stellen der Union

Die Gruppe hat dabei alle zwei Jahre ein '''Arbeitsprogramm''' mit den Maßnahmen zur Umsetzung ihrer Ziele und Aufgaben zu erstellen (Art 19 Abs 4 CER-RL).

Die Gruppe hat regelmäßig zu tagen. Mindestens einmal jährlich hat eine Tagung gemeinsam mit der Kooperationsgruppe nach der [[Special:MyLanguage/Network and Information Security Directive (NIS II-RL)|NIS 2-RL]] stattzufinden (Art 19 Abs 5 CER-RL).

Die Kommission hat der Gruppe im Bedarfsfall, mindestens jedoch alle vier Jahre, einen '''zusammenfassenden Bericht''' über die von den MS übermittelten Informationen (Art 4 Abs 3, Art 5 Abs 4 CER-RL) zu übermitteln (Art 19 Abs 7 CER-RL).

== Bedeutung von Normen und Standards (Art 16 CER-RL) ==

Die MS haben, um die abgestimmte Umsetzung dieser Richtlinie voranzutreiben, die Anwendung von europäischen und internationalen Normen und technischen Spezifikationen zu fördern, die für die Maßnahmen zur Sicherheit und Resilienz kritischer Einrichtungen relevant sind, sofern dies sinnvoll ist und ohne die Verwendung einer bestimmten Technologieart vorzuschreiben oder diese zu bevorzugen (Art 16 CER-RL).

== Synergien ==

=== NIS-2-RL ===

* Die Identität der nach CER-RL ermittelten kritischen Einrichtungen ist auch der für [[Special:MyLanguage/Network and Information Security Directive (NIS II-RL)|NIS-2-RL]] zuständigen Behörde mitzuteilen (Art 6 Abs 4 CER-RL).
* In Bezug auf Digitale Infrastruktur sind die nach NIS-2 zuständige Behörde zuständige Behörden (Art 9 Abs 1 CER-RL).
* In Bezug auf Cybersicherheitsrisiken, Cyberbedrohungen und Cybersicherheitsvorfällen etc ist eine Zusammenarbeit und ein Informationsaustausch der nach der CER-RL zuständigen Behörde mit der NIS-2-Behörde vorgesehen (Art 9 Abs 6 CER-RL).
* Die Gruppe für die Resilienz kritischer Einrichtungen hat mindestens einmal jährlich gemeinsam mit der Kooperationsgruppe nach der [[Special:MyLanguage/Network and Information Security Directive (NIS II-RL)|NIS 2-RL]] zu tagen (Art 19 Abs 5 CER-RL).

=== DORA ===

* Als Sonderregelung sind in Bezug auf das Bankwesen und Finanzmarktinfrastrukturen (grundsätzlich) die nach [[Special:MyLanguage/Digital Operational Resilienec Act (DORA)|DORA]] bestimmte Behörde auch nach CER-RL zuständige Behörden (Art 9 Abs 1 CER-RL).

=== Schiffe, Hafenanlagen, Zivilluftfahrt ===

* Bei der Organisation von Beratungsmissionen sind Berichte über etwaige Inspektionen und Überwachungen nach anderen Rechtsakten (Verordnung (EG) 725/2004 des Europäischen Parlaments und des Rates vom 31. März 2004 zur Erhöhung der Gefahrenabwehr auf Schiffen und in Hafenanlagen; Verordnung (EG) 300/2008 des Europäischen Parlaments und des Rates vom 11. März 2008 über gemeinsame Vorschriften für die Sicherheit in der Zivilluftfahrt und zur Aufhebung der Verordnung (EG) 2320/2002; Richtlinie 2005/65/EG des Europäischen Parlaments und des Rates vom 26. Oktober 2005 zur Erhöhung der Gefahrenabwehr in Häfen) zu berücksichtigen (Art 18 Abs 9 CER-RL).

== Sanktionen/sonstige Konsequenzen (Art 21, 22 CER-RL) ==

=== Allgemeines (Art 21 CER-RL) ===

Zuständige Behörden müssen zur Beurteilung, ob kritische Einrichtungen die Verpflichtungen der CER-RL erfüllen, über '''Befugnisse und Mittel''' verfügen, um

* Vor-Ort-Kontrollen
* externe Aufsichtsmaßnahmen
* Audits

durchzuführen bzw anzuordnen ('''Aufsichtsmaßnahmen''') (Art 21 Abs 1 CER-RL).

Zuständige Behörden können dabei die Übermittlung von '''Informationen''' zur Beurteilung, ob die Maßnahmen zur Gewährleistung der Resilienz den Anforderungen entsprechen, und Nachweisen der wirksamen Umsetzung dieser Maßnahmen (einschließlich der Ergebnisse eines externen Audits) verlangen (Art 21 Abs 2 CER-RL).

Im Anschluss auf die Aufsichtsmaßnahmen oder die Prüfung der Informationen können die zuständigen Behörden anweisen, '''Maßnahmen''' zu ergreifen, um Verstöße zu beheben (Art 21 Abs 3 CER-RL).

In Umsetzung dieser Bestimmungen ist der Bundesminister für Inneres ermächtigt, von kritischen Einrichtungen '''Nachweise für die Erfüllung der Anforderungen''' gemäß §§ 14, 15 RKEG-Entwurf sowie die Durchführung von '''Audits'''<ref>Die Audits werden dabei durch '''qualifizierte Stellen''', dh natürliche oder juristische Personen oder eingetragene Personengesellschaften, die aufgrund eines begründeten schriftlichen Antrags bescheidmäßig zur Durchführung von Audits berechtigt sind (§ 21 RKEG-Entwurf), durchgeführt.</ref> zu verlangen, wobei die erforderlichen Informationen dafür zu übermitteln sind (§ 20 Abs RKEG-Entwurf).

Insbesondere Vor-Ort-Kontrollen werden durch § 20 Abs 3 RKEG-Entwurf näher konkretisiert.

=== Sanktionen (Art 22 CER-RL) ===

Die CER-RL überlässt die Schaffung von Vorschriften für '''Sanktionen''' bei Verstößen und alle für die Anwendung der Sanktionen erforderlichen Maßnahmen primär den MS. Die Sanktionen müssen dabei wirksam, verhältnismäßig und abschreckend sein (Art 22 CER-RL).

Die Verwaltungsstrafen werden daher durch § 22 RKEG-Entwurf umgesetzt und liegen in der Zuständigkeit der '''Bezirksverwaltungsbehörden'''.

Eine mit einer '''Geldstrafe''' '''bis zu 50 000 Euro''', im Wiederholungsfall bis zu 100 000 Euro, verbundene Übertretung besteht bspw für die fehlende Bekanntgabe einer Kontaktstelle/Ansprechperson oder die fehlende Übermittlung der Risikoanalyse oder des Resilienzplans (§ 22 Abs 1 RKEG-G).

Eine Nichtumsetzung der mit Bescheid angeordneten Maßnahmen nach Feststellung, dass die Anforderungen an die Risikoanalyse bzw an die Resilienzmaßnahmen nicht oder nicht vollständig erfüllt werden, und Verstöße gegen die Meldepflichten können mit einer '''Geldstrafe''' '''bis zu 7 Mio Euro''' bestraft werden (§ 22 Abs 2 RKEG-Entwurf).

Geldstrafen können, unter gewissen Umständen, auch '''gegen juristische Personen''' oder eingetragene Personengesellschaften verhängt werden (§ 22 Abs 3, 4 RKEG-Entwurf).

Werden Verpflichtungen durch Stellen der '''öffentlichen Verwaltung''' nicht eingehalten, ist die Nichteinhaltung mit Bescheid festzustellen sowie eine angemessene Frist zur Herstellung des rechtmäßigen Zustandes anzuordnen. Wird dieser Zustand nicht fristgerecht hergestellt, ist die Nichteinhaltung der Verpflichtungen in einer allgemeinen Weise zu veröffentlichen (§ 23 RKEG-Entwurf).

== Weiterführende Literatur & Links ==

=== Überblicksartikel ===

* ''Eisenmenger'', Ein neuer Rechtsrahmen für Kritische Infrastrukturen (KRITIS) - unter Berücksichtigung der EU-Resilienz-Richtlinie, NVwZ 2023, 1203
* ''Škorjanc'', Der neue acquis communautaire des europäischen IT-Sicherheitsrechts, ecolex 2023, 881

=== Sammelwerke ===

* ''Dittrich/Dochow/Ippach'' (Hrsg), Rechtshandbuch Cybersicherheit im Gesundheitswesen (2024)
* ''Hornung/Schallbruch'' (Hrsg), IT-Sicherheitsrecht. Praxishandbuch2 (2024)
* ''Kipker'' (Hrsg), Cybersecurity. Rechtshandbuch2 (2023)

=== Links ===

* [https://www.onlinesicherheit.gv.at/Services/Initiativen-und-Angebote/Strategische-Infrastrukturen/Austrian-Program-for-Critical-Infrastructure-Protection-APCIP.html Austrian Program for Critical Infrastructure Protection (<abbr>APCIP</abbr>)]
* [https://www.wko.at/noe/wirtschaft/2024-05-praesentation-markus-mueller-rke.pdf ''Bundesministerium für Inneres (BMI)'', Richtlinie zur Resilienz Kritischer Einrichtungen (RKE). Krisenresilienz und Sicherheit für Unternehmen (Stand 29. 5. 2024)]

== Einzelnachweise ==

Translations:Cyber Security Act (CSA)/26/de

2025-06-03T13:21:02Z