Von Zertifizierung zu Echtzeit-Steuerung: Auslagerungs­kontrolle operativ wirksam machen

Auf dem Papier sind Auslagerungsverträge aufsichtsrechtlich konform und sauber. In der Praxis fehlt Banken aber immer wieder die technische Transparenz über ihre FinTech-Dienstleister, etwa beim Zugriff auf Logs in Echtzeit. Doch wo diese Einblicke begrenzt sind, lässt sich Steuerung nur eingeschränkt belastbar nachweisen. Der nächste Entwicklungsschritt liegt deshalb darin, formale Kontrolle konsequent mit operativer Transparenz zu verbinden.

von Daniel Fischer, Accenture

Transparenz als Grundlage wirksamer Steuerung

Wenn ein FinTech die KYC-Prozesse einer Bank übernimmt und die entsprechenden Daten in einer Cloud-Computing-Plattform in der Region Frankfurt verarbeitet, entstehen dabei drei Klassen von Logs: Anwendungslogs beim FinTech, Infrastruktur-Logs beim Anbieter der Cloud-Computing-Plattform und Netzwerk-Logs irgendwo dazwischen. Die Bank sieht in der Regel keinen davon in Echtzeit.

Die Bank erhält monatliche Reports und im Idealfall ein SOC-2-Type-2-Attest, sprich einen unabhängigen Prüfbericht.“

Dazu kommt eventuell ein API-Endpoint, also eine spezifische digitale Adresse (URL) einer Schnittstelle, an der ein Server Anfragen empfängt und verarbeitet. Über diesen können sich die Banken dann Leistungskennzahlen ziehen. Aufsichtsrechtlich heißt das Auslagerungskontrolle. Belastbar wird diese aber nur, wenn die regelmäßigen Nachweise durch kontinuierliche, technisch auswertbare Einblicke ergänzt werden.

Kontrolle beginnt mit der Vertragserstellung

Die Grundlage dafür wird bereits in der Vertragsgestaltung gelegt. Dabei sind zwei Vertragsbestandteile sauber zu trennen. Der DORA-Abschnitt mit dem Cloud-Anbieter braucht explizite Klauseln zu Audit-Rechten auf Infrastrukturebene, Log-Bereitstellung und Subdienstleisterketten – konkret genug zur Umsetzung im Betrieb und nicht nur juristisch belastbar. Der MaRisk-Abschnitt mit dem FinTech regelt Weisungsrechte, Kündigungsfristen und Notfallvorkehrungen. Beide Abschnitte müssen widerspruchsfrei sein und aufeinander verweisen. Relevant wird das spätestens bei Incident-Response-Pflichten oder Fragen der Datenweitergabe.

Dahinter steckt ein einfaches Prinzip: Auslagerung überträgt die Tätigkeit, aber keine Verantwortung.“

Was das Institut selbst zu erfüllen hat, muss vertraglich auf den Dienstleister gespiegelt und dessen Einhaltung nachweisbar kontrolliert werden. Das betrifft beispielsweise Verschlüsselungs­standards, Zugriffskontrolle oder auch Patch-Management. Der Dienstleister führt aus, den Sicherheitsrahmen setzt jedoch weiterhin das Institut.

Audit-Rechte müssen technisch anschlussfähig sein

Audit- und Zugangsrechte, wie sie Art. 30 DORA fordert, entfalten ihren Wert erst, wenn sie nicht nur vertraglich vereinbart, sondern auch praktisch umgesetzt werden. Welche technischen Anforderungen damit verbunden sind, wird dabei nicht immer vollständig adressiert.

Ein belastbares Audit-Recht beschränkt sich daher nicht auf punktuelle Vor-Ort-Prüfungen, sondern umfasst insbesondere die strukturierte Bereitstellung relevanter Log-Daten in maschinenlesbaren Formaten (z. B. CEF, LEEF oder JSON), einen lesenden Zugriff auf zentrale Log-Streams in Cloud-Umgebungen, klar dokumentierte API-Schnittstellen für kontinuierliche Kontrollen sowie angemessene Transparenz auch auf Subdienstleisterebene.“

Gerade dieser letzte Punkt ist in der heutigen Bankenlandschaft oft der schwierigste. Wenn das FinTech bei einem Anbieter hostet und dieser wiederum weitere Dienstleister einbindet, muss die Kette transparent bleiben. Pool-Audits können dabei ein pragmatischer Kompromiss sein, ersetzen aber keine eigene Telemetrie.

Zertifikate ersetzen keine laufende Kontrolle

