Modul 7 - Auslagerung & IKT-Drittparteienrisiko

Wenn der Cloud-Anbieter “kritisch” wird

Es ist der 14. Januar 2026. In der Vorstandssitzung der xbank liegt ein Brief der EBA auf dem Tisch. Inhalt: ein bestimmter US-Hyperscaler — bei dem die Bank seit acht Jahren ihr Online-Banking-Frontend betreibt — wurde gerade EU-weit als Critical Third-Party Provider (CTPP) nach DORA Art. 31 eingestuft.

Was ändert sich für die Bank über Nacht?

• Der Anbieter unterliegt jetzt direkter EU-Aufsicht durch die ESAs (EBA, ESMA, EIOPA), nicht mehr nur durch die Bank selbst.
• Die EU-Aufseher dürfen eigene Inspektionen beim Anbieter durchführen, auch außerhalb der EU.
• Bei Nicht-Mitwirkung des Anbieters: Zwangsgelder bis 1% des weltweiten Tagesumsatzes pro Tag.
• Die Bank muss ihre eigene Konzentrations- und Exit-Bewertung aktualisieren — sind wir zu abhängig?

Genau dieses Szenario wird in den nächsten Jahren in vielen Vorstandsetagen durchgespielt — und es ist ein perfekter Aufhänger für Modul 7. Hier geht es um die Welt der Drittparteien: was Auslagerung bedeutet, wie der Lebenszyklus aussieht, was DORA verlangt, und wie Cloud-Sicherheit funktioniert.

Was bedeutet “Auslagerung” in einer Bank?

Nicht jedes Outsourcing ist eine Auslagerung im aufsichtsrechtlichen Sinne. Eine Auslagerung liegt nach MaRisk AT 9 vor, wenn:

• ein anderes Unternehmen mit der Wahrnehmung von Aktivitäten oder Prozessen beauftragt wird, die normalerweise die Bank selbst erbringen würde,
• diese Aktivitäten typischerweise ein Bestandteil der bankgeschäftlichen oder bankgeschäftsbegleitenden Tätigkeit sind.

Die Abgrenzung zum reinen Fremdbezug ist unscharf, aber bedeutsam:

Wesentliche Auslagerungen lösen verschärfte Pflichten aus: explizite Genehmigung der Aufsicht oft nötig, höhere Vertragsanforderungen, intensivere laufende Steuerung. DORA hat den Begriff inhaltlich aufgegriffen, ohne MaRisks Wesentlichkeits-Kategorie 1:1 zu übernehmen.

Drittparteien-Lebenszyklus — fünf Phasen

Jede einzelne Drittparteien-Beziehung folgt einem typischen Lebenszyklus. Wer das versteht, weiß auch, wo welche DORA-Artikel greifen.

Beachte: Phase 5 (Exit) wird in der Praxis am häufigsten unterschätzt. Banken haben oft hervorragende Onboarding-Prozesse, aber kein vorab gepröbtes Exit-Konzept. Wenn dann ein Anbieter pleite geht oder den Service einstellt, beginnt die Notfall-Migration ohne Drehbuch. DORA Art. 30 hat genau diese Lücke geschlossen: Exit-Strategien sind seit 17.01.2025 Vertrags-Pflichtinhalt, nicht mehr „nice to have”.

DORA Kapitel V vertieft (Art. 28–44)

Wir hatten in Modul 6 die Übersicht aller DORA-Kapitel gesehen. Kapitel V verdient eine Vertiefung — es ist mit 17 Artikeln das größte und für die Bank-Praxis eines der wichtigsten.

Pflichten der Bank (Art. 28–30)

Art. 28 — Allgemeine Grundsätze. Drittparteien-Risiko ist integraler Bestandteil des IKT-Risikomanagements. Die Verantwortung bleibt bei der Bank, auch wenn Funktionen ausgelagert sind. Pflicht zur laufenden Überwachung und zu einem zentralen Drittparteien-Register, das jährlich an die Aufsicht gemeldet wird.

Art. 29 — Konzentrationsrisiko. Vor jedem Vertragsschluss muss die Bank prüfen:

• Wie viele kritische Funktionen hängen schon an diesem Anbieter?
• Gibt es realistische Alternativ-Anbieter?
• Wie aufwendig wäre ein Wechsel?

Ein klassisches Cluster-Beispiel: 80% der deutschen Kernbank-Anwendungen laufen heute bei einem von drei großen IT-Dienstleistern. Wenn einer ausfällt, ist nicht nur die einzelne Bank in Schwierigkeiten, sondern ein Branchen-Cluster.

