DORA in Österreich/EU: Wer ist betroffen und 10 Schritte zum Minimal-Compliance-Setup

Autor: NEXORA Team Datum: Dezember 2025 Lesezeit: ca. 12 Minuten

Kurzbeschreibung

Dieser Artikel erklärt präzise, welche Finanzunternehmen und ICT-Dienstleister in Österreich und der EU von der Digital Operational Resilience Act (DORA) betroffen sind, beschreibt ein praxisnahes Minimal-Compliance-Setup in 10 konkreten Schritten und liefert Checklisten sowie typische Audit-Fragen für die interne Umsetzung und Aufsichtskommunikation.

Für Entscheider:

• Wer ist betroffen: DORA gilt ab 17. Januar 2025 für nahezu alle beaufsichtigten Finanzunternehmen in der EU (Banken, Zahlungsinstitute, E-Geld-Institute, Versicherungen, Wertpapierfirmen, Krypto-Dienstleister u.a.) sowie indirekt für deren ICT-Dienstleister. Als „kritische ICT-Drittanbieter" eingestufte Anbieter unterliegen einem europäischen Oversight-Rahmen durch die ESAs.

• Minimal-Compliance-Setup: Ein funktionierendes Basis-Setup umfasst: dokumentierte ICT-Risiko-Policy und Integration ins Gesamt-Risikomanagement, definierten Incident-Management-Prozess mit klaren Meldewegen, vollständiges Outsourcing-/ICT-Register (Register of Information), klare Rollen und Verantwortlichkeiten auf Management-Ebene, regelmäßige Resilience-Tests sowie Due-Diligence- und Monitoring-Prozesse für ICT-Drittanbieter.

• Zeitachse: DORA gilt seit 17. Januar 2025 unmittelbar in allen EU-Mitgliedstaaten. In Österreich war das vollständige Register of Information erstmals bis 31. März 2025 an die FMA zu übermitteln (gemäß aktueller FMA-Kommunikation, Stand: Dezember 2024). Ongoing Compliance bedeutet kontinuierliche Aktualisierung aller Artefakte, jährliche Reviews und Anpassung an neue RTS/ITS der ESAs.

• Aufsichtsfokus: Die FMA und andere europäische Aufsichtsbehörden legen besonderen Wert auf: ICT Risk Governance auf Management-Body-Ebene, vollständiges und aktuelles ICT-Register, funktionierenden Major-Incident-Reporting-Prozess, nachweisbare Testing-Strategie (inkl. TLPT für signifikante Institute gemäß den einschlägigen RTS) und Third-Party-Risk-Management mit klaren vertraglichen Regelungen (Audit-Rechte, Exit-Strategien, Sicherheitsstandards).

• Konsequenzen bei Nicht-Compliance: Unzureichende Umsetzung kann zu Aufsichtsmaßnahmen führen, darunter: Nachforderung von Verbesserungsplänen, On-Site-Inspections (gemeinsam mit OeNB/FMA), administrative Sanktionen, Reputationsrisiken sowie operationelle Störungen bei ungeklärten ICT-Abhängigkeiten. Fehlende Nachweise zur ICT-Resilienz können zudem Geschäftsbeziehungen zu Auftraggebern belasten.

1. Kontext & warum das Thema jetzt relevant ist (AT/EU)

Die Regulation (EU) 2022/2554 – Digital Operational Resilience Act (DORA) ist seit 17. Januar 2025 in allen EU-Mitgliedstaaten unmittelbar anwendbar. DORA schließt eine zentrale Lücke im europäischen Finanzaufsichtsrecht: Während nach der Finanzkrise 2008 vor allem die finanzielle Resilienz (Kapital, Liquidität) gestärkt wurde, blieben ICT-bezogene Risiken in fragmentierten nationalen Regelungen verankert. Mit der zunehmenden Digitalisierung des Finanzsektors – Cloud-Nutzung, API-basierte Dienstleistungen, Outsourcing kritischer Funktionen – wurde die operationelle Resilienz gegenüber Cyberbedrohungen und IT-Störungen zur systemischen Herausforderung.

DORA harmonisiert die Anforderungen an digitale operationelle Resilienz EU-weit und integriert erstmals ICT-Drittanbieter direkt in den Aufsichtsrahmen. Für österreichische Institute bedeutet dies: Die FMA (Finanzmarktaufsicht) überwacht die Einhaltung von DORA in enger Zusammenarbeit mit der OeNB (Oesterreichische Nationalbank). Die FMA arbeitet unter anderem mit Erhebungen zur digitalen Landschaft und ICT-Abhängigkeiten in Österreich; Details ergeben sich aus laufenden FMA-Publikationen und Aufsichtsformaten.

Relevanz für 2025: Unternehmen müssen nicht nur formale Compliance nachweisen, sondern auch substanzielle Prozesse etablieren. Die Aufsicht prüft keine „Papier-Compliance", sondern erwartet nachweisbare Umsetzung in Governance, Testing, Incident Management und Third-Party-Oversight.

2. Wer ist betroffen? (Scope)

Finanzunternehmen gemäß Art. 2 DORA

