Komplexe Aufgaben – (un)klare Ansagen?! : Absehbare Meldepflichten nach NIS-2-Umsetzungsgesetz, KRITIS-Dachgesetz und DORA

Durch ihren Fokus auf IT-/Cyber-Sicherheit sind die NIS-2-Richtlinie und ihr regulatorischer Rahmen von besonderer Bedeutung für das BSI. Eine nicht unwesentliche Veränderung im Bereich der Regulierung von IT-Sicherheit ist zu erwarten. Die NIS-2-Richtlinie wird in Deutschland voraussichtlich nicht rechtzeitig umgesetzt: „Anvisiert wird jetzt ein Inkrafttreten im Frühjahr 2025“ [3]. Im Rahmen des NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes (NIS2UmsuCG), das im aktuellen Regierungsentwurf [4] inzwischen auf einen imponierenden Umfang von 208 Seiten angewachsen ist, werden unter anderem Melde- und Registrierungspflichten neu geregelt.

Parallel zur NIS-2-Richtlinie werden weitere EU-Regularien ins deutsche nationale Recht umgesetzt: die bereits erwähnte Critical-Entities-Resilience-Directive (RCE- beziehungsweise CER-Directive), die im Rahmen des Gesetzes zur Umsetzung der CER-Richtlinie und zur Stärkung der Resilienz kritischer Anlagen (kurz: KRITISDachG, [5]) vom Bundesinnenministerium (BMI) umgesetzt wird, sowie der Digital-Operational-Resilience-Act (DORA, [6]), der für Finanzunternehmen gilt und direkt der Umsetzung durch die zuständige Aufsichtsbehörde, der Bundesanstalt für Finanzdienstleistungsaufsicht (Ba-Fin), unterliegt (siehe auch [7,8]). DORA ist bereits am 17. Januar 2023 in Kraft getreten – ab dem 17. Januar 2025 gilt die Anwendung von DORA auf der EU-Ebene.

Jede dieser EU-Regularien und so auch ihre Umsetzungen in das nationale Recht bedeuten teilweise neue, teilweise geänderte Meldepflichten für Sicherheitsvorfälle, Störungen oder IKT-bezogene Vorfälle – zusätzlich zu den bestehenden und relativ in ihren Vorgaben stabilen Meldepflichten für Verletzungen des Schutzes personenbezogener Daten gemäß EU Datenschutzgrundverordnung (DSGVO).

Daten(schutz)pannen

Melde- oder benachrichtigungspflichtige Ereignisse werden in Art. 33 und 34 DSGVO spezifiziert: Meldepflichtig sind gemäß Art. 33 DSGVO Datenpannen, konkret „Personal Data Breaches“ beziehungsweise „Verletzungen des Schutzes personenbezogener Daten“ definiert in Art. 4 Nr. 12 DSGVO als „eine Verletzung der Sicherheit, die, ob unbeabsichtigt oder unrechtmäßig, zur Vernichtung, zum Verlust, zur Veränderung, oder zur unbefugten Offenlegung von beziehungsweise zum unbefugten Zugang zu personenbezogenen Daten führt, die übermittelt, gespeichert oder auf sonstige Weise verarbeitet wurden.“

Filusch/Fünfstück nennen in [9] als weitere mögliche Verletzungen aus den Erwägungsgründen 75 und 85:

• die unbefugte Aufhebung der Pseudonymisierung oder
• einen Verlust der Vertraulichkeit von dem Berufsgeheimnis unterliegenden Daten.

Im Zentrum der Betrachtung steht auch hier der Begriff „Sicherheit“: Erfolgt „keine Verletzung der technischen und organisatorischen Maßnahmen, sondern eine Verletzung des Art. 6 DSGVO, findet […] eine Datenverarbeitung ohne Rechtsgrundlage statt und liegt kein sicherheitsrelevantes Ereignis vor, ergibt sich keine Meldebeziehungsweise Benachrichtigungspflicht“ [10].

Nach Art. 33 Abs. 1 DSGVO ist die Verletzung der Sicherheit personenbezogener Daten „unverzüglich“, das heißt „ohne schuldhaftes Zögern“ im Sinne des § 121 Abs. 1 BGB, zu melden. Laut Art. 33 Abs. 1 DSGVO soll die Meldung „möglichst binnen 72 Stunden“ erfolgen. Die Frist beginnt mit der positiven Kenntnisnahme beziehungsweise bei hinreichender Gewissheit von den tatsächlichen Umständen, die eine Meldepflicht der Verantwortlichen begründen – Meldepflichten gelten sowohl für die Verantwortlichen selbst als auch für Auftragsverarbeiter. Adressaten der Meldungen sind Datenschutzbehörden der Länder sowie der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI), beispielsweise als Verpflichteter nach § 169 Abs. 1 TKG [11].

Art. 33 DSGVO schreibt keine bestimmte Form für die Meldung von Datenpannen vor – womit er theoretisch auch keine Form verbietet. Datenschutzbehörden der Länder bieten Onlineformulare an, mit denen Meldungen durchgeführt werden können.

Oft wenig beachtet, doch für die Abwägung von Pro und Contra einer Meldung an Aufsichtsbehörden und/oder eine Benachrichtigung der Betroffenen durchaus relevant ist eine Risikobewertung: Eine Meldung an die Aufsichtsbehörde muss gemäß Art. 33 Abs. 1 DSGVO nämlich nicht erfolgen, wenn die Datenpanne „voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen“ führt.

