DORA Anforderungen — Die 5 Säulen im Überblick

Die DORA-Verordnung (EU 2022/2554) definiert fünf zentrale Anforderungssäulen für die digitale operationelle Resilienz von Finanzunternehmen. Wer DORA Anforderungen sauber umsetzen will, sollte nicht mit Einzelpflichten beginnen, sondern mit einem Gesamtbild aus IKT-Risikomanagement, Vorfallmanagement, Resilienztests, Drittparteiensteuerung und strukturiertem Informationsaustausch gemäß Art. 5 bis 45.

DORA ist seit dem 17. Januar 2025 anwendbar und richtet sich an einen breiten Kreis beaufsichtigter Finanzunternehmen, von Kreditinstituten über Zahlungsinstitute bis zu Versicherern, Wertpapierfirmen und bestimmten Kryptodienstleistern. Der praktische Kern der Verordnung ist einfach: Digitale Resilienz muss nicht nur technisch vorhanden sein, sondern organisatorisch gesteuert, nachweisbar dokumentiert und gegenüber Aufsicht, interner Revision und Geschäftsleitung belastbar erklärt werden.

Wenn Sie zuerst die Gesamtverordnung einordnen möchten, ist der Überblick zur DORA-Verordnung der beste Einstieg. Für den operativen Teilvorfallprozess lohnt sich ergänzend der Beitrag zu DORA Incident Reporting, und für die Lieferkette der vertiefende Artikel zu DORA und IT-Dienstleistern. Wenn Sie das Thema in Ihr Pflichtprogramm für Fachbereiche, IT und Compliance übersetzen wollen, führt die DORA-Schulung den nächsten sinnvollen Schritt aus.

Die 5 DORA-Säulen auf einen Blick

DORA Anforderungen lassen sich in fünf Säulen gliedern, weil die Verordnung genau so vom internen Kontrollrahmen bis zur Zusammenarbeit mit externen Partnern aufgebaut ist. Wer diese Logik versteht, kann Projekte besser priorisieren, Verantwortlichkeiten sauber zuweisen und gegenüber der BaFin klar begründen, warum bestimmte Maßnahmen zuerst umgesetzt wurden.

Die entscheidende Managementfrage lautet deshalb nicht, welche Säule „wichtiger“ ist, sondern welche Abhängigkeiten bestehen. Ohne ein funktionierendes IKT-Risikomanagement bleiben Vorfallklassifizierung und Testprogramme unscharf; ohne Drittparteiensteuerung entstehen blinde Flecken in kritischen Services; ohne Vorfallmanagement liefern Resilienztests keinen belastbaren Lernkreislauf.

Säule 1 — IKT-Risikomanagement (Art. 5-16)

Die erste und wichtigste DORA-Säule ist das IKT-Risikomanagement, weil Art. 5 bis 16 den operativen Steuerungsrahmen für alle weiteren Pflichten bilden. DORA verlangt hier kein loses Set technischer Maßnahmen, sondern ein Governance-System, das von der Geschäftsleitung verantwortet, dokumentiert und laufend fortentwickelt wird.

Art. 5 legt fest, dass das Leitungsorgan den IKT-Risikomanagementrahmen definiert, genehmigt, überwacht und für dessen Umsetzung verantwortlich ist. Praktisch bedeutet das: DORA ist kein reines IT-Projekt. Vorstand oder Geschäftsführung müssen Leitlinien, Risikoappetit, Eskalationswege und Kontrollmechanismen aktiv tragen. Wer die Verantwortung nur an IT-Sicherheit oder Informationssicherheit delegiert, verfehlt die Grundlogik der Verordnung.

