Rechtsordnung, Betreiberzugriff, Nachweise, Ausstieg: Was Unternehmen vor Vertragsabschluss oder Verlängerung nicht mit ihrem Cloud-Anbieter klären, fällt ihnen bei der Repatriation – der Rückholung von Daten und Workloads aus der Cloud – auf die Füße. Sechs Fragen für das Gespräch davor.
Digitale Souveränität klingt nach Geopolitik. Entschieden wird sie schon bei der Unterschrift eines Cloud-Vertrags: in der gewählten Architektur, bei der Anbieterwahl und in dem, was schriftlich zugesichert ist. Daran hängt, welches Recht gilt, wer technisch auf Daten zugreifen kann und ob sich Workloads später überhaupt noch verlagern lassen.
Wie eng diese Fesseln sitzen, merken viele Unternehmen erst beim Rückweg. Bis zur Repatriation wächst die Bindung an den Anbieter über Jahre durch Schnittstellen, proprietäre Funktionen, Datenmengen und eingespielte Abläufe. Wer unter diesen Bedingungen aussteigt, verhandelt aus einer schwachen Position. Vorher, bei Abschluss oder Verlängerung, ist noch vieles gestaltbar. Wer sich nach ISO 27001 zertifizieren lässt, ist sogar verpflichtet, die Weichen vorab zu stellen. Die Norm verlangt seit 2022, Sicherheitsanforderungen an Cloud-Dienste festzulegen, bevor der Dienst genutzt wird. Sechs Fragen gehören deshalb frühzeitig auf den Tisch.
1. Wer kontrolliert den Anbieter?
Daten in Deutschland ist ein Verkaufsargument, keine Rechtsauskunft. Entscheidend ist nicht allein der Serverstandort, sondern wer den Anbieter beherrscht und welchen Rechtsordnungen er unterliegt.
Steht ein US-Mutterkonzern dahinter, können auch US-amerikanische Pflichten relevant werden. Der Bezug muss dabei nicht offensichtlich sein. Manch europäischer Anbieter betreibt seine Plattform auf AWS, Azure oder Google Cloud und kann sich so die US-rechtliche Abhängigkeit über die Lieferkette ins Haus holen.
Tückisch ist, wenn diese Konstellation nachträglich entsteht: Wird ein europäisches Unternehmen von einem US-Konzern übernommen, bleiben die Daten, wo sie sind. Die Kontrolle aber wandert aus. Ist dieser Sachverhalt nicht geregelt, fehlen dem Kunden im Ernstfall die vertraglichen Reaktionsmöglichkeiten. In den Vertrag gehört deshalb eine Informationspflicht bei Änderungen der Kontrollstruktur.
2. Wie geht der Anbieter mit Zugriffen aus Drittländern um?
Welche Folgen eine solche Drittlandbindung hat, zeigt sich bereits im laufenden Betrieb. Einige Cloud-Anbieter lassen technische Störungen von Supportteams in Drittländern bearbeiten. Sie sollten offenlegen, welche Rollen dabei auf welche Daten zugreifen können, wie sie dies protokollieren und ob sie sich auf europäische Standorte begrenzen lassen. Entscheidend ist außerdem, ob solche Zugriffe nur durch entsprechend geschulte und autorisierte Mitarbeitende erfolgen dürfen.
Noch folgenreicher kann es sein, wenn eine ausländische Behörde die Herausgabe von Kundendaten verlangt. Der US CLOUD Act kann Anbieter, die US-amerikanischer Gerichtsbarkeit unterliegen, zur Herausgabe verpflichten, selbst wenn die Daten auf europäischen Servern liegen. Die DSGVO erlaubt eine Weitergabe jedoch nicht allein aufgrund einer solchen Anordnung. Für den Anbieter können damit widersprüchliche Pflichten entstehen.
Verantwortlich für die Auswahl und den datenschutzkonformen Einsatz des Dienstes bleibt das Kundenunternehmen. Ein Vertrag sollte den Anbieter deshalb dazu verpflichten, den Kunden zu informieren, soweit dies zulässig ist, und die Herausgabe auf das erforderliche Maß zu begrenzen sowie verfügbare Rechtsmittel zu nutzen.
3. Kann der Anbieter technisch auf die Daten zugreifen?
Viele Anbieter versichern, keinen Zugriff auf Kundendaten zu haben. „Wir greifen nicht zu“ ist ein Versprechen. „Wir können nicht zugreifen“ ist ein Zustand. Nur wenn der Anbieter weder Klartextdaten lesen noch die Schlüssel verwenden kann, kann er auch auf behördliche Anordnung keine lesbaren Inhalte herausgeben. Bleibt ihm ein technischer Weg, entscheiden Vertrag und interne Prozesse.
Ob der Zugriff tatsächlich ausgeschlossen ist, zeigt die Schlüsselverwaltung: Wer erzeugt und speichert die Schlüssel, wer darf sie verwenden, und ermöglichen Notfallzugänge eine Entschlüsselung? Solche Zugänge gehören eng begrenzt und lückenlos protokolliert. Eine eigene Ebene bilden die Metadaten. Auch wenn Inhalte verschlüsselt bleiben, ist oft sichtbar, wer wann welche Dokumente mit wem ausgetauscht hat. In einem M&A-Prozess kann das ähnlich aufschlussreich sein wie der Inhalt selbst.
4. Sind die Daten auch während der Verarbeitung geschützt?
Verschlüsselung bei Datenübertragung und -speicherung gilt längst als Standard. Zwei von drei Zuständen sind damit abgedeckt: der Transportweg (Data in Transit) und die Speicherung (Data at Rest). Der dritte bleibt meist offen. Für die Verarbeitung (Data in Use) werden Daten in der Regel entschlüsselt. Ausgerechnet dann, wenn Systeme mit ihnen arbeiten, liegen sie im Klartext vor.
Diesen blinden Fleck schließen isolierte Hardwareumgebungen. Sie kapseln die Verarbeitung so ab, dass auch privilegierte Administratoren keinen Einblick erhalten. Entscheidend ist also die Frage, ob unverschlüsselte Daten die Umgebung verlassen können. Die Antwort darauf sollte durch regelmäßige Penetrationstests nachweisbar sein.
5. Welche Nachweise liefert der Anbieter?
Ob ein Cloud-Dienst regulatorischen Anforderungen standhält, zeigt sich spätestens, wenn eine Aufsichtsbehörde Nachweise verlangt. Welche das sind – neben der DSGVO etwa Paragraf 203 StGB, NIS2 oder DORA –, hängt von der Branche ab. Dann muss das Unternehmen erklären können, wie seine Daten verarbeitet und geschützt werden.
Zertifikate allein machen die Cloud-Nutzung dabei nicht prüfungsfest. Entscheidend ist der Geltungsbereich. Ein Testat für ein Rechenzentrum hilft wenig, wenn die Anwendung anderswo läuft. Dazu kommen aktuelle Prüfberichte, Protokolle sicherheitsrelevanter Vorgänge und vertragliche Kontrollrechte. Diese Rechte gehören in den Vertrag, bevor sie gebraucht werden. Denn später lassen sie sich schwer nachverhandeln.
6. Wie realistisch ist ein Anbieterwechsel?
Der Vendor Lock-in zeigt sich beim Abschied, entsteht aber viel früher. Mit jeder proprietären Datenbank, jedem plattformeigenen Identitätsdienst und jeder anbieterspezifischen Automatisierung wächst die Bindung. Kommt es zum Wechsel, lassen sich die Daten zwar oft noch exportieren, zentrale Funktionen der Anwendung müssen jedoch neu gebaut werden. Der Anbieter sollte deshalb vorab benennen, welche Dienste nur auf seiner Plattform laufen.
Eine portable Architektur ist ein wichtiger Baustein für langfristige Unabhängigkeit. Entscheidend ist aber auch, dass Daten jederzeit exportiert werden können und für die Übergangphase klar geregelt ist, wie lange sie verfügbar bleiben und welche Unterstützung der Anbieter bei der Migration leistet. Ein dokumentierter Löschprozess inklusive Bestätigung stellt schließlich einen sauberen Wechsel sicher.
All das hat einen Preis. Der Migrationsaufwand und die Kosten des Parallelbetriebs beider Umgebungen summieren sich schnell. Eine Migration bleibt auch dann aufwendig, wenn der Anbieter aktiv unterstützt. Welche Kosten entstehen und welche Leistungen dabei übernommen werden, sollte deshalb geklärt werden, bevor ein Wechsel im Raum steht. Sind diese Kosten erst beim Ausstieg bekannt, ist der Verhandlungsspielraum gering.
Souveränität lässt sich nicht improvisieren
Ein Cloud-Vertrag ist schnell verlängert. Die Bindung an eine gewachsene Plattform löst sich dagegen nicht mit der Kündigung. Wer den Exit vorbereitet, bevor er ihn braucht, behält mehr Einfluss auf Fristen, Kosten und Übergang. Eine Exit-Klausel allein reicht dafür nicht. Technische Portabilität, vertragliche Rechte und ein erprobter interner Exit-Plan müssen zusammenpassen. Wer erst bei der Repatriation fragt, wie er aussteigen kann, hat die Bedingungen seines Ausstiegs längst akzeptiert.