Zurück zu Insights

OPERATIONELLE RESILIENZ

Cloud und Auslagerung unter DORA: Was DACH-Aufseher jetzt erwarten

13. Mai 20265 Min. Lesezeit Aegiron Capital Group
In diesem Artikel · 9 Abschnitte
  1. Das Informationsregister: kleiner Name, großes Projekt
  2. Konzentrationsrisiko und die Hyperscaler-Frage
  3. Exit-Strategien: der Fiktionstest
  4. Die DACH-Schicht obendrauf
  5. Sub-Auslagerung: die Kette unter dem Vertrag
  6. Wenn es bricht: Vorfälle treffen Auslagerung
  7. Eine Arbeits-Checkliste
  8. Testen: vom Tabletop zum TLPT
  9. Fazit

Ein Jahrzehnt lang landete jedes Gespräch zwischen einem Fintech und einem DACH-Aufseher irgendwann bei derselben Frage: „Und wer betreibt das eigentlich?“ Die Antworten — hier ein Hyperscaler, dort ein BPO-Dienstleister, darunter eine Kette von Subunternehmern — wurden von einem Flickwerk aus Auslagerungsrundschreiben regiert. Seit Januar 2025 hat DORA das Flickwerk für IKT-Dienstleistungen durch ein einheitliches, unmittelbar anwendbares Regime ersetzt — und die Frage deutlich geschärft; für Auslagerungen ohne IKT-Bezug, etwa ein klassisches BPO, gilt weiterhin das bisherige Auslagerungsrecht.

Der Digital Operational Resilience Act behandelt IKT-Drittparteienrisiko als eine seiner fünf Säulen — neben Risikomanagement, Vorfallsmeldung, Resilienztests und Informationsaustausch. Der konzeptionelle Wandel zählt: Auslagerung ist kein Beschaffungsthema mit Compliance-Anhang mehr, sondern Teil der operativen Resilienz des Hauses — verantwortet vom Leitungsorgan und laufend nachzuweisen.

Das Informationsregister: kleiner Name, großes Projekt

Jedes Finanzunternehmen muss ein Informationsregister über sämtliche vertraglichen Vereinbarungen mit IKT-Drittdienstleistern führen — gemappt auf die unterstützten Funktionen, nach Kritikalität gekennzeichnet und an die Aufsicht berichtet. Wer das als Spreadsheet-Übung versucht hat, entdeckte die eigentliche Schwierigkeit: Das Register erzwingt eine ehrliche Inventur des Bestands — inklusive der Schattenverträge, der nie dokumentierten Sub-Auslagerungsketten und der „temporären“ Tools, die tragend geworden sind. In der DACH-Aufsichtskultur ist ein unvollständiges Register keine Formalie — es ist der Beleg, dass das Haus seine eigenen Abhängigkeiten nicht kennt.

Die Vertragsebene folgt aus dem Register. DORA schreibt Mindestvertragsinhalte für IKT-Dienstleistungen vor — Prüf- und Zugangsrechte, Kündigungsrechte, Bedingungen für Unterauftragsvergabe und, bei kritischen Funktionen, tatsächlich ausführbare Exit-Strategien. Altverträge aus früheren Regimen erfüllen das selten out of the box; Repapering-Programme gehörten zu den prägenden Arbeitssträngen von 2025 und 2026.

Konzentrationsrisiko und die Hyperscaler-Frage

DACH-Aufseher äußern seit Jahren Konzentrationsbedenken zur Cloud-Infrastruktur; DORA gibt der Sorge auf zwei Ebenen Zähne. Auf Institutsebene müssen Häuser Konzentration vor Vertragsschluss bewerten — inklusive der unbequemen Frage, was passiert, wenn der gewählte Anbieter ausfällt, degradiert oder kommerziell feindselig wird. Auf Unionsebene werden kritische IKT-Drittdienstleister unter einem eigenen Überwachungsrahmen designiert, mit direkten Prüfbefugnissen der europäischen Aufsichtsbehörden gegenüber den Anbietern. Zum ersten Mal stehen die Hyperscaler innerhalb des Aufsichtsperimeters statt jenseits davon.

Die Cloud-Diskussion im Finanzwesen ist gereift: von „Ist das erlaubt?“ über „Ist das sicher?“ zur DORA-Frage: „Können Sie beweisen, dass Sie ihren Ausfall überleben würden?“

Exit-Strategien: der Fiktionstest

Nichts entlarvt die Qualität eines Auslagerungsrahmens so sehr wie seine Exit-Strategie. Unter DORA müssen Exit-Pläne für kritische Funktionen dokumentiert, gegen realistische Szenarien getestet und frei von der Fiktion sein, eine Kernsystem-Migration geschehe in der Kündigungsfrist eines Standardvertrags. Ernsthafte Häuser unterscheiden gestresste Exits (Anbieterausfall, aufsichtliche Anordnung) von geplanten, quantifizieren Datenportabilität praktisch — Formate, Volumina, Abhängigkeiten — und halten genug internes Wissen, um überhaupt neu ausschreiben zu können. Aufseher erwarten nicht, dass Exits schmerzfrei sind; sie erwarten, dass sie real sind.

Die DACH-Schicht obendrauf

DORA harmonisiert, aber lokale Textur bleibt. In Deutschland prägt die BaFin-Aufsichtspraxis — geformt durch Jahre von MaRisk- und BAIT-Durchsetzung — weiterhin, wie Prüfungen laufen und welche Dokumentationstiefe als glaubwürdig gilt; die Überführung der BAIT in den DORA-Rahmen konsolidiert die Erwartungen, statt sie zu senken. Die Schweiz außerhalb von DORA fährt ihre eigene Resilienz-Spur über die FINMA-Regeln zu Auslagerung und operationellen Risiken — inhaltlich konvergent, prozedural verschieden. Das wiederkehrende DACH-Muster, für das Multi-Markt-Häuser designen müssen.