Art. 6 verlangt einen internen, soliden und umfassend dokumentierten IKT-Risikomanagementrahmen. Dieser Rahmen muss kritische oder wichtige Funktionen schützen, sämtliche relevanten IKT-Assets erfassen und in nachvollziehbare Prozesse für Identifikation, Schutz, Erkennung, Reaktion und Wiederherstellung übersetzt werden. Für viele Institute bedeutet das eine Konsolidierung bestehender Vorgaben aus BAIT, VAIT, MaRisk, ZAIT oder internen Auslagerungsrichtlinien in ein klar auf DORA ausgerichtetes Zielmodell.

Die Artikel 7 bis 15 konkretisieren die Mindestbestandteile dieses Rahmens:

1. Art. 7 fokussiert auf IKT-Systeme, Protokolle und Tools.
2. Art. 8 verlangt die Identifikation relevanter Informationsbestände, IKT-Assets und Abhängigkeiten.
3. Art. 9 verpflichtet zu Schutz- und Präventionsmaßnahmen.
4. Art. 10 verlangt geeignete Erkennungsmechanismen.
5. Art. 11 regelt Reaktion und Wiederherstellung.
6. Art. 12 fordert belastbare Backup-, Restore- und Recovery-Verfahren.
7. Art. 13 verlangt Lernen und Weiterentwicklung nach Störungen und Tests.
8. Art. 14 adressiert die Krisen- und Kommunikationssteuerung.
9. Art. 15 schafft die Grundlage für weitere Harmonisierung technischer Methoden.

Die operative Konsequenz ist klar: Ein Institut braucht nicht nur Policies, sondern eine belastbare Asset-Sicht, Notfallmechanik, Entscheidungswege und Management-Transparenz. Typische Mindestmaßnahmen sind ein vollständiges Inventar geschäftskritischer Anwendungen, eine Zuordnung zu kritischen oder wichtigen Funktionen, definierte RTO- und RPO-Werte, dokumentierte Notfall- und Kommunikationspläne, abgestufte Eskalationsstufen sowie regelmäßige Berichte an das Leitungsorgan.

Besonders relevant ist Art. 12, weil hier Backup- und Wiederherstellung nicht als reine Technikfrage behandelt werden. DORA erwartet Verfahren, mit denen Daten und Systeme innerhalb vertretbarer Zeit wiederhergestellt werden können. Häuser, die Backups zwar technisch erzeugen, aber Wiederanlauf, Integritätsprüfung und Entscheidungslogik nicht testen, erfüllen den materiellen Anspruch dieser Vorschrift nur teilweise.

Art. 13 bringt einen Punkt auf den Tisch, der in Prüfungen oft unterschätzt wird: Lernen ist Pflicht. Institute müssen aus Vorfällen, Testresultaten und Beinahe-Ausfällen nachvollziehbare Verbesserungen ableiten. DORA misst Reife deshalb nicht an der Behauptung „wir hatten keinen großen Vorfall“, sondern an der Frage, ob Erkenntnisse systematisch in Kontrollen, Architektur und Governance zurückfließen.

Art. 16 schließlich eröffnet für bestimmte Finanzunternehmen einen vereinfachten IKT-Risikomanagementrahmen. Das ist keine generelle Ausnahme, sondern eine proportionale Ausgestaltung. Kleine oder weniger komplexe Institute können nicht alle Elemente in derselben Tiefe wie ein grenzüberschreitender Konzern aufbauen, müssen aber weiterhin ein funktionsfähiges und prüfbares Kontrollsystem vorhalten.

Säule 2 — Vorfallmanagement und Meldepflichten (Art. 17-23)

Die zweite DORA-Säule verlangt einen vollständigen Prozess für IKT-bezogene Vorfälle, weil Resilienz nur dann belastbar ist, wenn Störungen erkannt, klassifiziert, gesteuert und bei Erheblichkeit korrekt gemeldet werden. Art. 17 bis 23 verbinden operative Incident Response mit aufsichtsrechtlicher Berichtspflicht.