Art. 30 — Vertragliche Vereinbarungen. Acht Pflicht-Inhalte:

Diese acht Punkte sind in jedem DORA-Audit Pflicht-Lesefutter — die Bank muss zu jedem ihrer Drittpartei-Verträge zeigen können, wo welcher Punkt geregelt ist.

Das CTPP-Konzept (Art. 31–44) — neu mit DORA

Bis DORA hat jede Bank ihre Drittparteien selbst gesteuert. Mit DORA gibt es eine neue Kategorie: Critical Third-Party Provider (CTPPs) — Anbieter, die für viele Banken gleichzeitig kritisch sind.

Wer wird CTPP? Die ESAs (EBA, ESMA, EIOPA) entscheiden anhand eines Kriterienkatalogs (Art. 31):

• Systemische Bedeutung: Wie viele Finanzunternehmen sind Kunden?
• Kritikalität der Funktionen: Sind das nur Standard-Dienste oder Kernbank-Funktionen?
• Substituierbarkeit: Wie schwer ist ein Wechsel?
• Vernetzung: Hängen viele andere Anbieter selbst von diesem ab?

Erwartet werden 2025/2026 als CTPPs: die großen Hyperscaler (Microsoft Azure, AWS, Google Cloud), bestimmte SWIFT-nahe Anbieter, große Kernbank-Dienstleister.

Direkte EU-Aufsicht. Ein CTPP unterliegt nicht mehr nur der Bank-Aufsicht (über die Banken-Verträge), sondern bekommt eigene EU-Aufseher — sogenannte „Lead Overseer”. Diese dürfen:

• Untersuchungen anstoßen (Art. 35)
• Inspektionen vor Ort durchführen, auch außerhalb der EU (Art. 36–37)
• Empfehlungen aussprechen (Art. 35)
• Bei Nicht-Mitwirkung Zwangsgelder verhängen — bis 1% des weltweiten Tagesumsatzes des Anbieters pro Tag (Art. 43)

Cloud-Sicherheit — der wichtigste Spezialfall

Auslagerung in die Cloud ist heute der dominante Drittparteien-Fall. Über 70% aller deutschen Banken nutzen 2026 mindestens einen großen Hyperscaler für kritische Funktionen. Was Cloud-Sicherheit besonders macht: die Verantwortungs-Verteilung hängt vom Modell ab.

Drei Cloud-Modelle, drei Verantwortungs-Ebenen

Shared Responsibility — wer macht was?

Was du dir mitnehmen musst: Selbst beim ausgelagertsten Modell (SaaS) bleiben Daten und Identitäten Verantwortung der Bank. Capital One 2019 ist genau dafür der Lehrstück-Fall — die Misskonfiguration einer AWS-WAF war kein AWS-Versagen, sondern ein Bank-Versagen. AWS hatte das Werkzeug korrekt geliefert; die Bank hatte es falsch konfiguriert.

BSI C5 als Cloud-Audit-Standard

Der BSI C5 (Cloud Computing Compliance Criteria Catalogue) ist seit 2020 der deutsche Cloud-Audit-Standard. 17 Themenbereiche mit konkreten Anforderungen an den Cloud-Anbieter. Ein C5-Testat wird von einer Wirtschaftsprüfungs- gesellschaft erstellt und ist heute in vielen Banken-Verträgen mit Cloud-Anbietern Standard.

ISO/IEC 27017 und 27018 — die internationalen Pendants

• ISO 27017 — Cloud-spezifische Erweiterung zu ISO 27002. Liefert zusätzliche Controls für Cloud-Service-Provider und Cloud-Kunden. International, BSI-kompatibel.
• ISO 27018 — Datenschutz-Erweiterung speziell für Public Cloud. Hilft beim DSGVO-Nachweis bei Cloud-Auslagerungen.

Praxis-Mix in deutschen Banken: BSI C5 + ISO 27017 + ISO 27018 + DORA-spezifische RTS — Cloud-Audits werden heute mit allen vier Werken gleichzeitig durchgeführt. Tendenz zur Konsolidierung über die kommenden Jahre.

Praxis: Bank-Beispiele

SolarWinds 2020 — die Software-Lieferkette als Eintrittspunkt

