Überblick
Der Digital Operational Resilience Act (DORA), Verordnung (EU) 2022/2554, gilt seit dem 17. Januar 2025 unmittelbar für einen breiten Kreis von Finanzunternehmen in der Europäischen Union. DORA verlangt, dass kritische und wichtige Funktionen auch bei Cyberangriffen, Systemausfällen, Datenproblemen oder Störungen von ICT-Drittdienstleistern beherrscht und wiederhergestellt werden können.
DORA ist kein reines IT-Compliance-Projekt. Das Leitungsorgan trägt die Gesamtverantwortung für das ICT-Risikomanagement. Geschäftsmodell, Outsourcing, Cloud-Nutzung, Incident Reporting, Resilienztests, Vertragsgestaltung, Konzentrationsrisiken und Wiederherstellung werden damit zu Managemententscheidungen.
Entscheidend ist nicht die Zahl der Richtlinien, sondern der Nachweis, dass Governance, Systeme, Daten, Dienstleister, Tests und Krisenprozesse im Zusammenspiel funktionieren.
DORA verlangt nachweisbare digitale Betriebsfähigkeit – vor, während und nach einer ICT-Störung.
DORA in fünf Minuten
| Managementfrage | Antwort |
|---|---|
| Seit wann gilt DORA? | Seit 17. Januar 2025. |
| Wer ist betroffen? | Ein breiter Kreis regulierter Finanzunternehmen sowie bestimmte ICT-Drittdienstleister im Oversight-Rahmen. |
| Kernbereiche? | ICT-Risikomanagement, Vorfallsmeldung, Resilienztests, ICT-Drittparteienrisiko und Informationsaustausch. |
| Verantwortung? | Das Leitungsorgan trägt die Gesamtverantwortung. |
| Größter Fehler? | DORA als Dokumentationsprojekt ohne operative Wirksamkeit behandeln. |
Warum DORA Chefsache ist
DORA verbindet digitale Betriebsfähigkeit direkt mit Aufsicht, Kundenvertrauen, Marktzugang und Stabilität. Für Geschäftsleitungen geht es um kritische Abhängigkeiten, schnelle Entscheidung und belastbare Nachweise.
| Dimension | CEO-Frage | DORA-Beitrag |
|---|---|---|
| Kritische Funktionen | Welche Leistungen müssen trotz schwerer ICT-Störung fortgeführt werden? | ICT-Risikomanagement, BIA, Continuity und Recovery. |
| Outsourcing | Welche Provider-Abhängigkeiten gefährden uns? | Register, Verträge, Exit und Konzentrationsanalyse. |
| Vorfall | Können wir korrekt klassifizieren und fristgerecht melden? | Incident Management und harmonisierte Meldung. |
| Wirksamkeit | Wie beweisen wir reale Resilienz? | Tests, TLPT, Audit und Lessons Learned. |
Executive Decision Guide
| Entscheidung | Leitfrage | Ergebnis |
|---|---|---|
| Governance | Wer entscheidet über ICT-Risiko, Ausnahmen und Eskalation? | Mandat, RACI und Board Reporting. |
| Kritikalität | Welche Funktionen, Assets und Services sind kritisch oder wichtig? | Freigegebte Klassifizierung und Abhängigkeitsmodell. |
| Provider | Welche ICT-Dienstleister sind geschäftskritisch? | Vollständiges Register, Due Diligence und Exit. |
| Reporting | Können wir Vorfälle korrekt melden? | End-to-End-Prozess, Datenmodell und Übungen. |
| Testing | Welche Tests beweisen reale Resilienz? | Mehrjähriges risikobasiertes Testprogramm. |
Anwendungsbereich und betroffene Unternehmen
DORA gilt für zahlreiche regulierte Finanzunternehmen. Die konkrete Anwendbarkeit hängt von Tätigkeit, Zulassung, Größe und sektorspezifischen Ausnahmen ab. Der Scope muss rechtlich und organisatorisch dokumentiert werden.
Proportionalität und vereinfachter Rahmen
Umfang und Intensität der Maßnahmen dürfen an Größe, Risikoprofil und Komplexität angepasst werden. Proportionalität bedeutet jedoch nicht Verzicht, sondern begründete Ausgestaltung.
Leitungsorgan und Governance
Das Leitungsorgan definiert, genehmigt, überwacht und verantwortet den ICT-Risikomanagementrahmen. Es genehmigt Strategien, Toleranzwerte, Continuity- und Recovery-Pläne, Budgets, Audits und wesentliche Providervereinbarungen.
Board Charter, RACI, Risikotoleranz, Policy-Set, Reporting und Entscheidungslog.
Arbeitsmittel unter Resources ansehenICT-Risikomanagementrahmen
Der Rahmen umfasst Governance, Strategien, Policies, Verfahren, Protokolle und Tools für Identifikation, Schutz, Erkennung, Reaktion, Wiederherstellung, Lernen und Kommunikation.
ICT-Assets, Funktionen und Abhängigkeiten
Kritische oder wichtige Funktionen müssen mit Anwendungen, Infrastrukturen, Daten, Standorten und Dienstleistern verknüpft werden. Ohne diese Sicht sind Risiko, Testing und Incident Response unzuverlässig.
Schutz und Prävention
DORA erwartet risikoadäquate Kontrollen für Konfiguration, Identitäten, Netzwerke, Schwachstellen, Changes, Verschlüsselung, Datenintegrität und physische Sicherheit.
Erkennung und Monitoring
Ungewöhnliche Aktivitäten, Leistungsprobleme und Störungen müssen zeitnah erkannt, korreliert, eskaliert und in ein gemeinsames Lagebild überführt werden.
Business Continuity und ICT Recovery
ICT-Business-Continuity sowie Reaktions- und Wiederherstellungspläne müssen kritische Funktionen, Aktivierung, Recovery-Ziele, Kommunikation, Datenintegrität und alternative Kapazitäten abdecken.
Backups und Wiederherstellbarkeit
Backups müssen geschützt, getrennt und getestet sein. Maßstab ist die Wiederherstellbarkeit kritischer Services, nicht der erfolgreiche Backup-Job.
ICT-Vorfallmanagement
Ein einheitlicher Prozess muss Erkennung, Aufzeichnung, Klassifizierung, Eskalation, Reaktion, Kommunikation, Meldung und Nachbereitung abdecken.
Klassifizierung von Vorfällen
Die Klassifizierung berücksichtigt harmonisierte Kriterien wie Kunden, Dauer, geografische Wirkung, wirtschaftliche Auswirkung, Datenverlust und Kritikalität betroffener Services.
Meldung schwerwiegender ICT-Vorfälle
Schwerwiegende Vorfälle werden über standardisierte Erst-, Zwischen- und Abschlussmeldungen berichtet. Die größte Herausforderung ist die rechtzeitige Verfügbarkeit belastbarer Daten.
Klassifizierung, Mindestdatensatz, Eskalation, Meldung und Übungsszenarien.
Arbeitsmittel unter Resources ansehenDigital Operational Resilience Testing
Das Testprogramm kann Scans, Szenario-, Performance-, End-to-End-, Penetrations- und Wiederherstellungstests umfassen. Findings müssen bis zum wirksamen Abschluss verfolgt werden.
Threat-Led Penetration Testing
Ausgewählte Unternehmen müssen realitätsnahe TLPT gegen kritische Produktionssysteme durchführen, grundsätzlich mindestens alle drei Jahre, sofern die Aufsicht nichts anderes festlegt.
Scope, Control Team, Provider-Steuerung, Remediation und Board Reporting.
Arbeitsmittel unter Resources ansehenICT-Drittparteienrisiko
Outsourcing überträgt Aufgaben, nicht Verantwortung. Vor Vertragsabschluss sind Risiko, Kritikalität, Standort, Konzentration, Unterauftragnehmer, Auditierbarkeit und Exit zu bewerten.
Register of Information
Das strukturierte Register aller ICT-Dienstleistungsverträge unterstützt Aufsicht, Provider-Steuerung, Kritikalitätsbewertung und Konzentrationsanalyse.
Datenmodell, Provider-Hierarchie, Vertragsmapping und Qualitätskontrollen.
Arbeitsmittel unter Resources ansehenVertragliche Mindestanforderungen
Verträge müssen Leistungsumfang, Standorte, Daten, Vorfallsunterstützung, Audit, Kündigung und Exit abdecken. Für kritische Funktionen gelten erweiterte Anforderungen.
Unterauftragnehmer und ICT-Lieferketten
Subcontracting beeinflusst Transparenz, Kontrollrechte und Exitfähigkeit. Wesentliche Änderungen benötigen definierte Informations-, Bewertungs- und Entscheidungsprozesse.
Konzentrationsrisiken
Abhängigkeiten von einzelnen Providern, Regionen, Plattformen oder Subcontracting-Ketten können mehrere kritische Funktionen gleichzeitig treffen.
Exit-Strategien
Exit-Strategien müssen realistisch, finanziert und testbar sein. Daten, Technologie, Wissen, Alternativen und Übergangszeit entscheiden über die tatsächliche Exitfähigkeit.
Kritische ICT-Drittdienstleister und EU-Oversight
Als kritisch eingestufte Provider unterliegen einem EU-weiten Oversight-Rahmen. Finanzunternehmen bleiben dennoch für ihre eigenen Risiken und Verträge verantwortlich.
Audit, Assurance und Evidenz
Aufsicht und Prüfer erwarten die nachvollziehbare Verbindung von Risiko, Entscheidung, Umsetzung, Monitoring, Test, Finding und Verbesserung.
Executive Dashboard und KPIs
| KPI | Managementfrage |
|---|---|
| Critical Function Coverage | Sind Funktionen, Assets, Provider und Recovery-Ziele verbunden? |
| Major Incident Readiness | Kann das Unternehmen klassifizieren und fristgerecht melden? |
| Recovery Test Success | Welche kritischen Services wurden innerhalb ihrer Ziele wiederhergestellt? |
| Register Data Quality | Wie vollständig und konsistent ist das Register? |
| Provider Concentration | Wo bestehen nicht akzeptable Abhängigkeiten? |
| Open High Findings | Wie lange bleiben wesentliche Findings offen? |
Roadmap von 30 Tagen bis 24 Monate
| Phase | Schwerpunkt | Ergebnis |
|---|---|---|
| 0–30 Tage | Scope, Governance, kritische Funktionen, Register- und Reporting-Gaps. | Mandat und Sofortmaßnahmen. |
| 31–90 Tage | Policies, Incident Reporting, Provider-Inventar, Testplan und KPIs. | Funktionsfähiges Operating Model. |
| 4–6 Monate | Datenqualität, Verträge, Recovery, Tests und Audit Trail. | Messbare Wirksamkeit. |
| 7–12 Monate | Konzentration, Exit, Übungen und Kontrollmonitoring. | Erhöhte Resilienz. |
| 13–24 Monate | Automatisierung, TLPT-Reife und gruppenweite Integration. | Dauerhaftes Resilience-Modell. |
Zusammenspiel mit anderen Frameworks
| Framework | Zusammenspiel |
|---|---|
| NIS2 | DORA ist für viele Finanzunternehmen der sektorspezifische ICT-Risikorechtsrahmen. |
| ISO/IEC 27001 | Das ISMS liefert Governance und Kontrollen, ersetzt aber DORA-spezifische Pflichten nicht. |
| ISO 22301 | BCMS, BIA, Krise und Recovery unterstützen operationale Resilienz. |
| NIST CSF 2.0 | NIST unterstützt outcome-basierte Steuerung; DORA definiert regulatorische Pflichten. |
| CRA | CRA adressiert Produktsicherheit; DORA die Resilienz von Finanzunternehmen. |
Typische Managementfehler
- DORA als IT- oder Rechtsprojekt ohne Board Ownership behandeln.
- Das Register erst kurz vor einer Meldung rekonstruieren.
- Verträge ergänzen, ohne reale Audit- und Exitfähigkeit zu schaffen.
- Incident Reporting ohne Datenmodell und Übungen organisieren.
- Tests durchführen, aber Findings nicht schließen.
- Kritische Funktionen nicht mit Assets und Providern verknüpfen.
- Proportionalität als pauschale Ausnahme verstehen.
Wie reife Unternehmen vorgehen
- DORA in Risk, Security, BCM, Procurement und Audit integrieren.
- Ein gemeinsames Datenmodell für Funktionen, Assets, Provider, Verträge, Vorfälle und Tests etablieren.
- Board Reporting auf kritische Abhängigkeiten und Restrisiken fokussieren.
- Incident Reporting und Recovery regelmäßig üben.
- Registerdaten kontinuierlich pflegen.
- Exitfähigkeit in Architektur- und Einkaufsentscheidungen verankern.
DORA Toolkits und Self-Assessment
DORA Governance Toolkit
Board Charter, Policies, RACI, Risikotoleranz und Reporting.
Incident Reporting Toolkit
Klassifizierung, Datenmodell, Eskalation und Meldung.
Register of Information Toolkit
Provider-Hierarchie, Verträge und Datenqualität.
ICT Third-Party Risk Toolkit
Due Diligence, Verträge, Konzentration und Exit.
Resilience Testing Toolkit
Testprogramm, Findings, Retests und TLPT Readiness.
Executive DORA Self-Assessment
Fragen, Scoring, Evidenz und Auswertungsprompts.
Häufige Fragen
Was ist DORA?
Kurzantwort: Die EU-Verordnung über digitale operationale Resilienz im Finanzsektor.
Praktische Einordnung: Sie harmonisiert ICT-Risiko, Vorfälle, Tests und Drittparteienrisiko.
Managementempfehlung: Behandeln Sie DORA als integriertes Resilienzprogramm.
Seit wann gilt DORA?
Kurzantwort: Seit 17. Januar 2025.
Praktische Einordnung: Die Anforderungen sind unmittelbar anwendbar.
Managementempfehlung: Steuern Sie offene Lücken als laufendes Risiko.
Wer ist betroffen?
Kurzantwort: Ein breiter Kreis regulierter Finanzunternehmen.
Praktische Einordnung: Die Anwendbarkeit hängt von Tätigkeit, Zulassung und Ausnahmen ab.
Managementempfehlung: Dokumentieren Sie den Scope.
Gilt DORA für ICT-Dienstleister?
Kurzantwort: Teilweise indirekt und für kritische Provider auch im Oversight-Rahmen.
Praktische Einordnung: Providerpflichten wirken meist über Finanzkunden.
Managementempfehlung: Bereiten Sie DORA-fähige Verträge und Evidenz vor.
Ist DORA nur Cybersecurity?
Kurzantwort: Nein.
Praktische Einordnung: DORA verbindet Security mit Betriebsfähigkeit, Recovery, Testing und Providersteuerung.
Managementempfehlung: Organisieren Sie DORA nicht nur beim CISO.
Wer trägt die Gesamtverantwortung?
Kurzantwort: Das Leitungsorgan.
Praktische Einordnung: Es muss Rahmenwerk, Strategie und wesentliche Entscheidungen genehmigen.
Managementempfehlung: Etablieren Sie nachweisbare Board Governance.
Muss der Vorstand geschult werden?
Kurzantwort: Ja, regelmäßig und angemessen.
Praktische Einordnung: DORA verlangt ausreichendes Wissen über ICT-Risiken.
Managementempfehlung: Planen Sie rollenbezogene Schulungen.
Was bedeutet Proportionalität?
Kurzantwort: Anpassung an Größe, Risiko und Komplexität.
Praktische Einordnung: Kernverantwortung entfällt nicht.
Managementempfehlung: Dokumentieren Sie die Begründung.
Was ist der ICT-Risikomanagementrahmen?
Kurzantwort: Das Gesamtsystem für ICT-Risiken.
Praktische Einordnung: Er umfasst Governance, Schutz, Erkennung, Reaktion und Recovery.
Managementempfehlung: Verbinden Sie Framework und operative Evidenz.
Was ist eine kritische oder wichtige Funktion?
Kurzantwort: Eine Funktion, deren Störung wesentliche Auswirkungen hätte.
Praktische Einordnung: Die Einstufung steuert strengere Anforderungen.
Managementempfehlung: Nutzen Sie ein einheitliches Modell.
Müssen ICT-Assets inventarisiert werden?
Kurzantwort: Ja.
Praktische Einordnung: Ohne Assetsicht sind Risiko und Incident Response unzuverlässig.
Managementempfehlung: Verbinden Sie Assets mit Funktionen.
Welche Rolle spielt Business Continuity?
Kurzantwort: Eine zentrale Rolle.
Praktische Einordnung: ICT-Continuity und Recovery müssen kritische Funktionen stützen.
Managementempfehlung: Integrieren Sie DORA und BCMS.
Reichen Backups aus?
Kurzantwort: Nein.
Praktische Einordnung: DORA verlangt Wiederherstellungsfähigkeit.
Managementempfehlung: Testen Sie End-to-End-Recovery.
Was ist Cyber Recovery?
Kurzantwort: Vertrauenswürdige Wiederherstellung nach Cyberangriffen.
Praktische Einordnung: Sie berücksichtigt kompromittierte Identitäten, Systeme und Backups.
Managementempfehlung: Planen Sie Clean Recovery.
Was ist ein ICT-bezogener Vorfall?
Kurzantwort: Ein Ereignis mit Auswirkung auf ICT-Sicherheit oder -Verfügbarkeit.
Praktische Einordnung: Nicht jeder Vorfall ist meldepflichtig.
Managementempfehlung: Definieren Sie Triage und Erfassung.
Wann ist ein Vorfall schwerwiegend?
Kurzantwort: Wenn harmonisierte Kriterien und Schwellenwerte erfüllt sind.
Praktische Einordnung: Kunden, Dauer, Daten, Wirtschaft und Kritikalität zählen.
Managementempfehlung: Automatisieren Sie die Klassifizierung soweit möglich.
Wie läuft die DORA-Meldung ab?
Kurzantwort: Über Erst-, Zwischen- und Abschlussmeldung.
Praktische Einordnung: Datenqualität und Freigaben sind die größte Herausforderung.
Managementempfehlung: Üben Sie den Prozess.
Das passende DORA Toolkit enthält editierbare Vorlagen, Register, Entscheidungsmatrizen, Checklisten und Auswertungshilfen.
Passende Arbeitsmittel unter Resources ansehenWas ist eine erhebliche Cyberbedrohung?
Kurzantwort: Eine Bedrohung mit potenziell hoher Auswirkung.
Praktische Einordnung: Sie kann freiwillig gemeldet werden.
Managementempfehlung: Definieren Sie Kriterien und Freigaben.
Wer meldet an die Aufsicht?
Kurzantwort: Das Finanzunternehmen über den vorgesehenen Weg.
Praktische Einordnung: Interne Aufgaben können delegiert werden.
Managementempfehlung: Definieren Sie Owner und Vertretung.
Müssen Vorfälle geübt werden?
Kurzantwort: Praktisch ja.
Praktische Einordnung: Ungeübte Prozesse scheitern an Daten und Entscheidungen.
Managementempfehlung: Führen Sie Tabletop- und Technikübungen durch.
Was ist Digital Operational Resilience Testing?
Kurzantwort: Ein risikobasiertes Testprogramm.
Praktische Einordnung: Es umfasst mehrere Testarten.
Managementempfehlung: Steuern Sie Findings bis zum Abschluss.
Was ist TLPT?
Kurzantwort: Ein realitätsnaher fortgeschrittener Angriffstest.
Praktische Einordnung: Nur ausgewählte Unternehmen sind verpflichtet.
Managementempfehlung: Bereiten Sie Governance und Scope vor.
Das passende DORA Toolkit enthält editierbare Vorlagen, Register, Entscheidungsmatrizen, Checklisten und Auswertungshilfen.
Passende Arbeitsmittel unter Resources ansehenWie oft findet TLPT statt?
Kurzantwort: Grundsätzlich mindestens alle drei Jahre.
Praktische Einordnung: Die Aufsicht kann abweichend entscheiden.
Managementempfehlung: Verankern Sie TLPT in der Mehrjahresplanung.
Was ist das Register of Information?
Kurzantwort: Das strukturierte Register aller ICT-Dienstleistungsverträge.
Praktische Einordnung: Es ist Kern von Providersteuerung und Aufsicht.
Managementempfehlung: Betreiben Sie es kontinuierlich.
Das passende DORA Toolkit enthält editierbare Vorlagen, Register, Entscheidungsmatrizen, Checklisten und Auswertungshilfen.
Passende Arbeitsmittel unter Resources ansehenMuss jeder ICT-Vertrag ins Register?
Kurzantwort: Grundsätzlich sind ICT-Vereinbarungen zu erfassen.
Praktische Einordnung: Detailtiefe folgt den technischen Standards.
Managementempfehlung: Definieren Sie vollständige Datenquellen.
Wer besitzt das Register?
Kurzantwort: Ein klarer fachlicher Owner.
Praktische Einordnung: Dezentrale Daten müssen zentral qualitätsgesichert werden.
Managementempfehlung: Definieren Sie Data Ownership.
Welche Datenqualität erwartet die Aufsicht?
Kurzantwort: Vollständige, konsistente und valide Daten.
Praktische Einordnung: Fehlerhafte IDs und Hierarchien erschweren Meldung und Analyse.
Managementempfehlung: Nutzen Sie Validierungsregeln.
Was sind kritische ICT-Drittdienstleister?
Kurzantwort: Von den ESAs für Oversight eingestufte Provider.
Praktische Einordnung: Die Einstufung entbindet Kunden nicht.
Managementempfehlung: Steuern Sie das eigene Risiko weiter.
Was ist Konzentrationsrisiko?
Kurzantwort: Abhängigkeit von wenigen Providern, Regionen oder Plattformen.
Praktische Einordnung: Mehrere Funktionen können gleichzeitig betroffen sein.
Managementempfehlung: Berichten Sie Konzentration auf Board-Ebene.
Das passende DORA Toolkit enthält editierbare Vorlagen, Register, Entscheidungsmatrizen, Checklisten und Auswertungshilfen.
Passende Arbeitsmittel unter Resources ansehenWelche Vertragsklauseln verlangt DORA?
Kurzantwort: Unter anderem Leistung, Standort, Daten, Vorfälle, Audit und Exit.
Praktische Einordnung: Für kritische Funktionen gelten erweiterte Anforderungen.
Managementempfehlung: Nutzen Sie standardisierte Klauseln.
Das passende DORA Toolkit enthält editierbare Vorlagen, Register, Entscheidungsmatrizen, Checklisten und Auswertungshilfen.
Passende Arbeitsmittel unter Resources ansehenDarf ein Provider Auditrechte beschränken?
Kurzantwort: Nur in vertretbaren Grenzen.
Praktische Einordnung: Pauschale Einschränkungen können DORA unterlaufen.
Managementempfehlung: Verhandeln Sie wirksame Rechte.
Was ist bei Cloud-Verträgen wichtig?
Kurzantwort: Regionen, Daten, Subcontracting, Portabilität, Konzentration und Exit.
Praktische Einordnung: Risiken sind technisch und vertraglich verflochten.
Managementempfehlung: Bewerten Sie Architektur und Vertrag gemeinsam.
Was verlangt DORA beim Subcontracting?
Kurzantwort: Transparenz und Steuerung wesentlicher Unterauftragnehmer.
Praktische Einordnung: Änderungen können das Risiko verändern.
Managementempfehlung: Definieren Sie Informations- und Entscheidungsrechte.
Braucht jedes Institut eine Exit-Strategie?
Kurzantwort: Für relevante ICT-Services ja.
Praktische Einordnung: Exit muss ohne unvertretbare Störung möglich sein.
Managementempfehlung: Testen Sie wesentliche Annahmen.
Das passende DORA Toolkit enthält editierbare Vorlagen, Register, Entscheidungsmatrizen, Checklisten und Auswertungshilfen.
Passende Arbeitsmittel unter Resources ansehenMuss Exit getestet werden?
Kurzantwort: Nicht immer als Vollmigration, aber realistisch bewertet.
Praktische Einordnung: Ungetestete Annahmen sind schwach.
Managementempfehlung: Nutzen Sie Tabletop- und Portabilitätstests.
Welche Rolle spielt Procurement?
Kurzantwort: Eine zentrale Rolle.
Praktische Einordnung: Due Diligence, Verträge, Register und Exit liegen dort mit.
Managementempfehlung: Etablieren Sie gemeinsame Freigaben.
Welche Rolle spielt der CIO?
Kurzantwort: ICT-Architektur, Betrieb, Recovery und Providerleistung.
Praktische Einordnung: DORA verbindet Technik und Business.
Managementempfehlung: Machen Sie Resilienz zum Architekturprinzip.
Welche Rolle spielt der CISO?
Kurzantwort: Security-Risiko, Erkennung, Incident Response und Testing.
Praktische Einordnung: DORA erweitert den Fokus auf Betriebsfähigkeit.
Managementempfehlung: Integrieren Sie Security und Resilience.
Welche Rolle spielt der CRO?
Kurzantwort: Unabhängige Risikosicht und Aggregation.
Praktische Einordnung: ICT-Risiko gehört ins Enterprise Risk.
Managementempfehlung: Nutzen Sie eine gemeinsame Taxonomie.
Welche Rolle spielt die interne Revision?
Kurzantwort: Unabhängige Prüfung von Governance und Wirksamkeit.
Praktische Einordnung: DORA verlangt risikobasiertes Audit.
Managementempfehlung: Prüfen Sie Datenketten end-to-end.
Wie oft sollte das Board berichten?
Kurzantwort: Regelmäßig und bei kritischen Ereignissen sofort.
Praktische Einordnung: Quartalsweise ist häufig sinnvoll.
Managementempfehlung: Berichten Sie Entscheidungen und Restrisiken.
Welche KPIs sind sinnvoll?
Kurzantwort: Coverage, Recovery, Incident Readiness, Registerqualität, Konzentration und Findings Aging.
Praktische Einordnung: Aktivitätszahlen reichen nicht.
Managementempfehlung: Berichten Sie Trends und Schwellenwerte.
Das passende DORA Toolkit enthält editierbare Vorlagen, Register, Entscheidungsmatrizen, Checklisten und Auswertungshilfen.
Passende Arbeitsmittel unter Resources ansehenWie verbindet man DORA mit ISO 27001?
Kurzantwort: ISO 27001 liefert Governance und Controls.
Praktische Einordnung: DORA-spezifische Pflichten müssen ergänzt werden.
Managementempfehlung: Nutzen Sie ein gemeinsames Control Framework.
Wie verbindet man DORA mit ISO 22301?
Kurzantwort: ISO 22301 unterstützt BIA, Krise und Recovery.
Praktische Einordnung: DORA vertieft ICT-Anforderungen.
Managementempfehlung: Integrieren Sie beide Systeme.
Wie verhält sich DORA zu NIS2?
Kurzantwort: DORA ist für viele Finanzunternehmen der sektorspezifische ICT-Rahmen.
Praktische Einordnung: Die Abgrenzung ist unternehmensbezogen.
Managementempfehlung: Dokumentieren Sie Schnittstellen.
Wie lange dauert die Umsetzung?
Kurzantwort: Mehrere Monate bis Jahre.
Praktische Einordnung: Daten- und Providerprozesse brauchen Zeit.
Managementempfehlung: Arbeiten Sie in priorisierten Wellen.
Was kostet DORA?
Kurzantwort: Abhängig von Reifegrad, Providerlandschaft und Testing.
Praktische Einordnung: Dauerhafte Betriebsfähigkeit kostet mehr als Dokumentation.
Managementempfehlung: Erstellen Sie ein TCO-Modell.
Was ist der häufigste Fehler?
Kurzantwort: DORA als einmaliges Compliance-Projekt behandeln.
Praktische Einordnung: Die Verordnung verlangt laufende Fähigkeiten.
Managementempfehlung: Etablieren Sie ein Operating Model.
Wo sollte ein Unternehmen beginnen?
Kurzantwort: Mit Scope, Governance, kritischen Funktionen, Register- und Incident-Gaps.
Praktische Einordnung: Diese Themen steuern die übrige Umsetzung.
Managementempfehlung: Starten Sie mit einer Baseline.
Das passende DORA Toolkit enthält editierbare Vorlagen, Register, Entscheidungsmatrizen, Checklisten und Auswertungshilfen.
Passende Arbeitsmittel unter Resources ansehenWas ist die wichtigste erste Managemententscheidung?
Kurzantwort: Wer DORA steuert und welche Funktionen priorisiert sind.
Praktische Einordnung: Ohne Governance und Priorität bleibt das Programm fragmentiert.
Managementempfehlung: Mandatieren Sie Sponsor und Owner.
Das passende DORA Toolkit enthält editierbare Vorlagen, Register, Entscheidungsmatrizen, Checklisten und Auswertungshilfen.
Passende Arbeitsmittel unter Resources ansehenGlossar
| Begriff | Bedeutung |
|---|---|
| DORA | Digital Operational Resilience Act. |
| Critical or Important Function | Funktion, deren Störung wesentliche Auswirkungen hätte. |
| Register of Information | Register der ICT-Dienstleistungsverträge. |
| TLPT | Threat-Led Penetration Testing. |
| CTPP | Critical ICT Third-Party Provider. |
Primärquellen
Maßgeblich bleiben DORA, die ergänzenden Rechtsakte, ESA-Leitlinien und die Anforderungen der zuständigen Aufsicht.