Art. 17 verpflichtet Finanzunternehmen zu einem Prozess für das Management IKT-bezogener Vorfälle. Dieser Prozess muss Vorfälle erfassen, überwachen, behandeln und dokumentieren. Praktisch bedeutet das: Ein Ticket-System allein reicht nicht. Erforderlich ist ein geregeltes Zusammenspiel aus Erkennung, Bewertung, Eskalation, Kommunikationsentscheidung, Ursachenanalyse und Nachbearbeitung.

Art. 18 regelt die Klassifizierung. Institute müssen anhand festgelegter Kriterien entscheiden, wann ein Vorfall als schwerwiegend einzustufen ist und welche Auswirkungen auf Dienstleistungen, Daten, Verfügbarkeit, Integrität, Vertraulichkeit und betroffene Kunden bestehen. Genau hier scheitern viele Programme, weil technische Severity-Skalen aus dem SOC nicht automatisch mit aufsichtsrechtlicher Erheblichkeit identisch sind. DORA verlangt also eine Brücke zwischen Technik, Betrieb, Recht und Aufsicht.

Art. 19 begründet die Meldepflicht für schwerwiegende IKT-bezogene Vorfälle und die freiwillige Meldung erheblicher Cyberbedrohungen. Die konkrete Ausgestaltung erfolgt über harmonisierte technische Standards und Meldeformate. Für die Praxis heißt das: Unternehmen brauchen eine belastbare Entscheidungskette, wer klassifiziert, wer meldet, wer freigibt und welche Informationen in welcher Qualität zu welchem Zeitpunkt vorliegen müssen. Ohne vorbereitete Rollen und Templates wird die Fristlogik schnell zum operativen Risiko.

Art. 20 und 21 zielen auf die Harmonisierung von Inhalt, Vorlagen und zentralisierten Meldewegen. Das ist für Finanzgruppen wichtig, weil unterschiedliche Länder- und Aufsichtskanäle nur mit sauberer Datenhaltung und klarer Zuständigkeit beherrschbar sind. Wer in mehreren Jurisdiktionen tätig ist, sollte Incident-Datenfelder deshalb nicht erst im Krisenfall zusammenführen, sondern vorab in ein gruppenweites Reportingmodell überführen.

Art. 22 regelt das aufsichtsrechtliche Feedback und macht deutlich, dass Meldungen keine reine Einbahnstraße sind. Behörden können Rückfragen stellen, Nachweise anfordern und aus dem Vorfallmanagement Erkenntnisse für ihre Aufsichtspraxis ableiten. Die Qualität der Erstmeldung und der Folgekommunikation beeinflusst daher unmittelbar die Wahrnehmung der Governance-Reife.

Art. 23 enthält eine Sonderregelung für betriebliche oder sicherheitsbezogene Zahlungsvorfälle bestimmter Institute. Diese Schnittstelle ist in Zahlungsinstituten, E-Geld-Häusern und betroffenen Kreditinstituten besonders wichtig, weil bestehende sektorspezifische Meldepflichten mit DORA zusammengedacht werden müssen. Das Ziel ist keine doppelte Bürokratie, sondern ein konsistenter Meldeprozess, der regulatorische Überschneidungen sauber beherrscht.

Konkrete Maßnahmen für Säule 2 sind:

1. Ein einheitliches Incident-Klassifizierungsmodell mit regulatorischer Schwelle.
2. Ein Eskalationsprozess mit 24/7-Erreichbarkeit für kritische Entscheidungen.
3. Vorab definierte Meldebausteine, Freigaben und Kontaktpunkte.
4. Eine Root-Cause-Analyse mit dokumentierten Maßnahmen.
5. Ein Lessons-Learned-Prozess, der in Kontrollen, Architektur und Schulungen zurückspielt.

Wenn Sie die Meldepflichten vertiefen möchten, behandelt unser Beitrag zu DORA Incident Reporting die operative Meldelogik, typische Fehler bei der Klassifizierung und die Schnittstellen zu bestehenden Zahlungs- und Sicherheitsmeldungen im Detail.

Säule 3 — Testen der digitalen Betriebsstabilität (Art. 24-27)

Die dritte DORA-Säule verlangt regelmäßige Resilienztests, weil Kontrollen nur dann belastbar sind, wenn ihre Wirksamkeit praktisch überprüft wird. Art. 24 bis 27 verschieben den Fokus deshalb von der reinen Dokumentation auf nachweisbare Widerstandsfähigkeit unter realistischen Bedingungen.

Art. 24 formuliert die allgemeinen Anforderungen an Resilienztests. Finanzunternehmen müssen ein umfassendes, risikobasiertes Programm für die Prüfung digitaler Betriebsstabilität unterhalten. Getestet werden sollen nicht nur einzelne Systeme, sondern auch Prozesse, Szenarien, Abhängigkeiten und die Fähigkeit zur Wiederaufnahme kritischer Leistungen.

Art. 25 präzisiert, dass IKT-Tools und -Systeme mit einer Bandbreite geeigneter Methoden zu testen sind. Dazu gehören je nach Risikolage unter anderem Schwachstellenanalysen, Szenariotests, End-to-End-Tests, Penetrationstests, Quellcodeprüfungen, physische Sicherheitsprüfungen, Kompatibilitäts- und Performance-Tests sowie Übungen der Notfall- und Wiederanlaufverfahren. DORA will damit verhindern, dass Institute nur auf einen Standardtest pro Jahr setzen und daraus pauschal Resilienz ableiten.

Art. 26 ist besonders relevant, weil er für bestimmte Finanzunternehmen fortgeschrittene Tests auf Basis von Threat-Led Penetration Testing, also TLPT, vorsieht. Gemeint sind realitätsnahe, bedrohungsorientierte Tests gegen kritische oder wichtige Funktionen. Diese Anforderung richtet sich nicht an jedes Institut in gleicher Intensität, kann bei größeren oder systemisch relevanten Häusern aber erhebliche Vorbereitungsarbeit auslösen. Neben Technik und Scope sind dabei auch Governance, Schutzvorkehrungen, Einbindung von Drittparteien und Remediation entscheidend.

Art. 27 definiert Anforderungen an Tester. Das ist prüfungsrelevant, weil Institute nicht nur irgendeinen Dienstleister beauftragen dürfen, sondern auf Unabhängigkeit, Fachkunde, Methodik und Integrität der Durchführung achten müssen. Interne Ressourcen können unter Umständen eingesetzt werden, sofern die Anforderungen erfüllt sind; in vielen Fällen wird jedoch eine externe oder gemischt organisierte Testdurchführung sinnvoll sein.

Für die Praxis hilft eine einfache Differenzierung:

Die entscheidende Managementbotschaft lautet: Ein Resilienztest ist erst dann DORA-wirksam, wenn Ergebnisse in Maßnahmen übersetzt werden. Institute sollten deshalb nicht nur Testberichte archivieren, sondern einen Remediation-Tracker mit Fristen, Verantwortlichen, Kritikalität und Wirksamkeitsprüfung führen. Genau diese Linie verbindet Säule 3 mit Art. 13 DORA: Testen ist kein Selbstzweck, sondern ein Lernkreislauf.

Säule 4 — IKT-Drittparteienrisikomanagement (Art. 28-44)

Die vierte DORA-Säule ist in vielen Instituten der aufwendigste Baustein, weil digitale Resilienz heute stark von Cloud-, Software-, Plattform-, Daten- und Sicherheitsdienstleistern abhängt. Art. 28 bis 44 verlangen deshalb eine systematische Steuerung von IKT-Drittparteirisiken über den gesamten Lebenszyklus der Auslagerung oder Fremdbeziehung.

Art. 28 enthält die Grundprinzipien. Finanzunternehmen müssen IKT-Drittparteirisiken als integralen Bestandteil ihres IKT-Risikomanagementrahmens behandeln. Praktisch heißt das: Drittparteien dürfen nicht in einem isolierten Einkaufsprozess verschwinden. Sie gehören in Risikoanalyse, Governance, Informationssicherheit, Business Continuity und Management-Reporting.

Ein zentrales Instrument ist das Informationsregister über alle vertraglichen Vereinbarungen über IKT-Dienstleistungen. Dieses Register ist mehr als eine Lieferantenliste. Es muss nachvollziehbar zeigen, welche Anbieter welche Leistungen erbringen, welche kritischen oder wichtigen Funktionen betroffen sind, welche Standorte und Unterauftragnehmer relevant sind und wo Konzentrationsrisiken entstehen.

Art. 29 verlangt eine vorvertragliche Bewertung von Risiken, insbesondere Konzentrationsrisiken. Institute müssen vor Vertragsabschluss prüfen, ob sie sich in kritischen Bereichen zu stark von einzelnen Anbietern, Regionen, Technologien oder Konzernstrukturen abhängig machen. Diese Analyse wird in der Praxis oft unterschätzt, ist aber zentral für die Frage, ob eine Auslagerung oder Beschaffung überhaupt in der vorliegenden Form verantwortbar ist.

Art. 30 regelt wesentliche Vertragsbestimmungen. DORA erwartet konkrete Klauseln zu Leistungsumfang, Service Levels, Verfügbarkeit, Informationssicherheit, Mitwirkung bei Vorfällen, Zugangs-, Prüf- und Kontrollrechten, Kündigungsrechten, Datenlokation, Unterbeauftragung, Exit-Unterstützung und Zusammenarbeit mit zuständigen Behörden. Für Standardverträge großer Cloud- oder SaaS-Anbieter ist das regelmäßig ein Verhandlungsthema. Genau deshalb sollte der Einkauf hier nie allein agieren.

Die Art. 31 bis 44 etablieren zusätzlich einen europäischen Aufsichtsrahmen für kritische IKT-Drittdienstleister. Für Finanzunternehmen ist dabei wichtig: Auch wenn die direkte Aufsicht über bestimmte kritische Anbieter auf europäischer Ebene stattfindet, entbindet das die Institute nicht von ihrer eigenen Steuerungs- und Überwachungspflicht. Das Missverständnis „der Provider wird ja ohnehin beaufsichtigt“ ist daher gefährlich.

Konkrete Umsetzungsmaßnahmen in Säule 4 sind:

1. Aufbau eines vollständigen IKT-Drittparteiregisters mit Kennzeichnung kritischer oder wichtiger Funktionen.
2. Standardisierte Vorabprüfung von Sicherheits-, Resilienz- und Konzentrationsrisiken.
3. Überarbeitung von Vertragsmustern mit DORA-relevanten Mindestklauseln.
4. Laufende Überwachung über KPIs, KRIs, Audits, Attestierungen und Service-Reviews.
5. Dokumentierte Exit-Strategien für kritische Anbieter und realistische Wechsel- oder Notfalloptionen.

Institute, die ihre Lieferkette vertieft prüfen möchten, finden im Beitrag zu DORA und IT-Dienstleistern eine praxisnahe Einordnung zu Vertragsklauseln, Registerlogik und typischen Audit-Fragen.

Säule 5 — Informationsaustausch (Art. 45)

Die fünfte DORA-Säule betrifft den strukturierten Informationsaustausch über Cyberbedrohungen und Erkenntnisse, weil Resilienz im Finanzsektor nicht nur institutsspezifisch, sondern auch sektorübergreifend gedacht wird. Art. 45 erlaubt Finanzunternehmen, unter bestimmten Bedingungen Informationen und Intelligence über Cyberbedrohungen auszutauschen.

Wichtig ist dabei zweierlei. Erstens handelt es sich nicht um eine pauschale Freigabe für informellen Datenaustausch. Der Austausch muss in vertrauenswürdigen Arrangements erfolgen, auf die Stärkung der digitalen operationellen Resilienz ausgerichtet sein und die Vertraulichkeit geschützter Informationen wahren. Zweitens ersetzt Art. 45 keine gesetzlichen Meldepflichten und keine internen Kontrollpflichten. Informationsaustausch ist ein zusätzlicher Resilienzhebel, nicht deren Ersatz.

Für Institute ist diese Säule vor allem dann wertvoll, wenn branchenspezifische Angriffsmuster, Taktiken oder Schwachstellen frühzeitig geteilt werden. Wer aus Bedrohungsinformationen schneller Rückschlüsse für Detection Rules, Härtungsmaßnahmen oder Drittparteienbewertungen ziehen kann, verkürzt Reaktionszeiten und erhöht die Qualität präventiver Kontrollen.

Sinnvolle Mindestfragen für Art. 45 sind:

1. In welchem Kreis wird ausgetauscht und mit welcher Governance?
2. Welche Informationen dürfen geteilt werden und welche nicht?
3. Wie werden Vertraulichkeit, Datenminimierung und Verantwortlichkeiten abgesichert?
4. Wie fließen erhaltene Erkenntnisse in Detection, Patch-Management und Risikoanalysen zurück?

Gerade kleinere Institute sollten Art. 45 nicht als „optional und daher verzichtbar“ missverstehen. Wo interne Threat-Intelligence-Ressourcen begrenzt sind, kann ein sauber geregelter Austausch den Reifegrad der Säulen 1 bis 3 spürbar erhöhen.

Proportionalitätsprinzip — Anpassung nach Größe und Risiko

Das Proportionalitätsprinzip ist für DORA Anforderungen zentral, weil die Verordnung ausdrücklich anerkennt, dass nicht jedes Finanzunternehmen dieselbe Komplexität, Größe und Risikodichte aufweist. Art. 4 DORA verlangt daher, dass Anforderungen im Verhältnis zu Größe, Gesamtrisikoprofil sowie Art, Umfang und Komplexität der Dienstleistungen, Tätigkeiten und Operationen angewendet werden.

Konkret bedeutet das nicht, dass kleine Institute ganze Säulen auslassen dürfen. Das Proportionalitätsprinzip reduziert nicht den Pflichtenkern, sondern passt Intensität und Ausgestaltung an. Eine kleine Spezialfinanzierungsgesellschaft mit begrenzter IT-Landschaft braucht typischerweise kein Programm in derselben Tiefe wie eine international tätige Bankengruppe mit mehreren Rechenzentren, vielen Cloud-Abhängigkeiten und hochkritischen Zahlungsprozessen. Beide müssen jedoch IKT-Risiken steuern, Vorfälle behandeln, testen, Drittparteien überwachen und den Informationsaustausch sinnvoll einordnen.

Für die Praxis lassen sich vier Leitfragen ableiten:

1. Wie kritisch sind die digitalen Services für Kunden, Marktinfrastruktur und Aufsicht?
2. Wie komplex ist die IKT-Landschaft einschließlich externer Provider und Unterauftragnehmer?
3. Wie groß ist das potenzielle Schadensbild bei Ausfall, Manipulation oder Datenverlust?
4. Welche Fähigkeiten sind intern vorhanden und welche müssen kontrolliert eingekauft oder extern geprüft werden?

Art. 16 konkretisiert diese Logik für den vereinfachten IKT-Risikomanagementrahmen bestimmter Institute. Er ist kein Freifahrtschein, sondern ein Hinweis, dass DORA Reife und Nachweisbarkeit fordert, nicht künstliche Komplexität. Ein schlanker, gelebter und dokumentierter Rahmen ist deshalb regulatorisch stärker als eine umfangreiche Papierlage ohne belastbare Umsetzung.

Auch im Prüfungsdialog mit der BaFin ist Proportionalität kein pauschales Argument, sondern eine Begründungsdisziplin. Institute sollten dokumentieren können, warum sie bestimmte Tests, Reporting-Tiefen, Vertragsbausteine oder Wiederherstellungsszenarien gewählt haben und wie diese Entscheidungen zum eigenen Risikoprofil passen. Wer Proportionalität nur behauptet, aber nicht herleitet, erzeugt eher Rückfragen als Entlastung.

Umsetzungs-Checkliste für jede Säule

Die schnellste Art, DORA Anforderungen in ein reales Programm zu übersetzen, ist eine Checkliste mit klaren Verantwortlichkeiten pro Säule. Entscheidend ist dabei, nicht fünf Parallelprojekte zu starten, sondern ein gemeinsames Steuerungsmodell mit Prioritäten, Meilensteinen und Nachweisen aufzubauen.

Checkliste Säule 1: IKT-Risikomanagement

1. Leitungsorgan, Rollen und Berichtswege formell festlegen.
2. Kritische oder wichtige Funktionen identifizieren und mit IKT-Assets verknüpfen.
3. IKT-Risikomanagementrahmen dokumentieren und vorhandene Policies daran ausrichten.
4. Backup-, Wiederherstellungs- und Krisenkommunikationsverfahren überprüfen.
5. Lern- und Verbesserungsprozess aus Vorfällen und Tests verbindlich machen.

Checkliste Säule 2: Vorfallmanagement und Meldepflichten

1. Incident-Prozess auf regulatorische Klassifizierung erweitern.
2. Kriterien für schwere IKT-Vorfälle und Zahlungsvorfälle definieren.
3. Meldewege, Freigaben und Templates vorbereiten.
4. Root-Cause-Analyse und Lessons Learned standardisieren.
5. Management und relevante Fachbereiche für Eskalationen schulen.

Checkliste Säule 3: Testen der digitalen Betriebsstabilität

1. Jährlichen Resilienztestplan mit risikobasierter Priorisierung aufsetzen.
2. Geeignete Testarten pro kritischer Funktion definieren.
3. Anforderungen für unabhängige Tester dokumentieren.
4. Ergebnisse in einen Remediation-Tracker überführen.
5. Wiederholungstests und Wirksamkeitskontrollen terminieren.

Checkliste Säule 4: IKT-Drittparteienrisikomanagement

1. Vollständiges Register aller IKT-Dienstleistungen und Anbieter aufbauen.
2. Kritische oder wichtige Funktionen je Anbieter kennzeichnen.
3. Vorvertragliche Risiko- und Konzentrationsprüfung standardisieren.
4. Vertragsmuster um DORA-Klauseln ergänzen.
5. Exit-Strategien und laufende Überwachung kritischer Anbieter fest verankern.

Checkliste Säule 5: Informationsaustausch

1. Geeignete Austauschformate und vertrauenswürdige Kreise identifizieren.
2. Governance für zulässige Inhalte und Freigaben definieren.
3. Vertraulichkeits- und Datenschutzgrenzen dokumentieren.
4. Erkenntnisse in Detection, Risikoanalyse und Drittparteiensteuerung zurückspielen.
5. Wirksamkeit des Austauschs regelmäßig bewerten.

FAQ

Müssen alle 5 Säulen gleichzeitig umgesetzt werden?

Nein, aber alle fünf Säulen müssen in einem gemeinsamen Zielbild berücksichtigt werden. DORA ist seit dem 17. Januar 2025 anwendbar; Institute sollten daher nicht nacheinander isolierte Einzellösungen bauen, sondern ein priorisiertes Programm aufsetzen. In der Praxis beginnt die Umsetzung oft mit Säule 1 und 2, weil Governance, Risiko- und Vorfallmanagement die Basis für Tests und Drittparteiensteuerung bilden.

Was bedeutet das Proportionalitätsprinzip konkret?

Das Proportionalitätsprinzip nach Art. 4 DORA bedeutet, dass Maßnahmen zur Größe, Komplexität und Risikolage des Instituts passen müssen. Ein kleineres Institut kann Prozesse schlanker organisieren, muss aber denselben Pflichtenkern erfüllen. Entscheidend ist deshalb nicht die Länge der Dokumentation, sondern ob der gewählte Ansatz für das eigene Risikoprofil plausibel, funktionsfähig und prüfbar ist.

Welche Säule erfordert den meisten Aufwand?

In vielen Finanzunternehmen verursacht Säule 4 den größten Aufwand, weil Drittparteien, Verträge, Informationsregister, Audit-Rechte und Exit-Szenarien historisch oft über verschiedene Bereiche verteilt sind. Wo die interne Governance schwach ist, kann allerdings Säule 1 noch aufwendiger werden, weil ohne sauberen IKT-Risikomanagementrahmen alle anderen Pflichten nur fragmentiert erfüllt werden.

Gibt es Erleichterungen für kleine Finanzunternehmen?

Ja, aber keine vollständige Ausnahme. DORA arbeitet mit Proportionalität nach Art. 4 und für bestimmte Fälle mit einem vereinfachten IKT-Risikomanagementrahmen nach Art. 16. Kleine Institute können Maßnahmen also schlanker ausgestalten, müssen jedoch weiterhin Vorfälle steuern, testen, Drittparteirisiken überwachen und ihre digitale operationelle Resilienz nachweisbar organisieren.

Was sind die 5 Säulen von DORA?

Die fünf Säulen sind IKT-Risikomanagement, Vorfallmanagement und Meldepflichten, Testen der digitalen Betriebsstabilität, IKT-Drittparteienrisikomanagement und Informationsaustausch. Sie entsprechen den Kapiteln II bis VI der DORA-Verordnung und bilden zusammen den Kern der digitalen operationellen Resilienz im Finanzsektor.

Was bedeutet IKT-Risikomanagement nach DORA?

IKT-Risikomanagement nach DORA bedeutet einen formellen Governance- und Kontrollrahmen für Identifikation, Schutz, Erkennung, Reaktion, Wiederherstellung und Weiterentwicklung digitaler Systeme und Prozesse. Das Leitungsorgan trägt dafür Verantwortung; technische Maßnahmen allein genügen nicht.

Wie oft müssen Resilienztests durchgeführt werden?

DORA verlangt ein regelmäßiges, risikobasiertes Testprogramm nach Art. 24 und 25. Die konkrete Frequenz hängt von Kritikalität, Komplexität und Risikoprofil ab. Für bestimmte größere oder exponierte Institute kommen fortgeschrittene Tests einschließlich TLPT nach Art. 26 hinzu.

Welche Drittanbieter fallen unter DORA?

Unter DORA fallen IKT-Drittdienstleister, die IKT-Services für Finanzunternehmen erbringen, zum Beispiel Cloud-, Hosting-, Software-, Daten-, Security- oder Netzwerkservices. Besonders relevant sind Anbieter, die kritische oder wichtige Funktionen unterstützen oder durch Konzentration ein erhöhtes Ausfallrisiko erzeugen.

CTA: DORA-Anforderungen in ein belastbares Schulungsprogramm übersetzen

DORA Anforderungen sind nur dann wirksam umgesetzt, wenn Fachbereiche, IT, Informationssicherheit, Auslagerungsmanagement und Leitungsorgan dieselbe Logik teilen. Unsere DORA-Schulung unterstützt Sie dabei, die fünf Säulen in klare Verantwortlichkeiten, belastbare Nachweise und ein prüfbares Umsetzungsprogramm für Ihr Finanzunternehmen zu übersetzen.

Wenn Sie zunächst die Grundlagen der Verordnung vertiefen möchten, lesen Sie den Überblick zur DORA-Verordnung, die Details zu DORA Incident Reporting und die operative Perspektive auf DORA und IT-Dienstleister. So bauen Sie aus den abstrakten Anforderungen ein belastbares Compliance-System statt einer bloßen Sammlung einzelner Policies.

Primärquelle

• Verordnung (EU) 2022/2554 auf EUR-Lex