DORA: Was der Finanzsektor jetzt umsetzen muss und wie Zero-Trust-Segmentierung hilft

Seit dem 17. Januar 2025 gilt DORA verbindlich für den europäischen Finanzsektor. Anderthalb Jahre später ist aus dem Stichtag Alltag geworden: Aufsichtsbehörden fordern Informationsregister an, für schwerwiegende IT-Vorfälle laufen feste Meldefristen, und die ersten bedrohungsgeleiteten Penetrationstests sind im Gange. Wer die Verordnung bislang als Dokumentationsübung verstanden hat, stellt spätestens jetzt fest: Ohne technische Substanz geht es nicht.

Dieser Überblick ordnet ein, was DORA regelt, wen die Verordnung erfasst und was sich hinter den fünf Säulen verbirgt. Er zeigt außerdem, weshalb Zero-Trust-Segmentierung zu den wirksamsten Werkzeugen zählt, um die Vorgaben in die Praxis zu übersetzen.

Was hinter DORA steckt

DORA steht für Digital Operational Resilience Act, formal die Verordnung (EU) 2022/2554. In Kraft getreten am 16. Januar 2023, gilt sie seit dem 17. Januar 2025 unmittelbar in sämtlichen EU-Mitgliedstaaten. Eine nationale Umsetzung braucht es nicht, die Vorgaben wirken direkt. In Deutschland überwacht die BaFin ihre Einhaltung.

Das Ziel heißt digitale operationale Resilienz: Finanzunternehmen sollen schwere IT-Störungen und Cyberangriffe abwehren können, vor allem aber soll ihr Geschäftsbetrieb ihnen standhalten. DORA unterstellt, dass Vorfälle eintreten. Gefragt wird deshalb weniger, ob sich ein Angriff verhindern lässt, sondern ob kritische Funktionen währenddessen verfügbar bleiben und wie zügig der Normalbetrieb zurückkehrt.

Wen die Verordnung erfasst

Der Anwendungsbereich ist weit gefasst: Rund 20 Kategorien von Finanzunternehmen fallen darunter, neben Banken und Versicherern auch Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Handelsplätze, Fondsverwalter und Anbieter von Krypto-Dienstleistungen. Erfasst sind auch Unternehmen mit Sitz außerhalb der EU, sobald sie auf europäischen Märkten aktiv sind.

Bemerkenswert ist vor allem der zweite Adressatenkreis: IKT-Drittdienstleister. IT-Dienstleister, Cloud-Provider und Software-Häuser, die für regulierte Finanzunternehmen arbeiten, bekommen DORA über die Vertrags- und Prüfanforderungen ihrer Kunden zu spüren. Wer als kritischer IKT-Drittdienstleister eingestuft wird, untersteht sogar unmittelbar der europäischen Aufsicht; bei Verstößen drohen Zwangsgelder von bis zu einem Prozent des durchschnittlichen weltweiten Tagesumsatzes.

Die fünf Säulen im Überblick

Säule 1: IKT-Risikomanagement

Gefordert ist ein dokumentierter Rahmen, der IKT-Risiken kontinuierlich identifiziert, bewertet und behandelt: belastbare Systeme, die Erkennung ungewöhnlicher Aktivitäten, Business-Continuity-Pläne für kritische Funktionen und ein Lernprozess aus eigenen wie fremden Vorfällen. Die Verantwortung trägt ausdrücklich das Leitungsorgan. Der Vorstand kann IKT-Risiken nicht an die IT-Abteilung abschieben.

Fundament von allem ist Sichtbarkeit. Ohne Wissen darüber, welche Systeme existieren, wie sie kommunizieren und welche Abhängigkeiten zwischen Anwendungen bestehen, lassen sich Risiken weder einschätzen noch behandeln. Genau diese Bestandsaufnahme schreibt DORA vor.

Säule 2: Behandlung und Meldung von IKT-Vorfällen

Vorfälle sind nach einheitlichen Kriterien zu klassifizieren, schwerwiegende der Aufsicht zu melden. Die Fristen sind knapp bemessen: Erstmeldung binnen vier Stunden nach der Einstufung, spätestens 24 Stunden nach Kenntnisnahme; Zwischenbericht nach 72 Stunden; Abschlussbericht innerhalb eines Monats. Wer solche Zeiten halten will, braucht Erkennung, Bewertung und Berichtswege, bevor etwas passiert.

