Ein Security-Team will Schlüsselmaterial selbst kontrollieren, der Fachbereich braucht kurzfristig skalierbare Analytics-Kapazität, und die Rechtsabteilung fragt nach Zugriffsmöglichkeiten aus Drittstaaten. Genau an solchen Konflikten entscheidet sich Sovereign Cloud versus Public Cloud. Die Frage ist nicht, welche Cloud grundsätzlich besser ist. Entscheidend ist, welche Kontrolle ein konkreter Workload tatsächlich benötigt – und ob Architektur, Verträge und Betrieb dieses Kontrollniveau auch liefern.
Die Gegenüberstellung wird häufig zu simpel geführt. Public Cloud steht dann für Geschwindigkeit und Skalierung, Sovereign Cloud für Sicherheit und Compliance. Das trifft den Kern nicht. Sicherheit lässt sich in einer Public Cloud sehr hoch umsetzen, wenn Verantwortlichkeiten, Identitäten, Konfigurationen und Überwachung sauber organisiert sind. Umgekehrt garantiert das Etikett souverän keine belastbare Kontrolle, wenn zentrale Betriebs-, Support- oder Managementfunktionen weiterhin außerhalb des gewünschten Rechts- und Einflussraums liegen.
Sovereign Cloud versus Public Cloud ist keine Standortfrage
Public Cloud beschreibt vor allem ein Bereitstellungsmodell: Ein Anbieter stellt standardisierte, mandantenfähige Infrastruktur-, Plattform- oder Softwaredienste bereit, die Kunden über Self-Service konsumieren. Die wirtschaftlichen Vorteile entstehen durch Standardisierung, Automatisierung und Skaleneffekte. Für viele Workloads ist das sinnvoll: etwa für Entwicklung, Kollaboration, globale Anwendungen, elastische Verarbeitung oder Managed Services, deren Eigenbetrieb unverhältnismäßig wäre.
Sovereign Cloud ist dagegen kein einheitlich normierter technischer Begriff. Im Kern geht es um nachweisbare Handlungs- und Kontrollfähigkeit. Je nach Angebot kann das Datenresidenz in einem bestimmten Land oder der EU einschließen, aber ebenso den Betreiber, das Personal mit privilegiertem Zugriff, den Support, die juristische Kontrolle des Dienstleisters, die Schlüsselverwaltung und die Möglichkeit, den Dienst unabhängig weiterzubetreiben oder geordnet zu verlassen.
Datenstandort ist deshalb nur eine Dimension. Liegen Daten in Frankfurt, aber das Control Plane, der Remote-Support oder ein zentraler Identitätsdienst unterliegen anderen Zugriffs- und Rechtsstrukturen, bleibt die Souveränitätsfrage offen. Für hochkritische Systeme zählt nicht nur, wo Daten ruhen, sondern wer Administrationsrechte ausüben kann, welche Telemetrie abfließt und welche Instanz im Störfall tatsächlich entscheidet.
Auch Public Cloud und Sovereign Cloud schließen sich nicht zwingend aus. Ein souverän ausgestaltetes Angebot kann auf Technologie eines großen Cloud-Anbieters basieren, aber mit abweichendem Betriebsmodell, separaten Zugriffsprozessen oder lokaler Schlüsselkontrolle arbeiten. Umgekehrt kann ein privater Cloud-Stack im eigenen Rechenzentrum wenig souverän sein, wenn er von wenigen externen Spezialisten abhängt, keine Exit-Option bietet oder nicht mehr sicher betreibbar ist.
Die vier Kontrollfragen vor jeder Entscheidung
Statt über Cloud-Kategorien zu streiten, solltest du für jeden Workload ein Zielbild für Kontrolle definieren. Vier Fragen bringen meist schneller Klarheit als eine lange Anbieter-Shortlist.
Erstens: Welche rechtliche Kontrolle ist erforderlich? Hier geht es um anwendbares Recht, Eigentums- und Kontrollstrukturen des Dienstleisters, mögliche behördliche Zugriffe, Auftragsverarbeitung und Nachweisfähigkeit gegenüber Prüfern. Regulierte Branchen, öffentliche Stellen und Betreiber kritischer Dienste können dabei deutlich engere Anforderungen haben als ein interner Entwicklungsservice. Die Datenschutz-Grundverordnung beantwortet diese Fragen nicht pauschal durch den Speicherort allein.
Zweitens: Welche operative Kontrolle brauchst du? Prüfe, wer Plattform und Managementebene betreibt, aus welchen Regionen Support geleistet wird und wie privilegierte Zugriffe beantragt, protokolliert und überwacht werden. Entscheidend ist auch, ob dein Team im Incident selbst handlungsfähig bleibt. Ein Vertrag, der weitreichende Prüf- und Informationsrechte verspricht, hilft wenig, wenn Logs unvollständig sind oder Eskalationen über mehrere Organisationen laufen.
Drittens: Welche technische Kontrolle ist unverzichtbar? Dazu gehören Mandantentrennung, Netzwerkarchitektur, Verschlüsselung, Identity and Access Management, Bring-your-own-Key- oder Hold-your-own-Key-Modelle sowie die Trennung von Daten- und Managementebene. Eine kundenseitig kontrollierte Schlüsselverwaltung kann Risiken reduzieren. Sie löst aber nicht jedes Problem: Metadaten, Laufzeitdaten, Backups, Suchindizes und administrative Operationen müssen separat bewertet werden.
Viertens: Wie wirtschaftlich unabhängig willst du bleiben? Souveränität hat eine finanzielle Seite. Proprietäre Plattformdienste können Time-to-Market und Betrieb erheblich verbessern, erhöhen aber gegebenenfalls Wechselkosten. Portabilität ist nicht identisch mit der Möglichkeit, virtuelle Maschinen zu exportieren. Relevant sind Datenformate, Schnittstellen, Infrastrukturdefinitionen, CI/CD-Pipelines, Observability, Identitätsmodelle und die Fähigkeiten deiner Teams.
Die Architektur entscheidet über mehr als der Vertrag
Souveränität entsteht nicht durch ein einzelnes Beschaffungsmerkmal. Sie wird in der Zielarchitektur konkret. Eine Datenklassifizierung allein reicht nicht aus, wenn alle Daten mit derselben Plattform, denselben Administrationswegen und denselben Backup-Mechanismen verarbeitet werden. Besser ist eine abgestufte Architektur: Standard-Workloads erhalten den passenden Grad an Public-Cloud-Standardisierung, während besonders schutzbedürftige Daten, Schlüssel oder Steuerungsfunktionen in strengeren Zonen liegen.
Dabei lohnt sich eine saubere Trennung zwischen Datenebene und Control Plane. Wenn Anwendungen in einer Umgebung laufen, ihre Policies, Identitäten, Images oder Secrets aber von einer zentralen Managementebene abhängen, muss diese Abhängigkeit in das Risiko- und Resilienzmodell einfließen. Das gilt ebenso für zentrale SaaS-Dienste. Sie können fachlich sinnvoll sein, doch ihre Protokollierung, Exportfähigkeit und Integration in Security Operations müssen vor der Einführung geklärt sein.
Für Architekten ist zudem die Frage wichtig, auf welcher Abstraktionsebene Portabilität realistisch ist. Container helfen, aber sie machen Anwendungen nicht automatisch cloud-agnostisch. Managed Datenbanken, Event-Dienste, IAM-Policies und proprietäre KI- oder Analysefunktionen prägen die Bindung oft stärker als die Laufzeitumgebung. Das ist kein Argument gegen solche Dienste. Es ist ein Argument, die bewusste Bindung dort zu akzeptieren, wo ihr Nutzen die späteren Kosten überwiegt.
Compliance darf kein Ersatz für Risikobewertung sein
Zertifikate, Testate und Vertragsanhänge sind wertvolle Entscheidungsgrundlagen. Sie ersetzen jedoch keine Bewertung des konkreten Einsatzes. Eine Zertifizierung kann etwa Aussagen über Prozesse und Kontrollen eines Dienstleisters treffen, aber nicht automatisch belegen, dass deine Konfiguration, deine Datenflüsse und deine Berechtigungskonzepte angemessen sind.
Gerade bei hybriden und Multi-Cloud-Architekturen entstehen Risiken an den Übergängen: beim Identitätsföderieren, beim zentralen Logging, bei Backups, bei der Datenreplikation und in den Betriebsprozessen. Wer eine souveräne Zone aufbaut, aber Security-Events, Konfigurationsdaten oder Schlüsselmaterial unkontrolliert in andere Umgebungen überträgt, unterläuft das eigene Schutzkonzept.
Für CIOs und CISOs heißt das auch: Beschaffung, Recht, Architektur, Security und Betrieb müssen dieselben Begriffe verwenden. Wenn Souveränität nur als Compliance-Anforderung im Lastenheft auftaucht, entstehen später Interpretationskonflikte. Formuliere prüfbare Anforderungen – etwa zu Administratorzugriffen, Protokollierungsfristen, Schlüsselkontrolle, Subunternehmern, Supportstandorten, Wiederanlauf und Datenexport – und ordne sie einer Verantwortlichkeit zu.
Ein pragmatisches Entscheidungsmodell für den Betrieb
Eine Cloud-Strategie gewinnt nicht dadurch, dass sie eine Plattform zur Ideallösung erklärt. Sie gewinnt, wenn Teams nachvollziehbar entscheiden können. Klassifiziere Workloads nach Schutzbedarf, regulatorischer Bindung, Kritikalität, Latenz, Skalierungsprofil, Abhängigkeiten und erwarteter Lebensdauer. Daraus lässt sich ein zulässiger Korridor ableiten – von Standard-Public-Cloud über kontrollierte Managed-Modelle bis zu dedizierten oder selbst betriebenen Umgebungen.
Plane den Exit bereits bei der Einführung. Gemeint ist nicht die unrealistische Annahme eines schnellen Komplettwechsels, sondern ein getesteter Mindestgrad an Handlungsfähigkeit: Datenexporte, Wiederherstellung außerhalb der Primärumgebung, dokumentierte Abhängigkeiten, klare Kündigungs- und Übergabeprozesse sowie ausreichend Wissen im eigenen Team. Diese Disziplin stärkt auch dann deine Verhandlungsposition, wenn ein Wechsel niemals stattfindet.
Die sinnvollste Entscheidung ist häufig eine differenzierte. Public Cloud kann für standardisierte, dynamische und international ausgerichtete Services die bessere Wahl sein. Ein souveränes Betriebsmodell kann dort notwendig werden, wo rechtliche, operative oder strategische Kontrolle nicht verhandelbar ist. Entscheidend ist, dass du Souveränität nicht einkaufst wie ein Label, sondern als nachweisbare Fähigkeit deiner Organisation gestaltest.