Bei einer nicht erfolgten oder unvollständigen Meldung oder Benachrichtigung kann die Aufsichtsbehörde Bußgelder nach Art. 83 Abs. 4 Lit. a DSGVO verhängen, nach aktueller Fassung: „[…] Geldbußen von bis zu 10.000.000 EUR oder im Fall eines Unternehmens von bis zu 2 % seines gesamten weltweit erzielten Jahresumsatzes des vorangegangenen Geschäftsjahrs […], je nachdem, welcher der Beträge höher ist.“ Die Datenschutzaufsicht kann ebenfalls eine Verwarnung gegenüber dem Verantwortlichen gemäß Art. 58 Abs. 2 Lit. b DSGVO aussprechen. Sie kann auch Anordnungen zur Anpassung, Beschränkung oder sogar (bspw. bei wiederholten Verstößen) zum Verbot von Verarbeitungen erlassen (Art. 58 Abs. 2 Lit. f DSGVO).

Sicherheitsvorfälle

Sicherheitsvorfälle ohne Verletzung personenbezogener Daten lösen keine Meldepflicht nach DSGVO aus. Hier finden andere, teilweise neue Regularien Anwendung. Meldepflichten gelten – auch nach der Modernisierung und europaweiten Vereinheitlichung der Regulierung – weiterhin nicht für alle Arten von Sicherheitsvorfällen. Sie gelten nicht einheitlich für alle Unternehmen oder Behörden, sondern für bestimmte Gruppen, Sektoren oder Branchen, wobei es oft den Unternehmen überlassen wird, festzustellen, ob eine bestimmte Regulierung sie adressiert. Meldepflichten wurden zuletzt mit dem IT Sicherheitsgesetz 2.0 („Zweites Gesetz zur Erhöhung der Sicherheit informationstechnischer Systeme“, ITSiG 2.0) aus dem Jahr 2021 und darauffolgenden Ergänzungen beispielsweise bezüglich der Unternehmen im besonderen öffentlichen Interesse (UBI) geregelt (vgl. [12]).

„Die […] gestiegenen Cybersicherheitsanforderungen an juristische und natürliche Personen, die wesentliche Dienste erbringen oder Tätigkeiten ausüben, werden mit der 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 vom 27. Dez. 2022, S. 80, im Folgenden NIS-2-Richtlinie) in der gesamten Europäischen Union weiter angeglichen“, heißt es in der Einleitung zum Regierungsentwurf des NIS-2-Umsetzungsgesetzes. Doch infolge der Umsetzung europäischer Regulierung wie DORA, NIS-2- oder CER-Richtlinie ist in Deutschland eine Diversifizierung der Meldepflichten für Sicherheitsvorfälle zu erwarten, die schon zuvor durch zahlreiche Ausnahmen gekennzeichnet waren.

Meldepflichten gemäß NISUmsuCG sowie KRITIS-DachG-E

Mit den Entwürfen des KRITIS-DachG vom 27.Juli sowie 21. Dezember 2023 wurde erstmalig eine zusätzliche Meldeinstanz neben dem bis dahin als zentrale Meldestelle festgelegten Bundesamt für Sicherheit in der Informationstechnik (BSI) etabliert: das Bundesamt für Bevölkerungsschutz und Katastrophenhilfe (BBK).

Nun regeln die §§ 32ff. des Regierungsentwurfs des NIS-2-Umsetzungsgesetzes – vorbehaltlich von Änderungen durch den Bundestag im weiteren Verfahren – Meldepflichten für Sicherheitsvorfälle für „besonders wichtige Einrichtungen und wichtige Einrichtungen“, während in § 5 unter der Überschrift „Allgemeine Meldestelle für die Sicherheit in der Informationstechnik“ dem BSI gemäß Abs. 1 noch die Rolle als „der nationale Koordinator für die Zwecke einer koordinierten Offenlegung von Schwachstellen“ überlassen wird. Das BSI nimmt „als zentrale Stelle für Meldungen von Dritten Informationen über Sicherheitsrisiken in der Informationstechnik entgegen und wertet diese Informationen aus“.

Das bisher als Grundstein der KRITIS-Regulierung in Deutschland geltende BSI-Gesetz (BSIG) definierte in § 8b das BSI als zentrale Meldestelle für KRITIS-Betreiber – § 4b BSIG definierte das Bundesamt als zentrale allgemeine Meldestelle für Sicherheit in der IT. Das BSI dürfte zur Abwehr von Gefahren Informationen sammeln und auswerten sowie sich mit anderen Behörden austauschen. Anders als noch im ITSIG 2.0 und im aktuellen BSIG festgelegt, sind die genannten Einrichtungen nun jedoch gemäß § 32 Abs. 1 BSI-Gesetz-E vom 22. Juli 2024 verpflichtet, „an eine vom Bundesamt [für Sicherheit in der Informationstechnik] und dem Bundesamt für Bevölkerungsschutz und Katastrophenhilfe eingerichtete gemeinsame Meldestelle zu melden“ (zu Kritik siehe etwa [13,14]).

Das dreistufige Melderegime nach § 32 BSIG-E

Meldepflichten für Sicherheitsvorfälle werden im NIS2UmsuCG vom 22. Juli 2024 (vgl. § 32 BSIG-E) angelehnt an die DSGVO organisiert und sollen dreistufig erfolgen: „Die bislang einstufige Meldepflicht bei Vorfällen wird durch das dreistufige Melderegime der NIS-2-Richtlinie ersetzt. Dabei soll der bürokratische Aufwand für die Einrichtungen im Rahmen des bestehenden mitgliedstaatlichen Umsetzungsspielraums minimiert werden“, heißt es im Regierungsentwurf.

Konkret wird mit § 32 BSIG-E zu den Meldepflichten festgelegt, dass besonders wichtige Einrichtungen sowie wichtige Einrichtungen an die eingerichtete gemeinsame Meldestelle erstens „unverzüglich, spätestens jedoch innerhalb von 24 Stunden nach Kenntniserlangung von einem erheblichen Sicherheitsvorfall“ eine Erstmeldung einreichen, zweitens „unverzüglich, spätestens jedoch innerhalb von 72 Stunden nach Kenntniserlangung von einem erheblichen Sicherheitsvorfall, eine Meldung über diesen Sicherheitsvorfall“ vornehmen und drittens „spätestens einen Monat nach Übermittlung der Meldung des Sicherheitsvorfalls“ eine Abschlussmeldung erstatten (vgl. § 32 Abs. 1 BSIG-E).