Säule 3: Tests der digitalen Resilienz

Der Risikorahmen ist regelmäßig zu prüfen, vom Schwachstellen-Scan bis zur szenariobasierten Übung. Für bedeutende Institute kommt mindestens alle drei Jahre ein bedrohungsgeleiteter Penetrationstest (TLPT) hinzu, angelehnt an das TIBER-EU-Rahmenwerk: Ein Angriffsteam simuliert reale Angreifer gegen die produktive Umgebung, kritische Funktionen eingeschlossen.

Säule 4: Management des IKT-Drittparteienrisikos

Finanzunternehmen müssen ein vollständiges Informationsregister aller IKT-Dienstleister führen, Mindestvertragsklauseln durchsetzen und für kritische Anbieter Ausstiegsstrategien bereithalten. Der Gedanke dahinter: Auslagern lässt sich die Leistung, nicht die Verantwortung. Konzentrationsrisiken, etwa wenn viele Institute am selben Cloud-Anbieter hängen, betrachtet die Aufsicht gesondert.

Säule 5: Informationsaustausch

DORA ermuntert Finanzunternehmen, Bedrohungsinformationen in vertrauenswürdigen Kreisen zu teilen. Diese Säule bleibt freiwillig, dient aber demselben Zweck: Der Sektor als Ganzes soll Angriffe früher erkennen und schneller darauf reagieren.

Der Kern: Weiterlaufen statt nur abwehren

Verdichtet man die fünf Säulen, bleibt eine Botschaft: Die Aufsicht erwartet, dass ein Finanzunternehmen einen erfolgreichen Angriff übersteht. Das bricht mit der traditionellen Denkschule, die alle Energie in die Abwehr an der Netzgrenze investiert. Resilienz bedeutet, die Ausbreitung eines Angriffs zu begrenzen, kritische Funktionen abzuschotten und den Vorfall geordnet abzuarbeiten, während das Kerngeschäft weiterläuft.

An diesem Punkt setzt Zero-Trust-Segmentierung an. Den Erstzugriff verhindert sie nicht, aber sie entscheidet mit darüber, ob aus einem kompromittierten System ein lokaler Zwischenfall wird oder ein unternehmensweiter Ausfall.

Was Zero-Trust-Segmentierung konkret zu DORA beiträgt

• Sichtbarkeit und Mapping (Säule 1): Eine Echtzeitkarte aller Kommunikationsbeziehungen zwischen Anwendungen, Workloads und Endgeräten liefert exakt die Bestandsaufnahme, die das IKT-Risikomanagement verlangt. Überflüssige Verbindungen und riskante Abhängigkeiten werden sichtbar, bevor Angreifer sie entdecken.
• Eindämmung als Architekturprinzip: Least-Privilege-Regeln zwischen Workloads bremsen die laterale Ausbreitung von Angriffen und Ransomware. Ein kompromittiertes System bleibt genau das und wird kein Flächenbrand.
• Ringfencing kritischer Funktionen: Kernbankanwendungen, Zahlungsinfrastruktur und Backup-Umgebungen lassen sich gezielt abschirmen. Gerade intakte Backups sind im Ernstfall die Bedingung dafür, dass Wiederherstellung überhaupt gelingt.
• Schnellere Erkennung: Die Verkehrsdaten der Segmentierung speisen das SIEM und machen ungewöhnliche Kommunikation sichtbar, ein direkter Beitrag zur Anomalie-Erkennung aus Säule 1 und zur Vorfallbewertung aus Säule 2.
• Reaktionsfähigkeit im Ernstfall: Betroffene Systeme oder ganze Zonen sind mit wenigen Schritten isoliert, während die Aufklärung läuft. Das verkürzt Vorfälle und unterfüttert die Meldungen mit belastbaren Fakten.
• Nachweisbarkeit: Dokumentierte Richtlinien und Kommunikationskarten geben Prüfern konkrete Belege statt Absichtserklärungen, nützlich für DORA-Prüfungen ebenso wie für ISO 27001, PCI DSS oder SWIFT-Anforderungen.

