SCHWERPUNKT2. Juni 2026

Hyperscaler ohne Maulkorb: Wie Banken Cloud-Souveränität per IaC & Zero Trust erzwingen

Schwerpunkt: Rechenzentren & Digitale Souveränität
Stefan Schmid über die Controlled Cloud
Stefan Schmid, Geschäftsführer bei Sopra Steria Custom Software Solutions Sopra Steria

Multi-Cloud und Partnerschaften mit Hyperscalern sind gelebte Praxis in der Banken- und Versicherungswelt. Wer als CIO digitale Souveränität will, muss die Hyperscaler-Cloud nicht verhindern, sondern beherrschbar machen – technisch, organisatorisch und vertraglich.

von Stefan Schmid, Geschäftsführer bei Sopra Steria Custom Software Solutions

Der Druck kommt aus mehreren Richtungen zugleich: Fachbereiche erwarten Tempo gerade dort, wo KI-Funktionen in Endkundenkanälen, neue Produkte oder neue Sicherheitsmechanismen kurzfristig umgesetzt werden müssen. Gleichzeitig bleibt der Kostendruck hoch, und Cloud wird ohne saubere Steuerung nicht automatisch günstiger, was Versicherer häufig noch unmittelbarer spüren als Banken.

Hinzu kommen neue Cyberrisiken und eine Regulatorik, die Nachweisbarkeit zur Grundanforderung macht: DORA ist seit dem 17. Januar 2025 anzuwenden und verpflichtet Institute, ICT-Drittparteien, Resilienztests und Exitstrategien systematisch zu steuern. Auch die BaFin hat ihre Erwartungen an Cloud Auslagerungen praxisnäher beschrieben und betont Governance, geteilte Zuständigkeiten sowie laufende Überwachung.

In diesem Umfeld ist „kontrollierte Cloud“ weder ein Anbietersiegel noch eine Standortdebatte.

Kontrolliert ist eine Cloud dann, wenn ein Institut jederzeit belegen kann, wer worauf zugreifen darf, wo Daten verarbeitet werden, welche Sicherheitsmaßnahmen greifen und wie im „Ernstfall“ der Wechsel oder das Zurückholen von Workloads organisiert ist.“

Ein Realitätscheck hilft, den Begriff zu erden: Banken und Versicherer betreiben nicht „die eine“ Cloud Architektur. Typisch sind mehrere große Plattformen, daneben ein breiter Anwendungszoo, und SaaS ist längst Standard. Multi-Cloud ist daher selten Kür, sondern operative Notwendigkeit, und die Cloud Entscheidung fällt sinnvollerweise je Plattform und Workload. Wer lediglich bestehende Anwendungen „umzieht“, aber Automatisierung, Servicebreite und moderne Security Mechanismen nicht nutzt, erreicht oft nur eine teurere Variante des bisherigen Betriebs.

Autor Stefan Schmid, Sopra Steria
Stefan Schmid, Geschäftsführer bei Sopra Steria Custom Software Solutions, präsentiert sich in einem modernen Büro. Der Fokus liegt auf seiner Rolle in der Cloud-Architektur und der Umsetzung von IT-Transformationsprogrammen in regulierten Branchen. Stefan Schmid ist Geschäftsführer bei Sopra Steria Custom Software Solutions (Webseite) in München und verantwortet IT- und Transformationsprogramme in regulierten Branchen. Mit mehr als 25 Jahren Erfahrung in der IT‑ und Managementberatung verfügt er über  Expertise in der Digitalisierung von Banken und Versicherungen. Seine Schwerpunkte liegen in IT‑Governance, Outsourcing, Enterprise-Architekturen und der Umsetzung großskaliger Transformationsprogramme.

Sicherheitsdruck in den digitalen Kanälen

In der Praxis zeigt sich ein wiederkehrendes Muster. Ein Institut möchte eine kundennahe Anwendung modernisieren, weil die Time-to-Market leidet und der Sicherheitsdruck in den digitalen Kanälen steigt, etwa durch neue Betrugs- und Angriffsmuster. Technisch wäre die Migration überschaubar, operativ entsteht jedoch Reibung, weil Rollen, Prozesse und Richtlinien aus dem On Prem Betrieb stammen.

Die Folge sind lange Freigabeschleifen, Nacharbeiten und eine Cloud, die sich am Ende wie das alte Rechenzentrum anfühlt. Der Durchbruch gelingt meist dann, wenn nicht zuerst migriert, sondern das Zielbetriebsmodell neu aufgesetzt wird: Zuständigkeiten im Shared Responsibility Modell werden klar, Skills werden aufgebaut, Guardrails werden standardisiert und die Nachweisführung wird so gestaltet, dass sie dauerhaft funktioniert.

Im Kern sind es fünf Hebel, die Cloud Nutzung kontrollierbar machen:

  • Eine technische Cloud-Architektur, die „by design“ skalierbar, sicher, wartbar, kosteneffizient und resilient ist. Eine moderne Cloud-Architektur wird nicht per Hand konfiguriert, sondern wird über „Infrastructure as Code“ entwickelt.
  • Ein Target Operating Model, das verteilte Verantwortung zwischen Institut und Cloud Provider abbildet, statt sie in Silos zu verstecken: „Shared Responsibility“ regelt die Verantwortlichkeiten für Identitäten, Schlüssel, Logging, Patchen und Incident Response eindeutig.
  • Zero Trust als Ersatz für das klassische Perimeter Denken, wodurch Aspekte wie IAM, Least Privilege Access und Key Management zu Souveränitätskernen werden.
  • Nachweisbarkeit als Dauerzustand über Telemetrie, Logging und Monitoring, damit Fragen der Revision nicht im Projektmodus beantwortet werden.
  • Exit Fähigkeit vor dem Go live, inklusive vertraglicher Vorkehrungen für Datenzugriff und -transfer, Portierung von Infrastruktur, Support nach Kündigung und Alternativszenarien wie Re Insourcing oder Providerwechsel.

Wer Multi-Cloud als Realität akzeptiert, kann Chaos vermeiden, indem Kontrollen standardisiert werden: gemeinsame Guardrails, einheitliches Sicherheitsmanagement, konsistente Nachweisführung und ein Betriebsmodell, das Providergrenzen überbrückt. So lässt sich Hyperscaler Power dort nutzen, wo sie den größten Nutzen stiftet, ohne digitale Souveränität als Verzicht misszuverstehen.“ Stefan Schmid, Sopra Steria Custom Software Solutions/dk

Schreiben Sie einen Kommentar

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