Eine Fortschrittsmeldung wird gemäß § 32 Abs. 2 BSIG-E dann notwendig, wenn der Sicherheitsvorfall innerhalb eines Monats nach der Erstmeldung noch nicht zu Ende ist. Dann „legt die betreffende Einrichtung statt einer Abschlussmeldung zu diesem Zeitpunkt eine Fortschrittsmeldung vor.“ In diesem Fall ist die Abschlussmeldung nach abschließender Bearbeitung des Sicherheitsvorfalls zu übermitteln.

• Angaben zur Art der Bedrohung beziehungsweise ihrer zugrunde liegenden Ursache, die wahrscheinlich den Sicherheitsvorfall ausgelöst hat
• Angaben zu den getroffenen und laufenden Abhilfemaßnahmen
• gegebenenfalls grenzüberschreitende Auswirkungen des Sicherheitsvorfalls

Diese Meldepflicht gilt für besonders wichtige und wichtige Einrichtungen. Betreiber kritischer Anlagen sind gemäß § 32 Abs. 3 zu weiteren Angaben verpflichtet, „zur Art der betroffenen Anlage und der kritischen Dienstleistung sowie zu den Auswirkungen des Sicherheitsvorfalls auf diese Dienstleistung […], wenn ein erheblicher Sicherheitsvorfall Auswirkungen auf die von ihnen betriebene kritische Anlage hat oder haben könnte.“

Anwendungsbereich der Meldepflichten

Eine Meldung sollte sich auf wesentliche beziehungsweise erhebliche Sicherheitsvorfälle beziehen, die sich folgendermaßen von den (einfachen) Sicherheitsvorfällen unterscheiden:

• Gemäß § 2 Nr. 40 BSIG-E ist ein Sicherheitsvorfall ein Ereignis, das die Verfügbarkeit, Integrität oder Vertraulichkeit gespeicherter, übermittelter oder verarbeiteter Daten oder der Dienste, die über informationstechnische Systeme, Komponenten und Prozesse angeboten werden oder zugänglich sind, beeinträchtigt.
• Gemäß § 2 Nr. 11 ist ein erheblicher Sicherheitsvorfall ein Sicherheitsvorfall, der schwerwiegende Betriebsstörungen der Dienste oder 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 […]

Was die Einzelheiten zur Ausgestaltung des Meldeverfahrens und zur Konkretisierung der Meldungsinhalte betrifft, so sollten diese gemäß § 32 Abs. 4 BSIG-E vom BSI „nach Anhörung der betroffenen Betreiber und der betroffenen Wirtschaftsverbände im Einvernehmen mit dem Bundesamt für Bevölkerungsschutz und Katastrophenhilfe“ festgelegt und vom BSI „auf dessen Internetseite veröffentlicht“ werden.

Bezüglich des Austauschs der Informationen über Sicherheitsvorfälle zwischen den Aufsichtsbehörden legt § 32 Abs. 5 fest, dass das BSI „den zuständigen Aufsichtsbehörden des Bundes unverzüglich die bei ihm eingegangenen Meldungen zur Verfügung“ stellt. Im § 40 Abs. 1 wird das Bundesamt entsprechend als „nationale Verbindungsstelle sowie die zentrale Melde- und Anlaufstelle für die Aufsicht für besonders wichtige Einrichtungen und wichtige Einrichtungen in der Sicherheit in der Informationstechnik“ bestimmt und ist gemäß § 40 Abs. 3 Nr. 3 für die kontinuierliche Aktualisierung des Lagebilds „bezüglich der Sicherheit in der Informationstechnik von kritischen Anlagen, besonders wichtigen Einrichtungen und wichtigen Einrichtungen“ verantwortlich. Wenn ein erheblicher Sicherheitsvorfall zwei oder mehr EU-Mitgliedstaaten betrifft, übernimmt das BSI die Unterrichtung der betroffenen Mitgliedstaaten und der ENISA (§ 40 Abs. 4 Nr. 3 BSIG-E).

Bußgelder nach § 65 BSIG-E

Bußgelder werden im § 65 BSIG-E geregelt. Ordnungswidrig handelt, wer vorsätzlich oder fahrlässig

• gemäß § 65 Abs. 2 Nr. 4 entgegen § 32 Abs. 1 Satz 1 eine Meldung nicht, nicht richtig, nicht vollständig oder nicht rechtzeitig übermittelt und/oder
• gemäß § 65 Abs. 2 Nr. 5 entgegen § 32 Abs. 2 Satz 2 eine Abschlussmeldung nicht, nicht richtig, nicht vollständig oder nicht rechtzeitig macht.

Nach aktueller Fassung des BSIG-E vom 22. Juli 2024 können solche Ordnungswidrigkeiten gemäß § 65 Abs. 5 Nr. 1 geahndet werden

• bei besonders wichtigen Einrichtungen nach § 28 Absatz 1 Satz 1 mit einer Geldbuße bis zu zehn Millionen Euro (§ 65 Abs. 5 Nr. 1 Lit. a BSIG-E) oder bei einem Jahresumsatz von mehr als 500 Millionen Euro abweichend mit einer Geldbuße bis zu 2 % des Jahresumsatzes (§ 65 Abs. 6 BSIG-E),
• bei wichtigen Einrichtungen im Sinne des § 28 Abs. 2 Satz 1 mit einer Geldbuße bis zu sieben Millionen Euro (§ 65 Abs. 5 Nr. 1 Lit. b BSIG-E) oder bei einem Jahresumsatz von mehr als 500 Millionen Euro abweichend mit einer Geldbuße bis zu 1,4 Prozent des Jahresumsatzes (§ 65 Abs. 7 BSIG-E).