Wir hatten den Vorfall in Modul 1 historisch und in Modul 3 als Angriffsklasse behandelt. Im Drittparteien-Kontext zeigt er das Lieferketten-Problem in Reinkultur: SolarWinds war ein vertrauenswürdiger Anbieter für Netzwerk-Management-Software. Banken wie viele andere Organisationen hatten SolarWinds-Verträge mit allen Zertifikaten, Audit-Berichten und Service-Levels — und bekamen trotzdem die kompromittierte Update-Datei.

Was Drittparteien-Steuerung daraus lernen muss:

• Audit-Berichte zeigen einen Stichtag, nicht den heutigen Zustand
• Zertifikate sind kein Schutz vor Supply-Chain-Kompromittierung
• Code-Signing-Verifikation und Detektion von ungewöhnlichem Update-Verhalten müssen on top kommen
• DORA Art. 30 verlangt heute genau solche Vertragsklauseln (Sub-Anbieter, Audit-Rechte, Notfall-Konzepte)

MOVEit / Cl0p Mai-Juni 2023 — die unbekannte Drittpartei

Cl0p nutzte einen Zero-Day in Progress MOVEit Transfer — einer Datenübertragungs-Software. Über 2.500 Organisationen waren betroffen, darunter Deutsche Bank, Aon, AXIS Capital, Postbank Schweiz.

Das Bemerkenswerte aus Drittparteien-Sicht: Viele Banken waren nicht direkt MOVEit-Kunden, sondern über ihre Dienstleister, die MOVEit einsetzten. Die Banken kannten den Anbieter „MOVEit” nicht einmal — er war eine Subunternehmen-Komponente ihrer Drittparteien.

DORA Art. 30 Punkt 5 (Subunternehmer-Klauseln) und das Drittparteien-Register adressieren genau dieses Problem: die Bank muss die Subunternehmer-Kette ihrer kritischen Anbieter kennen.

Capital One 2019 — Cloud-Misskonfig als Bank-Versagen

Im Juli 2019 wurde bekannt, dass eine ehemalige AWS-Mitarbeiterin 100 Millionen Datensätze der Capital One exfiltriert hatte. Der Angriffsweg:

1. Eine Misskonfiguration der AWS Web Application Firewall (WAF)
2. Erlaubte Server-Side Request Forgery (SSRF)
3. Damit Zugriff auf die AWS-Metadata-API
4. Und dort gespeicherte temporäre Credentials
5. Mit denen S3-Buckets gelesen werden konnten

Aus Shared-Responsibility-Sicht: AWS hatte alle Werkzeuge korrekt bereitgestellt. Die WAF-Konfiguration war Verantwortung von Capital One. Das Versagen war Bank-seitig.

Folgen:

• 80 Mio Dollar Strafe vom US-OCC wegen mangelhafter Cloud-Risiko-Steuerung
• 190 Mio Dollar Settlement mit US-Bundesgericht
• CEO musste sich vor dem US-Senat verantworten

Lehre: Eine Cloud-Auslagerung ist kein Auslagerung der Verantwortung. Bei jeder Audit-Frage „wer hat das konfiguriert” ist meist die Bank gemeint.

Norm-zu-Realität-Mapping mit Drittparteien-Beispiel

Die fünf Merksätze für Modul 7

1. Auslagerung verlagert die Aktivität, nicht die Verantwortung. Egal wie viel ausgelagert ist — die Bank haftet, die Bank antwortet im Audit, die Bank wird sanktioniert.

2. Drittparteien-Lebenszyklus hat fünf Phasen. Pre-Assessment, Vertrag, Onboarding, laufende Steuerung, Exit. Phase 5 wird am häufigsten unterschätzt — DORA Art. 30 macht Exit-Strategien zur Vertrags-Pflicht.

3. CTPPs sind ein neues Konzept. Erste Anbieter bekommen 2025/2026 den Status „kritisch nach DORA Art. 31” und damit direkte EU-Aufsicht. Bewertungs-Druck auf die Bank, das Konzentrationsrisiko zu prüfen.

4. Cloud-Verantwortung folgt dem Shared-Responsibility-Modell. Daten und Identitäten bleiben immer Bank-Verantwortung — auch bei SaaS. Capital One 2019 ist der Lehrstück-Fall dafür.

5. DORA Art. 30 verlangt acht Pflicht-Inhalte. Beschreibung, SLA, Datenort, Audit-Rechte, Subunternehmer, Exit, Datenrückgabe, Insolvenz-Konzepte. Wer einen seiner Verträge ohne diese acht Punkte hat, hat ein DORA-Compliance-Problem.