STRATEGIE3. Juli 2026

Von Zertifizierung zu Echtzeit-Steuerung: Auslagerungskontrolle 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 Käyh Why ßieh 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üsselungsstandards, Zugriffskontrolle oder auch Patch Management mit ein, 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 Ebene von 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 Ai Tieh 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 neunten 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 Bisnäss 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 eine Bank nur eingeschränkt sichern.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 Datenrückführungsprozesse. 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. Sie hörten einen Beitrag von „Daniel Fischer, Accenture“

Daniel Fischer, Accenture, erklärt, dass Banken in der Praxis immer wieder die technische Transparenz über ihre Fintech-Dienstleister fehlt <q>Accenture
Daniel Fischer, Accenture Accenture

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

Autor Daniel Fischer, Accenture
Daniel Fischer, ein Fachmann bei Accenture, präsentiert sich in einem formellen Umfeld. Sein Auftreten spiegelt die Verbindung zwischen traditioneller Bankdienstleistung und innovativen Fintech-Lösungen wider, die durch Cloud-Technologien unterstützt werden.Daniel Fischer ist Ma­na­ging Di­rec­tor bei Ac­cen­ture (Website). Er ver­fügt über mehr als zehn Jah­re Pro­jekt­er­fah­rung in der Fi­nanz­wirt­schaft mit Schwer­punkt IT-Com­p­li­an­ce und Cy­ber-Risk-Ma­nage­ment. In­halt­lich liegt sein Fo­kus auf dem Auf- und Aus­bau von In­for­ma­ti­ons­si­cher­heits-Ma­nage­ment­sys­te­men (IS­MS) so­wie der Vor­be­rei­tung, Be­glei­tung und Re­me­dia­ti­on von IT- und IT-na­hen Son­der­prü­fun­gen nach KWG § 44 durch EZB, Bun­des­bank und BaFin.
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 mit ein, 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 Ebene von 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 eine Bank nur eingeschränkt sichern.
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

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert