Erkenntnisse aus einem Jahr DORA Umsetzung

Was Institute geschafft haben – und wo es noch hakt

Abonnieren Sie den kostenlosen Bank Blog Newsletter

Seit Januar 2025 gilt DORA verbindlich. Trotz langer Vorbereitung bleibt viel zu tun. Wir reflektieren Erfahrungen aus dem ersten Jahr anhand von Beobachtungen aus Projekten und Prüfungen: Was hat sich bewährt, wo muss nachgearbeitet werden?

Ein Jahr DORA bei Banken und Sparkassen

Wo Banken und Sparkassen bei DORA nach einem Jahr der Umsetzung stehen.

Partner des Bank Blogs

Die Targobank ist Partner des Bank Blogs

Der größte Aufwand für laufende DORA‑Nacharbeiten entfällt auf das Informationsregister sowie auf vertragliche Nachschärfungen mit externen IKT‑Dienstleistern (Informations‑ und Kommunikationstechnologie) und deren Subdienstleistern. Bestehende Governance hilft, doch oft fehlt ein durchgängiger, funktionsübergreifender Ansatz. Große Häuser kämpfen mit Koordination, kleinere mit Kapazitäten. In den Verbünden entlastet zentrale IT, aber die institutsindividuelle Umsetzung muss schritthalten.

Ein Dienstleisterregister und verbesserte Vertragsgrundlagen bilden die Basis, um Drittparteien wirksam zu steuern, Vorfälle verlässlich zu erkennen und zu melden sowie ein tragfähiges Testprogramm bis hin zu realitätsnahen Übungen aufzubauen. Entscheidend sind klare Verantwortlichkeiten und passende Schwellenwerte für Kennzahlen (KPI). Abläufe müssen definiert und erprobt sein, damit Entscheidungen und Meldungen ohne Reibungsverluste erfolgen.

Dienstleisterregister & Drittparteiensteuerung

Bei vielen Instituten bleibt die steuernde Wirkung ihrer Dienstleisterregister bislang hinter den Anforderungen zurück. Solange die Mindestinhalte nicht konsistent in einem einheitlichen Datenmodell abgebildet sind, lässt sich die Verantwortung für Pflege und Nutzung nicht verlässlich in die Linie übergeben. Häufig fehlt die klare Zuordnung von Funktionen, genutzten IKT‑Services, Verträgen und Subdienstleistern, oder vorhandene Transparenz findet keinen Eingang in Steuerungsprozesse. Anlassbezogene Aktualisierungen bei neuen Services, Vertragsänderungen oder Vorfällen können dann ausbleiben.

In solchen Fällen gilt es, den Übergang vom Projekt in den Betrieb zu vollziehen. Ein risikobasierter Roll‑out priorisiert zunächst kritische Funktionen und Anbieter, definiert Zuständigkeiten und feste Aktualisierungsanlässe und integriert das Register in bestehende Betriebswerkzeuge. Wo diese Inhalte bislang fehlen, sind Vertragsnachverhandlungen mit Dienstleistern erforderlich, um Mindestinhalte wie Informations- und Meldepflichten, Prüf- und Zugriffsrechte, Transparenz zu Subdienstleistern sowie Exit- und Übergaberegelungen verbindlich zu verankern. Ziel ist ein kompaktes, adressatengerechtes Reporting, das Abhängigkeiten, Konzentrationen und Exit‑Fähigkeiten sichtbar macht. Alle beteiligten Bankfunktionen müssen hierfür eine gemeinsame Datenquelle pflegen und nutzen, in der Bezeichnungen konsistent geführt und Dienstleister vollständig erfasst sind.

Vorfälle & Meldewesen: Kriterien und Wege

Auch beim Umgang mit Vorfällen haben noch nicht alle Institute ihr Zielbild erreicht. Einstufungen und Meldeschwellen sind teilweise uneinheitlich, Kontrollen zur Überwachung des IT‑Betriebs nicht durchgängig formalisiert oder nicht ausreichend auf Anomalien ausgerichtet. Wenn die Übersetzung technischer Alarme in belastbare Geschäftsmetriken fehlt, können Relevanz und Meldepflichten falsch eingestuft werden. Im Schwachstellenmanagement fehlt häufig eine angemessene Frequenz und ein klarer Prozess zur verantwortungsvollen Offenlegung (Responsible Disclosure). Die notwendige Erfassung und Nachverfolgung von Drittanbieter‑ und Open‑Source‑Komponenten bleibt ein neuralgischer Punkt.

Eine kompakte Einstufungsmatrix mit wenigen, messbaren Kriterien und klaren Zeitvorgaben kann Abhilfe schaffen. Grundlage für die Nutzung sind eindeutige Zuständigkeiten für Erkennung, Erstbewertung, Eskalation und Meldung an den Krisenstab. Die Kontrollen zur Überwachung des IT‑Betriebs sollten formalisiert, regelmäßig auf Wirksamkeit geprüft und im Testprogramm geübt werden. Kritische Dienstleister müssen vertraglich zur proaktiven Zuarbeit verpflichtet und in Übungen eingebunden werden. Die Rückkopplung von Entscheidungen, Annahmen und Fristen an Risikoanalyse, Testprogramm und Verträge ist entscheidend.

Testprogramm & Übungen mit externen Teams

