Frankfurt bedeutet nicht souverän
Ein Missverständnis, das Unternehmen Millionen an Compliance-Kopfschmerzen kostet: Daten in einem Frankfurter Rechenzentrum eines US-Hyperscalers zu speichern, erfüllt die EU-Datensouveränitätsanforderungen. Tut es nicht.
Der US CLOUD Act gibt US-Strafverfolgungsbehörden die Befugnis, US-basierte Technologieunternehmen zur Herausgabe von Daten zu zwingen. Unabhängig davon, wo diese Daten physisch gespeichert sind.
Ihre Produktionsdatenbank liegt in AWS eu-central-1? Rechtlich ist sie immer noch im Zugriff von US-Anordnungen.
Für viele Workloads ist das akzeptabel. Die DSGVO verlangt nicht strikt, dass alle EU-Daten innerhalb der EU-Grenzen bleiben. Aber für regulierte Branchen (Gesundheit, Banken, Behörden, kritische Infrastruktur) ist der Unterschied zwischen Datenresidenz und Datensouveränität entscheidend.
Residenz vs. Souveränität: Der Unterschied, der zählt
Datenresidenz bedeutet: Ihre Daten liegen auf Servern innerhalb einer bestimmten geografischen Grenze. Frankfurt, Dublin, Amsterdam. Einfacher physischer Standort.
Datensouveränität bedeutet: Diese Daten unterliegen ausschließlich den Gesetzen dieser Jurisdiktion. Kein Zugriff ausländischer Regierungen. Keine grenzüberschreitende rechtliche Exposition.
Die meisten Unternehmen denken, sie haben Souveränität, wenn sie nur Residenz haben. Diese Lücke wächst, während die Durchsetzung bei DSGVO, NIS2, DORA und dem EU Data Act strenger wird.
Was die DSGVO tatsächlich verlangt
Die DSGVO schreibt keine EU-Datenresidenz vor. Was sie vorschreibt: Personenbezogene Daten, die außerhalb der EU/des EWR übertragen werden, müssen “im Wesentlichen gleichwertigen” Schutz erhalten.
Drei Mechanismen für rechtmäßige internationale Übermittlungen:
- Angemessenheitsbeschlüsse. Die Europäische Kommission erklärt ein Land für angemessen. Die USA haben derzeit Angemessenheit unter dem EU-US Data Privacy Framework, obwohl rechtliche Anfechtungen laufen.
- Standardvertragsklauseln (SVKs). Vorab genehmigte Vertragsvorlagen, die den Empfänger an EU-Datenschutzstandards binden.
- Verbindliche interne Datenschutzvorschriften (BCRs). Für multinationale Organisationen.
In der Praxis ist es der einfachste Weg, die Daten in der EU zu belassen. Keine Angemessenheitsbeschlüsse zu überwachen. Keine SVKs zu pflegen. Kein Risiko eines Schrems-III-Urteils, das Ihren Übermittlungsmechanismus über Nacht ungültig macht.
Die Cloud-Anbieter-Landschaft
US-Hyperscaler mit EU-Regionen
AWS, Azure und Google Cloud bieten alle EU-Rechenzentrumsregionen. Feature-reich, gut dokumentiert, und Ihr Engineering-Team kennt sie bereits.
Der Kompromiss: US-Jurisdiktion. Der CLOUD Act gilt. Einige Hyperscaler bieten “Sovereign Cloud”-Konfigurationen an (Microsoft Cloud for Sovereignty, AWS European Sovereign Cloud). Diese sind Schritte in die richtige Richtung, aber die zugrunde liegende juristische Person bleibt US-basiert.
Europäische Cloud-Anbieter
OVHCloud (Frankreich), Hetzner (Deutschland), IONOS (Deutschland), Scaleway (Frankreich), UpCloud (Finnland). EU-Hauptsitz. EU-Jurisdiktion. Keine CLOUD-Act-Exposition.
Der Kompromiss: weniger Managed Services, kleinere Ökosysteme, potenziell weniger ausgereifte Tools. Aber für Compute, Storage, Datenbanken und Kubernetes-Hosting sind sie praxiserprobt.
Hetzner ist besonders beliebt im deutschen Markt. Wettbewerbsfähige Preise. Rechenzentren in Nürnberg, Falkenstein und Helsinki. DSGVO-konform standardmäßig, weil es keine Jurisdiktionskomplexität gibt.
Der hybride Ansatz
Das empfehlen wir den meisten Kunden. Sensible Daten (personenbezogene Daten, Finanzunterlagen, Gesundheitsdaten) auf EU-souveräner Infrastruktur. Alles andere dort, wo es technisch sinnvoll ist.
Ihre Benutzer-Authentifizierungsdatenbank und Kundendaten auf Hetzner. Content Delivery, Analytics-Verarbeitung und nicht-sensible Workloads auf AWS oder Azure. Verbunden über verschlüsseltes VPN oder Private-Network-Links.
Sie bekommen Souveränität, wo es zählt, und Hyperscaler-Features, wo Sie sie brauchen.
Regulatorische Anforderungen jenseits der DSGVO
NIS2 schreibt keine Datenresidenz direkt vor, verlangt aber Lieferketten-Risikomanagement. Wenn die Jurisdiktion Ihres Cloud-Providers rechtliche Risiken einführt, ist das ein Lieferkettenrisiko, das Sie bewerten müssen. Siehe unseren NIS2-Compliance-Leitfaden.
DORA ist am strengsten. Finanzunternehmen müssen das IKT-Drittanbieter-Konzentrationsrisiko managen. Sich vollständig auf einen einzigen US-Hyperscaler zu verlassen, ist ein Compliance-Problem.
Der EU Data Act fügt Datenportabilitätsanforderungen für Cloud-Dienste hinzu. Anbieter müssen Tools für Datenexport und -wechsel bereitstellen.
Branchenspezifische Regeln können noch strenger sein. Deutsche Gesundheitsdaten unterliegen zusätzlichen Anforderungen des nationalen Rechts. Finanzdaten unter BaFin-Regulierung. Daten des öffentlichen Sektors unter BSI-Richtlinien.
Entscheidungsrahmen für die Architektur
Stellen Sie diese vier Fragen:
1. Welche Datenklassifizierungsstufen haben Sie? Nicht alle Daten brauchen den gleichen Schutz. Definieren Sie Stufen. Wenden Sie unterschiedliche Residenzanforderungen auf jede an.
2. Was ist Ihre regulatorische Exposition? NIS2-reguliert? DORA-anwendbar? Verarbeitung von Kinderdaten? Gesundheitsdaten? Jede Regulierung verschiebt die Kalkulation.
3. Was ist Ihre Risikotoleranz bei Übermittlungen? Das EU-US Data Privacy Framework existiert heute, könnte aber rechtlich angefochten werden.
4. Was kostet die Souveränität technisch? Vollständig EU-souveräne Infrastruktur bedeutet weniger Managed Services. Mehr Ops-Aufwand. Wägen Sie das gegen die Compliance-Kosten der Alternative ab.
Für die meisten EU-fokussierten KMU ist der Sweet Spot: Europäisches Hosting für Produktionsdaten und kundenorientierte Systeme, mit Hyperscaler-Services für nicht-sensibles Computing und globale CDN-Auslieferung.
Praktische Umsetzungsschritte
Schritt 1: Dateninventur. Klassifizieren Sie jeden Datentyp. Personenbezogen, besonders schützenswert, finanziell, gesundheitsbezogen, geschäftsvertraulich, öffentlich. Erfassen Sie, wo jeder aktuell liegt.
Schritt 2: Regulatorisches Mapping. Für jeden Datentyp identifizieren, welche Regulierungen gelten.
Schritt 3: Anbieterbewertung. Cloud-Anbieter bewerten nach: Unternehmensjurisdiktion, CLOUD-Act-Exposition, vertragliche Schutzmaßnahmen, Verschlüsselungs-Key-Management, Zertifizierungen (ISO 27001, C5, SOC 2).
Schritt 4: Architekturdesign. Infrastrukturtopologie entwerfen. Welche Services laufen wo? Wie fließen Daten zwischen Umgebungen?
Schritt 5: Alles dokumentieren. Transfer Impact Assessments. Lieferantenrisikobewertungen. Architekturentscheidungsprotokolle. Regulierungsbehörden verlangen diese Dokumentation.
Für den breiteren EU-Compliance-Kontext siehe unseren Pillar-Guide zur EU-Compliance für Softwareteams. Für DSGVO-konforme Architektur: unser Architektur-Leitfaden.
Datenresidenz für Ihre EU-Software klären? Lassen Sie uns gemeinsam Ihre Architektur planen. Wir helfen Teams, pragmatische Souveränitätsentscheidungen zu treffen.
