#DORA #RegulatoryStandards #OperativeResilienz
Kürzlich, am 17. Juli 2024, haben ESMA, EBA und EIOPA (zusammen kurz ESA: European Supervisory Authorities) die letzten finalen Versionen der Regulatory Technical Standards (RTS) & Implementing Technical Standards (ITS) für den Digital Operational Resilience Act (DORA) veröffentlicht. Damit haben sie die letzten Teile des DORA-Puzzles geliefert, die ein vollständiges Verständnis der DORA-Anforderungen ermöglichen.
Gleichzeitig bleiben die Herausforderungen, die auch die letzten RTS & ITS nicht lösen konnten, bestehen – ein Interpretationsspielraum bleibt. Eine vertiefte Auseinandersetzung mit den DORA-Anforderungen wird daher weiterhin empfohlen.
In einem früheren Artikel haben wir bereits die RTS & ITS aus dem ersten Batch analysiert. Die gleiche Analyse soll nun für die neuen Konkretisierungen vorgenommen werden.
Die heutige Veröffentlichung enthält 6 Konkretisierungen zu DORA. Die folgende Grafik zeigt unsere Analyse des Nutzens der RTS & ITS für die Interpretation von DORA und den Aufwand, der damit verbunden sein kann.
RTS to specify the reporting of major ICT-related incidents (Art. 20.a) & ITS to establish the reporting details for major ICT related incidents (Art. 20.b): Diese RTS & ITS konkretisieren die Anforderungen an das Incident Reporting, indem sie sowohl die inhaltlichen Anforderungen als auch die Art und Weise des Reportings konkretisieren. Hier haben die ESA erfreulicherweise erkannt, dass im Falle eines Cyber-Angriffs das Reporting die Abwehr & Schadensbegrenzung nicht behindern darf – und mehrere Argumente aus den Konsultationen berücksichtigt.
Das Beste zuerst: Die Anzahl der Datenfelder in den Berichtsvorlagen wurde von 84 auf 59 reduziert, also um fast 30%. Die Pflichtfelder wurden immerhin von 37 auf 28 reduziert (-1/4).
Vorfälle müssen wie im Entwurf innerhalb von 4 Stunden nach Einstufung und 24 Stunden nach Entdeckung gemeldet werden, allerdings mit nur 10 statt 17 Datenfeldern. Die Fristen für Folgeberichte wurden leicht verlängert und sind besser messbar. Der Zwischenbericht ist nun 72 Stunden nach der Erstmeldung fällig und nicht mehr zum Zeitpunkt des Vorfalls. Ebenso ist der Abschlussbericht nun einen Monat nach dem Zwischenbericht fällig und nicht mehr nach dem Vorfall. Darüber hinaus werden die Anforderungen an die Berichterstattung über das Wochenende reduziert, so dass die Berichte in der Regel erst bis 12 Uhr des folgenden Arbeitstages übermittelt werden müssen.
Um den Anforderungen kleiner Unternehmen gerecht zu werden, wird ein einheitliches Meldeformular für alle Meldungen sowie eine verhältnismäßige und ausgewogene Datenerhebung eingeführt. Daraus ergeben sich je nach Unternehmensgröße neue und durchaus aufwändige Anpassungen der bestehenden Prozesse. Im Hinblick auf weitere Regelungen wie NIS2 sind diese Anforderungen jedoch bereits abgestimmt.
Guidelines on the estimation of aggregated annual costs and losses caused by major ICT-related incidents (Art. 18/20): In diesem Leitfaden wird konkretisiert, wie die Kosten von Störfällen zu ermitteln sind. Die endgültige Fassung bringt einige Erleichterungen, z.B. die freie Wahl des Bezugsjahres für die Kosten und die Konzentration auf Bruttobeträge, anstatt zusätzlich Nettobeträge anzugeben.
RTS to specify threat led penetration testing (Art. 26.1): Dieser RTS vertieft die Anforderungen an das Threa Led Penetration Testing (TLPT) und orientiert sich in der finalen Version sehr eng am TIBER-EU Framework. Damit schafft der RTS Klarheit über die notwendigen Schritte und Anforderungen, die Unternehmen zur Erreichung der DORA-Konformität einhalten müssen. Durch die Anlehnung an TIBER-EU wird sichergestellt, dass die Anforderungen praxisnah und flexibel bleiben.
RTS to specify the elements to determine and assess when sub-contracting ICT services supporting a critical or important function (Art. 30.5): Dieser RTS soll die Anforderungen an Unternehmen konkretisieren, welche kritischen IKT-Funktionen ausgelagert werden können und welche Sorgfaltspflichten dabei zu erfüllen sind. Während die anderen finalen Versionen zeitnah auf den Websites von EBA, EIOPA & ESMA veröffentlicht wurden, ist die finale Version dieses RTS dort nicht zu finden. Für sachdienliche Hinweise zum Verbleib dieses finalen RTS wäre das Autorenteam außerordentlich dankbar.
Guidelines on cooperation ESAs –CAs (Competent Authorities) regarding DORA oversight (Art. 32.7): Diese Guideline beschreibt die Zusammenarbeit zwischen den European Supervisory Authorities (ESA) und den Competent Authorities (CA). Direkte Anforderungen an Unternehmen sind in dieser Guideline nicht enthalten. Da die Konsultationen diesbezüglich ein weitgehend positives Feedback ergeben haben, werden in der finalen Version keine wesentlichen Änderungen vorgenommen.
RTS on harmonisation of oversight conditions (Art. 41): Dieser RTS-Entwurf wurde in 2 endgültige RTS-Dokumente aufgeteilt: Das erste mit fast gleichem Titel mit Bezug auf Artikel 41 (1) a, b & c, das zweite mit dem Titel „RTS specifying the criteria for determining the composition of the joint examination team (JET)“ mit Bezug auf Artikel 41 (1) c. Beide RTS beschreiben, wie die Aufsichtsregeln für IKT-Dienstleister harmonisiert werden sollen. Direkte Anforderungen an die Unternehmen enthält dieser RTS nicht, so dass sich hier keine relevanten Änderungen ergeben.
Auch wenn die Anforderungen an die externe Meldung von Cyber-Angriffen erfreulicherweise etwas gelockert wurden, ist es unwahrscheinlich, dass ein bestehendes Incident Management System bereits alle diese Felder enthält. Der Hersteller des eingesetzten Systems sollte daher dringend um eine möglichst verbindliche Aussage gebeten werden, ob die von DORA geforderten 59 Felder rechtzeitig mit einem Software-Update ausgeliefert werden. Unabhängig davon, ob ein Update oder eine Eigenentwicklung erfolgt, sollte zeitnah ein Projekt aufgesetzt werden, um das eigene Störfallmanagementsystem zeitnah anzupassen. Auch aufgrund der Ambitionen der ESA, ein europaweites Informations- und Frühwarnsystem für Cyber-Angriffe zu etablieren, dürften die Erwartungen eines Auditors an die vollständige Verfügbarkeit solcher Daten sehr hoch sein – und entsprechende Feststellungen eher schwerwiegend.
Trotz eines gewissen Hypes um Threat Led Penetration Testing (TLPT) ist der Handlungsdruck hier nicht so groß. Schließlich müssen die lokalen Regulatoren zunächst die Dienstleister für die Angreiferteams (Red Teams) auswählen, geeignete Threat-Intelligence-basierte Tests erstellen und nicht zuletzt alle teilnehmenden Finanzinstitute informieren. Daher wird es wahrscheinlich ausreichen, sich voll und ganz auf die Verbesserung der eigenen digitalen Widerstandsfähigkeit zu konzentrieren und spezifische Vorbereitungen für TLPT aufzuschieben, bis man darüber informiert wird, dass man dafür ausgewählt wurde.
Sollten Sie bereits mit der Umsetzung der DORA-Anforderungen begonnen haben, unterstützen wir Sie gerne zunächst bei der Erweiterung der bestehenden Gap-Analyse um die veröffentlichten RTS & ITS, um den Anpassungsbedarf zu identifizieren. Da das Zeitfenster bis zum Inkrafttreten von DORA und damit der Umsetzung sehr eng ist, empfehlen wir einen kurzfristigen Start und eine iterative Umsetzung. In einem weiteren Blogartikel haben wir 5 Erfolgsfaktoren beschrieben, die Sie bei der erfolgreichen Umsetzung von DORA unterstützen können.
Sollten Sie noch nicht mit der Umsetzung der DORA-Anforderungen begonnen haben, unterstützen Sie unsere Experten gerne dabei, sofort mit No-Regret-Maßnahmen (z.B. Definition von Risk Appetite, DORA-Strategie oder Risikomanagement-Framework) zu beginnen, um keine weitere Zeit zu verlieren, sowie parallel eine grundlegende Gap-Analyse von DORA und den veröffentlichten RTS & ITS zu erarbeiten. Bei komplexen Unternehmensstrukturen empfehlen wir darüber hinaus ein zentrales Projekt-/Programmmanagement zur Steuerung der Umsetzung über alle Unternehmen hinweg.
Unsere Experten bei Horn & Company stehen Ihnen gern persönlich zur Verfügung, um die Implikationen der DORA-Regulatorik auf Ihre DOR-Strategie oder Ihr IKT-Risikomanagement zu besprechen.
Robert Tippmann
E-Mail: robert.tippmann@horn-company.de
Leon Heyn
E-Mail: leon.heyn@horn-company.de
Ihr Tor zu Branchenkenntnissen und Expertenanalysen! Folgen Sie uns auf LinkedIn für exklusive Fachartikel und Einblicke.