Solche Kontrollen lassen sich auch extern beziehen: Managed-Mikrosegmentierung deckt Sichtbarkeit, Regelwerk und laufenden Betrieb bis auf Workload-Ebene ab.

Warum gerade Banken und Finanzdienstleister profitieren

Zero-Trust-Segmentierung wirkt im Finanzwesen aus mehreren Gründen besonders gut. Einige davon zielen direkt auf den DORA-Kontext:

• Systemrelevante Kernsysteme: Handels-, Zahlungs- und Kernbankumgebungen sind lohnende Ziele mit enormem Schadenpotenzial. Auswertungen von IBM X-Force führten den Bankensektor über Jahre als das am häufigsten angegriffene Ziel von Cyberkriminellen.
• Legacy- und ungepatchte Systeme: Zwischen bekannt gewordener Schwachstelle und eingespieltem Patch liegt oft ein langes Zeitfenster; manche Altsysteme erhalten überhaupt keine Updates mehr. Segmentierung reduziert die Erreichbarkeit solcher Systeme deutlich und verschafft Zeit.
• Cloud-Migration ohne Kontrollverlust: Richtlinien haften am Workload, nicht an der Infrastruktur. Zieht eine Anwendung in die Cloud, zieht der Schutz mit. Genau dieser Punkt kommt bei DORA-Prüfungen von Auslagerungen regelmäßig auf.
• Automatisierte Ransomware-Reaktion: Die schnellste Eindämmung ist das Kappen der Kommunikationswege. Bekannte Ausbreitungsports wie RDP und SMB lassen sich präventiv schließen und im Ernstfall organisationsweit sperren.
• Messbarer Effekt: Modellrechnungen beziffern die durch Zero-Trust-Segmentierung vermiedenen Ausfallkosten für ein typisches Großunternehmen auf gut 20 Millionen US-Dollar pro Jahr. Für die Vorstandsvorlage zählt am Ende beides: gesenktes Risiko und belegbare Zahlen.

Fünf praktische Schritte Richtung DORA-Konformität

In der Praxis hat sich diese Reihenfolge bewährt:

1. Kritische Funktionen bestimmen: Welche Prozesse müssen im Ernstfall weiterlaufen, und welche Systeme tragen sie? Diese Liste steuert alle weiteren Entscheidungen.
2. Kommunikation kartieren: Ohne Echtzeitsicht auf Datenflüsse bleiben Risikoanalyse und Register graue Theorie. Beim Mapping tauchen regelmäßig Verbindungen auf, die niemand mehr erklären kann.
3. Drittparteien erfassen: Informationsregister aufbauen, Verträge an den DORA-Mindestklauseln messen, Ausstiegsszenarien für kritische Anbieter dokumentieren.
4. Segmentierung risikobasiert einführen: Zunächst die kritischen Funktionen per Ringfencing schützen und riskante Ports schließen. Danach die Umgebung Schritt für Schritt weiter segmentieren, im Beobachtungsmodus getestet, bevor Regeln scharfgeschaltet werden.
5. Testen und üben: Resilienztests und TLPT nicht als Pflichtprogramm abhaken. Wer die eigene Kommunikationskarte kennt, baut Testszenarien gezielt und übersetzt Erkenntnisse direkt in Richtlinien.

Der Einstieg beginnt mit einer ehrlichen Bestandsaufnahme der kritischen Funktionen und ihrer Kommunikationsbeziehungen. Von dort führt der Weg über Richtliniendesign und Beobachtungsmodus in den Regelbetrieb, bei Bedarf gestützt auf externe Spezialisten für Segmentierung und Resilienztests.

Grundlage dieses Beitrags sind zwei Fachartikel zu DORA und zur Zero-Trust-Segmentierung im Finanzsektor sowie der Text der Verordnung (EU) 2022/2554.

Passende Managed Services

• Mikrosegmentierung – Sichtbarkeit, Least-Privilege-Regeln und Eindämmung bis auf Workload-Ebene, umgesetzt mit Plattformen wie Illumio.