DORA-konforme IT-Architektur: Was die Verordnung von Ihrem Betrieb und Ihren Verträgen verlangt

Der Digital Operational Resilience Act (DORA) gilt seit Anfang 2025 für Finanzunternehmen in der EU und verlangt, dass ihre IT Störungen verkraftet, statt sie nur zu dokumentieren. Für Sie als IT-Leitung bedeutet das: Redundanz, Wiederanlauf und die Verantwortung Ihrer Dienstleister müssen im Design und im Vertrag stehen, nicht in einer Richtlinie, die niemand testet.

Wen DORA trifft, auch ohne Banklizenz

DORA richtet sich an Banken, Versicherungen, Zahlungsdienstleister und andere beaufsichtigte Finanzunternehmen. Betroffen sind aber auch die IT-Dienstleister, die für diese Unternehmen kritische Systeme betreiben, weil die Verordnung die Anforderungen an Drittanbieter durchreicht. Wer ein Kundenportal, eine Antragsstrecke oder eine Schnittstelle für einen Finanzkunden hostet, bekommt die Fragen aus DORA im nächsten Vertragsgespräch gestellt. Diese Einordnung ersetzt keine Rechtsberatung; sie erklärt, warum das Thema auch bei Betrieben ankommt, die sich nicht als Finanzunternehmen sehen.

Widerstandsfähigkeit im Design statt in der Dokumentation

Der Kern von DORA ist einfach: Der Ausfall einer einzelnen Komponente darf den Geschäftsbetrieb nicht stoppen, und nach einer Störung muss der Betrieb in einer definierten Zeit wieder laufen. Eine Transaktionsdatenbank auf einem einzelnen Server erfüllt das nicht, egal wie gut die Richtlinie dazu formuliert ist. Erfüllt wird es durch Architektur: mehrere Replikate der Datenbank, automatisches Umschalten, Lastverteiler vor den Anwendungsservern, Backups, die tatsächlich zurückgespielt werden.

Der häufigste Fehler, den wir sehen, ist Compliance auf dem Papier. Es entstehen Richtlinien, Rollen und Prozessbeschreibungen, während die monolithische Anwendung auf derselben Maschine weiterläuft wie vor fünf Jahren. Die Aufsicht fragt am Ende nicht nach dem Dokument, sondern nach dem Wiederanlauf. Nachrüsten ist möglich, aber meist teurer als ein Neuentwurf der kritischen Teile; beginnen Sie dort, wo ein Ausfall am meisten kostet.

Wartungsvertrag Webanwendung Reaktionszeit: Was DORA in den Vertrag schreibt

DORA verlangt, dass Verträge mit IT-Dienstleistern messbare Leistungsziele enthalten. Für einen Wartungs- oder Hostingvertrag heißt das konkret: eine garantierte Reaktionszeit bei Störungen, eine definierte Zeit bis zur Wiederherstellung, Regelungen für Sicherheitsupdates und Backups, ein Prüfrecht und ein geordneter Ausstieg, falls der Dienstleister ausfällt. Ein Vertrag, der alles nur „nach bestem Bemühen“ zusagt, reicht dafür nicht.

Ehrlich ist dabei auch die Grenze: Eine Reaktionszeit lässt sich garantieren, die Lösung einer Störung nur nach bestem Bemühen. Ein seriöser Dienstleister schreibt beides in den Vertrag, statt eine Behebungszeit zu versprechen, die er bei einem unbekannten Fehler nicht halten kann. Wer Ihnen beides garantiert, hat entweder eine sehr einfache Anwendung oder einen sehr optimistischen Vertrieb.

Vier Schritte, mit denen Sie anfangen

Kritische Prozesse benennen. Legen Sie fest, welche Systeme den Geschäftsbetrieb tragen. Nur diese brauchen die höchste Stufe an Redundanz; das interne Berichtswesen darf länger stehen als die Antragsstrecke.

Einzelne Ausfallpunkte beseitigen. Für jedes kritische System die Frage: Was passiert, wenn dieser Server, diese Datenbank, dieser Anbieter ausfällt? Wo die Antwort „Stillstand“ lautet, braucht es ein Replikat oder einen zweiten Weg.

Überwachung und Wiederanlauf automatisieren. Störungen müssen erkannt werden, bevor ein Kunde anruft. Umschaltungen auf Ersatzsysteme und das Zurückspielen von Backups gehören als geprobte Abläufe hinterlegt, nicht als Anleitung im Wiki.

Regelmäßig proben. DORA verlangt wiederkehrende Tests der Widerstandsfähigkeit. Spielen Sie einen Ausfall durch, einen Datenverlust, einen Erpressungsangriff, und messen Sie, wie lange der Wiederanlauf wirklich dauert. Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung. Wie Sie Änderungen dabei ohne Risiko für den Betrieb einspielen, beschreibt der Artikel zur Staging-Umgebung.

Muss es Multi-Cloud sein?

Nein. DORA schreibt keine Technologie vor, sondern Ziele. Eine sauber gebaute Architektur bei einem einzigen Anbieter mit getrennten Verfügbarkeitszonen kann konform sein; zwei Anbieter parallel erhöhen die Redundanz, verdoppeln aber den Betriebsaufwand und die Zahl der Verträge, die Sie prüfen müssen. Entscheidend ist, dass Sie den Ausfall des Anbieters durchgespielt und einen Ausstieg vertraglich geregelt haben.

DORA und NIS2: Warum beides auf denselben Schreibtisch kommt

Die NIS2-Richtlinie richtet sich an Betreiber wichtiger und besonders wichtiger Einrichtungen quer durch die Branchen, DORA an den Finanzsektor. Beide verlangen Risikomanagement, die Meldung von Vorfällen und Kontrolle über Dienstleister. Wer die vier Schritte oben umgesetzt und seine Verträge nachgezogen hat, erfüllt damit den Kern beider Regelwerke. Die Unterschiede liegen in Meldefristen und Prüftiefe, und die klärt Ihre Rechtsabteilung, nicht Ihr Hoster.

Nehmen Sie den Wartungs- oder Hostingvertrag Ihres wichtigsten Systems und suchen Sie darin die Reaktionszeit, die Wiederherstellungszeit und die Regelung für den Ausstieg. Was fehlt, bringen Sie mit in den Potenzial-Check: eine halbe Stunde, kostenlos, und Sie wissen danach, was in Ihrer Architektur und in Ihrem Vertrag vor dem nächsten Prüfgespräch nachgezogen werden muss.