DORA: Was der Finanzsektor wissen muss und wie Zero-Trust-Segmentierung dabei hilft

Seit dem 17. Januar 2025 gilt DORA verbindlich für den europäischen Finanzsektor. Eineinhalb Jahre später ist aus dem Stichtag Alltag geworden: Aufsichtsbehörden fragen Informationsregister ab, schwerwiegende IT-Vorfälle müssen nach festen Fristen gemeldet werden, und die ersten bedrohungsgeleiteten Penetrationstests laufen. Wer die Verordnung bisher als reines Papierprojekt behandelt hat, merkt spätestens jetzt: DORA verlangt technische Substanz.

Dieser Beitrag erklärt, was DORA regelt, für wen die Verordnung gilt, was hinter den fünf Säulen steckt und warum Zero-Trust-Segmentierung eines der wirksamsten Werkzeuge ist, um die Anforderungen in die Praxis zu bringen.

Was ist DORA?

DORA steht für Digital Operational Resilience Act, formal die Verordnung (EU) 2022/2554 . Sie trat am 16. Januar 2023 in Kraft und gilt seit dem 17. Januar 2025 unmittelbar in allen EU-Mitgliedstaaten. Als Verordnung braucht sie keine nationale Umsetzung: Die Anforderungen gelten direkt, in Deutschland überwacht die BaFin ihre Einhaltung.

Das Ziel ist digitale operationale Resilienz: Finanzunternehmen sollen schwere IT-Störungen und Cyberangriffe nicht bloß abwehren, ihr Geschäftsbetrieb soll sie aushalten. DORA geht davon aus, dass Vorfälle passieren. Die Verordnung fragt deshalb weniger, ob ein Angriff verhindert wird, und mehr, ob kritische Funktionen währenddessen weiterlaufen und wie schnell der Normalzustand zurückkehrt.

Für wen gilt DORA?

Der Anwendungsbereich ist breit: Rund 20 Kategorien von Finanzunternehmen fallen unter die Verordnung, darunter Banken, Versicherer, Zahlungs- und E-Geld-Institute, Wertpapierfirmen, Handelsplätze, Fondsverwalter und Anbieter von Krypto-Dienstleistungen. Auch Unternehmen außerhalb der EU sind betroffen, sobald sie auf EU-Märkten tätig sind.

Neu ist vor allem der zweite Kreis: IKT-Drittdienstleister. Wer als IT-Dienstleister, Cloud-Anbieter oder Software-Haus für regulierte Finanzunternehmen arbeitet, bekommt DORA über Vertragsanforderungen und Prüfpflichten seiner Kunden zu spüren. Als kritisch eingestufte IKT-Drittdienstleister stehen sogar unter direkter Aufsicht der europäischen Behörden, mit Zwangsgeldern von bis zu einem Prozent des durchschnittlichen weltweiten Tagesumsatzes bei Verstößen.

Die fünf Säulen von DORA

1. IKT-Risikomanagement

Finanzunternehmen brauchen einen dokumentierten Rahmen, der IKT-Risiken laufend identifiziert, bewertet und behandelt. Dazu gehören 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. Wichtig: Die Verantwortung liegt ausdrücklich beim Leitungsorgan. Der Vorstand kann IKT-Risiken nicht an die IT-Abteilung delegieren.

Die Grundlage von allem ist Sichtbarkeit. Wer nicht weiß, welche Systeme existieren, wie sie kommunizieren und welche Abhängigkeiten zwischen Anwendungen bestehen, kann Risiken weder bewerten noch behandeln. Genau diese Bestandsaufnahme fordert DORA explizit ein.

2. Behandlung und Meldung von IKT-Vorfällen

