„Unsere Daten liegen in Deutschland“ klingt zunächst beruhigend. Die Aussage beantwortet aber nur einen Teil der relevanten Fragen. Souveränität zeigt sich nicht auf der Rechenzentrumskarte, sondern in Architektur, Vertrag und Betrieb. Eine deutsche Postleitzahl ist hilfreich. Ein vollständiges Souveränitätskonzept ist sie noch nicht.
KURZANTWORT Eine souveräne Cloud gibt einem Unternehmen überprüfbare Kontrolle über Daten, Zugriffe, Verschlüsselung, Betrieb und Anbieterwechsel. Der Standort des Rechenzentrums allein reicht dafür nicht aus. Entscheidend sind auch Rechtsräume, Supportzugriffe, Schlüsselverwaltung, technische Abhängigkeiten und ein praktisch getesteter Exit-Plan.
Warum der Serverstandort allein nicht genügt
Der Speicherort ist relevant, aber nicht gleichbedeutend mit Kontrolle. Für eine belastbare Beschaffungsentscheidung sollten Unternehmen drei Ebenen auseinanderhalten:
- Datenresidenz: Wo werden Daten gespeichert und verarbeitet?
- Kontrollsouveränität: Wer kann technisch oder rechtlich auf Daten und Systeme zugreifen?
- Operative Souveränität: Kann das Unternehmen die Umgebung steuern, wiederherstellen und bei Bedarf verlassen?
Diese Prüfung darf nicht bei der Produktivdatenbank enden. Backups, Protokolle, Telemetrie, Metadaten und Supportdaten können anderen Datenflüssen, Speicherorten oder Zugriffsregeln folgen. Genau dort entstehen Lücken zwischen einem Versprechen auf der Website und der tatsächlich betriebenen Architektur.
Der politische Kontext erhöht den Handlungsdruck, ohne bereits eine neue Beschaffungsvorschrift zu schaffen: Die Europäische Kommission untersucht in einer bis zum 15. September 2026 laufenden Konsultation Abhängigkeiten, internationale Datenflüsse und Risiken durch Drittstaatenzugriffe. Der Bericht zur Digitalen Dekade 2026 stellt zugleich erhebliche Abhängigkeiten von Nicht-EU-Anbietern bei Cloud-Diensten, Cybersecurity und weiteren strategischen Technologien fest. Das ist ein guter Anlass, Anforderungen zu präzisieren. Es ist kein Grund für hektische Plattformwechsel.
Vom Souveränitätsziel zum prüfbaren Anforderungskatalog
Bevor Sie Anbieter vergleichen, klassifizieren Sie Ihre Workloads. Schutzbedarf, regulatorische Vorgaben, Ausfallfolgen, Integrationen und notwendige Plattformdienste bestimmen, welches Maß an Souveränität angemessen ist. Ein öffentliches Webangebot braucht andere Kontrollen als Produktionsdaten, Personalakten oder ein geschäftskritisches Transaktionssystem. Formulieren Sie daraus Muss-, Soll- und Kann-Kriterien und ordnen Sie jedem Kriterium einen Nachweis zu. „Datenhaltung in der EU“ wird so beispielsweise zu einer prüfbaren Vorgabe für Produktivdaten, Backups, Logs und Supportartefakte. Aus „kundeneigene Schlüssel“ werden konkrete Anforderungen an Key Store, Rollen, Rotation und Notfallverfahren. Dieses Vorgehen verhindert zwei typische Fehler: maximale Anforderungen für unkritische Systeme und zu vage Versprechen für kritische Workloads.
Wer kann unter welchen Bedingungen auf die Daten zugreifen?
Eine souveräne Cloud macht Zugriffe nachvollziehbar, begrenzbar und überprüfbar. Entscheidend ist nicht nur, wer im Normalbetrieb zugreifen darf, sondern auch, was bei Supportfällen, Sicherheitsvorfällen und behördlichen Anfragen gilt.
Diese Punkte gehören in die Prüfung
- Welche Gesellschaft erbringt die Leistung, und welchem Recht unterliegt sie?
- Welche Unterauftragnehmer und Supporteinheiten sind beteiligt, und aus welchen Ländern administrieren sie die Umgebung?
- Müssen Supportzugriffe freigegeben werden, werden sie vollständig protokolliert und gelten Ausnahmen für Notfälle?
- Wie behandelt der Anbieter Behördenanfragen, Drittstaatenzugriffe und Benachrichtigungen an den Kunden?
Verlangen Sie dafür mehr als eine Compliance-Folie: eine aktuelle Unterauftragnehmerliste, ein Datenflussdiagramm, den Auftragsverarbeitungsvertrag samt technischen und organisatorischen Maßnahmen, den dokumentierten Supportprozess sowie exportierbare Audit- und Zugriffsprotokolle.
Azure Customer Lockbox bietet für unterstützte Dienste einen Freigabe- und Protokollierungsprozess, wenn Microsoft-Personal ausnahmsweise direkten Zugriff auf Kundendaten benötigt. Microsoft dokumentiert jedoch Ausnahmen, etwa seltene Notfallszenarien; auch externe rechtliche Datenanfragen lösen keinen Lockbox-Prozess aus. Zudem ist die Abdeckung dienstabhängig. Die richtige Prüfebene lautet daher nicht „Azure ja oder nein?“, sondern „Welche Kontrolle greift für genau diesen Dienst und diesen Zugriffspfad?“
Wer kontrolliert Schlüssel und administrativen Kontrollpfad?
„Die Daten sind verschlüsselt“ ist eine Baseline, noch kein Souveränitätsnachweis. Entscheidend ist, wer Schlüssel erzeugt, speichert, verwendet, rotiert und sperrt – und ob der Anbieter technisch trotzdem Klartext verarbeiten kann.
Prüfen Sie das Schlüsselmodell pro Dienst
- Nutzt der Dienst plattformverwaltete oder kundeneigene Schlüssel (Customer-Managed Keys)?
- Wo liegt das Schlüsselmaterial, wer darf es verwenden und wie werden Änderungen protokolliert?
- Was passiert bei Schlüsselverlust, Ausfall des Key Managements oder einem Notfallzugriff?
- Welche Daten bleiben außerhalb des vereinbarten Modells, etwa temporäre Daten, Metadaten oder einzelne Servicekomponenten?
Microsoft unterscheidet bei seinen Souveränitätskontrollen zwischen Datenresidenz, Verschlüsselung im Ruhezustand und während der Übertragung sowie Confidential Computing für Daten in Verarbeitung. Die Dokumentation weist zugleich darauf hin, dass nicht jeder Azure-Dienst dieselben Optionen für kundeneigene Schlüssel oder Managed HSM unterstützt. Mehr Kontrolle schafft außerdem mehr Betriebsverantwortung: Ohne getestete Rotation, Wiederherstellung und Rollenmodelle kann ein starkes Schlüsselkonzept selbst zum Verfügbarkeitsrisiko werden.
BESCHAFFUNGSKRITERIUM Dokumentieren Sie nicht nur, dass Verschlüsselung vorhanden ist. Halten Sie fest, welches Schlüsselmodell je Datenklasse und Dienst vorgeschrieben ist, welche Ausnahmen zulässig sind und wer diese genehmigt.
Wie realistisch ist ein späterer Ausstieg?
Ein belastbarer Exit-Plan erhält Handlungsfähigkeit. Er ist kein Misstrauensvotum gegen den Anbieter, sondern Teil eines ordentlichen Betriebsmodells – und sollte vor der ersten Migration entstehen, nicht nach der ersten unerwarteten Preiserhöhung.
Ein Exit muss technisch und kaufmännisch funktionieren
- Datenformate, Schnittstellen und Exportwege sind dokumentiert und maschinenlesbar.
- Proprietäre APIs, Managed Services und Identitätsabhängigkeiten sind inventarisiert.
- Datenvolumen, Übertragungsdauer, Egress-, Migrations- und Parallelbetriebskosten sind kalkuliert.
- Fristen, Mitwirkungspflichten, Löschung von Restdaten und Backups sowie Nachweise sind vertraglich geregelt.
- Der Exit wurde für repräsentative Workloads praktisch getestet.
Portabilität bedeutet nicht, dass jeder Workload morgen verschoben werden muss. Sie bedeutet, dass ein Wechsel möglich bleibt, ohne die Anwendung praktisch neu bauen zu müssen. Container und Infrastructure as Code können helfen. Sie beseitigen aber weder Datenbankabhängigkeiten noch proprietäre Ereignisdienste, Identitätsmodelle oder Betriebswissen. Genau deshalb gehört der Exit-Aufwand in die Architekturentscheidung.
Wie eigenständig kann die Organisation die Cloud betreiben?
Souveränität ist auch Betriebsfähigkeit. Eine Organisation bleibt nur dann handlungsfähig, wenn sie Konfigurationen, Berechtigungen, Logs, Backups und Wiederherstellung selbst verstehen und kontrollieren kann – unabhängig davon, wer den täglichen Betrieb übernimmt.
- Konfigurationen werden reproduzierbar als Infrastructure as Code verwaltet.
- Logs und Monitoringdaten sind vollständig exportierbar und außerhalb der Plattform auswertbar.
- Das interne Team kann Rollen und Berechtigungen steuern und administrative Änderungen nachvollziehen.
- Backup- und Restore-Verfahren sind dokumentiert; Wiederherstellungen werden regelmäßig getestet.
- Für längere Supportstörungen, Vertragsänderungen und neue Unterauftragnehmer existieren klare Bewertungs- und Eskalationswege.
Ein Managed-Service-Partner kann fehlende Kapazität ausgleichen. Verantwortung lässt sich trotzdem nicht vollständig auslagern. Rollen, Entscheidungsrechte, Notfallzugänge und Wissenstransfer müssen so gestaltet sein, dass der Kunde seine Umgebung beurteilen und bei Bedarf übernehmen oder übertragen kann. Souveränität entsteht deshalb nicht allein durch Produktauswahl, sondern durch Architektur, Governance und einen belastbaren Betrieb.
STACKIT, Azure oder Hybrid Cloud? Der Workload entscheidet
Es gibt keine pauschale Siegerliste. Die sinnvolle Plattform ergibt sich aus Schutzbedarf, Funktionsbedarf und akzeptierter Abhängigkeit des jeweiligen Workloads.
|
Kriterium |
Zu klärende Frage |
|---|---|
|
Schutzbedarf |
Wie sensibel sind Daten und Geschäftsprozesse? |
|
Rechts- und Zugriffsrisiko |
Welche Drittstaatenzugriffe müssen technisch oder vertraglich begrenzt werden? |
|
Funktionsbedarf |
Welche Cloud-Dienste benötigt die Anwendung tatsächlich? |
|
Integrationen |
Welche Abhängigkeiten bestehen zu Microsoft, SaaS, On-Premises oder Partnern? |
|
Portabilität |
Wie stark darf sich der Workload an proprietäre Services binden? |
|
Betriebsfähigkeit |
Wer überwacht, sichert und entstört die Anwendung? |
|
Exit-Aufwand |
Wie lange und wie teuer wäre ein realistischer Wechsel? |
So lassen sich die Optionen einordnen
STACKIT sollten Unternehmen genauer prüfen, wenn europäische Betreiberstrukturen, regionale Datenverarbeitung und ein EU-Rechtsrahmen besonders hoch gewichtet werden. STACKIT dokumentiert derzeit Cloud-Regionen in Deutschland und Österreich. Auch hier bleiben die konkrete Serviceverfügbarkeit, Supportwege, Schlüsselmodelle und Exportmöglichkeiten auf Dienstebene zu prüfen.
Azure kann sinnvoll sein, wenn Funktionsbreite, globale Skalierung, bestehende Microsoft-Integration oder spezialisierte Plattformdienste entscheidend sind. Dann müssen Souveränitätskontrollen pro Dienst bewusst ausgewählt, konfiguriert und überwacht werden. Ein großes Portfolio ist ein Vorteil – und eine Einladung, genauer hinzusehen.
Ein Hybridmodell bietet sich an, wenn Workloads unterschiedliche Anforderungen haben. Kritische Daten oder Kernanwendungen können anders betrieben werden als standardisierte Kollaborations-, Analyse- oder Skalierungsdienste. Hybrid ist allerdings kein Selbstzweck: Zusätzliche Plattformen erhöhen den Bedarf an Governance, Monitoring, Fähigkeiten und sauber definierten Verantwortlichkeiten.
KERNAUSSAGE Nicht das Anbieterlogo entscheidet über Souveränität. Entscheidend ist, welcher Workload wo betrieben wird, welche Kontrollen greifen und welche Abhängigkeiten bewusst akzeptiert werden.
Fazit: Souveränität muss prüfbar werden
Cloud-Souveränität ist keine Ja-Nein-Eigenschaft und kein Häkchen hinter dem Serverstandort. Sie hat Abstufungen, die sich aus Schutzbedarf, Architektur, Vertrag und Betriebsmodell ergeben. Wer Zugriffe, Schlüssel, Exit und Betriebsfähigkeit pro Workload bewertet, ersetzt die Grundsatzdebatte durch überprüfbare Anforderungen. Genau das macht Anbieter vergleichbar – und Entscheidungen langfristig tragfähig.
Für Ausschreibungen empfiehlt sich ein einfaches Prinzip: Jede Souveränitätsanforderung erhält einen Verantwortlichen, einen akzeptierten Nachweis und einen festen Prüfzyklus. Denn auch ein passendes Ausgangsdesign bleibt nicht automatisch passend, wenn Dienste, Unterauftragnehmer, Verträge oder interne Prozesse sich verändern.
Welche Form von Souveränität braucht welcher Workload?
In der kostenlosen Interlake Beratungsanalyse betrachten wir Daten, Zugriffswege, Abhängigkeiten, Betriebsanforderungen und Exit-Möglichkeiten – bevor aus einer Grundsatzdebatte eine teure Fehlentscheidung wird.
FAQ zur souveränen Cloud
Reicht ein Rechenzentrum in Deutschland für eine souveräne Cloud?
Nein. Der Standort beantwortet nicht, wer auf Daten zugreifen kann, welchem Recht der Anbieter unterliegt, wer die Schlüssel kontrolliert oder wie ein Anbieterwechsel funktioniert.
Was gehört zu einer Cloud-Exit-Strategie?
Dazu gehören exportierbare Daten, dokumentierte Schnittstellen, portable Anwendungen, geklärte Kosten und Fristen sowie getestete Verfahren für Migration, Übergabe und Löschung.
Ist eine europäische Cloud automatisch souverän?
Nein. Auch bei einem europäischen Anbieter müssen Supportzugriffe, Unterauftragnehmer, Schlüsselverwaltung, Portabilität und betriebliche Abhängigkeiten geprüft werden.
Wann ist eine Hybrid Cloud sinnvoll?
Eine Hybrid Cloud ist sinnvoll, wenn Workloads unterschiedliche Anforderungen an Schutzbedarf, Funktionalität, Skalierung, Rechtsraum oder Portabilität haben und die Organisation die zusätzliche Betriebs- und Governance-Komplexität beherrscht.
