Datensouveränität nach dem Data Privacy Framework: warum EU-Hosting zur Architekturfrage wird
Das EU-US Data Privacy Framework bleibt vorerst gültig, steht aber unter Revision. Warum Hosting-Standort, Betreiberkontrolle und Verschlüsselungshoheit keine Compliance-Häkchen sind, sondern Architekturentscheidungen mit langer Halbwertszeit.
Wer personenbezogene Daten in die USA übermittelt, stützt sich seit 2023 auf den Angemessenheitsbeschluss zum EU-US Data Privacy Framework (DPF). Im September 2025 hat das Gericht der Europäischen Union (EuG) eine Klage dagegen abgewiesen, das Framework bleibt damit gültige Rechtsgrundlage. Doch der Fall ist nicht abgeschlossen: Ende Oktober 2025 wurde Rechtsmittel zum Europäischen Gerichtshof eingelegt (Rechtssache C-703/25 P). Ein erneutes Kippen, ein „Schrems III", ist nicht ausgeschlossen.
Diese Unsicherheit ist kein Grund zur Panik, aber ein guter Anlass, eine Frage von der Compliance-Ebene auf die Architekturebene zu heben.
Warum das mehr als ein Häkchen ist
Der bequeme Umgang mit Datentransfers besteht darin, sie als Vertragsfrage zu behandeln: Solange ein gültiger Beschluss oder Standardvertragsklauseln vorliegen, ist die Übermittlung gedeckt. Das stimmt rechtlich, verkennt aber das eigentliche Risiko. Jede Rechtsgrundlage für Drittlandstransfers steht seit Jahren unter Vorbehalt. Safe Harbor fiel 2015, das Privacy Shield 2020, und der aktuelle Rahmen wird gerichtlich überprüft. Wer seine Architektur an einer Rechtsgrundlage ausrichtet, die alle paar Jahre wackelt, baut eine Abhängigkeit ein, die er nicht kontrolliert.
Die robustere Frage lautet nicht „ist der Transfer gedeckt", sondern „findet der Transfer überhaupt statt". Daten, die die EU nicht verlassen und auf die kein Drittland-Zugriff besteht, brauchen keinen Angemessenheitsbeschluss.
Drei Architekturentscheidungen
Hosting-Standort. Wo die Daten physisch liegen, ist die erste und sichtbarste Entscheidung. Ein Rechenzentrum in Frankfurt statt in einer US-Region ist die Grundlage, aber für sich allein nicht ausreichend, denn der Standort allein sagt nichts über die Kontrolle.
Betreiberkontrolle. Entscheidend ist, wer rechtlich und tatsächlich Zugriff auf die Daten und die Infrastruktur hat. Ein in der EU stehender Server, der von einem Unternehmen betrieben wird, das einem Drittlandrecht mit weitreichenden Herausgabepflichten unterliegt, löst das Problem nur halb. Die Frage nach dem anwendbaren Recht des Betreibers gehört deshalb zur Architektur, nicht nur zum Vertrag.
Verschlüsselungshoheit. Wer die Schlüssel hält, kontrolliert den Zugriff. Verschlüsselung, bei der ausschließlich der Kunde über die Schlüssel verfügt, macht einen Zugriff durch Dritte technisch wirkungslos, selbst wenn dieser rechtlich erzwungen würde. Schlüsselhoheit verlagert die Kontrolle von einer Zusage zu einer technischen Eigenschaft.
Souveränität als Voreinstellung, nicht als Nachrüstung
Diese drei Entscheidungen lassen sich nachträglich nur schwer und teuer ändern. Sie gehören an den Anfang einer Architektur, nicht in ein Projekt, das erst startet, wenn ein Gericht den nächsten Beschluss kippt. Genau das meint Souveränität by design: nicht die nachträgliche Absicherung eines Transfers, sondern eine Auslegung, die den problematischen Transfer gar nicht erst nötig macht.
In unserer Plattform ist EU-Hosting in Frankfurt die Voreinstellung, nicht die Premium-Option. Der Punkt selbst ist jedoch unabhängig vom Anbieter: Wer Standort, Betreiberkontrolle und Schlüsselhoheit früh klärt, macht sich von der nächsten gerichtlichen Wendung unabhängig.
Das Data Privacy Framework mag die aktuelle Prüfung überstehen oder nicht. Eine Architektur, die nicht von der Antwort abhängt, ist in beiden Fällen die ruhigere Wahl.