DORA gilt gemäß Artikel 2 für ein breites Spektrum an Finanzunternehmen („financial entities"), darunter:

• Kreditinstitute (Art. 2 Abs. 1 lit. a) – z.B. Banken, Bausparkassen

• Zahlungsinstitute und E-Geld-Institute (lit. b–c) – auch FinTechs mit Zahlungslizenz

• Wertpapierfirmen (lit. d)

• Crypto-Asset Service Provider (CASP) nach MiCA-Verordnung (lit. e)

• Zentrale Gegenparteien (CCPs), zentrale Wertpapierverwahrstellen (CSDs), Handelsplätze (lit. f–h)

• Manager von Investmentfonds (AIFMs, UCITS-ManCos) (lit. i–j)

• Versicherungs- und Rückversicherungsunternehmen, Versicherungsvermittler (lit. k–m)

• Einrichtungen der betrieblichen Altersversorgung (IORPs) (lit. n)

• Ratingagenturen, Administratoren kritischer Benchmarks, Crowdfunding-Dienstleister, Datenbereitstellungsdienste (lit. o–s)

• Verbriefungsregister (lit. t)

Proportionalitätsprinzip: DORA sieht (begrenzt) Proportionalität vor (Art. 4). Kleinstunternehmen („microenterprises": <10 Mitarbeiter, <2 Mio. EUR Umsatz/Bilanzsumme) haben erleichterte Anforderungen, bleiben aber grundsätzlich im Scope. Trading Venues, CCPs, CSDs, TRs sind von Proportionalität ausgenommen.

ICT-Dienstleister: Normal und „kritisch"

DORA betrifft ICT-Dienstleister indirekt und direkt:

Indirekt: Alle ICT-Drittanbieter („ICT third-party service providers"), die ICT-Services an Finanzunternehmen erbringen, werden über vertragliche Pflichten der Finanzunternehmen in DORA-Compliance eingebunden (Art. 28, 30):

• Audit-Rechte für Finanzunternehmen und Aufsichtsbehörden

• Sicherheits- und Resilienzanforderungen

• Incident-Meldepflichten

• Exit-Strategien, Datenrückführung, Interoperabilität

Direkt – „Critical ICT Third-Party Providers": Anbieter, die von den ESAs (EBA, ESMA, EIOPA) als kritisch eingestuft werden, unterliegen einem europäischen Oversight Framework (Art. 31 ff.). Kriterien für die Einstufung als „critical" (Art. 31 Abs. 2) umfassen:

• Systemische Bedeutung (wie viele Finanzunternehmen nutzen den Anbieter?)

• Systemische Auswirkungen im Falle eines Ausfalls

• Keine einfachen Alternativen verfügbar (Konzentrations-/Lock-in-Risiko)

Die ESAs werden kritische ICT-Drittanbieter auf Basis der festgelegten Kriterien designieren (Stand Dezember 2024: erste Designierungen werden für 2025 erwartet). Für diese Anbieter führt ein Lead Overseer (eine der ESAs) Oversight-Aktivitäten durch: Informationsanfragen, Inspections, Empfehlungen zur Risikominderung. Finanzunternehmen bleiben jedoch stets primär verantwortlich für Third-Party-Risk-Management.

Praxisbeispiele

Beispiel 1 – Österreichische Bank mit Cloud-Outsourcing: Eine mittelgroße österreichische Bank (Kreditinstitut nach CRR/CRD) lagert ihre Kernbankensysteme und Zahlungsverarbeitung an zwei Cloud-Service-Provider aus. Die Bank ist DORA-Finanzunternehmen. Sie muss:

• Beide Cloud-Anbieter im ICT-Register führen (mit allen DORA/FMA-Feldern, inkl. Kritikalität, Sub-Outsourcing)

• Verträge auf DORA-Klauseln prüfen (Audit-Rechte, Exit, Security)

• Due Diligence und kontinuierliches Monitoring durchführen

• Falls einer der Cloud-Anbieter als „critical" designiert wird, muss die Bank Empfehlungen des Lead Overseers in ihr Third-Party-Management integrieren.

Beispiel 2 – FinTech-Zahlungsinstitut mit SaaS-Kernsystem: Ein in Österreich lizenziertes Zahlungsinstitut (gemäß ZaDiG 2018 / PSD2) nutzt ein SaaS-Kernsystem eines spezialisierten Anbieters. Das Zahlungsinstitut ist DORA-Finanzunternehmen. Der SaaS-Anbieter erbringt eine „critical or important function" (Zahlungsabwicklung). Das Zahlungsinstitut muss:

• ICT-Risiko-Policy und Testing-Strategie definieren

• Den SaaS-Anbieter im Register führen, Due Diligence dokumentieren

• Vertragliche Exit-Regelungen und Interoperabilität sicherstellen

• Major ICT-Incidents (z.B. Ausfall des SaaS-Systems) gemäß Art. 19 an die FMA melden.

Kein Finanzunternehmen, aber betroffen: Ein reiner Software-Anbieter (z.B. Core-Banking-SaaS-Hersteller) ohne eigene Finanzlizenz ist kein DORA-Finanzunternehmen. Wird er jedoch von vielen Banken als kritisch eingestuft und erfüllt die Kriterien für „critical ICT third-party", unterliegt er dem Oversight der ESAs.

3. Was bedeutet „Minimal-Compliance-Setup"? (Definition + Zielbild)

Definition

Ein „Minimal-Compliance-Setup" ist das kleinste konsistente und nachweisbare Set an Governance-Elementen, Policies, Prozessen, Registern und Artefakten, mit dem ein Finanzunternehmen gegenüber der Aufsicht, internen/externen Prüfern und Stakeholdern darlegen kann, dass die DORA-Grundanforderungen ernsthaft, systematisch und proportional umgesetzt werden.

„Minimal" bedeutet nicht „unzureichend", sondern vielmehr:

• Keine redundanten oder rein formalen Dokumente ohne praktische Umsetzung

• Fokus auf Substanz statt auf Volumen

• Proportional zur Größe, Komplexität und Risikoprofil des Unternehmens

• Skalierbar: Ein Minimal-Setup bildet die Basis für künftige Reifegradsteigerungen.

Zielbild eines Minimal-Compliance-Setups

Ein Minimal-Setup umfasst typischerweise:

• ICT Risk Management Framework

• Dokumentierte ICT-Risiko-Policy (integriert in Gesamt-Risikomanagement)

• Inventar von ICT- und Informationsassets

• Risikobewertungsmethodik (inkl. Legacy-Systeme, Konzentrationsrisiken)

• Zuordnung von Rollen und Verantwortlichkeiten (Management Body, CISO/IKT-Verantwortliche, Control Functions)

• Definierte ICT Business Continuity Policy und Recovery-Pläne

• Incident Management & Reporting

• Prozess zur Klassifizierung von ICT-Incidents (Anlehnung an Delegated Regulation (EU) 2024/1772)

• Definition „Major ICT-related Incident" mit klaren Schwellenwerten

• Interne Eskalationswege, Rollen (z.B. CISO, Incident Response Team)

• Schnittstelle zur FMA-Meldung (Initial Notification, Intermediate/Final Report gemäß Delegated Regulation (EU) 2025/301)

• Voluntary Notification-Prozess für signifikante Cyber-Threats

• Testing & Resilience

• Testing-Strategie, die verschiedene Test-Typen abdeckt:

• Vulnerability Assessments, Penetration Tests

• Scenario-based Testing

• Ggf. Threat-Led Penetration Testing (TLPT) gemäß Art. 26 für signifikante Institute (mind. alle 3 Jahre)

• Dokumentierte Test-Resultate und Remediation-Pläne

• Review-Prozess für Test-Ergebnisse auf Management-Ebene

• Third-Party Risk Management

• ICT Third-Party Risk Policy (Strategie gemäß Art. 28 DORA)

• Vollständiges Register of Information (Outsourcing-/ICT-Register) gemäß Implementing Regulation (EU) 2024/2956, inkl.:

• Alle ICT-Drittanbieter (auch Sub-Outsourcing)

• Klassifizierung nach Kritikalität

• Vertragsdetails, SLAs, Exit-Regelungen

• Due Diligence-Prozess vor Vertragsabschluss

• Kontinuierliches Monitoring (KPIs, SLA-Einhaltung, Incident-Reports von Drittanbietern)

• Exit-Strategie und Contingency-Pläne für kritische Outsourcing-Arrangements

• Governance & Rollen

• Management Body Responsibility: Formale Genehmigung der ICT-Risiko-Policy, DORA-Strategie, Budget, Testing-Plan

• Definierte Rollen: z.B. CISO, ICT Risk Control Function (kann mit CISO kombiniert sein unter Bedingungen), Compliance, Operational Risk

• Reporting-Linien: regelmäßige Management-Reports zu ICT-Risiken, Incidents, Testing, Third-Party-Monitoring

• Awareness & Training: Schulungsprogramme für Mitarbeiter, Management und (wo relevant) ICT-Drittanbieter

• Contracting & Vendor Oversight

• Vertragstemplates/Standard-Klauseln für ICT-Services, die DORA-Anforderungen integrieren (siehe unten Abschnitt „Contracting")

• Prozesse für Vertragsverhandlung, -überwachung und -anpassung

• Dokumentation & Evidence

• Evidence Pack: Ein strukturierter Satz von Nachweisdokumenten für interne/externe Prüfung und Aufsicht (siehe Download-Artefakt unten)

• Change-Management für Policies und Prozesse

• Kontinuierliche Verbesserung: Lessons Learned aus Incidents, Tests, Audits

Wichtig: Das Minimal-Setup ist kein statisches Ziel, sondern ein Ausgangspunkt. Unternehmen sollten ihr Setup regelmäßig (mind. jährlich) überprüfen, an regulatorische Updates (neue RTS/ITS) anpassen und im Rahmen von Reifegradmodellen weiterentwickeln.

4. Die „10 Schritte"-Roadmap zum Minimal-Compliance-Setup

Die folgende Roadmap führt von „kaum vorbereitet" zu einem funktionierenden Minimal-Setup. Die Schritte bauen teilweise aufeinander auf, können aber auch parallel bearbeitet werden.

Schritt 1: Scope & Rollen klären

Schrittziel: Definieren, welche Unternehmensteile, Geschäftsfelder und ICT-Services unter DORA fallen. Identifizieren, wer intern verantwortlich ist (Management Body, CISO, Compliance, Risk, Legal, Procurement) und wer externen Support leisten könnte.

Typische Nachweise/Artefakte:

• DORA-Projekt-Charter mit Scope-Definition

• Stakeholder-Matrix (Rollen, Verantwortlichkeiten, RACI)

• Liste der betroffenen Gesellschaften (bei Gruppen)

• Konsolidierungslogik für Meldungen (z.B. Gruppenebene)

Häufige Fehler:

• Scope zu eng definieren (z.B. nur IT, nicht Operational Risk, Procurement, Legal)

• Management Body nicht frühzeitig eingebunden

• Unklare Verantwortlichkeiten zwischen Konzernmutter und Tochtergesellschaften

---

Schritt 2: Governance & Management Body Ownership formal verankern

Schrittziel: Sicherstellen, dass das Management Body (Vorstand/Geschäftsführung) formell Verantwortung für ICT-Risiko und DORA übernimmt, wie in Art. 5 DORA gefordert.

Typische Nachweise/Artefakte:

• Vorstandsbeschluss/Geschäftsführerbeschluss zur DORA-Strategie

• Organisationshandbuch/Geschäftsordnung mit DORA-Verantwortlichkeiten

• Ressourcenplanung (Budget, Personal) für DORA-Umsetzung

• Eskalationswege für Major Incidents (CISO → Management Body)

Häufige Fehler:

• Management Body betrachtet DORA als „IT-Thema" ohne eigene Verantwortung

• Keine klare Zuordnung auf Vorstandsressort/Geschäftsführer

• Fehlende Dokumentation der Management Body-Entscheidungen

---

Schritt 3: Gap-Analyse durchführen

Schrittziel: Bestehendes ICT-Risiko-, Security- und Outsourcing-Framework gegen DORA-Anforderungen spiegeln. Identifizieren, was bereits vorhanden ist (z.B. aus ISO 27001, EBA Outsourcing Guidelines, NIS2) und wo Lücken bestehen.

Typische Nachweise/Artefakte:

• Gap-Analyse-Report (DORA-Anforderungen vs. IST-Zustand)

• Priorisierte Maßnahmenliste mit Verantwortlichen und Deadlines

• Mapping bestehender Policies/Prozesse auf DORA-Artikel

• Risikoregister für identifizierte Gaps

Häufige Fehler:

• Analyse auf Dokumentenebene, ohne Praxis zu prüfen („Papier-Compliance")

• Keine Priorisierung nach Risiko und Aufsichtsrelevanz

• Fehlende Einbindung von Business-Units und Fachbereichen (nur IT)

---

Schritt 4: ICT Risk Management Policy & Methodik definieren/aktualisieren

Schrittziel: Bestehende ICT-Risiko-Policy anpassen oder neue Policy erstellen gemäß Art. 6 DORA. Integration in das Gesamt-Risikomanagement.

Typische Nachweise/Artefakte:

• ICT Risk Management Policy (genehmigt durch Management Body), umfassend:

• Risikokategorien (z.B. Cyber, System Availability, Data Integrity, Third-Party)

• Risikobewertungsmethodik (Likelihood/Impact)

• Risk Appetite/Toleranzen

• Rollen und Verantwortlichkeiten

• Eskalationsmechanismen

• Kontinuierliche Überwachung und Reporting

• Asset-Inventar (ICT- und Informationsassets)

• Risiko-Register (ICT-Risiken)

Häufige Fehler:

• Policy ist zu generisch und nicht auf tatsächliche ICT-Landschaft zugeschnitten

• Keine Integration mit bestehenden Risk-Frameworks (Operational Risk, Compliance Risk)

• Fehlende Verbindung zu Business Continuity und Disaster Recovery

---

Schritt 5: Incident Management & Incident Reporting Prozess aufsetzen

Schrittziel: Prozess für Detection, Classification, Response, Recovery und Reporting von ICT-Incidents etablieren. Schnittstelle zur FMA-Meldung gemäß Art. 19 DORA aufbauen.

Typische Nachweise/Artefakte:

• Incident Management Policy mit:

• Incident-Klassifizierungskriterien (gemäß Delegated Regulation (EU) 2024/1772)

• Definition „Major ICT-related Incident" und Schwellenwerte

• Eskalationswege (intern und extern)

• Rollen (Incident Response Team, CISO, Communication)

• Incident Reporting Procedure (inkl. Timelines, Templates gemäß Implementing Regulation (EU) 2025/302)

• Incident-Log/Ticket-System (auch für Non-Major Incidents)

• Testlauf des Meldeprozesses (z.B. Tabletop Exercise)

Häufige Fehler:

• Schwellenwerte für „Major" sind unklar oder zu hoch angesetzt

• Keine Schnittstelle zwischen IT-Incident-Management und Compliance/Risk

• Meldeweg zur FMA ist nicht getestet oder nicht dokumentiert

• Keine Prozesse für „Voluntary Notification" von Cyber-Threats

---

Schritt 6: Testing & Resilience-Konzept etablieren

Schrittziel: Strategie und Plan für regelmäßige Tests der ICT-Systeme und Prozesse (Art. 24-26 DORA) definieren, proportional zum Risikoprofil.

Typische Nachweise/Artefakte:

• ICT Testing Strategy/Plan, umfassend:

• Test-Typen (Vulnerability Scans, Penetration Tests, Scenario-based Tests, ggf. TLPT)

• Frequenz und Scope

• Rollen (interne/externe Tester)

• Remediation-Prozess

• Test-Reports und Remediation-Pläne (auch historisch)

• Für signifikante Institute: TLPT-Plan gemäß Delegated Regulation (EU) 2025/1190, TIBER-EU Framework (alle 3 Jahre)

• Purple-Teaming-Exercises (bei TLPT)

Häufige Fehler:

• Testing wird als „Penetration Test einmal jährlich" reduziert, ohne systematische Strategie

• Remediation-Pläne werden nicht umgesetzt oder nachgehalten

• Keine Integration von Test-Ergebnissen in Risk Register und Management Reporting

• TLPT-Anforderungen werden ignoriert (falls zutreffend)

---

Schritt 7: Third-Party Risk Management implementieren

Schrittziel: Strategie und Prozesse für Management von ICT-Drittanbieter-Risiken über den gesamten Lifecycle (Art. 28 DORA): Due Diligence, Contracting, Monitoring, Exit.

Typische Nachweise/Artefakte:

• ICT Third-Party Risk Policy (gemäß Art. 28 DORA), umfassend:

• Klassifizierungskriterien für Kritikalität

• Due-Diligence-Anforderungen (je nach Kritikalität)

• Monitoring-Mechanismen

• Exit-Strategie-Anforderungen

• Sub-Outsourcing-Management

• Due-Diligence-Checklisten und Reports (je Anbieter)

• Kontinuierliches Monitoring (KPIs, SLA-Tracking, Incident-Reports)

• Exit-Pläne und Contingency-Maßnahmen für kritische Anbieter

Häufige Fehler:

• Due Diligence ist rein formal („Fragebogen abhaken"), ohne substanzielle Bewertung

• Keine kontinuierliche Überwachung nach Vertragsabschluss

• Exit-Strategien sind theoretisch, aber nicht getestet

• Sub-Outsourcing wird nicht erfasst oder gemanagt

---

Schritt 8: Outsourcing-/ICT-Register und Register of Information aufbauen

Schrittziel: Vollständiges, aktuelles und konsistentes Register aller ICT-Drittanbieter gemäß Art. 28 Abs. 2 DORA und Implementing Regulation (EU) 2024/2956 etablieren.

Typische Nachweise/Artefakte:

• Register of Information (Excel/Database/GRC-Tool), umfassend alle Felder gemäß ITS:

• Anbieter (Name, LEI, Standort)

• ICT-Service-Beschreibung

• Klassifizierung (critical/important function, Sub-Outsourcing)

• Vertragsdaten (Start, Ende, SLAs)

• Kritikalität und Konzentrationsrisiko

• Datenspeicherorte

• Exit-Regelungen

• Audit-Rechte

• Prozess zur kontinuierlichen Aktualisierung (mindestens jährlich, bei Änderungen sofort)

• Verantwortlichkeiten für Register-Pflege

• Erste Meldung an FMA in Österreich (Stichtag 31.03.2025, danach jährlich)

Häufige Fehler:

• Register ist unvollständig (z.B. fehlen kleinere Anbieter, Sub-Outsourcing)

• Klassifizierung (critical/important) ist inkonsistent oder nicht dokumentiert

• Keine klare Zuordnung von Verantwortlichkeiten für Register-Pflege

• Datenqualität ist schlecht (inkonsistente Einträge, veraltete Informationen)

---

Schritt 9: Vertragsmanagement/Standardklauseln anpassen

Schrittziel: Vertragstemplates und Standardklauseln für ICT-Services gemäß Art. 30 DORA anpassen, um DORA-Anforderungen abzubilden (Audit-Rechte, Sicherheit, Exit, etc.).

Typische Nachweise/Artefakte:

• Standard-Vertragsklauseln (Template/Playbook) für ICT-Services, umfassend:

• Leistungsumfang und Kritikalität

• Sicherheits- und Resilienzanforderungen (inkl. Standards wie ISO 27001, NIS2-Konformität)

• Audit-, Informations- und Zugangsrechte (für Finanzunternehmen und Aufsichtsbehörden)

• Incident-Meldepflichten (Timelines, Formate)

• Sub-Outsourcing-Regelungen (Genehmigung, Durchgriff)

• Exit-Strategie, Datenrückführung, Interoperabilität, Übergangsdienste

• Versicherungsnachweis, Haftung

• Verhandlungsplaybook (wie mit Anbietern verhandeln, die Standard-Terms haben)

• Vertragsinventar (welche Altverträge müssen angepasst werden)

Häufige Fehler:

• Standard-Klauseln sind vorhanden, aber werden bei tatsächlichen Verträgen nicht verwendet

• Keine differenzierte Klausel-Sets je nach Kritikalität

• Exit-Regelungen sind vage oder nicht praktikabel

• Keine Prozesse für regelmäßige Vertragsreviews

---

Schritt 10: Schulung, Awareness, Reporting & kontinuierliche Verbesserung

Schrittziel: Sicherstellen, dass alle relevanten Mitarbeiter (inkl. Management, IT, Risk, Procurement) DORA-Anforderungen verstehen. Etablierung von Management-Reporting und Lessons-Learned-Prozess.

Typische Nachweise/Artefakte:

• Schulungsplan (DORA Awareness für alle, spezifische Trainings für Rollen)

• Schulungsmaterialien und Teilnahmenachweise

• Management-Reports (z.B. quartalsweise):

• ICT-Risiko-Dashboard

• Incident-Statistiken

• Testing-Fortschritte

• Third-Party-Monitoring-Ergebnisse

• Maßnahmenfortschritt (DORA-Roadmap)

• Lessons-Learned-Prozess (nach Incidents, Tests, Audits)

• Jährlicher DORA-Compliance-Review (Gap-Analyse, Policy-Update)

Häufige Fehler:

• Schulungen sind rein formal („E-Learning abhaken"), ohne echte Awareness

• Management-Reporting ist zu detailliert oder zu oberflächlich

• Keine strukturierte Auswertung von Lessons Learned

• Kontinuierliche Verbesserung findet nicht statt (Setup bleibt statisch)

5. Kernbereiche von DORA im Minimal-Setup (detailliert)

5.1 ICT Risk Management (Kapitel II, Art. 5-16 DORA)

Regulatorische Anforderung: DORA verpflichtet Finanzunternehmen, ein umfassendes ICT-Risikomanagement-Framework zu etablieren (Art. 6), das in das Gesamt-Risikomanagement integriert ist. Das Management Body trägt die Gesamtverantwortung (Art. 5). Konkrete Anforderungen umfassen:

• Governance und Rollen (Management Body, CISO, ICT Risk Control Function)

• ICT-Risiko-Policy, Strategie und Risikotoleranz

• Asset-Inventar und Risiko-Assessment

• Schutz- und Präventionsmaßnahmen

• Detection und Monitoring

• Response und Recovery (inkl. Business Continuity)

• Backup-Strategien und Redundanz

• Vulnerability Management

• Kontinuierliche Überwachung und Anpassung

Minimal-Setup:

• ICT Risk Management Policy (genehmigt durch Management Body), die obige Punkte abdeckt

• Asset-Inventar (ICT- und Informationsassets), mit Risiko-Klassifizierung

• Risiko-Register (ICT-Risiken), mit Bewertung (Likelihood/Impact), Maßnahmen, Verantwortlichen

• Rollen-Definition: Management Body, CISO (oder IKT-Verantwortliche), ICT Risk Control Function (kann mit CISO kombiniert sein unter Einhaltung von Unabhängigkeit gemäß Art. 6 Abs. 4)

• Integration: ICT-Risiken sind Teil des Operational Risk Framework und werden in Risk Committees, Audit Committee und Board berichtet

• Reporting: Mind. jährlicher ICT-Risiko-Report an Management Body

Typische Fehler:

• Policy ist Kopie aus Standard-Vorlage, ohne Anpassung an tatsächliche ICT-Landschaft

• Asset-Inventar ist unvollständig (z.B. Legacy-Systeme fehlen)

• Risikoregister ist statisch und wird nicht aktualisiert

• Keine Verbindung zwischen ICT-Risiken und Business Impact

• CISO hat keine ausreichenden Ressourcen oder Eskalationsmöglichkeiten

5.2 Incident Management/Reporting (Kapitel III, Art. 17-23 DORA)

Regulatorische Anforderung: Finanzunternehmen müssen Prozesse für Detection, Management und Response auf ICT-Incidents haben (Art. 17). Major ICT-related Incidents müssen an die zuständige Aufsichtsbehörde (FMA) gemeldet werden (Art. 19):

Hinweis: Die folgenden Zeitvorgaben basieren auf den einschlägigen delegierten Rechtsakten (RTS/ITS) und können durch zukünftige Anpassungen geändert werden.

• Initial Notification (innerhalb von 4 Stunden nach Awareness, gemäß Delegated Regulation (EU) 2025/301)

• Intermediate Report (bei signifikanten Statusänderungen)

• Final Report (mit Root-Cause-Analyse)

Klassifizierung erfolgt gemäß Delegated Regulation (EU) 2024/1772 (Kriterien: Auswirkung auf Verfügbarkeit, Integrität, Vertraulichkeit; Anzahl betroffener Kunden; geografische Reichweite; Dauer).

Freiwillige Meldung von signifikanten Cyber-Threats ist möglich (Art. 19 Abs. 2).

Minimal-Setup:

• Incident Management Policy/Procedure, umfassend:

• Incident-Detection (Monitoring-Tools, Alerting)

• Incident-Classification (gemäß DORA-Kriterien)

• Interne Eskalation (Incident Response Team, CISO, Management)

• Response und Containment

• Recovery und Restoration

• Post-Incident-Review (Root-Cause-Analyse, Lessons Learned)

• Incident Reporting Procedure zur FMA:

• Definierte Schwellenwerte für „Major"

• Templates gemäß Implementing Regulation (EU) 2025/302

• Timelines (4h, Intermediate, Final)

• Verantwortlichkeiten (wer meldet, wer genehmigt)

• Incident-Log (alle Incidents, auch Non-Major)

• Kundenkommunikation: Prozess zur Information betroffener Kunden bei Major Incidents (Art. 19 Abs. 3)

• Testing: Tabletop Exercises, um Incident Response und Reporting zu testen

Typische Fehler:

• Schwellenwerte für „Major" sind zu hoch, sodass meldepflichtige Incidents nicht gemeldet werden

• Incident-Response ist rein IT-getrieben, ohne Einbindung von Risk, Compliance, Communication

• Keine klare Verantwortlichkeit für FMA-Meldung (IT denkt, Compliance ist zuständig, und umgekehrt)

• Incident-Log ist unvollständig oder nicht analysierbar

• Keine Auswertung von Incidents für kontinuierliche Verbesserung

5.3 Testing/Resilience (Kapitel IV, Art. 24-27 DORA)

Regulatorische Anforderung: Finanzunternehmen müssen regelmäßig Tests ihrer ICT-Systeme und operationellen Resilienz durchführen (Art. 24-25):

• Verschiedene Test-Typen: Vulnerability Assessments, Penetration Tests, Scenario-based Tests

• Proportional zum Risikoprofil und zur Kritikalität

Hinweis: Die folgenden Test-Frequenzen und TLPT-Vorgaben basieren auf den einschlägigen delegierten Rechtsakten (RTS/ITS) und können durch zukünftige Anpassungen oder aufsichtliche Konkretisierungen geändert werden.

Signifikante Institute (identifiziert durch Aufsicht gemäß Art. 26 Abs. 8 und den einschlägigen RTS zu Threat-Led Penetration Testing, Delegated Regulation (EU) 2025/1190) müssen Threat-Led Penetration Testing (TLPT) durchführen (Art. 26):

• Mind. alle 3 Jahre

• TLPT basiert auf TIBER-EU Framework (oder nationale Implementierungen)

• TLPT simuliert realistische Angriffszenarien (Threat Intelligence, Red Teaming)

• Purple Teaming (Zusammenarbeit Red Team / Blue Team) ist verpflichtend in der Closure-Phase

• Interne Tester sind erlaubt (unter Bedingungen), aber jede 3. TLPT muss externe Tester einbinden

Minimal-Setup:

• ICT Testing Strategy, die verschiedene Test-Typen definiert:

• Vulnerability Scans (z.B. quartalsweise automatisiert)

• Penetration Tests (z.B. jährlich auf kritische Systeme)

• Scenario-based Tests (z.B. Cyber-Attack-Simulation, Ransomware-Scenario)

• Business Continuity/Disaster Recovery Tests (z.B. jährlich)

• Test-Plan (Frequenz, Scope, Verantwortlichkeiten, Budget)

• Test-Reports und Remediation-Pläne (inkl. Tracking von Maßnahmen)

• Für signifikante Institute: TLPT-Plan gemäß Delegated Regulation (EU) 2025/1190, inkl.:

• Scope-Definition (welche critical/important functions)

• Auswahl externe/interne Tester

• Koordination mit TLPT Authority (FMA)

• Purple-Teaming-Exercise

• Remediation und Management-Reporting

Typische Fehler:

• Testing ist nicht systematisch (ad-hoc Penetration Tests ohne Strategie)

• Remediation-Pläne werden nicht umgesetzt oder nachgehalten (Findings bleiben offen)

• Keine Integration von Test-Ergebnissen in Risiko-Register und Management-Reporting

• TLPT wird als „normale Penetration Test" missverstanden

• Keine Dokumentation, dass Tests durchgeführt wurden (fehlende Nachweise für Aufsicht)

5.4 Third-Party Risk/Oversight (Kapitel V, Art. 28-44 DORA)

Regulatorische Anforderung: DORA führt umfassende Anforderungen an das Management von ICT-Drittanbieter-Risiken ein (Art. 28-30):

• ICT Third-Party Risk Policy (Art. 28 Abs. 1), inkl. Strategie, Risikoklassifizierung, Exit-Regelungen

• Due Diligence vor Vertragsabschluss (Art. 28 Abs. 2)

• Kontinuierliches Monitoring (Art. 28 Abs. 3)

• Register of Information (Art. 28 Abs. 2) – vollständiges Verzeichnis aller ICT-Drittanbieter

• Vertragliche Anforderungen (Art. 30):

• Leistungsbeschreibung und SLAs

• Sicherheits- und Resilienzanforderungen

• Audit-, Informations- und Zugangsrechte (inkl. für Aufsichtsbehörden)

• Incident-Meldepflichten

• Sub-Outsourcing-Regelungen (Genehmigung, Transparenz)

• Exit-Strategie, Datenrückführung, Interoperabilität, Übergangsdienste

• Notification an FMA bei geplanten Verträgen für critical/important functions (Art. 28 Abs. 3 letzter Satz) (Details unklar, FMA-Guidance erforderlich)

Oversight Framework für „critical ICT third-party providers" (Art. 31 ff.):

• ESAs designieren kritische Anbieter (jährlich)

• Lead Overseer (EBA/ESMA/EIOPA) führt Oversight durch: Informationsanfragen, Inspections, Empfehlungen

• Finanzunternehmen müssen Empfehlungen des Lead Overseers in ihr Third-Party-Management integrieren (Art. 42)

Minimal-Setup:

• ICT Third-Party Risk Policy, umfassend:

• Risikoklassifizierung (z.B. Critical / Important / Standard, basierend auf Kritikalität der Function, Datensensitivität, Konzentrations-/Ersetzbarkeitsrisiko)

• Due-Diligence-Anforderungen (je nach Risikoklasse)

• Monitoring-Mechanismen (KPIs, SLA-Tracking, Incident-Reports, periodische Reviews)

• Exit-Strategie-Anforderungen (Contingency, Transition-Plan, Testing)

• Sub-Outsourcing-Management (Transparenz, Genehmigung, Durchgriff)

• Due-Diligence-Prozess:

• Checkliste/Fragebogen (Security, Resilienz, Financial Stability, Compliance, Zertifizierungen)

• Dokumentation der Due-Diligence-Ergebnisse

• Risk-Acceptance-Entscheidung (bei Risiken)

• Register of Information (siehe Schritt 8)

• Kontinuierliches Monitoring:

• KPI-Tracking (z.B. Verfügbarkeit, Response-Times)

• SLA-Reports

• Incident-Reports von Drittanbietern

• Periodische Reviews (z.B. jährlich)

• Change-Management (bei Änderungen beim Anbieter, z.B. Standortwechsel, Sub-Outsourcing)

• Exit-Strategie:

• Contingency-Pläne für kritische Anbieter

• Transition-Plan (wie wechseln zu Alternative)

• Testing von Exit-Plänen (z.B. alle 2 Jahre)

• Contracting: siehe Schritt 9

Typische Fehler:

• Risikoklassifizierung ist inkonsistent oder nicht dokumentiert

• Due Diligence ist rein formal (Fragebogen abhaken), ohne substanzielle Analyse

• Kein kontinuierliches Monitoring (nur bei Vertragsabschluss Due Diligence, danach nichts)

• Exit-Strategien sind theoretisch, aber nicht getestet oder nicht praktikabel

• Sub-Outsourcing wird nicht erfasst oder gemanagt

• Keine Integration von Third-Party-Risks in Gesamt-Risiko-Register

5.5 Governance/Rollen/Reporting an Management

Regulatorische Anforderung: DORA legt explizite Verantwortung auf das Management Body (Art. 5):

• Definition, Genehmigung und Überwachung aller ICT-Risiko-Arrangements

• Genehmigung von ICT-Risiko-Policy, Testing-Plan, Budget

• Regelmäßige Information über ICT-Risiken, Incidents, Testing, Third-Party-Monitoring

CISO/ICT-Verantwortliche (Art. 6 Abs. 9): Finanzunternehmen müssen ICT-Verantwortliche mit ausreichender Autorität, Ressourcen und direktem Zugang zum Management Body bestellen.

ICT Risk Control Function (Art. 6 Abs. 4): Unabhängige Kontrollfunktion für ICT-Risiko (kann mit CISO kombiniert sein unter Bedingungen).

Minimal-Setup:

• Management Body Responsibility:

• Formale Genehmigung der DORA-Strategie/Roadmap (Vorstandsbeschluss/GF-Beschluss)

• Genehmigung ICT-Risiko-Policy, Testing-Plan, Third-Party-Risk-Policy

• Budget für DORA-Umsetzung (Personal, Tools, externe Berater, Testing)

• Definition von ICT-Risiko-Toleranzen/Thresholds

• Rollen-Definition:

• CISO/IKT-Verantwortliche: Klare Job Description, Ressourcen, Eskalationsmöglichkeiten

• ICT Risk Control Function: Kann mit CISO kombiniert sein, sofern Unabhängigkeit gewährleistet (Art. 6 Abs. 4)

• Incident Response Team: Definierte Rollen (Lead, IT, Communication, Legal, Risk)

• Third-Party-Management-Team: Procurement, Risk, IT, Legal

• Reporting-Linien:

• Regelmäßige Management-Reports (z.B. quartalsweise):

• ICT-Risiko-Dashboard (Top-Risiken, Maßnahmen, Trends)

• Incident-Statistiken (Anzahl, Klassifizierung, Major Incidents)

• Testing-Fortschritte (geplant vs. durchgeführt, Findings, Remediation)

• Third-Party-Monitoring (neue Anbieter, Risikobewertung, Konzentrations-Risiko)

• DORA-Compliance-Status (Roadmap, offene Maßnahmen)

• Ad-hoc-Reporting: Bei Major Incidents sofortige Information an Management Body

Typische Fehler:

• Management Body ist nicht substanziell involviert (betrachtet DORA als IT-Projekt)

• CISO/IKT-Verantwortliche haben keine ausreichenden Ressourcen oder Autorität

• Reporting ist zu detailliert (technische Details) oder zu oberflächig (keine Handlungsempfehlungen)

• Keine klare Eskalation bei Major Incidents oder kritischen Risiken

6. Contracting & Vendor Oversight: Was in Verträge/SLAs gehört

Gemäß Art. 30 DORA müssen Verträge mit ICT-Drittanbietern (insbesondere für critical/important functions) bestimmte Elemente enthalten. Folgende Prinzipien und Inhalte sollten in Verträgen/SLAs verankert sein (keine Musterklauseln, nur inhaltliche Leitplanken):

• Leistungsumfang und Service Level:

• Klare Beschreibung der ICT-Services

• Service Level Agreements (Availability, Performance, Response Times)

• Kritikalität der Function/Service

• Sicherheits- und Resilienzanforderungen:

• Sicherheitsstandards (z.B. ISO 27001, SOC2, NIS2-Konformität)

• Verschlüsselung, Access Controls, Monitoring

• Business Continuity/Disaster Recovery (RTO/RPO)

• Backup-Strategien und Testing

• Audit-, Informations- und Zugangsrechte:

• Recht des Finanzunternehmens auf Audits/Inspections (on-site oder remote)

• Recht der Aufsichtsbehörden (FMA) auf Audits/Inspections beim ICT-Drittanbieter (Art. 30 Abs. 3 lit. e DORA)

• Informationsrechte: Regelmäßige Reports (Security, Availability, Incidents)

• Alternative Assurance-Levels: Falls „traditionelle" Audits Rechte anderer Kunden beeinträchtigen, können alternative Nachweise vereinbart werden (z.B. Third-Party-Certifications, Pooled Audits)

• Incident-Meldepflichten:

• ICT-Drittanbieter muss Incidents, die das Finanzunternehmen betreffen, unverzüglich melden

• Timelines (z.B. innerhalb 2h nach Detection)

• Formate (z.B. Incident-Report-Template)

• Sub-Outsourcing:

• Sub-Outsourcing nur mit Genehmigung des Finanzunternehmens

• Transparenz über Sub-Dienstleister (Register)

• „Durchgriff" auf Sub-Dienstleister (Audit-Rechte)

• Datenspeicherorte und Datenschutz:

• Klare Vereinbarung, wo Daten gespeichert werden (EU/EWR bevorzugt)

• GDPR-Konformität (Data Processing Agreement)

• Datenportabilität und Interoperabilität

• Exit-Strategie, Datenrückführung, Übergangsdienste:

• Exit-Klausel: Möglichkeit zur ordentlichen und außerordentlichen Kündigung

• Datenrückführung: Prozess und Timelines zur Rückführung aller Daten (strukturiert, lesbar)

• Interoperabilität: Standards, um Daten/Services leicht auf andere Anbieter zu migrieren

• Übergangsdienste: ICT-Drittanbieter erbringt während Transition-Period (z.B. 6-12 Monate) weiterhin Services

• Testing von Exit: Regelmäßige Tests des Exit-Plans (z.B. alle 2 Jahre)

• Versicherung und Haftung:

• Nachweis ausreichender Versicherungsdeckung (Cyber, Professional Liability)

• Haftungsregelungen (Caps, Exclusions)

• Änderungsmanagement:

• ICT-Drittanbieter muss geplante Änderungen (z.B. Standortwechsel, technische Upgrades, Sub-Outsourcing) rechtzeitig mitteilen

• Genehmigungspflicht für wesentliche Änderungen

• Vertragslaufzeit und Verlängerung:

• Angemessene Kündigungsfristen (mind. 6-12 Monate bei kritischen Services)

• Regelmäßige Vertragsreviews (z.B. alle 2-3 Jahre)

Praxistipp: Bei Standardverträgen großer Cloud-Anbieter (z.B. AWS, Azure, Google Cloud) sind individuelle Verhandlungen oft schwierig. Finanzunternehmen sollten:

• Addendum/Side-Letter aushandeln, die DORA-Anforderungen abdeckt

• Alternative Assurance nutzen (z.B. SOC2 Type II, ISO 27001, DORA-Attestierungen der Anbieter)

• Auf ESA-Empfehlungen achten, falls Anbieter als „critical" designiert wird

7. Typische Prüfungs-/Audit-Fragen (Checklist-Style)

Die folgende Liste enthält Fragen, die interne Revision, externe Prüfer oder Aufsicht (FMA) stellen könnten. Sie dienen als interne Prüfliste:

• Governance:

• Hat das Management Body die DORA-Strategie/Roadmap formell genehmigt (Vorstandsbeschluss)?

• Sind Rollen und Verantwortlichkeiten für ICT-Risiko und DORA klar definiert und kommuniziert?

• Gibt es einen CISO/IKT-Verantwortlichen mit ausreichenden Ressourcen und direktem Zugang zum Management Body?

• ICT Risk Management:

• Existiert eine dokumentierte ICT-Risiko-Policy, die in das Gesamt-Risikomanagement integriert ist?

• Wird ein vollständiges Asset-Inventar (ICT- und Informationsassets) geführt und regelmäßig aktualisiert?

• Wie werden ICT-Risiken bewertet (Methodik, Kriterien) und im Risikoregister erfasst?

• Werden ICT-Risiken regelmäßig (mind. jährlich) an das Management Body berichtet?

• Incident Management:

• Gibt es einen dokumentierten Incident-Management-Prozess mit klaren Eskalationswegen?

• Wie definieren Sie „Major ICT-related Incident"? Welche Schwellenwerte nutzen Sie?

• Wurde der FMA-Meldeprozess (Art. 19) bereits getestet (z.B. Tabletop Exercise)?

• Werden alle ICT-Incidents (auch Non-Major) in einem Log erfasst und ausgewertet?

• Testing:

• Existiert eine ICT-Testing-Strategie, die verschiedene Test-Typen (Vulnerability, Penetration, Scenario-based) abdeckt?

• Wie häufig werden Tests durchgeführt? Sind die Frequenzen risikoadäquat?

• Werden Test-Ergebnisse und Remediation-Pläne dokumentiert und nachgehalten?

• Falls zutreffend: Ist TLPT geplant/durchgeführt gemäß Art. 26 DORA?

• Third-Party Risk:

• Existiert eine ICT-Third-Party-Risk-Policy mit klarer Strategie und Risikoklassifizierung?

• Wie wird Due Diligence bei neuen ICT-Drittanbietern durchgeführt? Ist der Prozess dokumentiert?

• Gibt es ein kontinuierliches Monitoring-System für ICT-Drittanbieter (KPIs, SLA-Tracking)?

• Sind Exit-Strategien für kritische ICT-Drittanbieter definiert und getestet?

• Register of Information:

• Ist das Register of Information vollständig (alle ICT-Drittanbieter, inkl. Sub-Outsourcing)?

• Wie stellen Sie sicher, dass das Register aktuell ist (Prozess, Verantwortlichkeiten)?

• Wurde das Register fristgerecht (in Österreich: 31.03.2025) an die FMA übermittelt?

• Sind alle erforderlichen Felder gemäß Implementing Regulation (EU) 2024/2956 ausgefüllt?

• Contracting:

• Enthalten Ihre Verträge mit ICT-Drittanbietern die in Art. 30 DORA geforderten Elemente (Audit-Rechte, Exit, Sicherheit)?

• Wie handhaben Sie Standardverträge großer Anbieter (z.B. Cloud-Provider)?

• Gibt es ein Vertragsinventar und einen Prozess für regelmäßige Vertragsreviews?

• Management-Reporting:

• Erhält das Management Body regelmäßig Reports zu ICT-Risiko, Incidents, Testing, Third-Party-Monitoring?

• Wie werden Handlungsempfehlungen und Eskalationen an das Management kommuniziert?

• Schulung & Awareness:

• Sind alle relevanten Mitarbeiter (IT, Risk, Procurement, Management) über DORA-Anforderungen geschult?

• Gibt es einen regelmäßigen Schulungsplan?

• Kontinuierliche Verbesserung:

• Gibt es einen Lessons-Learned-Prozess nach Incidents, Tests, Audits?

• Wie wird sichergestellt, dass DORA-Compliance kontinuierlich verbessert wird (jährliche Reviews, Policy-Updates)?

• Dokumentation & Evidence:

• Sind alle relevanten Nachweise (Policies, Prozesse, Reports, Meeting-Protokolle) strukturiert und zugänglich?

• Könnten Sie innerhalb von 2 Wochen ein DORA-Evidence-Pack für die Aufsicht zusammenstellen?

• Oversight von „critical ICT third-party providers":

• Falls Sie kritische ICT-Drittanbieter nutzen, die von den ESAs als solche designiert wurden: Wie integrieren Sie Empfehlungen des Lead Overseers in Ihr Third-Party-Management?

Was tun als Nächstes? – 3 Optionen

Option 1: Self-Check (intern)

Vorgehen: Nutzen Sie die 10-Schritte-Roadmap und die Audit-Fragen in diesem Artikel, um intern ein Screening durchzuführen:

• Arbeiten Sie sich durch jeden Schritt und prüfen Sie, ob die typischen Artefakte vorhanden und aktuell sind.

• Dokumentieren Sie Gaps in einer Maßnahmenliste (inkl. Priorität, Verantwortlichkeit, Deadline).

• Präsentieren Sie die Ergebnisse dem Management Body mit Handlungsempfehlungen.

Geeignet für: Unternehmen, die bereits ein funktionierendes ICT-Risikomanagement haben und nur noch DORA-spezifische Anpassungen benötigen.

Zeitrahmen: 2-4 Wochen (je nach Größe und Komplexität).

Option 2: Workshop (intern oder mit externer Begleitung)

Vorgehen: Führen Sie einen fokussierten DORA-Readiness-Workshop durch (1-2 Tage), idealerweise mit Cross-Functional-Team (IT, Risk, Compliance, Procurement, Legal):

• Scope & Rollen klären: Wer ist betroffen, wer ist verantwortlich?

• Gap-Analyse: Wo stehen wir, was fehlt?

• Priorisierung: Welche Maßnahmen sind dringend (Minimal-Setup), welche mittelfristig (Reifegradsteigerung)?

• Roadmap & Timeline: Wann muss was fertig sein?

• Ressourcen & Budget: Welche internen/externen Ressourcen brauchen wir?

Output: Priorisierte Maßnahmenliste, Roadmap mit Meilensteinen, Budget-Planung, Risiko-Assessment (was passiert, wenn wir nicht rechtzeitig fertig werden).

Geeignet für: Unternehmen, die noch am Anfang stehen oder bei denen unklar ist, wie groß die Gaps sind.

Zeitrahmen: 1-2 Tage Workshop + 1 Woche Nachbereitung (Dokumentation, Management-Präsentation).

Option 3: Implementierung (schrittweise Umsetzung)

Vorgehen: Setzen Sie ein DORA-Implementierungsprojekt auf (intern oder mit externer Unterstützung):

• Projektsetup: Projektleitung, Steering Committee (mit Management-Body-Vertretung), Arbeitsgruppen (Governance, Incident, Testing, Third-Party)

• Schrittweise Umsetzung der 10 Schritte (siehe oben):

• Policies erstellen/aktualisieren

• Prozesse definieren und implementieren

• Register aufbauen/vervollständigen

• Verträge anpassen

• Testing durchführen

• Schulungen durchführen

• Reporting: Regelmäßige Status-Updates an Management Body

• Go-Live: Formelle Inbetriebnahme des Minimal-Setups

• Post-Go-Live: Kontinuierliche Verbesserung, jährliche Reviews

Geeignet für: Unternehmen mit größeren Gaps, die substanzielle Änderungen an Governance, Prozessen und Tools benötigen.

Zeitrahmen: 6-12 Monate (je nach Ausgangslage und Ressourcen).

9. FAQ (6-8 Fragen)

F1: Gilt DORA für mein FinTech / meine Versicherung / mein Zahlungsinstitut?

A: DORA gilt für nahezu alle beaufsichtigten Finanzunternehmen in der EU (siehe Art. 2 DORA). Konkret:

• FinTechs: Ja, wenn sie eine Finanzlizenz haben (z.B. Zahlungsinstitut, E-Geld-Institut, Crypto-Asset-Service-Provider nach MiCA, Wertpapierfirma).

• Versicherungen: Ja, alle Versicherungs- und Rückversicherungsunternehmen sowie Versicherungsvermittler.

• Zahlungsinstitute: Ja, alle Zahlungsinstitute und E-Geld-Institute (gemäß PSD2/EMD2).

Einzige Ausnahmen: Bestimmte Kleinstunternehmen (<10 Mitarbeiter, <2 Mio. EUR Umsatz/Bilanzsumme) haben erleichterte Anforderungen, bleiben aber im Scope. Mitgliedstaaten können zudem bestimmte kleine Institute gemäß CRD (Art. 2 Abs. 5 Ziff. 4-23 der Richtlinie 2013/36/EU) ausnehmen, aber dies ist optional.

F2: Gilt DORA auch für reine ICT-Dienstleister ohne Finanzlizenz?

A: Ja, aber indirekt und (für kritische Anbieter) direkt:

Indirekt: Alle ICT-Dienstleister, die Services an Finanzunternehmen erbringen, werden über vertragliche Pflichten in DORA-Compliance eingebunden (Art. 28, 30):

• Finanzunternehmen müssen von ihren ICT-Drittanbietern bestimmte Sicherheits-, Audit- und Exit-Regelungen fordern.

• ICT-Drittanbieter müssen diese vertraglichen Anforderungen erfüllen, um Finanzunternehmen als Kunden zu behalten.

Direkt: ICT-Drittanbieter, die von den ESAs als „critical ICT third-party providers" designiert werden, unterliegen einem europäischen Oversight Framework (Art. 31 ff.):

• Lead Overseer (EBA/ESMA/EIOPA) kann Informationen anfordern, Inspections durchführen, Empfehlungen aussprechen.

• Keine Lizenzpflicht, aber faktische Aufsicht.

Praxistipp: ICT-Dienstleister sollten sich auf DORA-Anforderungen vorbereiten, indem sie:

• DORA-konforme Vertragstemplates entwickeln

• Zertifizierungen (ISO 27001, SOC2) erlangen

• Transparenz über Sub-Outsourcing und Datenspeicherorte schaffen

F3: Welche Dokumente brauche ich für ein DORA Minimal-Compliance-Setup?

A: Kern-Dokumente eines Minimal-Setups:

• ICT-Risiko-Policy (genehmigt durch Management Body)

• Incident-Management-Policy/Procedure (inkl. FMA-Meldeprozess)

• ICT-Testing-Strategie/Plan

• ICT-Third-Party-Risk-Policy

• Register of Information (vollständig, aktuell)

• Vertragsvorlagen (mit DORA-Klauseln)

• Asset-Inventar (ICT- und Informationsassets)

• Risiko-Register (ICT-Risiken)

• Management-Reports (ICT-Risiko, Incidents, Testing, Third-Party)

• Schulungsnachweise (DORA-Awareness)

• Evidence-Pack (strukturierte Dokumentation aller Nachweise)

Hinweis: Die Dokumente müssen nicht umfangreich sein, aber substanziell und praxistauglich (keine „Papier-Compliance").

F4: Wie lange dauert es typischerweise, ein DORA-Minimal-Setup umzusetzen?

A: Die Dauer hängt stark von der Ausgangslage ab:

• Unternehmen mit gutem ICT-Risikomanagement (z.B. ISO 27001, EBA Outsourcing Guidelines): 3-6 Monate für DORA-spezifische Anpassungen (Register vervollständigen, Policies anpassen, FMA-Meldeprozess aufsetzen).

• Unternehmen mit fragmentiertem Setup: 6-12 Monate für substanzielle Änderungen (neue Policies, Prozess-Redesign, Tool-Implementierung, Vertragsanpassungen).

• Unternehmen ohne strukturiertes ICT-Risikomanagement: 12-18 Monate (Aufbau von Grund auf).

Kritische Faktoren für Geschwindigkeit:

• Verfügbarkeit interner Ressourcen (Personal, Budget)

• Management-Commitment

• Komplexität der ICT-Landschaft und Outsourcing-Struktur

• Notwendigkeit, Altverträge anzupassen

Praxistipp: Beginnen Sie mit den dringendsten Elementen (Register of Information, Incident-Reporting-Prozess, Management-Body-Beschluss) und arbeiten Sie sich schrittweise vor.

F5: Wie unterscheidet sich DORA von bestehenden Outsourcing-Regelungen und nationalen Vorgaben (z.B. FMA-Mindeststandards)?

A: DORA harmonisiert und erweitert bestehende Regelungen:

Gemeinsamkeiten:

• DORA baut auf EBA Outsourcing Guidelines (EBA/GL/2019/02) auf und übernimmt viele Prinzipien (Due Diligence, Monitoring, Exit-Strategien).

• Nationale Vorgaben (z.B. FMA-Mindeststandards zum Auslagerungsmanagement) sind weitgehend in DORA integriert.

Unterschiede/Erweiterungen:

• Breiterer Scope: DORA gilt für alle Finanzunternehmen EU-weit (nicht nur Banken), inkl. Versicherungen, Zahlungsinstitute, Krypto-Dienstleister.

• ICT-Fokus: DORA deckt umfassend alle ICT-Risiken ab (nicht nur Outsourcing), inkl. Incident Management, Testing, Resilience.

• Direkter Oversight für kritische ICT-Drittanbieter: DORA führt erstmals eine direkte Aufsicht kritischer ICT-Anbieter durch ESAs ein (bisher nur indirekt über Finanzunternehmen).

• Standardisierte Meldeprozesse: DORA führt EU-weit einheitliche Templates und Timelines für Major-Incident-Reporting ein.

• Testing-Anforderungen: DORA definiert explizite Testing-Anforderungen, inkl. TLPT für signifikante Institute.

Praxistipp: Unternehmen, die bereits EBA Outsourcing Guidelines oder FMA-Mindeststandards umsetzen, haben eine gute Basis. Sie müssen aber:

• Scope erweitern (alle ICT-Services, nicht nur Outsourcing)

• Register vervollständigen (alle ICT-Drittanbieter, inkl. Sub-Outsourcing)

• Incident-Reporting-Prozess anpassen (neue Templates, Timelines)

• Testing-Strategie erweitern (ggf. TLPT).

F6: Was ist ein „Major ICT-related Incident" und wie erkenne ich ihn?

A: Ein „Major ICT-related Incident" ist ein ICT-Incident, der bestimmte Schwellenwerte überschreitet und deshalb an die Aufsichtsbehörde (FMA) gemeldet werden muss (Art. 19 DORA).

Klassifizierungskriterien gemäß Delegated Regulation (EU) 2024/1772 (Art. 18 DORA):

• Auswirkung auf Verfügbarkeit, Integrität, Vertraulichkeit von Daten oder Services

• Anzahl betroffener Kunden/Gegenparteien (inkl. relevance)

• Geografische Reichweite der Auswirkung

• Dauer der Störung

• Kritikalität der betroffenen Services (z.B. Zahlungsverkehr, Handelsplattform)

Beispiele für „Major":

• Ausfall der Online-Banking-Plattform für >100.000 Kunden über >4 Stunden

• Datenleck mit Zugriff auf personenbezogene Daten von >10.000 Kunden

• Ransomware-Angriff, der kritische Geschäftsprozesse beeinträchtigt

• Ausfall der Zahlungsverarbeitung mit signifikanten finanziellen Auswirkungen

Praxistipp:

• Definieren Sie klare Schwellenwerte für Ihr Unternehmen (basierend auf DORA-Kriterien und Risikoprofil)

• Dokumentieren Sie die Klassifizierungslogik in der Incident-Management-Policy

• Trainieren Sie Incident-Response-Team und Management, um „Major" schnell zu erkennen

• Im Zweifelsfall (insbesondere in ersten Monaten nach DORA-Anwendungsbeginn): lieber melden (Initial Notification) und später korrigieren, als nicht zu melden.

F7: Was passiert, wenn ich DORA-Anforderungen nicht erfülle?

A: Mögliche Konsequenzen bei Nicht-Compliance:

• Aufsichtsmaßnahmen:

• FMA kann Verbesserungspläne mit Deadlines fordern

• On-Site-Inspections (gemeinsam mit OeNB) zur Überprüfung der ICT-Resilienz

• Anordnungen zur Nachbesserung spezifischer Punkte (z.B. Vervollständigung des Registers, Anpassung von Verträgen)

• Administrative Sanktionen:

• DORA ermöglicht Geldstrafen bei Verstößen (Höhe variiert je nach Verstoß und Mitgliedstaat)

• Veröffentlichung von Sanktionen (Reputationsschaden)

• Operative Konsequenzen:

• Ungeklärte ICT-Abhängigkeiten können zu operationellen Störungen führen (Ausfall kritischer Services, Datenverlust)

• Fehlende Exit-Strategien können im Falle eines Anbieterausfalls zu Business-Continuity-Problemen führen

• Geschäftliche Konsequenzen:

• Reputationsrisiken: Kunden und Partner verlieren Vertrauen bei bekannten Compliance-Mängeln

• Geschäftsbeziehungen: Finanzunternehmen, die selbst DORA-compliant sein müssen, könnten Verträge mit nicht-compliant ICT-Drittanbietern kündigen oder nicht verlängern

• Persönliche Konsequenzen:

• Management Body kann zur Rechenschaft gezogen werden (Art. 51 DORA: Sanktionen auch gegen natürliche Personen)

Praxistipp: Investieren Sie frühzeitig in ein solides Minimal-Setup. Die Kosten für Nicht-Compliance (Sanktionen, operative Störungen, Reputationsschäden) übersteigen typischerweise die Kosten für eine ordentliche Umsetzung.

F8: Muss ich mein Register of Information jährlich aktualisieren?

A: Ja, aber nicht nur jährlich:

• Erstmeldung: In Österreich war das vollständige Register erstmals bis 31. März 2025 an die FMA zu übermitteln (gemäß aktueller FMA-Kommunikation, Stand: Dezember 2024; Art. 28 Abs. 9 DORA, Implementing Regulation (EU) 2024/2956). In anderen EU-Mitgliedstaaten können die nationalen Fristen abweichen.

• Jährliche Aktualisierung: Danach ist das Register jährlich (jeweils zum 31. März) zu aktualisieren und an die FMA zu übermitteln.

• Ad-hoc-Aktualisierung: Bei wesentlichen Änderungen (z.B. neuer kritischer ICT-Drittanbieter, Kündigung eines wichtigen Vertrags, signifikante Änderung bei Sub-Outsourcing) sollte das Register sofort aktualisiert werden (interne Pflicht, Meldung an FMA gemäß Notification-Pflicht in Art. 28 Abs. 3 letzter Satz – Details unklar, FMA-Guidance erforderlich).

Praxistipp:

• Implementieren Sie einen Prozess für kontinuierliche Aktualisierung (nicht nur einmal jährlich „alles auf einmal")

• Definieren Sie klare Verantwortlichkeiten (wer pflegt das Register, wer genehmigt Änderungen)

• Nutzen Sie ein GRC-Tool oder Datenbank statt Excel, um Konsistenz und Nachvollziehbarkeit zu gewährleisten

10. Download-Paket

A) DORA Minimal-Compliance-Setup – 10-Schritte Checkliste (1 Seite):

Hinweis: Diese Checkliste ist ein Orientierungsrahmen. Sie stellt keine Rechtsberatung dar. Passen Sie die Checkliste an Ihr spezifisches Risikoprofil und Ihre Ausgangslage an.

B) DORA Evidence Pack – Muster-Inhaltsverzeichnis (strukturiert):

Dieses Inhaltsverzeichnis zeigt, wie ein typisches DORA Evidence Pack strukturiert sein könnte. Es dient als Vorlage für die interne Dokumentation und als Vorbereitung auf Audits/Aufsichtsprüfungen.

1. Governance & Organisation

1.1 DORA-Rollen und Verantwortlichkeiten

• Organisationshandbuch/Geschäftsordnung (Auszug: DORA-Verantwortlichkeiten)

• Job Description CISO/IKT-Verantwortliche

• Rollen-Matrix (RACI) für DORA-Umsetzung

1.2 Beschlüsse des Management Bodies

• Vorstandsbeschluss/GF-Beschluss: Genehmigung DORA-Strategie/Roadmap

• Vorstandsbeschluss/GF-Beschluss: Genehmigung ICT-Risiko-Policy

• Vorstandsbeschluss/GF-Beschluss: Budget für DORA-Umsetzung

• Protokolle relevanter Management-Meetings (z.B. Risk Committee, Audit Committee)

1.3 Organisations- und Eskalationspläne

• Eskalationswege für Major ICT-Incidents

• Kommunikationspläne (intern, extern, Aufsichtsbehörde, Kunden)

2. ICT Risk Management

2.1 Policy

• ICT Risk Management Policy (aktuelle Version, genehmigt durch Management Body)

• Change-History der Policy (frühere Versionen, Änderungsprotokoll)

2.2 Risiko-Register

• ICT-Risiko-Register (Excel/GRC-Tool-Export)

• Risikobewertungsmethodik (Beschreibung, Kriterien, Matrix)

2.3 Asset-Inventar

• ICT-Asset-Inventar (Excel/CMDB-Export)

• Informationsasset-Inventar (Datenklassifizierung)

2.4 Business Continuity & Disaster Recovery

• ICT Business Continuity Policy

• Disaster Recovery Plan

• Test-Reports von BCM/DR-Tests (z.B. jährlich)

2.5 Management-Reporting

• Management-Reports zu ICT-Risiko (Quartalsberichte, aktuellster Bericht)

• Präsentationen an Management Body (z.B. Risk Dashboard)

3. Incident Management & Reporting

3.1 Policies & Procedures

• Incident Management Policy

• Incident Reporting Procedure (inkl. FMA-Meldeprozess)

3.2 Incident-Log

• Incident-Log (alle Incidents, auch Non-Major) (Excel/Ticket-System-Export)

• Beispiel-Incident-Reports (Major und Non-Major)

3.3 FMA-Meldungen

• Übersicht über alle FMA-Meldungen (Major ICT-related Incidents)

• Kopien der Initial Notifications, Intermediate/Final Reports

3.4 Testing & Tabletop Exercises

• Protokolle von Tabletop Exercises (Incident-Response-Tests)

• Lessons-Learned-Reports nach Incidents

4. Testing & Resilience

4.1 Testing-Strategie

• ICT Testing Strategy/Plan

• Jährlicher Testing-Kalender

4.2 Test-Reports

• Vulnerability Scan Reports (z.B. quartalsweise)

• Penetration Test Reports (z.B. jährlich)

• Scenario-based Test Reports

• (Für signifikante Institute:) TLPT-Report und Remediation-Plan

4.3 Remediation-Tracking

• Tracking-Liste für Findings aus Tests (Status, Verantwortlichkeit, Deadline)

5. Third-Party Risk & Register of Information

5.1 Third-Party-Risk-Policy

• ICT Third-Party Risk Policy (aktuelle Version)

5.2 Register of Information

• Register of Information (vollständig, alle Felder gemäß ITS) (Excel/GRC-Tool-Export)

• Prozessbeschreibung für Register-Pflege

• Nachweise der FMA-Meldungen in Österreich (31.03.2025, danach jährlich)

5.3 Due Diligence

• Due-Diligence-Checkliste/Template

• Beispiel-Due-Diligence-Reports (für kritische Anbieter)

5.4 Monitoring

• KPI-Dashboard für ICT-Drittanbieter

• SLA-Reports (Beispiele)

• Incident-Reports von Drittanbietern (Beispiele)

5.5 Exit-Strategien

• Exit-Plan-Template

• Beispiel-Exit-Pläne (für kritische Anbieter)

• Nachweise von Exit-Plan-Tests

5.6 Oversight von „critical ICT third-party providers"

• Liste der genutzten kritischen Anbieter (falls zutreffend)

• Empfehlungen des Lead Overseers (falls erhalten)

• Dokumentation der Integration von Empfehlungen in Third-Party-Management

6. Contracting

6.1 Vertragstemplates

• Standard-Vertragsklauseln (Template/Playbook) für ICT-Services

• Verhandlungsplaybook

6.2 Vertragsinventar

• Liste aller ICT-Verträge (inkl. Status bzgl. DORA-Compliance)

• Priorisierungsliste für Vertragsanpassungen

6.3 Beispiel-Verträge

• Anonymisierte Beispiel-Verträge (DORA-compliant)

7. Schulung & Awareness

7.1 Schulungsplan

• DORA-Schulungsplan (jährlich)

• Schulungsmaterialien (Präsentationen, E-Learning-Module)

7.2 Teilnahmenachweise

• Teilnahmelisten (anonymisiert oder aggregiert)

• Schulungszertifikate (Beispiele)

7.3 Awareness-Kampagnen

• Interne Kommunikation (Newsletter, Intranet-Artikel) zu DORA

8. Management-Reporting & Continuous Improvement

8.1 Management-Reports

• Quartalsberichte: ICT-Risiko-Dashboard, Incident-Statistiken, Testing-Fortschritte, Third-Party-Monitoring, DORA-Compliance-Status

• Präsentationen an Management Body

8.2 Lessons-Learned-Prozess

• Prozessbeschreibung für Lessons Learned

• Beispiel-Lessons-Learned-Reports (nach Incidents, Tests, Audits)

8.3 Jährliche Reviews

• Jährlicher DORA-Compliance-Review-Report

• Policy-Update-Protokolle

9. Externe Audits & Assessments

9.1 Interne Revision

• Audit-Reports der Internen Revision zu DORA-Compliance (falls vorhanden)

9.2 Externe Prüfungen

• Reports externer Prüfer (z.B. Wirtschaftsprüfer, Sicherheitsberater) zu DORA-Compliance (falls vorhanden)

9.3 Aufsichtskommunikation

• Schreiben von/an FMA zu DORA (z.B. Nachfragen, Klarstellungen)

10. Projektdokumentation

10.1 DORA-Projekt

• Projekt-Charter

• Projekt-Plan (Roadmap, Meilensteine)

• Status-Reports

10.2 Gap-Analyse

• Gap-Analyse-Report (IST vs. SOLL)

• Maßnahmenliste (priorisiert, mit Status)

Hinweis: Dieses Inhaltsverzeichnis ist ein Vorschlag. Passen Sie es an Ihre spezifische Situation, Größe und Komplexität an. Nicht alle Punkte sind für alle Unternehmen relevant (z.B. TLPT nur für signifikante Institute gemäß den einschlägigen RTS zu Threat-Led Penetration Testing).

Sie möchten Ihr DORA-Compliance-Setup professionell aufbauen oder optimieren?

• Kostenloses 20-Minuten-Erstgespräch: Diskutieren Sie Ihre DORA-Herausforderungen und erhalten Sie eine erste Einschätzung (unverbindlich, ohne Verpflichtung).

• DORA Readiness-Assessment (Fixed Scope): Strukturierte Gap-Analyse anhand der 10 Schritte und Audit-Fragen, mit priorisierter Maßnahmenliste und Management-Präsentation (Dauer: 2-3 Wochen).

• Vendor-Contract Review unter DORA: Prüfung bestehender ICT-Verträge auf DORA-Compliance, Identifikation kritischer Lücken, Entwicklung von Nachverhandlungs-Strategien.

Kontaktieren Sie uns für ein unverbindliches Gespräch:

Jetzt Erstgespräch Vereinbaren

Über NEXORA Unternehmensberatung GmbH:

NEXORA Unternehmensberatung GmbH ist eine in Wien ansässige Boutique-Beratung mit Schwerpunkt auf Strategy, Compliance/RegTech, Market Entry und Digital Transformation für Finanzunternehmen und internationale Unternehmen in Österreich und der EU. Unser Team verbindet tiefes Regulatory-Know-how mit praktischer Umsetzungserfahrung, um Kunden nicht nur „Papier-Compliance", sondern substanzielle, praxistaugliche Lösungen zu liefern. Wir arbeiten eng mit unseren Kunden zusammen, um maßgeschneiderte Ansätze zu entwickeln, die sowohl regulatorische Anforderungen erfüllen als auch operationelle Effizienz steigern.

Disclaimer

Dieser Beitrag stellt keine Rechts- oder Steuerberatung dar und kann eine individuelle Beratung im Einzelfall nicht ersetzen. Die Inhalte basieren auf der aktuellen Rechtslage (Stand Dezember 2025) und öffentlich verfügbaren Quellen. Bei konkreten Fragestellungen zu DORA-Compliance sollten Sie qualifizierten fachlichen Rat (z.B. Rechtsanwälte mit Finanzmarktrechtsspezialisierung, spezialisierte Berater) einholen. Die Autoren übernehmen keine Haftung für die Vollständigkeit, Richtigkeit oder Aktualität der bereitgestellten Informationen.

Quellen & weiterführende Links

Dieser Artikel basiert ausschließlich auf Primärquellen und offiziellen Dokumenten:

• EUR-Lex – Regulation (EU) 2022/2554 (DORA):

https://eur-lex.europa.eu/eli/reg/2022/2554/oj

• Europäische Aufsichtsbehörden (ESAs) – DORA:

• EBA: https://www.eba.europa.eu/regulation-and-policy/digital-operational-resilience-act-dora

• ESMA: https://www.esma.europa.eu/policy-activities/digital-operational-resilience-act-dora

• EIOPA: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en

• Delegated and Implementing Regulations (RTS/ITS):

• Commission Delegated Regulation (EU) 2024/1772 (ICT incident classification)

• Commission Delegated Regulation (EU) 2025/301 (Incident reporting content and timelines)

• Commission Implementing Regulation (EU) 2025/302 (Templates for incident reporting)

• Commission Delegated Regulation (EU) 2024/1774 (ICT risk management framework)

• Commission Delegated Regulation (EU) 2024/1773 (ICT third-party service provider policy)

• Commission Implementing Regulation (EU) 2024/2956 (Register of information)

• Commission Delegated Regulation (EU) 2025/1190 (TLPT RTS)

• Commission Delegated Regulation (EU) 2025/532 (Subcontracting ICT services)

• FMA Österreich – DORA-Informationen:

• https://www.fma.gv.at/en/cross-sectoral-topics/dora/

• https://www.fma.gv.at/en/cross-sectoral-topics/dora/dora-managing-of-ict-third-party-risk/

• https://www.fma.gv.at/en/cross-sectoral-topics/dora/dora-ict-risk-management/

• https://www.fma.gv.at/en/banks/incoming-platform/reporting-circumstances-under-dora/

• FMA Publikationen: „Let's talk about supervision" (DORA-spezifische Ausgaben)

• TIBER-EU Framework (ECB):

https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html

• ESAs – Guide on Oversight Activities:

(Verfügbar über die ESA-Websites, siehe oben)

Hinweis: Die obigen Links waren zum Zeitpunkt der Erstellung (Dezember 2025) aktuell. Bitte prüfen Sie regelmäßig auf Updates, da DORA ein dynamisches Regelwerk ist und kontinuierlich durch neue RTS/ITS, Leitlinien und Q&As der ESAs und nationalen Aufsichtsbehörden ergänzt wird.

Dieser Artikel dient als Orientierung für die DORA-Compliance- Vorbereitung und ersetzt keine individuelle rechtliche oder regulatorische Beratung. Passen Sie die Inhalte an Ihr spezifisches Risikoprofil und Ihre organisatorische Struktur an.