DORA nach 15 Monaten: Was Security-Teams in Finanzinstituten aus den ersten Audits 2026 lernen
7 Min. Lesezeit
DORA gilt seit dem 17. Januar 2025 verbindlich für Finanzinstitute in der EU. Nach fünfzehn Monaten Regelbetrieb sind die ersten Audit-Zyklen durch. Die Lehren daraus sind für Security-Teams in Banken, Versicherungen und Asset-Managern konkret und unbequem. Das Incident-Reporting in vier Stunden, die Dritt-Anbieter-Verträge mit neuen Klauseln und das TLPT-Testregime bringen Operationen an Grenzen, die mit den üblichen Prozessen nicht mehr abzudecken sind.
Das Wichtigste in Kürze
- Vier-Stunden-Klassifizierung ist der Engpass. Nach erster Meldung beim Aufseher bleiben 72 Stunden für einen Zwischenbericht, ein Monat für den Abschluss. Der limitierende Faktor in der Praxis ist die erste Klassifizierungsentscheidung binnen weniger Stunden.
- Dritt-Anbieter-Register ist Audit-Prio eins. Die geforderten Vertrags-Klauseln (Audit-Rechte, Exit-Strategie, SLA-Garantien) sind in vielen Bestandsverträgen nicht vorhanden. Nachverhandlung mit Cloud-Providern und kritischen SaaS-Anbietern läuft bei vielen Instituten parallel zum Regelbetrieb.
- TLPT trifft auf unterdimensionierte Red-Teams. Threat-Led Penetration Testing nach TIBER-EU braucht akkreditierte Anbieter und interne Defender, die das mitgehen. Der Markt für beide Seiten ist eng, die Planungsvorläufe liegen bei sechs bis neun Monaten.
VerwandtNIS2-Meldewege: Die erste Incident-Stunde operativ gestalten / Adaptive MFA in Entra, Okta und Duo: NIS2-Rollout
Was die ersten Audits 2026 wirklich gezeigt haben
Die Aufseher in der EU (BaFin, EBA, ESMA, EIOPA und die ECB für die größten Institute) haben 2025 und im ersten Quartal 2026 die ersten Audit-Runden gefahren. Die inhaltlichen Fragen waren vorhersehbar. Die Antworten aus den Instituten waren es selten. Die häufigsten Findings aus den Gesprächen in Compliance-Abteilungen deutscher Banken lassen sich in drei Themen bündeln: Incident-Klassifizierung in der engen Frist, Vertragslücken bei Dritt-Anbietern und unterdimensionierte Testkapazitäten für TLPT. Keines dieser Themen ist neu, aber jedes hat durch DORA einen verbindlichen Rahmen bekommen, der die früheren internen Toleranzen sprengt. Dazu kommt, dass die Aufseher ihre Interpretation präzisieren, sobald mehr Fälle vorliegen. Was 2025 als Pilot-Regelauslegung durchging, wird 2026 strenger gewichtet.
Die erste Stunde nach einem Incident ist der entscheidende Zeitraum. Die Regulierung verlangt eine initiale Meldung binnen vier Stunden nach Klassifizierung eines ICT-Incidents als major. Die Klassifizierung selbst muss auf Basis nachvollziehbarer Kriterien laufen. In der Praxis heißt das: Wenn um drei Uhr morgens ein Alarm kommt, der sich als möglicher Major-Incident darstellt, muss das SOC in wenigen Stunden entscheiden, ob die Meldeschwelle erreicht ist. Parallel läuft die Vorbereitung der Meldung selbst. Wer das nicht in der Runbook-Automation hat, läuft in Stress. Die Lehre aus den ersten Audits: Institute ohne klare Eskalations-Ketten und ohne definierte Klassifizierungsmatrix hatten in den ersten Monaten mehr als ein Finding in diesem Bereich.
Dritt-Anbieter-Register und Exit-Szenarien
Die zweite große Baustelle sind die Verträge mit ICT-Dritt-Anbietern. DORA fordert in den Verträgen explizite Klauseln zu Audit-Rechten, Exit-Strategien, Service-Level-Garantien, Sicherheitsverpflichtungen und Incident-Meldepflichten. Die Realität: Die meisten Cloud-Verträge, SaaS-Abonnements und Outsourcing-Vereinbarungen aus den Vorjahren erfüllen diese Anforderungen nicht vollständig. Die Nachverhandlung ist nicht einseitig. Anbieter mit Marktmacht (Hyperscaler, führende SaaS-Plattformen) haben eigene Vertragsstandards, die mit DORA-Anforderungen nicht immer deckungsgleich sind.
Die Lehre aus den ersten fünfzehn Monaten: Institute, die das Thema früh proaktiv angefasst haben, haben bei den Hyperscalern angepasste Vertragsanhänge bekommen, die einen Großteil der DORA-Anforderungen abbilden. Institute, die gewartet haben, verhandeln jetzt nach. Die Verhandlungsposition ist ungleich schlechter, weil der Anbieter weiß, dass die Zeit drängt. Ein Detail, das oft übersehen wird: Die Register-Pflicht ist kumulativ. Jede Aktualisierung eines Vertrags, jede neue Unterauftragnehmer-Anbindung und jede Kritikalitätsänderung muss zeitnah im DORA-Register nachgehalten werden. Ohne Workflow zur kontinuierlichen Pflege veraltet das Register innerhalb weniger Monate.
Wo DORA-Umsetzungen 2026 scheitern
- Klassifizierungsmatrix nur auf Papier, nicht im SOC-Runbook
- Dritt-Anbieter-Register ohne zentrale Pflege-Verantwortung
- Vertragslücken bei kritischen Cloud- und SaaS-Anbietern ignoriert
- TLPT-Planung erst im Audit-Jahr statt sechs Monate vorher
Was DORA-Readiness stützt
- Automatisierte Klassifizierung im SIEM, nicht als Excel-Tabelle
- Dediziertes Register-Team mit Schnittstelle zu Vertragsmanagement
- Vertragsaddenda mit den Top-20-Anbietern parallel verhandelt
- TLPT-Planung mit 9 Monaten Vorlauf, inklusive interner Red-Team-Vorbereitung
Die Exit-Strategie ist das Feld, in dem viele Institute unterschätzt haben, was gefordert ist. DORA verlangt nicht nur eine Kündigungs-Klausel, sondern einen belastbaren Plan, wie im Fall eines Anbieter-Ausfalls oder einer Terminierung der Betrieb in überschaubarer Zeit auf eine Alternative wandert. Bei einem kritischen SaaS-Kernbankensystem ist das kein juristisches Thema, sondern ein mehrjähriges Transitions-Projekt. Die Aufseher haben in den ersten Audits dokumentiert, dass ein Papier-Exit-Plan ohne realistischer Durchspielung nicht ausreicht.
Das bedeutet in der Praxis: Für die Top-fünf bis Top-zehn kritischen Dritt-Anbieter pro Institut braucht es einen ausgearbeiteten Transitions-Plan mit Zeitfenster, Ziel-Architektur, Datenmigrations-Ansatz und klarer Ownership. Für Cloud-Provider ist das oft ein Multi-Cloud- oder Multi-Region-Setup, für SaaS-Kernsysteme eine Backup-Provider-Strategie oder ein internes Fallback. Die Dokumentation dieser Pläne ist der erste Schritt, die periodische Aktualisierung und die gelegentliche Simulations-Übung sind der zweite. Wer das ernsthaft durchzieht, findet Schwachstellen in den eigenen Prozessen, die im regulären Betrieb nicht sichtbar werden.
TLPT in der Praxis: Markt, Kapazität und interne Reife
Threat-Led Penetration Testing nach TIBER-EU ist die strengste Testanforderung unter DORA und greift bei den Instituten, die unter die TLPT-Schwellen fallen (vereinfacht: größere Banken, Zahlungsdienstleister und Marktinfrastruktur-Betreiber). Der Test wird von akkreditierten Red-Team-Anbietern durchgeführt, mit Ziel auf das reale Produktions-System und ohne vorherige Ankündigung im operativen Verteidigungsteam. Die Herausforderung 2026 liegt doppelt.
Erstens ist der Markt der akkreditierten Anbieter eng. In Deutschland und Europa gibt es zwei-stellige, nicht drei-stellige Zahlen an akkreditierten Red-Team-Providern für TLPT. Die Terminkalender sind sechs bis neun Monate im Voraus gefüllt. Wer im zweiten Halbjahr 2026 testen will, verhandelt jetzt. Zweitens ist die interne Reife entscheidend. Ein TLPT bringt nur dann Erkenntnisse, wenn das Blue Team, die Detection-Pipeline und die Incident-Response-Prozesse reif genug sind, um die Simulation zu verarbeiten. Institute, die den TLPT-Zeitpunkt zu früh gewählt haben, haben wertvolle Red-Team-Kapazität auf ein Ergebnis verbraucht, das schon aus einer Asset-Inventur ersichtlich gewesen wäre.
Die pragmatische Reihenfolge, die sich 2026 herauskristallisiert, sieht so aus: Erst interne Reifegradprüfung, dann gezielte Purple-Team-Übungen über sechs Monate, dann TLPT mit externem akkreditiertem Anbieter. Wer direkt mit dem TLPT startet, läuft in ein sehr teures Audit mit überwiegend generischen Findings. Wer die Vorstufen baut, bekommt aus dem TLPT spezifische Schwachstellen-Reports, die den Mehrwert rechtfertigen.
Ein zusätzlicher Punkt, der in der zweiten DORA-Runde sichtbar wird, ist die Integration von TLPT-Erkenntnissen in das laufende Risikomanagement. Viele Institute behandeln TLPT-Berichte wie klassische Pentest-Reports: Findings werden priorisiert, gefixt und abgehakt. Das greift zu kurz. Die Aufsicht erwartet, dass TLPT-Erkenntnisse in die strategische Risikoanalyse einfließen, dass Schwachstellen-Trends über mehrere Tests dokumentiert werden und dass die Wirksamkeit von Mitigations in Folge-Tests verifiziert wird. Der Unterschied zwischen reinem Pentest-Tracking und echtem Resilience-Management wird in der zweiten Audit-Runde zum Prüffeld.
Die Schnittstelle zur Business-Continuity-Planung wird ebenfalls geprüft. TLPT simuliert Angreifer-Szenarien, BCP plant Ausfall-Szenarien. Beide Disziplinen laufen in vielen Instituten getrennt. DORA fordert ihre Verzahnung. Wer die Übungen koordiniert fährt, schafft Evidenz für die Resilienz-Prüfung, die deutlich belastbarer ist als getrennte Einzel-Nachweise.
Der operative Fahrplan für Security-Teams in der zweiten DORA-Phase
Für Security-Teams, die das erste DORA-Jahr überstanden haben und jetzt die zweite Audit-Runde vorbereiten, hat sich ein Vier-Phasen-Rhythmus bewährt.
Der Rhythmus hat zwei Vorteile. Erstens entkoppelt er die TLPT-Durchführung von der Audit-Vorbereitung, sodass beide Themen die eigene Aufmerksamkeit bekommen, die sie brauchen. Zweitens gibt er dem Incident-Management-Team Zeit, Runbook-Änderungen nach jeder Phase einzubauen, ohne dass es zu Pile-Up kommt. Wer alles ins vierte Quartal packt, hat im Audit eine Dokumentation, die auf dem Papier gut aussieht, aber im realen Betrieb nicht gelebt wurde.
Eine Beobachtung, die in Audit-Gesprächen immer wieder auftaucht: Die Aufseher prüfen nicht nur die Existenz von Prozessen, sondern ihre tatsächliche Anwendung. Ein Incident-Klassifizierungsprozess, der in den letzten sechs Monaten nicht benutzt wurde, weil kein Major-Incident vorlag, wird trotzdem geprüft. Die Aufseher verlangen dann Übungen oder Tabletop-Exercises, die die Einsatzbereitschaft dokumentieren. Institute, die Tabletop-Exercises vierteljährlich durchführen, kommen in diesen Fragen deutlich besser weg als solche, die das nur jährlich machen.
Ein weiterer Aspekt, der in der zweiten Welle häufiger fällt, ist die Rolle der Geschäftsleitung. DORA ist kein reines Compliance-Thema und kein reines IT-Thema. Die Verantwortung liegt beim Vorstand, nicht bei der zweiten Führungsebene. Aufseher prüfen, ob der Vorstand die DORA-Maßnahmen aktiv steuert, ob er regelmäßig Berichte bekommt und ob er die Remediations-Roadmap mitbeschlossen hat. Wer das an die IT-Leitung delegiert, bekommt Findings auf Vorstandsebene. Institute mit einer etablierten ICT-Risk-Review im Vorstand (meist quartalsweise mit eigener Agenda) liefern deutlich glaubwürdigere Evidenz als solche, die DORA als technisches Projekt behandeln.
Schließlich verändert DORA die Zusammenarbeit zwischen Informationssicherheit, IT-Betrieb und operativer Compliance. Die drei Funktionen müssen in denselben Workflows laufen, nicht in getrennten Silos. Institute, die in der ersten Runde noch mit Excel-basierten Handovers zwischen CISO, CIO und Compliance gearbeitet haben, bauen in der zweiten Runde gemeinsame GRC-Plattformen auf, in denen Findings, Maßnahmen und Evidenzen zentral geführt werden. Das reduziert Suchzeiten im Audit und zeigt der Aufsicht eine koordinierte Organisation statt mehrerer Einzel-Dokumentationen.
Zum Schluss ein Punkt, der den Unterschied zwischen Audit-Pflicht und Resilienz-Nutzen macht. DORA ist in der Praxis ein Rahmen, der Incident-Response-Reife und Drittpartei-Risikomanagement auf ein Niveau hebt, das viele Institute ohnehin brauchen. Wer die Anforderungen nur als Compliance-Pflicht sieht, bekommt teuere Dokumentation ohne Mehrwert. Wer die Anforderungen als Gelegenheit nutzt, die eigene Widerstandsfähigkeit gegen ICT-Störungen zu verbessern, hat nach zwölf Monaten nicht nur einen sauberen Audit-Bericht, sondern auch weniger nächtliche Überraschungen. Die Investitionen in SIEM-Automation, klare Runbooks und belastbare Exit-Pläne zahlen sich unabhängig von der Regulierung aus. DORA legt den Zeitrahmen fest, in dem sie gebaut werden müssen.
Häufige Fragen
Welche Institute fallen unter DORA?
Die Regulierung gilt für alle beaufsichtigten Finanzinstitute in der EU: Banken, Versicherungen, Wertpapierfirmen, Zahlungsdienstleister, E-Geld-Institute, Investmentfonds, Handelsinfrastrukturen und kritische ICT-Dritt-Anbieter. Es gibt Erleichterungen für Kleininstitute unter bestimmten Schwellenwerten, aber keine vollständige Ausnahme. Wer als Dienstleister für Finanzinstitute tätig ist, ohne selbst reguliert zu sein, bekommt über die Dritt-Anbieter-Klauseln der Kunden DORA-relevante Vorgaben durch die Hintertür.
Wie unterscheidet sich DORA von NIS2?
DORA ist sektor-spezifisch für Finanzinstitute und hat detailliertere Anforderungen an Incident-Reporting, Tests und Dritt-Anbieter-Management. NIS2 gilt branchenübergreifend und ist in manchen Aspekten oberflächlicher. Wo beide greifen, hat DORA Vorrang innerhalb seines Scope.
Was ist die Rolle der kritischen ICT-Dritt-Anbieter (CTPP)?
Die EU-Aufseher benennen Anbieter, die für mehrere Finanzinstitute kritisch sind, als CTPP und unterstellen sie einem eigenen Aufsichtsregime. Dazu gehören in der Regel große Cloud-Anbieter, zentrale Dienstleister für Zahlungsverkehr und spezialisierte Kernbankensystem-Anbieter. Die CTPP-Liste wird jährlich aktualisiert.
Wie oft muss ein TLPT durchgeführt werden?
Für Institute, die unter die TLPT-Pflicht fallen, ist ein Test mindestens alle drei Jahre vorgeschrieben. Nach wesentlichen Änderungen in der IT-Landschaft oder nach signifikanten Incidents kann die Aufsicht einen vorgezogenen Test verlangen. Die Planungsvorläufe liegen bei sechs bis neun Monaten.
Welche Rolle spielen interne Audits in der DORA-Umsetzung?
Die Interne Revision hat eine zentrale Rolle. Sie prüft kontinuierlich, ob ICT-Risikomanagement-Prozesse den DORA-Anforderungen entsprechen. Gleichzeitig berichtet sie an Vorstand und Aufsichtsrat. Ohne ausreichende interne Auditkapazität wird die externe Aufsichtsprüfung zum Stresstest, auf den Sie unvorbereitet sind.
Mehr aus dem MBF Media Netzwerk
Predictive Maintenance im Mittelstand: 100-Tage-Einstieg 2026
Quelle Titelbild: Pexels / Erik Mclean (px:9218590)