Zertifizierungen wie ISO27001 oder SOC 2 bleiben ein wichtiger Nachweis, bilden aber nur einen begrenzten Ausschnitt der operativen Realität ab. Ein Attest bescheinigt, dass Kontrollen in einem definierten Zeitraum funktioniert haben, nicht, ob kurzfristig beispielsweise ein Cloud-Objektspeicher öffentlich gestellt oder eine IAM-Policy verändert wurde. Die BaFin hat mehrfach klargestellt:

Zertifizierungen ersetzen keine eigene Prüfung und garantieren nicht die Umsetzung des eigenen Sicherheitsanspruch beim Dienstleister.“

Zumal etwa eine ISO27001-Zertifizierung auch nur das Management-System zertifiziert, nicht aber die konkrete Umsetzung oder das tatsächliche Sicherheitsniveau. Mehr Aussagekraft entsteht, wenn Institute Zertifizierungen durch kontinuierliche Konfigurationskontrolle und eigene Prüffähigkeit ergänzen, beispielsweise durch Drift Detection und CSPM-Lösungen, die den tatsächlichen Cloud-Zustand mit dem vereinbarten Soll-Zustand abgleichen.

Exit-Strategien brauchen operative Nachweise

Besonders sichtbar werden die Lücken häufig bei Exit-Strategien. In der Theorie liegen diese zwar vor, in der Praxis muss jedoch belegbar sein, dass sie unter realistischen Bedingungen funktionieren. Die entscheidende Frage für eine IT-Leitung ist nicht juristisch, sondern operativ. Vereinfacht gesagt: In welchem Format kommen vier Terabyte Kundendaten zurück, wenn das FinTech morgen insolvenzbedingt den Stecker zieht? Ein proprietärer Datenbank-Dump hilft wenig, wenn die Bank den dazugehörigen Software-Stack weder kennt noch betreiben kann.

In den Vertrag gehören deshalb standardisierte Exportformate wie Parquet, Avro oder CSV mit dokumentiertem Schema, garantierte Übergabezeiten in Stunden statt Tagen, regelmäßige Test-Restores mit Protokoll sowie definierte Eskalationspfade bei Ausfällen von Schlüsselpersonal.“

Die aufsichtlichen Anforderungen gelten dabei nicht nur für externe Auslagerungen. Auch innerhalb von Konzernen und Verbünden müssen Nachfolgevorkehrungen belastbar sein. Die 9. MaRisk-Novelle macht deutlich: Nachfolgevorkehrungen sind auch dann erforderlich, wenn niemand ernsthaft mit einer Beendigung rechnet. Vendor Lock-in über proprietäre Formate ist damit längst kein Beschaffungsthema mehr, sondern eine potenzielle Feststellung.

Resilienz endet nicht an der Schnittstelle

Der Bruch zwischen Anspruch und Realität zeigt sich bei der Resilienz: DORA verlangt für Institute, die nach risikobasierten Kriterien von der Aufsicht benannt werden, bedrohungsorientierte Tests nach TIBER-EU, sprich Red-Teaming gegen produktive Systeme, einschließlich ausgelagerter Komponenten.

In der Praxis endet der Penetrationstest jedoch häufig dort, wo das Risiko zu finden ist: an der Bank-FinTech-Schnittstelle, weil der Dienstleister „nicht in Scope“ ist.“

Gleichzeitig fordert AT 7.3 MaRisk ein Notfallkonzept, das ausgelagerte Prozesse einschließt. DORA ergänzt dies durch verpflichtende Szenario-Tests und Schaltübungen für den Ausfall kritischer Anbieter. Ein Business Continuity Management System, das an der API-Gateway-Grenze endet, ist unvollständig und stellt im Notfall keinen ganzheitlichen organisatorischen Rahmen dar, der die Handlungsfähigkeit einer Bank nur eingeschränkt sichert.
Vollständige Kontrolle bei weitgehender Auslagerung gibt es nicht.

Die Frage ist nicht, ob die Bank Kontrolle abgibt, sondern wie viel Telemetrie sie zurückhält.“

Damit Auslagerung tatsächlich wirksam wird, braucht es mehr als vertragliche Regelungen: etwa ein durchgängiges Log-Forwarding in das eigene Security Information and Event Management, gemeinsame Incident-Response-Übungen und getestete Daten­rückführungs­prozesse. Wo diese Elemente fehlen, entsteht leicht eine einseitige Abhängigkeit mit Vertragsanhang. Ein klarer Ausweg besteht darin, diese operativen Kontrollmechanismen systematisch aufzubauen und regelmäßig zu überprüfen. Daniel Fischer, Accenture