Interaktion des BSI mit anderen Behörden In § 35 BSIG-E werden, ähnlich den Benachrichtigungspflichten gemäß Art. 34 DSGVO, Unterrichtungspflichten festgelegt – und zwar für den Fall eines erheblichen Sicherheitsvorfalls. Das BSI kann „besonders wichtige Einrichtungen und wichtige Einrichtungen anordnen, die Empfänger ihrer Dienste unverzüglich über diesen erheblichen Sicherheitsvorfall zu unterrichten“, falls dieser die Erbringung des jeweiligen Dienstes beeinträchtigen könnte. Auch informiert das BSI die für die Einrichtung zuständige Aufsichtsbehörde über Anweisungen beziehungsweise Anordnungen. Für die Unterrichtungspflicht gilt die Interessenabwägung, das heißt die Interessen des Empfängers müssen die Interessen der Einrichtung überwiegen.

Gemäß § 35 Abs. 2 BSIG-E teilen zudem Einrichtungen „aus den Sektoren Finanzwesen, Sozialversicherungsträger sowie Grundsicherung für Arbeitssuchende, digitale Infrastruktur, Verwaltung von IKT-Diensten und digitale Dienste“ den potenziell von einer erheblichen Cyberbedrohung betroffenen Empfängern ihrer Dienste sowie dem BSI „unverzüglich alle Maßnahmen oder Abhilfemaßnahmen mit, die diese Empfänger als Reaktion auf diese Bedrohung ergreifen können“ (siehe auch Abschnitt zu „DORA“). Von einer „erheblichen Cyberbedrohung“ spricht man gemäß § 2 Nr. 10 BSIG E im Fall einer Cyberbedrohung, die das Potenzial besitzt, informationstechnische Systeme, Komponenten und Prozesse aufgrund der besonderen technischen Merkmale der Cyberbedrohung erheblich zu beeinträchtigen – eine Beeinträchtigung ist dabei erheblich, wenn sie erheblichen materiellen oder immateriellen Schaden verursachen kann.

(Besonders) wichtige Einrichtungen contra Finanzunternehmen

Adressaten der Meldepflichten nach § 32 BSIG-E sind „besonders wichtige Einrichtungen und wichtige Einrichtungen“, die wie folgt – und relativ aufwendig – in § 28 BSIG-E definiert werden:

• Gemäß § 28 Abs. 1 gelten als besonders wichtige Einrichtungen: Betreiber kritischer Anlagen (Definition siehe unten), qualifizierte Vertrauensdiensteanbieter, Top-Level-Domain-Name-Registries oder DNS-Diensteanbieter, Anbieter öffentlich zugänglicher Telekommunikationsdienste oder Betreiber öffentlicher Telekommunikationsnetze, die mindestens 50 Mitarbeiter beschäftigen (a) oder einen Jahresumsatz und eine Jahresbilanzsumme von jeweils über 10 Millionen Euro aufweisen (b) sowie sonstige natürliche oder juristische Personen oder rechtlich unselbstständige Organisationseinheiten einer Gebietskörperschaft, die anderen natürlichen oder juristischen Personen entgeltlich Waren oder Dienstleistungen anbieten, die einer der in Anlage 1 BSIG-E bestimmten Einrichtungsarten zuzuordnen sind und die mindestens 250 Mitarbeiter beschäftigen (a) oder einen Jahresumsatz von über 50 Millionen Euro und zudem eine Jahresbilanzsumme von über 43 Millionen Euro aufweisen (b). Ausgenommen sind dabei „Einrichtungen der Bundesverwaltung, sofern sie nicht gleichzeitig Betreiber kritischer Anlagen sind“. Die referenzierte Anlage 1 umfasst eine Tabelle mit „Sektoren besonders wichtiger und wichtiger Einrichtungen“ (Energie. Sport und Verkehr, Finanzwesen, Gesundheit, Digitale Infrastruktur – früher ITK – und Weltraum) sowie relevanter Branchen sowie Einrichtungsarten.
• Gemäß § 28 Abs. 2 gelten als wichtige Einrichtungen: Vertrauensdiensteanbieter, Anbieter öffentlich zugänglicher Telekommunikationsdienste oder Betreiber öffentlicher Telekommunikationsnetze, die weniger als 50 Mitarbeiter beschäftigen (a) sowie einen Jahresumsatz und eine Jahresbilanzsumme von jeweils 10 Millionen Euro oder weniger aufweisen (b), eine natürliche oder juristische Person oder eine rechtlich unselbstständige Organisationseinheit einer Gebietskörperschaft, die anderen natürlichen oder juristischen Personen entgeltlich Waren oder Dienstleistungen anbietet, die einer der in Anlagen 1 und 2 bestimmten Einrichtungsarten zuzuordnen sind und die mindestens 50 Mitarbeiter beschäftigen (a) oder einen Jahresumsatz und eine Jahresbilanzsumme von jeweils über 10 Millionen Euro aufweisen (b). Ausgenommen sind auch hier besonders wichtige und wichtige Einrichtungen der Bundesverwaltung.

Die „ineinandergreifende Logik“ von wichtigen, besonders wichtigen Einrichtungen und kritischen Anlagen ist nicht nur auf den ersten Blick komplex: In Art. 30 des NIS2UmsuCG werden „Weitere Änderungen des BSI-Gesetzes“, die Definition der kritischen Anlagen betreffend, angekündigt. Die Ankündigung einer weiteren Änderung der aktuellen Änderung des BSIG begründet das BMI mit der „beabsichtigten Verschiebung der gesetzlichen Bestimmung kritischer Anlagen“ in das KRITISDachG. Das BSI stellt ein kostenloses Tool zur NIS-2-Betroffenheitsprüfung zur Verfügung [15], das jedoch nur als „Orientierungshilfe dient“ und dessen Ergebnis „rechtlich nicht bindend ist“.