Vorfälle müssen nach einheitlichen Kriterien klassifiziert und schwerwiegende Vorfälle an die Aufsicht gemeldet werden. Die Fristen sind eng: Die Erstmeldung ist innerhalb von vier Stunden nach der Einstufung fällig, spätestens 24 Stunden nach Kenntnis. Ein Zwischenbericht folgt nach 72 Stunden, der Abschlussbericht innerhalb eines Monats. Solche Fristen lassen sich nur halten, wenn Erkennung, Bewertung und Berichtswege vorher stehen.

3. Tests der digitalen Resilienz

Der Risikorahmen muss regelmäßig getestet werden, von Schwachstellen-Scans bis zu szenariobasierten Übungen. 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, inklusive der kritischen Funktionen.

4. Management des IKT-Drittparteienrisikos

Finanzunternehmen müssen ein vollständiges Informationsregister aller IKT-Dienstleister führen, Mindestvertragsklauseln durchsetzen und Ausstiegsstrategien für kritische Anbieter vorhalten. Die Logik dahinter: Auslagern lässt sich die Leistung, nicht die Verantwortung. Konzentrationsrisiken, etwa wenn viele Institute vom selben Cloud-Anbieter abhängen, nimmt die Aufsicht gesondert in den Blick.

5. Informationsaustausch

DORA ermutigt Finanzunternehmen, Bedrohungsinformationen in vertrauenswürdigen Kreisen zu teilen. Diese Säule ist freiwillig, zahlt aber auf dasselbe Ziel ein: Der Sektor als Ganzes soll Angriffe früher erkennen und schneller reagieren.

Der Kern von DORA: Weiterbetrieb statt Perimeter-Denken

Zieht man die fünf Säulen zusammen, bleibt eine Botschaft übrig: Die Aufsicht erwartet, dass Finanzunternehmen einen erfolgreichen Angriff überstehen. Das ist ein Bruch mit der klassischen Denkweise, die alle Energie in die Abwehr am Perimeter steckt. Resilienz heißt, die Ausbreitung eines Angriffs zu begrenzen, kritische Funktionen abzuschirmen und den Vorfall kontrolliert abzuarbeiten, während das Kerngeschäft weiterläuft.

Genau an dieser Stelle wird Zero-Trust-Segmentierung relevant. Sie verhindert keinen Erstzugriff, aber sie entscheidet darüber, ob aus einem kompromittierten System ein lokaler Zwischenfall oder ein unternehmensweiter Ausfall wird.

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

• Sichtbarkeit und Mapping (Säule 1): Eine Echtzeit-Karte aller Kommunikationsbeziehungen zwischen Anwendungen, Workloads und Endgeräten liefert genau die Bestandsaufnahme, die das IKT-Risikomanagement fordert. Unnötige Verbindungen und riskante Abhängigkeiten werden sichtbar, bevor ein Angreifer sie findet.
• Eindämmung als Architekturprinzip: Least-Privilege-Regeln zwischen Workloads begrenzen die laterale Ausbreitung von Angriffen und Ransomware. Ein kompromittiertes System bleibt ein kompromittiertes System und wird kein Flächenbrand.
• Ringfencing kritischer Funktionen: Kernbankanwendungen, Zahlungsinfrastruktur und Backup-Umgebungen lassen sich gezielt abschirmen. Gerade geschützte Backups sind im Ernstfall die Voraussetzung dafür, dass Wiederherstellung überhaupt funktioniert.
• Schnellere Erkennung: Die Verkehrsdaten der Segmentierung fließen ins SIEM und machen ungewöhnliche Kommunikation sichtbar, ein direkter Beitrag zur Anomalie-Erkennung aus Säule 1 und zur Vorfallbewertung aus Säule 2.
• Reaktion im Vorfall: Betroffene Systeme oder ganze Zonen lassen sich mit wenigen Schritten isolieren, während die Aufklärung läuft. Das verkürzt die Dauer eines Vorfalls und stützt die Meldefristen mit belastbaren Fakten.
• Nachweisbarkeit: Dokumentierte Richtlinien und Kommunikationskarten liefern Prüfern konkrete Belege statt Absichtserklärungen. Das hilft bei DORA-Prüfungen ebenso wie bei ISO 27001, PCI DSS oder SWIFT-Anforderungen.