Sub-Auslagerung: die Kette unter dem Vertrag

Der Anbieter, den Sie beauftragen, ist selten der Anbieter, der rechnet. Unter jedem Managed Service liegt eine Kette — der SaaS-Anbieter auf einem Hyperscaler, das KYC-Utility auf einem weiteren SaaS, die Support-Funktion in einem Drittland —, und DORA verpflichtet Häuser, diese Kette für kritische Funktionen zu kennen, wesentliche Unterauftragsvergabe vertraglich zu begrenzen und vor Änderungen informiert zu werden. Praktisch verwandelt das Vendor-Management von bilateraler Beziehungspflege in Lieferketten-Kartografie — und fördert unbequeme Entdeckungen zutage: Ketten, die auf einen einzigen Infrastrukturanbieter zurücklaufen, Fourth Parties in Jurisdiktionen, die der Risikoappetit nie vorsah, und Notifikationsklauseln, die nur auf dem Papier existierten.

Die pragmatische Haltung ist wesentlichkeitsgetrieben: erschöpfend mappen, wo die Funktion kritisch ist, überall Transparenz kontrahieren und echte Vetorechte für die Glieder reservieren, deren Ausfall sich fortpflanzen würde. Perfektion über den gesamten Bestand wird weder erwartet noch erreicht; Unkenntnis über die kritischen Ketten ist in einer Prüfung weder akzeptabel noch überlebbar.

Wenn es bricht: Vorfälle treffen Auslagerung

DORAs Vorfallsregime und sein Auslagerungsregime treffen sich in der schlimmsten Stunde: Ein schwerwiegender IKT-Vorfall beim Anbieter ist der Vorfall des Instituts — mit den Klassifizierungspflichten des Instituts und den Meldefristen des Instituts. Das hat vertragliche Konsequenzen — Anbieter müssen schnell genug zur Meldung verpflichtet sein, damit das Haus seine eigenen Uhren einhält — und operative: Playbooks, die die Statusseite des Anbieters für einen ausreichenden Informationskanal halten, scheitern am ersten echten Test. Häuser, die Anbieter-Ausfallszenarien gemeinsam mit ihren kritischen Vendoren proben, verwandeln eine Compliance-Anforderung in echte Resilienz; der Rest entdeckt während eines Ausfalls, dass seine Eskalationsmatrix eine Ticket-Queue enthält.

Eine Arbeits-Checkliste

  1. Das Informationsregister als lebendes System mit Ownership bauen, nicht als jährliches Spreadsheet.
  2. Kritische IKT-Verträge gegen die DORA-Mindestinhalte repapern — Prüfrechte, Exit-Klauseln, Transparenz der Unterauftragskette.
  3. Konzentration ehrlich bewerten — einschließlich Sub-Anbieterketten, die auf dieselbe Infrastruktur auflösen.
  4. Exit-Strategien schreiben, die Systeme, Datenvolumina und Zeitachsen benennen — und sie testen.
  5. Für das Schweiz-Geschäft die FINMA-Erwartungen separat mappen und die Rahmenwerke einmal sauber abgleichen.

Testen: vom Tabletop zum TLPT

Resilienztests unter DORA skalieren mit dem Institut: Alle testen ihre IKT-Werkzeuge und -Systeme regelmäßig, während bedeutende Einheiten bedrohungsgeleiteten Penetrationstests unterliegen — realistische Angriffssimulationen gegen Produktivsysteme, unter aufsichtlicher Begleitung und, wo relevant, unter Einbeziehung kritischer Anbieter. Auch Häuser unterhalb der TLPT-Schwelle sollten die Richtung lesen: Annahmen über Anbieter-Failover, Backup-Wiederherstellungszeiten und Vorfallskommunikation sind Behauptungen, bis sie getestet sind — und Aufsichtsgespräche unterscheiden zunehmend zwischen Resilienz-Rahmenwerken, die geübt wurden, und solchen, die nur geschrieben wurden.

Fazit

DORA hat Auslagerungs-Governance von einer Ablagepflicht in eine Ingenieursdisziplin mit Rechtskraft verwandelt. Für Markteinsteiger ist das verkappte gute Nachricht: Wer mit sauberem Register, DORA-tauglichen Verträgen und getesteten Exit-Plänen ankommt, signalisiert operative Reife in der Sprache, die DACH-Aufseher am meisten respektieren. Aegiron Capital Group unterstützt Fintechs und ihre Technologieanbieter dabei, sich auf die Auslagerungs- und Resilienzfragen von Banken und Aufsehern im DACH-Raum vorzubereiten; Rechtsberatung und IT-Sicherheitsprüfungen übernehmen die Kanzlei und die Spezialisten, die Sie beauftragen.

Sind Sie als Anbieter bereit für regulierte Kunden?

Zwölf Fragen aus der Einkaufspraxis von Banken und Zahlungsdienstleistern — mit Readiness-Score und druckbarem Bericht. Kostenlos, ohne Registrierung.

DORA-Vendor-Check starten

Oder direkt ein Gespräch vereinbaren

Peter M. Badke

Peter M. Badke

Gründer, Aegiron Capital Group

Bankkaufmann (IHK), seit 2021 im Vertrieb und Partnergeschäft für Fintech-Anbieter im DACH-Raum. Zertifizierter Derivatehändler (Deutsche Börse Group).

Entwurf mit KI-Werkzeugen; redaktionell verantwortlich: Peter M. Badke.

LinkedIn