Ausnahmen für Finanzunternehmen, Telematik sowie anderslautende Vorgaben

Doch dies sind nicht die einzigen Ausnahmen. Gemäß § 28 Abs. 4 sind unter anderem die §§ 32, 35 BSIG-E (sowie sieben weitere Paragrafen) auf besonders wichtige Einrichtungen und wichtige Einrichtungen nicht anzuwenden, soweit diese „ein öffentliches Telekommunikationsnetz betreiben oder öffentlich zugängliche Telekommunikationsdienste erbringen“ oder Energieversorgungsnetze oder Energieanlagen im Sinne des Energiewirtschaftsgesetz (EnWG) betreiben. Dies bedeutet nicht automatisch, dass es keine verbindlichen Meldepflichten für diese Einrichtungen gibt, sondern vielmehr, dass diese gesondert im Telekommunikationsgesetz (TKG) beziehungsweise EnWG geregelt werden.

So wird beispielsweise im § 168 TKG eine dreistufige Meldepflicht für „erhebliche Sicherheitsvorfälle“ festgelegt die von Unternehmen, die öffentliches Telekommunikationsnetz betreiben oder öffentlich zugängliche Telekommunikationsdienste erbringen, sowohl gegenüber dem BSI als auch gegenüber der Bundesnetzagentur zu erfüllen ist.

Gemäß § 28 Abs. 5 BSIG-E gelten die §§ 32, 35 (und weitere) ebenfalls nicht für Finanzunternehmen nach Art. 2 Abs. 2 DORA sowie „die Gesellschaft für Telematik nach § 306 Abs. 1 Satz 3 des Fünften Buches Sozialgesetzbuch sowie für Betreiber von Diensten der Telematikinfrastruktur“.

Während Meldepflichten und die Ausnahmen davon für besonders wichtige und wichtige Einrichtungen gelten, sind Betreiber kritischer Anlagen gemäß § 32 Abs. 3 BSIG-E zu weiteren Angaben verpflichtet. Im § 28 Abs. 7 wird auch diese Zielgruppe genauer definiert, als „eine natürliche oder juristische Person oder eine rechtlich unselbständige Organisationseinheit einer Gebietskörperschaft, die unter Berücksichtigung der rechtlichen, wirtschaftlichen und tatsächlichen Umstände bestimmenden Einfluss auf eine oder mehrere kritische Anlagen ausübt“. Die aktuelle Version des BSIG-E enthält eine (neue) Ergänzung der Definition: „Abweichend von Satz 1 hat im Sektor Finanzwesen bestimmenden Einfluss auf eine Anlage, wer die tatsächliche Sachherrschaft ausübt. Die rechtlichen und wirtschaftlichen Umstände bleiben insoweit unberücksichtigt.“

Die in § 28 Abs. 2 erwähnte Anlage 2 enthält im Übrigen „Sektoren wichtiger Einrichtungen“, darunter die Sektoren „Transport und Verkehr“, Abfallbewirtschaftung, „Produktion, Herstellung und Handel mit chemischen Stoffen“, „Produktion, Verarbeitung und Vertrieb von Lebensmitteln“, Anbieter digitaler Dienste sowie Forschung.

Meldepflichten für Finanzunternehmen nach DORA

Zu der sich teilweise überschneidenden Regelung der Meldepflichten für Sicherheitsvorfälle im KRITISDachG-E und NIS2UmsuCG kommt für Finanzunternehmen mit DORA noch eine weitere EU-Regulierung hinzu. Das BaFin als zuständige Aufsicht regelt die Umsetzung und das Incident-Meldewesen zu (schwerwiegenden) IKT-bezogenen Vorfällen selbst (vgl. Vortrag/Präsentation „Incident-Meldewesen“ unter [8]).

• Ein IKT-bezogener Vorfall gemäß DORA Art. 3 Nr. 8 ist ein (1) nicht geplantes Ereignis beziehungsweise eine entsprechende Reihe verbundener Ereignisse, das/die (2) die Sicherheit von Netzwerk- und Informationssystemen beeinträchtigt und (3) nachteilige Auswirkungen auf die Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit von Daten oder auf erbrachte Dienstleistungen hat.
• Ein schwerwiegender IKT-bezogener Vorfall gemäß DORA Art. 3 Nr. 10 hat umfassende nachteilige Auswirkungen auf Netzwerk- und Informationssysteme, die kritische oder wichtige Funktionen ienes Finanzunternehmens unterstützen.

Der Begriff „Finanzunternehmen“ unterliegt dabei der Definition in Art. 2 Abs. 2 DORA und umfasst laut BaFin: CRR-Kreditinstitute (von englisch Capital-Requirements-Regulation, früher Einlagenkreditinstitut), Zahlungsinstitute (einschließlich registrierter Kontoinformationsdienstleister), E-Geld Institute, Wertpapierfirmen, Anbieter von Krypto-Dienstleistungen (gem. EU Markets-in-Crypto-Assets-Regulation, MiCA), Central Securities-Depositories (CSD), Central Counterparty-Clearing-Houses (CCP), Handelsplätze, Transaktionsregister, Verwaltungsgesellschaften, Alternative-Investment-Fund-Managers (AIFM), Datenbereitstellungsdienste, Versicherungs- und Rückversicherungsunternehmen, Versicherungsvermittler, Einrichtungen der betrieblichen Altersversorgung (EbAV), Ratingagenturen, Administratoren kritischer Referenzwerte, Verbriefungsregister sowie Schwarmfinanzierungsdienstleister (vgl. Vortrag/Präsentation „DORA – Ein Überblick“ unter [8]). Diese Incident-Meldepflichten gelten allerdings nicht für IKT-Drittdienstleister.