Warum gerade Banken und Finanzdienstleister profitieren

Illumio hat acht Gründe zusammengetragen, warum der Finanzsektor besonders von Zero-Trust-Segmentierung profitiert. Einige davon treffen den DORA-Kontext im Kern:

• Systemrelevante Kernsysteme: Handels-, Zahlungs- und Kernbankumgebungen sind attraktive Ziele mit enormem Schadenspotenzial. Nach Auswertungen von IBM X-Force war der Bankensektor über Jahre das meistangegriffene Ziel für Cyberkriminelle.
• Legacy- und ungepatchte Systeme: Zwischen Schwachstelle und Patch liegt oft ein langes Zeitfenster, manche Altsysteme erhalten gar keine Updates mehr. Segmentierung reduziert die Erreichbarkeit solcher Systeme drastisch und verschafft Zeit.
• Cloud-Migration ohne Kontrollverlust: Richtlinien hängen am Workload statt an der Infrastruktur. Wandert eine Anwendung in die Cloud, wandert der Schutz mit, ein Punkt, der bei DORA-Prüfungen von Auslagerungen regelmäßig zur Sprache kommt.
• Automatisierte Ransomware-Reaktion: Die schnellste Eindämmung ist das Kappen der Kommunikationswege. Bekannte Ausbreitungsports wie RDP und SMB lassen sich vorab schließen und im Ernstfall organisationsweit blockieren.
• Messbarer Nutzen: Illumio beziffert die vermiedenen Ausfallkosten durch Zero-Trust-Segmentierung auf gut 20 Millionen US-Dollar pro Jahr für ein typisches Großunternehmen. Für die Vorstandsvorlage zählt am Ende beides: weniger Risiko und belegbare Zahlen.

Praktische Schritte Richtung DORA-Konformität

Aus den Projekten der letzten Jahre hat sich eine Reihenfolge bewährt:

• 1. Kritische Funktionen bestimmen: Welche Prozesse müssen im Ernstfall weiterlaufen, und welche Systeme tragen sie? Diese Liste steuert alle weiteren Schritte.
• 2. Kommunikation kartieren: Ohne Echtzeit-Sicht auf Datenflüsse bleiben Risikoanalyse und Register Theorie. Das Mapping deckt regelmäßig Verbindungen auf, die niemand mehr erklären kann.
• 3. Drittparteien erfassen: Informationsregister aufbauen, Verträge gegen die DORA-Mindestklauseln prüfen, Ausstiegsszenarien für kritische Anbieter dokumentieren.
• 4. Segmentierung risikobasiert einführen: Zuerst die kritischen Funktionen per Ringfencing schützen und riskante Ports schließen, danach die Umgebung schrittweise weiter segmentieren, im Beobachtungsmodus getestet, bevor Regeln scharfgeschaltet werden.
• 5. Testen und üben: Resilienztests und TLPT nicht als Pflichtübung sehen. Wer die eigene Kommunikationskarte kennt, kann Testszenarien gezielt bauen und Erkenntnisse direkt in Richtlinien übersetzen.

DORA mit KAEMI umsetzen

Als Managed Service Provider und Illumio EMEA Partner of the Year begleiten wir bei KAEMI Finanzunternehmen und ihre Dienstleister auf genau diesem Weg: Zero-Trust-Mikrosegmentierung von der Sichtbarkeit über das Richtliniendesign bis zum laufenden Betrieb. Für die Testanforderungen aus Säule 3 liefern unsere Assessments und Penetrationstests die Standortbestimmung, aus der ein priorisierter Maßnahmenplan entsteht.

Wenn Sie wissen möchten, wo Ihre Umgebung in Sachen DORA heute steht, sprechen Sie mit uns . Der erste Schritt ist eine ehrliche Bestandsaufnahme der kritischen Funktionen und ihrer Kommunikation.

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