Ihr Legacy-System hat die DORA-Prüfung nicht bestanden. Was nun?

• DORA und NIS2 zeigen architektonische Lücken auf, die durch Richtlinien allein nicht behoben werden können
• Batch-basierte Legacy-Systeme können die Anforderungen an die Erkennung und Berichterstattung in Echtzeit nicht erfüllen
• Undokumentierte Abhängigkeiten erschweren eine vollständige IKT-Asset-Inventarisierung
• Mainframe-Abhängigkeiten stehen inzwischen im Fokus der Aufsichtsbehördenn
• Ein dokumentiertes Modernisierungsprogramm bildet die Basis für eine starke regulatorische Position

DORA (Digital Operational Resilience Act) stellt Finanzinstitute vor Anforderungen, die viele Legacy-Architekturen nur schwer erfüllen können.

DORA ist längst mehr als ein Compliance-Projekt für die Zukunft. Die Verordnung ist bereits in Kraft und rückt operative Resilienz, Transparenz sowie wirksame Kontrollmechanismen in den Mittelpunkt. Viele Legacy-Umgebungen erfüllen zwar die Anforderungen an die Dokumentation, stoßen bei den zugrunde liegenden architektonischen Voraussetzungen jedoch häufig an ihre Grenzen.

Batchbasierte Prozesse, fehlende Transparenz bei Systemabhängigkeiten und die Bindung an einzelne Plattformanbieter schaffen Herausforderungen, die sich nicht allein durch Prozessverbesserungen lösen lassen.

DORA ist nicht nur eine Compliance-Herausforderung. Sie ist ein Impulsgeber für die Modernisierung.

In den meisten Legacy-Umgebungen sind kritische Abhängigkeiten in den Code und nicht in die Dokumentation eingebettet.

DORA fordert ein jederzeit aktuelles und nachvollziehbares Verzeichnis aller IKT-Assets sowie ihrer Abhängigkeiten. In vielen Mainframe-Umgebungen sind diese Zusammenhänge jedoch lediglich in Batch-Abläufen, Job-Schedulern oder im Wissen langjähriger Entwicklerinnen und Entwickler verankert.

Die automatisierte Erfassung von Abhängigkeiten ist zunehmend der einzige verlässliche Weg, diese Anforderung zu erfüllen. Gleichzeitig bildet sie die Grundlage für jede realistische Modernisierungsstrategie.

Legacy-Architekturen erkennen Vorfälle häufig erst mit Verzögerung – oftmals erst nach Abschluss von Batch-Zyklen.

DORA verlangt, dass schwerwiegende IKT-Vorfälle innerhalb kurzer Zeit erkannt und gemeldet werden. Batchbasierte Systeme liefern die dafür erforderlichen Informationen jedoch oft erst nach Abschluss geplanter Verarbeitungsläufe. Das erschwert eine schnelle Reaktion erheblich – oder macht sie im Ernstfall sogar unmöglich.

Moderne Konzepte wie Observability, Echtzeit-Monitoring, Tracing und Alerting lassen sich nicht einfach nachträglich in Architekturen integrieren, die nie dafür ausgelegt wurden. Dabei handelt es sich nicht um eine Frage der Governance, sondern um eine grundlegende Einschränkung der Systemarchitektur.

Dies erklärt auch, warum viele KI-Initiativen in Legacy-Umgebungen scheitern: Ohne Echtzeitdaten und moderne Observability-Lösungen fehlen die notwendigen Grundlagen. Erst die Modernisierung der bestehenden Systemlandschaft schafft die Voraussetzungen für den erfolgreichen Einsatz von KI.

Lange Zeit akzeptierte Abhängigkeiten werden durch DORA zunehmend als Konzentrationsrisiken betrachtet.

DORA verpflichtet Unternehmen dazu, Konzentrationsrisiken im Zusammenhang mit IKT-Drittdienstleistern zu identifizieren und aktiv zu steuern. Kernsysteme, die von:

• einem einzigen Hardware-Anbieter
• Middleware Stack
• oder einem zunehmend knappen Angebot an Fachkräften abhängig sind,

fallen nun direkt in den Aufsichtsbereich

DORA schreibt keinen sofortigen Ausstieg aus Mainframe-Systemen vor. Unternehmen müssen jedoch nachweisen, dass sie die damit verbundenen Risiken aktiv steuern und langfristig reduzieren.

Modernisierung ist damit nicht länger nur eine Frage der Kostenoptimierung, sondern wird zunehmend zu einer regulatorischen Notwendigkeit.

Aufsichtsbehörden erwarten keine Perfektion. Entscheidend ist, dass Unternehmen ihre Risiken im Griff haben und Maßnahmen konsequent umsetzen. Genau darum geht es bei Steuerung und Umsetzung.

Besonders gut aufgestellt sind Unternehmen mit einem dokumentierten und vom Vorstand getragenen Modernisierungsprogramm, das architektonische Verbesserungen gezielt mit regulatorischen Anforderungen verknüpft. Wer nachvollziehbare Fortschritte nachweisen kann, ist gegenüber Aufsichtsbehörden deutlich besser positioniert als Unternehmen, die sich auf Absichtserklärungen oder langfristige Zukunftspläne verlassen.

In der Praxis bedeutet das, über punktuelle Verbesserungen hinauszugehen und eine durchgängige Modernisierung voranzutreiben – von der Analyse von Systemabhängigkeiten und der Weiterentwicklung der Architektur bis hin zu Echtzeit-Observability und einer KI-fähigen Datenbasis. Genau diese Fähigkeiten sind auch eine zentrale Voraussetzung für erfolgreiche KI-Modernisierungsinitiativen. Sie schaffen die Grundlage, um KI-Anwendungen auf einer resilienten, transparenten und regulatorisch konformen Technologiebasis zu skalieren.

Auch weltweit entstehen zunehmend vergleichbare regulatorische Vorgaben. Regelwerke wie die britischen Operational-Resilience-Anforderungen, Australiens CPS 230, die Technology Risk Management Guidelines der Monetary Authority of Singapore (MAS) oder NIS2 unterstreichen die Bedeutung von Resilienz, Transparenz bei Technologierisiken und einem wirksamen Management kritischer Systeme und Abhängigkeiten. Die konkreten Anforderungen unterscheiden sich zwar im Detail, die Stoßrichtung ist jedoch dieselbe: Unternehmen müssen die architektonischen Grundlagen ihrer geschäftskritischen Systeme gezielt stärken.