Finanzunternehmen müssen gemäß Art. 19 DORA als schwerwiegend klassifizierte IKT-bezogene Vorfälle direkt an die BaFin melden. Geplant ist eine dreistufige Meldung für schwerwiegende Vorfälle – aktuell mit acht Klassifizierungskriterien zur Beurteilung, ob ein Vorfall „schwerwiegend“ ist: eine Erst-, eine (oder mehrere) Zwischen- und eine Abschlussmeldung [16,17].

Eine Erstmeldung an die BaFin soll zwecks Beschreibung des Vorfalls die folgenden Fragen beantworten [7]:

• Was ist passiert?
• Welche Services sind betroffen?
• Welche Auswirkungen hat der Vorfall auf Kunden*, Gegenparteien oder andere Finanzmarktakteure?
• Dauert der Vorfall noch an? und falls ja: Wie lange wird er voraussichtlich noch andauern?
• Liegt dem Vorfall vermutlich eine böswillige Handlung zugrunde?
• Wie gravierend ist der Vorfall aus Sicht des Finanzinstituts zum Zeitpunkt der Meldungsabgabe? (Einschätzung des Schweregrades: sehr niedrig, niedrig, mittel, hoch, sehr hoch)
• Sind nachhaltige Auswirkungen auf das Finanzunternehmen, seine Kundschaft oder gar den Finanzmarkt zu erwarten – oder sind diese bereits sichtbar?
• Ist es wahrscheinlich, dass andere Finanzunternehmen von diesem Vorfall betroffen sind?

Meldungsinhalte gemäß DORA und RTS-E

Freiwillige Erst-, Zwischen und Abschlussmeldungen von Cyberbedrohungen sind, ähnlich wie in der NIS-2-Richtlinie – neben den obligatorischen Meldungen für schwerwiegende Vorfälle – möglich und erwünscht. Fristen sowie Inhalte solcher Meldungen werden gemäß Art. 20 DORA in Regulatory-Technical-Standards (RTS) geregelt. Formulare, Vorlagen und Meldeverfahren sind dagegen Gegenstand sogenannter Implementing-Technical-Standards (ITS). Ein finales Konsultationspapier zu den entsprechenden Entwürfen von RTS und ITS [16] liegt bereits vor und enthält Vorgaben bezüglich der – obligatorischen und freiwilligen – Inhalte von Meldungen.

Eine Erstmeldung (Initial Notification) sollte demnach auf die wesentlichen Informationen beschränkt sein und gemäß Art. 3 RTS-E JC 2023 83 [18] mindestens die folgenden Informationen über den Vorfall bereitstellen:

• Datum und Uhrzeit der Entdeckung und Klassifizierung des Vorfalls
• Beschreibung des Vorfalls
• Klassifizierungskriterien, die die Meldung des Vorfalls gemäß [Artikel 1 bis 8 der noch zu veröffentlichenden delegierten Verordnung] ausgelöst haben betroffene oder potenziell betroffene Mitgliedstaaten, sofern zutreffend
• Informationen darüber, wie der Vorfall entdeckt wurde
• Informationen über die Quelle des Vorfalls, sofern verfügbar
• Hinweis, ob es Auswirkungen oder potenzielle Auswirkungen auf andere Finanzinstitute und Dritte gibt, sofern zutreffend
• Informationen darüber, ob der Vorfall wiederkehrend ist oder in Zusammenhang mit einem früheren Vorfall steht, sofern zutreffend
• Hinweis, ob ein Notfallplan aktiviert wurde

Je nachdem, wie sich der Vorfall entwickelt, erwartet die BaFin auch mehrere Zwischenmeldungen – darin sollten Informationen zum Ausmaß sowie eine detailliertere Analyse des Vorfalls enthalten sein. Bei Änderungen des Status müssen die Finanzunternehmen anzeigen, „ob […] die Einschränkungen durch den Vorfall noch andauern, der Geschäftsbetrieb wiederhergestellt wurde oder ob sich der Vorfall sogar verschärft hat“ [7].

In der Abschlussmeldung müssen unter anderem die Ursache des Vorfalls, getroffene Maßnahmen, entstandene Kosten und Verluste enthalten sein. Konkret müssen Finanzunternehmen gemäß Art. 5 RTS-E JC 2024 33 [16] im Abschlussbericht folgende Informationen über den Vorfall bereitstellen:

• Informationen über die Hauptursache des Vorfalls
• Informationen über die Unfähigkeit, gesetzlichen Anforderungen zu entsprechen
• Informationen über die Verletzung von Vertragsvereinbarungen/ Service-Level-Agreements (SLAs)
• Datum und Uhrzeit, zu denen der Vorfall behoben wurde und die Hauptursache adressiert wurde
• Informationen über die vom Finanzunternehmen ergriffenen Maßnahmen und Aktionen zur Behebung des Vorfalls sowie zusätzliche Kontrollen zur Verhinderung ähnlicher Vorfälle in der Zukunft
• Informationen über die Herabstufung eines schwerwiegenden Vorfalls zu einem nicht schwerwiegenden Vorfall, sofern zutreffend
• Informationen, die für Abwicklungsbehörden relevant sind
• Informationen über direkte und indirekte Kosten und Verluste, die durch den Vorfall entstanden sind, sowie Informationen über finanzielle Erstattungen

