Findet DORA : Braucht es wirklich teure Projekte zum Digital Operational Resilience Act?
Obwohl ein Großteil der Bestimmungen des Digital Operational Resilience Act (DORA) bereits über Mindestanforderungen an das Risikomanagement (MaRisk), die bankaufsichtlichen Anforderungen an die IT (BAIT) und dergleichen abgebildet wird, sind im Markt überraschend viele Großprojekte mit Millionenbudgets zu beobachten. Unsere Autoren fragen sich, warum das so ist und wollen klären, welche (neuen?) Herausforderungen tatsächlich bestehen und wie ihnen zu begegnen ist.
Der Digital Operational Resilience Act (DORA) wurde am 14. Dezember 2022 durch das Europäische Parlament und den Europäischen Rat beschlossen – veröffentlicht wurde DORA am 27. Dezember 2022 im Amtsblatt der europäischen Union [1] und ist am 17. Januar 2023 in Kraft getreten. Ab dem 17. Januar 2025 finden die Vorgaben Anwendung. Ziel der DORA-Verordnung ist es, die digitale operationelle Resilienz des EU-Finanzsektors zu stärken. Hierzu definiert sie eine ausgeprägte Anzahl von Anforderungen, welche die Bandbreite verschiedenster Sicherheitsfelder abdecken.
Neben Anforderungen an die Sicherheitsmaßnahmen der Informations- und Kommunikationstechnologie (IKT), umfasst DORA unter anderem auch Themen zur Governance, zum Drittparteienrisikomanagement sowie zur Berichterstattung über IKT-Vorfälle. DORA bietet für Finanz- und Versicherungsinstitute einen Anlass, um ihre bisherigen Sicherheitsstandards zu hinterfragen. Aber sind auch alle bereits eingeführten Sicherheitsstandards über den Haufen zu werfen?
Auf dem Weg dahin, den Anforderungen von DORA gerecht zu werden, bestehen durchaus Herausforderungen, die für einige Unternehmen größer erscheinen als für andere. Das liegt unter anderem daran, dass in der Finanz- und Versicherungswirtschaft eine gewisse Unklarheit über die konkrete Auslegung und Umsetzung der Anforderungen besteht. Zum einen rührt das daher, dass die Regulierungsstandards (RTS) und Implementierungsstandards (ITS), welche die DORA-Anforderungen komplettieren und ebenso Rechtsgültigkeit besitzen, erst am 17. Juli 2024 veröffentlicht wurden [2]. Hierzu zählen RTS zu Threat-Led Penetration-Testing (Art. 26 Abs. 11), RTS zur Spezifizierung von Elementen bei der Untervergabe von kritischen oder wichtigen Funktionen (Art. 30 Abs. 5), RTS zur Festlegung der Meldung schwerwiegender IKT-Vorfälle (Art. 20a), ITS zur Festlegung der Einzelheiten der Berichterstattung über größere IKT-bezogene Vorfälle (Art. 20b) sowie RTS zur Harmonisierung der Voraussetzungen für die Durchführung der Überwachungstätigkeiten (Art. 41).
Darüber hinaus stellen Umfang, Detailgrad und Komplexität der DORA-Anforderungen mit Sicherheit zunächst eine Herausforderung für Unternehmen dar. Dennoch sind viele Anforderungen, die in DORA aufgegriffen werden, nicht neu – vielmehr bekommen sie einen neuen Stellenwert oder eine andere Blickrichtung. Andere bereits bestehende Themen wurden ergänzt oder umfassender reguliert.
Auch aktuell gelten bereits die bekannten sektoralen Anforderungen im deutschen Finanzmarkt. Hierzu zählen beispielsweise die Mindestanforderungen an das Risikomanagement (MaRisk) und die bankaufsichtlichen Anforderungen an die IT (BAIT) für Banken, die Mindestanforderungen an die Geschäftsorganisation von Versicherungsunternehmen (MaGo) und versicherungsaufsichtlichen Anforderungen an die IT (VAIT) für Versicherungen oder die Mindestanforderungen an das Risikomanagement von Instituten (ZAG-MaRisk), die dem Zahlungsdiensteaufsichtsgesetz (ZAG) unterworfen sind, sowie zahlungsdiensteaufsichtliche Anforderungen an die IT (ZAIT) für Zahlungsdienstanbieter im Sinne des § 27 Abs. 1 ZAG. Ergänzt werden diese etwa um einzelne Guidelines der Europäischen Bankenaufsichtsbehörde (EBA – bspw. Guidelines on internal governance under Directive 2013/36/EU, EBA Guidelines on outsourcing arrangements oder EBA Guidelines on ICT and security risk management) oder den Supervisory-Review-and-Evaluation-Process-(SREP)-Vorgaben.
Durch die Aufsichtsmitteilung der BaFin vom Juli 2024 zu den Umsetzungshinweisen zur DORA-Implementierung [3] ist zumindest klar, dass die BAIT mit dem Inkrafttreten von DORA ihre Gültigkeit verliert. Gleiches ist auch mit Blick auf die VAIT beziehungsweise ZAIT und kapitalverwaltungsaufsichtliche Anfoderungen an die IT (KAIT) zu erwarten, auch wenn dies noch nicht offiziell bestätigt wurde. MaRisk & Co. bleiben von DORA hingegen unberührt.
Wie tief ist das Wasser?
Die Frage ist nun für Viele: Ist der Sprung zu DORA wirklich so groß, wie es teils durch die Beratungsbranche suggeriert wird? Um diese Frage zu beantworten, führen Finanz- und Versicherungsunternehmen umfassende Gap-Analysen durch, die teilweise selbst bereits im Umfang einem Großprojekt gleichen. Zwar sind die Ergebnisse im Detail sehr unterschiedlich, eine „rote Linie“ lässt sich dennoch erkennen: Eine vollständige DORA-Compliance liegt nicht vor – um den Gap zu schließen, muss ein größeres DORA-Projekt her, die bisherigen internen Vorgaben und Maßnahmen reichen nicht aus.
Im Grundsatz mag diese Erkenntnis richtig sein, jedoch wird sie teils zu pauschal vergeben. Es lässt sich feststellen, dass alle Unternehmen, welche die bisherigen Regularien voll umgesetzt haben, gut aufgestellt sind. Lediglich für solche Unternehmen, die aktuell bereits Baustellen haben, scheint der Sprung zu DORA eine große Herausforderung zu sein.
Von der Bekanntmachung zur Anwendung – ein Zwischenfazit
Wie eingangs dargestellt, ist DORA schon länger bekannt. Richtig präsent ist DORA aber erst jetzt. Ein Grund dafür sind sicherlich die sukzessiv ergänzten RTS und ITS, wodurch die Anforderungen, welche DORA stellt, greifbarer werden. Aktuell bewegt DORA sehr viel.
Ein Blick in die Branche zeigt die Spanne des Aufwands, der im Hinblick auf eine DORA-Compliance betrieben wird, und wie weit die Unternehmen vorangeschritten sind: Auf der einen Seite laufen großangelegte DORA-Programme in Millionenhöhe, auf der anderen Seite stehen einige Unternehmen noch am Anfang – die meisten liegen irgendwo dazwischen. Gerade kleinere IT-Dienstleistungsunternehmen, die sich im Finanzwesen bewegen, werden unter DORA nun erstmals reguliert.
Noch eine gute Nachricht an dieser Stelle: Für Finanzinstitute, die aktuell noch unter KRITIS fallen und kritische Dienstleistungen bereitstellen, wird nicht noch zusätzlich eine Umsetzung von NIS-2 erforderlich sein. Hier gilt das „Lex specialis“ auch auf EU-Ebene: Eine Doppelregulierung wird es damit nicht geben – für den Finanzsektor ist DORA „schlagend“.
Was ändert sich also mit DORA, dass aktuell eine Vielzahl an Großprojekten im großvolumigen Umfang laufen? Eine mögliche Erklärung könnten die neu festgelegten Strafen sein. Kann dies jedoch der alleinige Grund sein, dass DORA eine größere Bedeutung zugewiesen wird? DORA ist für alle Beteiligten neu. So bestehen noch keine Prüfberichte der Aufsicht, wodurch jegliche Auslegung von DORA, seiner RTS und ITS nach derzeitigem Stand nur eine Interpretation sein kann.
Die Konsequenz ist ein Kampf um die Deutungshoheit, die besonders stark durch die „Big Player“ aus Finanzindustrie und Beratung gefärbt ist. Eine Gegenüberstellung von DORA und den bisherigen Regelungen aus BAIT, VAIT et cetera hilft dabei, die tatsächlichen Änderungen besser zu verstehen – oder besser: zu verstehen, was eigentlich bereits umgesetzt sein sollte.
Untiefen und Fahrrinnen
Um den Sprung zu DORA besser zu verstehen, hilft es einen Blick darauf zu werfen, wie Resilienz- und Security-Themen – wie Informationssicherheit, technische IT-Security, Business- und IT-Service-Continuity-Management sowie Incident- oder Krisenmanagement – aktuell durch MaRisk und seinesgleichen strukturiert sind (vgl. Abb. 1).
In den meisten Unternehmen werden die unterschiedlichen Themen einzeln betrachtet, in Teilen auch als integriertes Managementsystem, jedoch selten als Allin-One-Gesamtbild. Im Vergleich dazu setzt DORA einen neuen Fokus: Hatten BAIT/VAIT/ZAIT & Co. eine starke Ausrichtung auf Informationssicherheit nach ISO, verschiebt sich der Fokus dahingehend, dass DORA das IKT-Risikomanagement als Überbau sieht und sich am Cybersecurity-Framework (CSF) des NIST [4] orientiert: mit den Schritten Identify, Protect, Detect, Respond und Recover. Damit sollen sämtliche Anforderungen aus unterschiedlichen Schwerpunkten im Sinne einer gesamtheitlichen digitalen operationalen Resilienz näher zusammenrücken.
Vergleicht man die bisherigen und neuen Strukturen der Regularien anhand der Abbildungen 1 und 2, könnten die Schaubilder unterschiedlicher kaum sein – dass DORA dementsprechend als komplexe Neuregelung verstanden wird, ist nicht verwunderlich. Durch das Verständnis eines neuen Überbaus werden die Aspekte, die bereits BAIT & Co. gefordert haben, aber nicht gleichsam ausgeschaltet oder negiert. Schaut man pragmatisch hin, lassen sich die Themen einsortieren: Abbildung 3 stellt einen Ansatz dar, um DORA-Inhalte auf klassische Resilienz-und Security-Themen zu mappen – sie erhebt indessen keinen Anspruch auf Vollständigkeit.
Fremde Gezeiten
Dennoch ergeben sich auch inhaltliche Unterschiede, für die im Folgenden ein Überblick über die wesentlichen Änderungen skizziert werden soll. Die nachfolgende Auflistung stellt dabei eine stark verkürzte Auswahl der Änderungen in den Sicherheits- und Resilienzthemen dar.
Governance
Governance-Modell: DORA fordert die Einführung eines Three-Lines-of-Defence-Modells (3LoD), das auch eine IKT-Risikokontrollfunktion vorsieht, die der Rolle eines Informationssicherheitsbeauftragten (ISB) oder CISO nicht gleichgesetzt ist – aufsichtsrechtlich war ein solches Modell bislang nicht gefordert.
- Eine Strategie der digitalen operationellen Resilienz kommt als neue Anforderung hinzu und muss ergänzend beziehungsweise integrativ zur IT-Strategie angesehen werden, die BAIT & Co. gefordert haben.
- Verantwortung der Unternehmensführung: Künftig hat die Unternehmensführung eine ausgeweitete Verantwortung zur Freigabe von Leit- und Richtlinien sowie Plänen im Zusammenhang mit der digitalen operativen Resilienz und muss Kenntnisse und Fähigkeiten zu den zu managenden IKT-Risiken nachweisen.
IKT-Risikomanagement
- Prüf- und Analyseanforderungen zu IKT-Risiken, neuen Technologien, Altsystemen, Vorfällen und Tests: Unternehmen müssen künftig in ihrem Risikomanagement neben grundsätzlichen Gefährdungen (bspw. aus dem BSI Gefährdungskatalog) auch Risiken für neue Technologien und Altsysteme analysieren. Auch müssen die in (Major) Incidents oder in Tests aufgetretenen Schwachstellen vertieft analysiert, aufgearbeitet und berichtet werden.
- Schulung und Kommunikation: DORA legt einen besonderen Fokus auf Schulungspflichten. Diese umfassen Programme zur Sensibilisierung für IKT-Sicherheit und digitale operative Resilienz sowie die Anforderung, dass das Management stets auf dem neuesten Stand in Bezug auf IKT-Risiken bleibt – auch durch gezielte Schulungen. Finanzunternehmen müssen Kommunikationsstrategien, -leitlinien und -pläne für schwerwiegende IKT-Vorfälle und Schwachstellen entwickeln, um eine verantwortungsbewusste Offenlegung dieser Vorfälle und Schwachstellen zu gewährleisten.
Third-Party-Risk-Management
- Erweiterung der Anforderungen: Finanzunternehmen müssen Verträge mit ihren Dienstleistern schließen, die spezifische Resilienz-und Sicherheitsanforderungen umfassen. In diesem Kontext sind auch umfassende und regelmäßige Due-Diligence-Prüfungen durchzuführen, um sicherzustellen, dass die Dienstleister sowie Subunternehmen kontinuierlich die gleichen hohen Sicherheitsstandards aufweisen können, wie das Finanzinstitut selbst. Grundsätzlich gibt DORA Mindestvertragsinhalte vor (s. a. [3]), die unabhängig von der Bedeutung von IKT-Dienstleistern zu vereinbaren sind. Dies bedeutet in vielen Fällen eine Neuregelung von Verträgen oder Unterauftragsverfahren.
- Abgestimmte Notfall- und Exitstrategien: Finanzunternehmen müssen überdies in enge Abstimmung mit Dienstleistern treten, um Notfallpläne abzustimmen und Exit-Strategien zu erarbeiten – für den Fall von schwerwiegenden Störungen oder bei Beendigung der Dienstleistungsverträge, allem voran in Dienstleistungsverhältnissen mit Konzentrationsrisiken (bspw. wenn eine besondere Abhängigkeit zum Dienstleister besteht).
Change-Management
- Ganzheitliches Änderungsmanagement: Anders als BAIT, VAIT & Co. sieht DORA künftig vor, alle Änderungen an IKT-Systemen im Rahmen des Change-Managements auf kontrollierte Weise zu erfassen, zu testen, zu bewerten, zu genehmigen, zu implementieren und zu überprüfen. Zudem werden Mindestinhalte des Change- Management-Verfahrens gefordert – unter anderem Prüfpflichten, Testen von Änderungen, Auswirkungsanalysen oder Fallback-Lösungen.
Business-Continuity-Management (BCM)
- Auswirkungen auf die Markteffizienz: DORA stellt zwar nicht per se Anforderungen an das BCM, jedoch lassen sich Anforderungen aus dem IKT-Geschäftsfortführungsmanagement auch für das BCM ableiten. Beispielsweise sind Auswirkungen auf die Markteffizienz zu berücksichtigen, was sich unter anderem in der Business-Impact-Analyse (BIA) niederschlagen kann.
IT-Service-Continuity-Management (ITSCM) oder IKT-Geschäftsfortführungsmanagement
- Leitlinie und Pläne: Neu ist, dass DORA eine ITSCM-Leitlinie fordert, die sich jedoch mit einer übergeordneten BCM- oder Security Leitlinie kombinieren lässt. Zudem wird erstmals explizit ein IKT-Geschäftsfortführungsplan gefordert, der Maßnahmen zur Fortführung von kritischen Prozessen des IT-Betriebs (bspw. Incident-Management) nach einem Ausfall umfasst. Die Festlegung, welche IT-Prozesse hier im Scope stehen, sollte dabei über die BIA erfolgen.
- Szenario-spezifische Ausgestaltung: Bei der Erstellung von Disaster-Recovery-(DR)-Plänen (alternativ Reaktions- und Wiederherstellungspläne) sowie IT-Geschäftsfortführungsplänen muss ein Mindestset an Szenarien berücksichtigt werden. Hierzu zählen ein teilweiser oder vollständiger Ausfall von Räumlichkeiten, einschließlich Büro- und Geschäftsräumen und Datenzentren, ein erheblicher Ausfall von IT-Anlagen oder der Kommunikationsinfrastruktur, die Nichtverfügbarkeit einer kritischen Anzahl von Mitarbeitern*, die für die Gewährleistung der Kontinuität des Betriebs zuständig sind, Auswirkungen des Klimawandels und umweltschädigender Ereignisse, Naturkatastrophen, Pandemien und physische Angriffe, einschließlich Einbrüchen und Terroranschlägen, Insider-und Cyberangriffe, politische und soziale Instabilität, gegebenenfalls auch in dem Land, in dem ein IT-Drittdienstleister seine Dienste anbietet, und an dem Ort, an dem die Daten gespeichert und verarbeitet werden sowie großflächige Stromausfälle.
- Erweiterung des Testumfangs: Das Thema Testen bekommt unter DORA eine stärkere Gewichtung. Zwar sahen BAIT „jährliche“ und VAIT „regelmäßige“ Tests zur Überprüfung der Wirksamkeit der IT-Notfallpläne vor, DORA fordert jedoch mindestens eine jährliche und im Fall von wesentlichen Änderungen an kritischen IT-Systemen eine anlassbezogene Testfrequenz, um die Wirksamkeit und Angemessenheit der Aktivitäten für alle relevanten Szenarien zu überprüfen.
Krisenmanagement und Meldewesen
- Funktionen für das Krisenmanagement: Im Rahmen des Krisenmanagements werden erstmals explizit Kommunikations- und Krisenmanagementmaßnahmen gefordert.
- Meldung von IKT-bezogenen Vorfällen: Nachdem in BAIT und VAIT bisher lediglich bestimmt war, dass grundlegend Meldeprozesse für Störungen vorhanden sein müssen, stellt DORA nun konkretere Anforderungen für das Melden von Vorfällen. IT-Dienstleister sind hiervon ausgenommen. Hierzu werden Inhalte von Meldungen sowie Meldefristen definiert. Der entsprechende technische Implementierungsstandard stellt Formulare zur Verfügung und definiert den geforderten Meldeprozess. Dieser sieht vor, dass Finanzunternehmen einen Vorfall an die BaFin melden, welche diesen im Sinne eines Single- Point-of-Contacts an das BSI sowie die europäischen Aufsichtsbehörden weiterleitet.
Operative Informationssicherheit
- Anforderungen an Daten: Daten- und Systemsicherheitsmaßnahmen nehmen mit DORA deutlich zu. Diese umfassen beispielsweise das Ergreifen und die Kontrolle von Härtungsmaßnahmen, den Einsatz von Software und mobilen Datenträgern, Regelungen für mobiles Arbeiten in Bezug auf erlaubte Geräte und Software, Verfahren zum sicheren Löschen von Informationen sowie Vernichten von Datenträgern, Maßnahmen zum Schutz vor dem absichtlichen oder versehentlichen Verlust von Daten. Es gelten nun strengere Anforderungen für Systeme, die von IT-Drittdienstleistern betrieben werden – dazu gehört die Umsetzung von Herstellerempfehlungen auf den vom Institut betriebenen IKT-Systemen. Außerdem müssen Informationssicherheitsrollen und verantwortlichkeiten klar zwischen Finanzunternehmen und IT-Drittdienstleistern geregelt sein. Es muss sichergestellt sein, dass im Finanzunternehmen ausreichend Fähigkeiten zur Verwaltung und für die Sicherheit der eingesetzten IKT-Lösungen vorhanden bleiben. Zudem müssen technische und organisatorische Maßnahmen (TOM) implementiert werden, um die Risiken zu minimieren, die durch die Nutzung des IT-Drittdienstleisters auf die eigene Infrastruktur entstehen.
Threat-Led Penetration-Testing (TLPT)
Im Feld des Threat-Led Penetration-Testings gab es bisher das Rahmenwerk zum Threat-Intelligence-based Ethical Red-Teaming TIBER-DE [5]. Abseits kleinerer Details in der praktischen Umsetzung des TLPT ändert sich nicht sonderlich viel: Die zuständigen Behörden prüfen, welche Finanzunternehmen überhaupt TLPT durchführen müssen. Für Unternehmen, die in mehreren EU-Staaten aktiv sind, haben die TLPT nach DORA den Vorteil, dass die Testergebnisse EU-weit anerkannt werden. Darüber hinaus könnten unter besonderen Umständen auch interne Tester die Tests durchführen.
Navigation zum Ziel
Kritik ist das eine, eine Lösung das andere – wie viel Aufwand muss nun tatsächlich sein? In dieser Frage existieren gefühlt zwei Lager: eine Fraktion, die nach einem Pauschalansatz die wortgetreue Umsetzung der Anforderungen für notwendig erachtet und eine andere, die nach dem Ansatz „Mut zu Lücke“ vorgeht. Was ist richtig?
Die Antwort könnte schwieriger nicht sein und fällt von Institution zu Institution anders aus – und das ist auch gut so und genau im Sinne von DORA!
Unter der Prämisse, dass DORA für alle Betroffenen neu ist (auch für die BaFin und die Bundesbank), muss klar sein, dass jegliche Auslegung der DORA-Anforderungen eine Interpretation ist – ein „richtig“ und „falsch“ kann es zum gegenwärtigen Zeitpunkt nicht geben.
Ein Ansatz, um sich der Frage nach dem notwendigen Aufwand zu stellen, wäre es, sich das Kernelement von DORA bewusst zu machen: das IKT-Risikomanagement. Zieht man dieses als Implementierungsgrundlage heran, müssen die DORA-Anforderungen nicht im Wortlaut umgesetzt werden, sondern nach einem individuellen risikoorientierten Vorgehen. Dieses Verständnis ist wichtig, da DORA rein aus dem Gesetzestext keine Formulierung enthält (anders als bspw. VAIT I.7), wonach das Proportionalitätsprinzip zu berücksichtigen ist und konkretere Themen nach einem risikoorientieren Ansatz umzusetzen sind.
DORA definiert zwar konkrete Anforderungen – wie diese jedoch anzuwenden sind, hängt von den jeweiligen Risiken der einzelnen Unternehmen ab; die Ergebnisse der BIA und Risikoanalyse sind hierbei wesentliche Kriterien. Art. 4 DORA hebt dementsprechend hervor, dass die Anforderungen gemäß Unternehmensgröße, Risikoprofil sowie der Art der Geschäftstätigkeit verhältnismäßig umzusetzen sind.
Zudem muss man DORA – wie auch BAIT, VAIT & Co. – im übergeordneten Kontext verstehen: Ma-Risk, MaGo et cetera müssen also mitbetrachtet werden! Diese unterstreichen ebenfalls den Ansatz eines risikoorientierten Vorgehens, wie die MaGo (VAIT) beispielhaft aufgezeigt (MaGo: 14 Notfallmanagement, Satz 296 – siehe auch MaRisk AT 4.1. Risikotragfähigkeit 2–3 sowie AT 7.3): „Die den Notfallplänen zugrunde liegenden Notfallszenarien haben dem individuellen Risikoprofil hinreichend Rechnung zu tragen.“ Die Institute sind demnach selbst für die Risikotragfähigkeit und – daraus abgeleitet – für eine wirksame Umsetzung der DORA-Anforderungen zuständig.
Die Anforderungen von DORA können daher angepasst an das eigene Risikoprofil und den Risikoappetit des Unternehmens implementiert werden. Eine abgestufte Umsetzung von Maßnahmen, beispielsweise hinsichtlich der Häufigkeit und dem Umfang von Tests, der Gestaltung von Vertragsanforderungen an Dienstleistern oder betrachteten Szenarien, lässt sich so skalieren.
Unternehmen, die sich dieses Ansatzes bewusst sind und im Sinne eines Reifegradzyklus auch möglichen Abweichungen in einer künftigen DORA-Prüfung offen gegenüberstehen, können mit Blick auf eine Kosten-Nutzen- Betrachtung die scheinbar große Lücke zu DORA mit überschaubarem Aufwand verkürzen. Denn auch eine wortgetreue Umsetzung schützt nicht zwangsläufig vor Abweichungen – alles ist aktuell Interpretation.
Jann-Christoph Sowa ist Expert Security Consulting, Sven Stubbe ist Team-Manager, Hendrik Hoppe ist Secruity-Consultant bei HiSolutions.
Literatur
[1] 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://eurlex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32022R2554
[2] Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin), Delegierte Rechtsakte und Durchführungsstandards zu DORA sowie gemeinsame Leitlinien (Level 2 und 3), in: DORA – Digital Operational Resilience Act, August 2024, www.bafin.de/DE/Aufsicht/DORA/DORA_node.html#doc19669328bodyText5
[3] Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin), BaFin veröffentlicht Umsetzungshinweise zu DORA, Aktuelle Meldung, Juli 2024, www.bafin.de/SharedDocs/Veroeffentlichungen/DE/Meldung/2024/meldung_2024_07_08_DORAGap.html
[4] U.S. National Institute of Standards and Technology (NIST), Cybersecurity Framework – CSF 2.0, Portalseite, fortlaufend aktualisiert, www.nist.gov/cyberframework
[5] Deutsche Bundesbank, TIBER-DE – Threat Intelligence-based Ethical Red Teaming in Deutschland, undatiert, www.bundesbank.de/de/aufgaben/unbarer-zahlungsverkehr/tiber-de/tiber-de-816986