Insights
Digital Operational Resilience: Wie Sie Ihre IT-Architektur für den Ernstfall wappnen
Ein nie ausgelöster Failover ist ein Wunsch, kein Verfahren. Was DORA von der Architektur verlangt, warum Altsysteme die Schwachstelle sind und wie der Umbau in Etappen den Betrieb schützt.

Digital Operational Resilience ist die Fähigkeit, IT-Störungen, Angriffe und Ausfälle zu überstehen, ohne dass das Geschäft steht; für Finanzunternehmen und ihre IT-Dienstleister schreibt die EU-Verordnung DORA diese Fähigkeit inzwischen verbindlich vor. Für die IT-Leitung heißt das: Resilienz ist keine Eigenschaft, die man einem Altsystem nachträglich zuweist, sondern eine Architekturentscheidung.
Was DORA von der IT-Architektur verlangt
Der Digital Operational Resilience Act gliedert sich in fünf Bereiche: Management der IKT-Risiken, Meldung von IKT-Vorfällen, Tests der operativen Resilienz, Umgang mit Risiken durch Drittdienstleister und Austausch von Bedrohungsinformationen. Jeder Bereich hat eine Konsequenz für die Architektur. Wer Vorfälle melden muss, braucht eine Überwachung, die sie erkennt. Wer Resilienz testen muss, braucht eine Umgebung, in der ein Ausfall geübt werden kann, ohne Kunden zu treffen. Wer Drittrisiken steuern muss, braucht Komponenten, die sich austauschen lassen. Eine Architektur, die diese Punkte nicht hergibt, lässt sich mit Dokumenten nicht reparieren.
Bestandsaufnahme: Wiederanlaufzeit und Datenverlust pro System
Der Aufbau beginnt mit einer Liste aller kritischen Systeme und ihrer Abhängigkeiten. Für jedes System legen Sie fest, wie lange es ausfallen darf und wie viele Daten dabei verloren gehen dürfen. Diese zwei Werte entscheiden über die Architektur: Ein System, das Stunden ausfallen darf, braucht ein geprüftes Backup und einen dokumentierten Wiederanlauf. Ein System, das nicht ausfallen darf, braucht Redundanz über mehrere Standorte und einen automatischen Wechsel. Wer alles doppelt auslegt, zahlt für Redundanz, die niemand verlangt hat.
Legacy-Software modernisieren ohne Ausfall: der größte Hebel für Resilienz
Gewachsene Altsysteme sind in fast jeder Landschaft die Schwachstelle. Sie laufen als ein Block auf einer Maschine, lassen sich nicht redundant auslegen und haben keine Testumgebung, in der ein Ausfall geübt werden könnte. Der Umbau in einem Schritt wäre selbst der größte Vorfall des Jahres.
Der tragfähige Weg zerlegt das Altsystem in Etappen. Eine Funktion wird als eigener Dienst herausgelöst, läuft parallel zum Altsystem und übernimmt erst, wenn die Ergebnisse übereinstimmen. Nach jeder Etappe wird die Resilienz des neuen Dienstes getestet: Ausfall simulieren, Wiederanlauf messen, dokumentieren. Eine Versicherung, die ihre Policenverwaltung auf diese Weise umbaut, beginnt mit der Kundenverwaltung und endet Jahre später beim Kern, ohne dass ein Kunde zwischendurch etwas gemerkt hat.
Redundanz, die trägt: zwei Standorte, ein geübter Wechsel
Ein Lagerverwaltungssystem, das in zwei unabhängigen Regionen läuft und bei einem Ausfall automatisch umschaltet, klingt nach einer fertigen Lösung. Es ist erst eine, wenn der Wechsel regelmäßig geübt wird. Ein nie ausgelöster Failover ist ein Wunsch, kein Verfahren. DORA verlangt deshalb Tests und Dokumentation, und die Architektur muss beides ermöglichen: eine Umgebung, in der der Wechsel ohne Kundenkontakt ausgelöst werden kann, und Protokolle, die belegen, dass er funktioniert hat.
Souveränität als Teil der Resilienz
Zu den Drittrisiken gehört die Frage, was passiert, wenn Ihr Cloud-Anbieter ausfällt, die Konditionen ändert oder von einer Behörde außerhalb der EU zur Herausgabe verpflichtet wird. Die Antwort ist eine Ausstiegsstrategie, die auf dem Papier nichts wert ist, wenn die Architektur sie nicht hergibt. Daten und Code gehören dem Unternehmen, Schnittstellen folgen offenen Standards, Container laufen bei jedem Anbieter. Eine europäische Infrastruktur nimmt die Rechtsfrage dazu aus dem Spiel. Dann ist ein Anbieterwechsel ein Projekt mit Termin und kein Notfall.
Häufige Fragen zur Digital Operational Resilience
Was unterscheidet DORA von einer Zertifizierung nach ISO-Norm? Die ISO-Norm für Informationssicherheit beschreibt ein Managementsystem. DORA verlangt zusätzlich regelmäßige Resilienztests, Meldepflichten und eine strenge Steuerung von Dienstleistern. Wer zertifiziert ist, hat eine Basis, aber nicht die Erfüllung.
Was droht bei Verstößen? Bußgelder, Auflagen der Aufsicht bis zur Einschränkung der Geschäftstätigkeit und eine persönliche Verantwortung der Geschäftsleitung. Die Höhe legt die Aufsicht fest; Details klären Sie mit Ihrer Rechtsabteilung.
Wie lange dauert der Aufbau? Mit moderner Infrastruktur Monate, mit gewachsenen Altsystemen deutlich länger. Entscheidend sind Etappen mit Zwischenzielen, damit der Betrieb nie gefährdet ist.
Betrifft DORA auch Unternehmen außerhalb der Finanzbranche? Ja, als Dienstleister. Wer Software oder Hosting für ein Finanzunternehmen liefert, bekommt die Anforderungen über den Vertrag weitergereicht.
Welche Rolle spielt KI? KI kann Anomalien früh erkennen und Reaktionen beschleunigen. Ein KI-System, das automatisch auf Vorfälle reagiert, ist aber selbst ein kritisches IKT-System: Es muss überwacht, dokumentiert und jederzeit von Hand übersteuert werden können.
Der nächste Schritt: den Ausfall durchspielen
Nehmen Sie das eine System, dessen Ausfall Sie am meisten kosten würde, und beantworten Sie zwei Fragen: Wann wurde der Wiederanlauf zuletzt geübt, und wer hat das Protokoll? Fehlt eine der Antworten, gehen wir Ihre Systemliste in einer halben Stunde gemeinsam durch und klären, wo Architektur fehlt und wo nur ein Test: Potenzial-Check buchen.