Testprogramme existieren vielfach bereits auf dem Papier, laufen aber noch nicht überall im Regelbetrieb. Umfang und Tiefe bleiben uneinheitlich, und häufig fehlen End-to-End-Sichten, szenariobasierte Übungen und Einbindungen kritischer Dienstleister. Ergebnisse werden in solchen Fällen zwar dokumentiert, aber nicht konsequent priorisiert, terminiert und nachverfolgt. Mitunter bleibt unklar, wer die fachliche Abnahme übernimmt und welche Qualität ein Testnachweis haben muss.

Pragmatisch ist ein mehrjähriger, risikobasierter Plan mit klaren Zielen, der bei kritischen Funktionen und bekannten Schwachstellen ansetzt. Für jede Übung werden Zweck, Akzeptanzkriterien, Rollen und Zeitziele festgelegt. Regelmäßige Schwachstellenprüfungen, synthetisches End‑to‑End‑Monitoring und realitätsnahe Übungen mit externen Teams sollten miteinander kombiniert werden. Voraussetzung ist wiederum, dass Dienstleister vertraglich zu Beistellleistungen verpflichtet sind. Befunde sind in einem zentralen Register mit Verantwortlichen, Fälligkeiten und Wirksamkeitskontrollen zu erfassen, aus dem Management und Interne Revision adressatengerechte Berichte erhalten. Abgeleitete Maßnahmen müssen in Risikoanalyse, Verträge und Betrieb zurückfließen.

Regionalbankverbünde: zentrale IT, lokale Governance

Bei Sparkassen und Genossenschaftsbanken decken FI und Atruvia den Großteil der IKT‑Leistungen ab. Das senkt Komplexität, ersetzt aber nicht die institutsspezifische Governance. Zugleich bleibt ein institutsindividueller Anteil außerhalb der Verbundabdeckung, der eigenständig gesteuert und nach DORA-Maßstäben abgesichert werden muss. DSGV und BVR harmonisieren das Vorgehen im Verbund.

Auf Institutsebene sind diese Konzepte in Richtlinien, Rollen und Berichtspflichten zu übersetzen. Die Herausforderung ist ein IKT-Risikomanagementrahmen, der in OpRisk und BCM/ITSCM integriert und zugleich mit der gruppenweiten DORA-Governance kompatibel ist. In vielen Häusern fehlen hierfür noch lokale Risikolimite und Schwellenwerte, RACI-Zuständigkeiten, Berichtslinien und belastbare Wirksamkeitsnachweise, sodass ein Prüfungsrisiko besteht.

Schlanke, institutseigene Umsetzung von DORA

Erforderlich ist eine schlanke, institutseigene Umsetzung, die an die Verbundvorgaben anschlussfähig ist. Neben den Verbundleistungen ist der verbleibende institutsindividuelle Anteil (z. B. lokale Anwendungen, Schnittstellen, Spezialdienstleister) explizit in Register, Verträge, Monitoring und Testprogramm aufzunehmen.

Wichtig sind definierte Schnittstellen zwischen Verbunddaten und bankeigenen Prozessen, die Zusammenführung der Registerinformationen, konsistente Kennzahlen und Berichte sowie ein abgestimmter Governance-Kalender. Test- und Melderoutinen müssen an die bankeigene Risikolandschaft angepasst werden, so dass Ergebnisse in Risikoanalyse und Verträge zurückfließen. Regelmäßige Überprüfungen mit Management, Compliance und Interner Revision stellen Konsistenz sicher und schaffen Prüfungsbereitschaft.

Prüfungsbereitschaft und operative Resilienz durch DORA

Typische Nacharbeitsbedarfe ein Jahr nach Inkrafttreten der DORA

Überblick der typischen Nacharbeiten: Dienstleisterregister (Datenmodell, Verträge), Vorfälle & Meldewesen (Kriterien, Monitoring), Testprogramme (Plan, E2E-Übungen) und Regionalverbünde (lokaler IKT-Anteil, Governance).

Institute mit Nacharbeitsbedarf müssen das verbleibende Zeitfenster bis zum Beginn ihrer aufsichtlichen Prüfung nutzen. Es gilt, laufende Projekte zum Abschluss zu bringen, um Dienstleisterregister in tragfähige Betriebsprozesse zu überführen und vertragliche Mindestinhalte zu vereinbaren.

Parallel ist ein risikobasiertes Testprogramm aufzusetzen, in dem regelmäßige Übungen unter Verwendung der Einstufungsverfahren und Meldewege stattfinden und Befunde nachverfolgt werden. Sparkassen und Genobanken müssen ihren institutsindividuellen IKT-Anteil sichtbar machen und mit der Verbund-Governance verzahnen. So entstehen Prüfungsbereitschaft und belastbare operative Resilienz.


Partner des Bank Blog: Das Beratungshaus Berg Lund & Company

Bank Blog Partner Berg Lund & Company bietet Topmanagement-Beratung für die Finanzbranche.

Mehr über das Partnerkonzept des Bank Blogs erfahren Sie hier.

Über den Autor

Dr. Tobias Sander

Dr. Tobias Sander ist Senior Manager bei Berg Lund & Company und berät seit über 15 Jahren Banken und Finanzdienstleister. Der promovierte Physiker und Finanzmathematiker war zuvor für d-fine tätig.

Vielen Dank fürs Teilen und Weiterempfehlen


Mit dem kostenlosen Bank Blog Newsletter immer informiert bleiben:

Anzeige

Get Abstract: Zusammenfassungen interessanter Businessbücher

Kommentare sind geschlossen

Bank Blog Newsletter abonnieren

Bank Blog Newsletter abonnieren