Um einen ausgewogenen und verhältnismäßigen Ansatz sicherzustellen, wird in den Entwürfen von RTS und ITS [16] vorgeschlagen, dass die wesentlichen Datenfelder (46 von insgesamt 101 Datenfeldern in den Erst-, Zwischen- und Abschlussmeldungen) obligatorisch und die verbleibenden optional sind – je nach Art und Beschaffenheit des Vorfalls. Darüber hinaus schlägt das Konsultationspapier vor, dass die Mehrheit der Datenfelder und Details auf die Zwischen- und Abschlussmeldungen entfallen, wodurch (bes. kleinere) Finanzunternehmen ihre Ressourcen auf die Bewältigung des Vorfalls nach seiner Entdeckung konzentrieren können. Die Informationen zum Finanzunternehmen, das den Vorfall meldet sowie allgemeine Informationen (General Information), die bei jeder Meldung obligatorisch sind, umfassen beispielsweise 10 Pflicht- und 8 freiwillige Datenfelder, darunter: Name, Typ und LEI-Code des meldenden und/oder betroffenen Finanzunternehmens gemäß Art. 2 DORA, Kontaktdaten der verantwortlichen Personen innerhalb des betroffenen Finanzunternehmens oder eines Dritten, der im Auftrag des betroffenen Finanzunternehmens berichtet, et cetera.

Das Konsultationspapier stellt im Annex I Templates und Tabellen zur Verfügung, mit denen sich die Datenfelder zu verschiedenen Meldungen sowie allgemeine Informationen, erfragen und erfassen lassen.

Fristen gemäß DORA und ITS-E

Obwohl eine Übereinstimmung der Fristen für die Meldepflichten mit der NIS-2-Richtlinie wünschenswert wäre, da einige Unternehmen, die unter DORA fallen, auch von der NIS-2-Richtlinie betroffen sind, wurden bestimmte DORA-spezifische Aspekte angepasst. Während gemäß NIS-2 die erste Meldung innerhalb von 24 Stunden nach Entdeckung erfolgen muss, läuft gemäß DORA die Einreichungsfrist für die Erstmeldung ab dem Moment der Klassifizierung des Vorfalls als schwerwiegender IKT-bezogener Vorfall: Es gilt eine 4-Stunden-Frist für die Erstmeldung ab dem Moment der Klassifizierung des Vorfalls als schwerwiegend – und nicht später als 24 Stunden nach seiner Entdeckung. Der Abschlussbericht muss gemäß NIS-2 innerhalb von 20 Arbeitstagen eingereicht werden – unter DORA wurde eine Frist von 30 Tagen festgesetzt [16].

Zur Vermeidung von Doppelmeldungen ist eine Meldung an die BaFin vorgesehen, die wiederum direkt an BSI, European Banking Association (EBA), European Insurance and Occupational Pensions Authority (EIOPA) oder European Securities and Markets Authority (ESMA) sowie – insofern relevant – „weitere“, wie etwa die Europäische Zentralbank (EZB), und so mittelbar an die European Union Agency for Cybersecurity (ENISA) weitermeldet.

Da sich die Anforderungen aus DORA und NIS-2- Richtlinie teilweise überschneiden, kommt die Lex-specialis-Regelung zum Tragen, wie die BaFin erläutert: „Finanzunternehmen, die unter die NIS-2-Richtlinie fallen, müssen also künftig nur eine Vorfallsmeldung gemäß DORA bei der BaFin einreichen. Die BaFin stellt die Meldung unverzüglich dem Bundesamt für Sicherheit in der Informationstechnik zur Verfügung“ [7]. Im Hinblick darauf verwirrt es ein wenig, dass der Entwurf des NIS2UmsuCG dennoch Vorgaben für Finanzunternehmen enthält (z. B. in den Unterrichtungspflichten gem. § 35 Abs. 2 ), die eigentlich aufgrund von DORA direkt durch die BaFin adressiert werden sollten.

Fazit und Kritik

Ob Meldepflichten für Sicherheitsvorfälle, Störungen oder „IKT-bezogene Vorfälle“: Eine Anpassung der Nomenklatur einerseits und eine klare Abgrenzung der Zuständigkeiten in den verschiedenen regulatorischen Vorgaben (DORA, KRITIS-DachG oder NIS2UmsuCG) andererseits wären wünschenswert. Wachsende Komplexität ist der Feind der Sicherheit – dabei verspricht der Gesetzgeber mit dem NIS2UmsuCG eigentlich mehr Transparenz und Bürokratieabbau. Nach der Verbändeanhörung am 3. Juni 2024 hatte das BMI in Aussicht gestellt, „das Meldewesen klarer und leichter“ gestalten zu wollen. Wie von vielen Verbänden gefordert, solle es einheitliche und voll digitalisierte Prozesse geben – und zwar als „Gesamtlösung für Registrierungs- und Meldemöglichkeiten nach NIS2UmsuCG und KRITIS-Dachgesetz“ [3].

Im aktuellen Regierungsentwurf des NIS2UmsuCG vom 22. Juli 2024, der diesem Beitrag zugrunde liegt, sind jedoch keine der avisierten Anpassungen umgesetzt worden. Ob und wie das BMI diesen gordischen Knoten durchtrennt, bleibt abzuwarten. Die Meldepflichten für Sicherheitsvorfälle und damit auch Verfahren und Prozesse, die Unternehmen und Behörden dafür aufstellen müssen, werden künftig jedenfalls anders als bisher sein – und höchstwahrscheinlich auch komplexer.

Dr. Aleksandra Sowa ist zertifizierte Datenschutzbeauftragte, Datenschutzauditorin und IT-Compliance-Manager, Sachverständige für IT-Sicherheit sowie Mitglied im Leitungskreis der FG „Datenschutzfördernde Technik (Privacy- Enhancing Technologies)“ der GI e. V.

Literatur

[1] Europäische Union, 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 … (NIS-2-Richtlinie), in: Amtsblatt der Europäischen Union L 333, S. 80, Dezember 2022, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022L2555

[2] Europäische Union, Richtlinie (EU) 2022/2557 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über die Resilienz kritischer Einrichtungen …, in: Amtsblatt der Europäischen Union L 333, S. 164, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022L2557

[3] Benjamin Stiebel, NIS-2-Umsetzung dreht noch eine Runde, Tagesspiegel Background, Juni 2024, https://background.tagesspiegel.de/cybersecurity/nis-2-umsetzungdreht-noch-eine-runde (kostepflichtig)

[4] Bundesministerium des Innern und für Heimat (BMI), Entwurf eines Gesetzes zur Umsetzung der NIS-2- Richtlinie und zur Regelung wesentlicher Grundzüge des Informationssicherheitsmanagements in der Bundesverwaltung (NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz), Gesetzentwurf der Bundesregierung, Juli 2024, www.bmi.bund.de/SharedDocs/gesetzgebungsverfahren/DE/Downloads/kabinettsfassung/CI1/nis2-regierungsentwurf.pdf?__blob=publicationFile

[5] Bundesministerium des Innern und für Heimat (BMI), Entwurf eines Gesetzes zur Umsetzung der CERRichtlinie und zur Stärkung der Resilienz kritischer Anlagen Dokumentation des Gesetzgebungsverfahrens / Referentenentwürfe, Januar 2024, www.bmi.bund.de/SharedDocs/gesetzgebungsverfahren/DE/KRITISDachG.html

[6] Europäische Union, Verordnung (EU) 2022/2554 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über die digitale operationale Resilienz im Finanzsektor …, in: Amtsblatt der Europäischen Union L 333, S. 1, Dezember 2022, https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R2554

[7] Benedikt Queng und Michael Göddecke, Transparenz dank Meldepflicht, Journal der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin), Juni 2024, www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Fachartikel/2024/fa_bj_0618_DORA.html

[8] Bundesanstalt für Finanzdienstleistungsaufsicht (Ba-Fin), IT-Aufsicht im Finanzsektor: Was bedeutet DORA in der Praxis?, Vortragsunterlagen, Dezember 2023, www.bafin.de/SharedDocs/Veranstaltungen/DE/2023_12_05_IT_Aufsicht.html

[9] Karina Filusch, Frank Fünfstück, Melde- und Benachrichtigungspflichten nach der Datenschutzgrundverordnung (DSGVO), in: Dr. Aleksandra Sowa (Hrsg.), ITPrüfung, Datenschutzmanagement und KI-Audit, Neue Ansätze für die Arbeit der IT-Revision, Springer, in Vorbereitung für 2024

[10] Karina Filusch, Dr. Aleksandra Sowa, Meldepflichten bei Sicherheitsvorfällen und Datenpannen, Status quo und Ausblick, Privacy in Germany (PinG) 1/2024, S. 1, online auch auf https://kanzlei-filusch.de/wp-content/uploads/2024/03/PinG_2024-01_Filusch_personalisiert.pdf

[11] Bundesnetzagentur (BNetzA), Benachrichtigungspflichten im Fall einer Verletzung des Schutzes personenbezogener Daten, undatiert, www.bundesnetzagentur.de/DE/Fachthemen/Telekommunikation/Unternehmenspflichten/Datenschutz/Datenschutzverletzungenmelden/start.html

[12] Marvin Menze, Johannes Kraus, Alles in UBI?, Unternehmen im besonderen öffentlichen Interesse, <kes> 2024#3, S. 40

[13] Gesellschaft für Informatik (GI), GI-Stellungnahme zum KRITIS-Dachgesetz: Ein stärkeres BSI statt undurchsichtiger neuer Strukturen, August 2023, https://gi.de/meldung/gi-stellungnahme-zum-kritis-dachgesetz-ein-staerkeres-bsi-statt-undurchsichtiger-neuer-strukturen

[14] Gesellschaft für Informatik (GI), GI sieht Baustellen im NIS-2-Umsetzungsgesetz, Mai 2024, https://gi.de/meldung/gi-sieht-baustellen-im-nis2-umsetzungsgesetz

[15] Bundesamt für Sicherheit in der Informationstechnik (BSI), NIS-2-Betroffenheitsprüfung, Juli 2024, www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/NIS-2-regulierte-Unternehmen/NIS-2-Betroffenheitspruefung/nis-2-betroffenheitspruefung_node.html

[16] European Banking Association (EBA), European Insurance and Occupational Pensions Authority (EIOPA), European Securities and Markets Authority (ESMA), Draft Regulatory Technical Standards (RTS) on the content of the notification and reports for major incidents and significant cyber threats and determining the time limits for reporting major incidents and Draft Implementing Technical Standards (ITS) On the standard forms, templates and procedures for financial entities to report a major incident and to notify a significant cyber threat, Joint Committee Final Report JC 2024 33, Juli 2024, www.esma.europa.eu/sites/default/files/2024-07/JC_2024-33_-_Final_report_on_the_draft_RTS_and_ITS_on_incident_reporting.pdf

[17] European Supervisory Authorities (EBA, EIOPA and ESMA – the ESAs), ESAs published second batch of policy products under DORA, Pressemitteilung, Juli 2024, www.esma.europa.eu/press-news/esma-news/esas-published-second-batch-policy-products-under-dora

[18] European Banking Association (EBA), European Insurance and Occupational Pensions Authority (EIOPA), European Securities and Markets Authority (ESMA), Final report on Draft Regulatory Technical Standards specifying the criteria for the classification of ICT related incidents, materiality thresholds for major incidents and significant cyber threats under Regulation (EU) 2022/2554, Joint Committee Final Report JC 2023 83, Januar 2024, www.esma.europa.eu/sites/default/files/2024-01/JC_2023_83_-_Final_Report_on_draft_RTS_on_classification_of_major_incidents_and_significant_cyber_threats.pdf

[19] Sunita Ute Saxena, Pascal Schmidt, Christian Schmitt, Barbara Willkomm, Richtig melden, Synergien bei Meldepflichten zu IT-Sicherheit und Datenschutz nutzen, <kes> 2020#4, S. 45