Kann ich einen Cloud Service Provider mit Sitz in den USA nutzen, wenn meine Daten innerhalb der EU verbleiben müssen?

Die kurze Antwort lautet: bedingt. Ein US-basierter Cloud Service Provider mit EU-Rechenzentren ist nicht automatisch von der Speicherung von Daten von EU-Bürgern ausgeschlossen – aber eine konforme Nutzung erfordert mehr als die Auswahl einer Serverregion in Frankfurt oder Dublin. Die meisten Unternehmen, die glauben, diese Frage durch die Wahl des Standorts gelöst zu haben, haben lediglich die Adresse ihrer Daten geändert, nicht jedoch deren rechtliche Exponierung.

Dieser Beitrag behandelt drei Fragen: Ob US-Provider überhaupt genutzt werden dürfen, welche Datenkategorien den strengsten Souveränitätsanforderungen unterliegen und welche Schutzmaßnahmen notwendig sind, um eine wirklich konforme Lösung zu gewährleisten.

Executive Summary

Kernaussage: US-basierte Cloud Service Provider dürfen Daten von EU-Bürgern nur dann speichern, wenn spezifische technische und rechtliche Schutzmaßnahmen implementiert sind – Maßnahmen, die über die Auswahl eines EU-Servers hinausgehen und das strukturelle Problem adressieren, dass US-Recht für US-Unternehmen unabhängig vom Serverstandort gilt. Der US CLOUD Act und FISA Section 702 schaffen staatliche Zugriffsrisiken, die weder durch den EU-US Data Privacy Framework (DPF) noch durch Standardvertragsklauseln allein beseitigt werden. Die erforderliche Lösung ist architektonisch: Vom Kunden kontrollierte Verschlüsselung mit Schlüsseln außerhalb der Infrastruktur des Providers, sodass der Provider technisch nicht in der Lage ist, lesbare EU-Daten bereitzustellen – unabhängig von rechtlichem Zwang.

Warum das relevant ist: EU-Datenschutzbehörden haben Entscheidungen getroffen, wonach bestimmte US-Cloud-Modelle die DSGVO verletzen – unabhängig vom Serverstandort. Die NIS 2-Richtlinie, DORA und branchenspezifische nationale Gesetze stellen zusätzliche Souveränitätsanforderungen mit Strafen von bis zu 4 % des weltweiten Umsatzes. Unternehmen, die ihre US-Provider-Modelle nicht an die Post-Schrems II-Standards angepasst haben, sind aktivem Durchsetzungsrisiko ausgesetzt.

wichtige Erkenntnisse

1. EU-Serverstandort bedeutet nicht EU-Gerichtsbarkeit. Das Frankfurter Rechenzentrum eines US-Providers unterliegt weiterhin US-Rechtsansprüchen aufgrund der Konzernstruktur. Die Geografie ändert den Speicherort der Daten, aber nicht, welche Regierung Zugriff erzwingen kann.
2. Der EU-US Data Privacy Framework hebt den CLOUD Act nicht auf. Der DPF bietet einen Übertragungsmechanismus für personenbezogene Daten gemäß DSGVO – er entbindet US-Provider jedoch nicht von Überwachungspflichten nach US-Recht. CLOUD Act-Anforderungen bleiben unabhängig von der DPF-Teilnahme bestehen.
3. Für einige Datenkategorien gelten Beschränkungen, die US-Provider ohne architektonische Souveränitätskontrollen faktisch ausschließen. Gesundheitsdaten nach nationalem Recht, Finanzdaten nach DORA, klassifizierte Regierungsdaten und bestimmte als risikoreich eingestufte personenbezogene Daten gemäß DSGVO Art. 9 unterliegen Restriktionen, die generische SCC-Modelle nicht ausreichend adressieren.
4. Konforme Nutzung eines US-Providers erfordert spezifische technische Schutzmaßnahmen, nicht nur juristische Dokumentation. Nach Schrems II hat der EDSA die vom Kunden kontrollierte Verschlüsselung mit Schlüsseln außerhalb der Provider-Infrastruktur als erforderliche technische Zusatzmaßnahme festgelegt. Vertragliche Zusagen reichen nicht aus, wenn US-Recht die Herausgabe unabhängig von Vertragsklauseln verlangt.
5. Die architektonische Alternative ist eine Single-Tenant-Bereitstellung in Europa mit kundengesteuerter Verschlüsselung. Damit wird das CLOUD Act-Problem strukturell gelöst: Der Provider kann keine lesbaren Daten liefern, da er nie im Besitz der Schlüssel war – so ist die gleichzeitige Einhaltung von US-Recht und EU-Datenschutz technisch möglich.

Das Kernproblem: Gerichtsbarkeit folgt dem Unternehmen, nicht dem Server

Die Annahme hinter vielen „EU-Rechenzentrums“-Modellen ist, dass der physische Datenstandort die rechtliche Zuständigkeit bestimmt. Das ist nicht der Fall. Der US CLOUD Act (2018) verpflichtet US-Unternehmen, von ihnen kontrollierte Daten auf rechtmäßige Anforderung bereitzustellen – unabhängig vom Speicherort. Eine Anfrage an den Hauptsitz eines US-Providers zwingt zur Herausgabe von Daten aus EU-Servern. Die Serveradresse ist irrelevant; die Konzernzugehörigkeit entscheidet über die US-Reichweite. FISA Section 702 erweitert dies auf Kommunikationsdaten im Rahmen nationaler Sicherheitsbefugnisse. Weder CLOUD Act noch FISA 702 verlangen EU-kompatible richterliche Kontrolle oder Kundenbenachrichtigung.

Das ist kein theoretisches Risiko. Österreichische, französische und italienische Datenschutzbehörden haben entschieden, dass bestimmte US-Cloud-Modelle die DSGVO verletzen, weil das CLOUD Act-Risiko nicht ausreichend adressiert wurde.

Was der EU-US Data Privacy Framework regelt – und was nicht

Viele Unternehmen gehen davon aus, dass der 2023 eingeführte EU-US Data Privacy Framework das Schrems II-Problem gelöst hat. Das stimmt nicht. Der DPF bietet einen Angemessenheitsmechanismus nach DSGVO Art. 45 – eine Rechtsgrundlage für die Übertragung personenbezogener Daten an zertifizierte US-Unternehmen. Er hebt jedoch den US CLOUD Act nicht auf. US-Provider mit DPF-Zertifizierung sind weiterhin verpflichtet, CLOUD Act-Anforderungen nachzukommen. Der DPF beantwortet die Frage nach der Übertragungsgrundlage, nicht aber, ob eine US-Behörde die Herausgabe von EU-Daten erzwingen kann.

Gegen den DPF laufen zudem Klagen von NOYB – der Organisation, die 2020 das Privacy Shield zu Fall brachte. Unternehmen, die sich ausschließlich auf die DPF-Zertifizierung verlassen, tragen das gleiche Risiko einer Ungültigerklärung wie beim Privacy Shield. Vom Kunden kontrollierte Verschlüsselung schützt unabhängig vom Rechtsrahmen, da der Provider praktisch keinen Zugriff auf die Daten hat – egal, welches Übertragungsmodell gilt.

Für welche Datentypen gelten die strengsten Souveränitätsanforderungen?

Nicht alle Daten bergen das gleiche Souveränitätsrisiko. Fünf Kategorien unterliegen den restriktivsten Anforderungen nach EU- und nationalem Recht.

Besonders schützenswerte personenbezogene Daten (DSGVO Art. 9). Gesundheits-, biometrische, genetische und andere sensible Daten benötigen eine spezielle Rechtsgrundlage über die Standard-DSGVO hinaus. Übertragungen müssen sowohl Kapitel V als auch die Art. 9-Basis erfüllen – eine doppelte Anforderung, die generische SCC-Modelle oft nicht abdecken.

Gesundheits- und Patientendaten. Nationale Gesundheitsgesetze gehen über die DSGVO hinaus. Frankreich verlangt, dass Gesundheitsdaten auf französischer Infrastruktur verarbeitet werden. Deutschland stellt vergleichbare Anforderungen an Patientendaten. Mehrere nationale Regelungen schließen US-Provider für Gesundheitsdaten ohne Souveränitätskontrollen auf Infrastrukturebene faktisch aus – unabhängig von SCC-Modellen.

Finanzdaten. DORA (ab Januar 2025) verpflichtet Finanzunternehmen und deren IT-Dienstleister zu vertraglichen Regelungen zu Datenlokalisierung, Schlüsselmanagement und Exit-Strategien. Die EBA-Outsourcing-Guidelines verlangen dokumentierte Souveränitätsbewertungen. EU-Finanzunternehmen, die US-Cloud-Provider ohne angemessenes Schlüsselmanagement nutzen, sind derzeit nicht compliant.

Regierungs- und verteidigungsnahe Daten. Klassifizierte Daten, Daten von Verteidigungsauftragnehmern und Daten, die nationalen Cloud-Policies für den öffentlichen Sektor unterliegen, dürfen häufig unter keinem Übertragungsmechanismus auf US-Infrastruktur verarbeitet werden. Die meisten EU-Mitgliedstaaten haben explizite Beschränkungen für die Verarbeitung von Regierungsdaten durch nicht-europäische Provider.

Betriebsdaten kritischer Infrastrukturen. NIS 2 Art. 21 verpflichtet Betreiber kritischer Dienste – Energie, Transport, Gesundheit, Wasser, Finanz- und Digitalinfrastruktur – zur Bewertung der Souveränitätsstrategie von Cloud-Providern im Rahmen der Lieferkettensicherheit. Die Toleranzschwelle für CLOUD Act-Risiken ist hier deutlich niedriger als bei allgemeinen Geschäftsdaten.

Erforderliche technische und rechtliche Schutzmaßnahmen

Für Unternehmen, die US-Provider-Modelle konform gestalten wollen, sind vier Schutzmaßnahmen erforderlich.

Transfer Impact Assessment mit ehrlicher CLOUD Act-Bewertung. Ein TIA, dessen Schlussfolgerung auf technischen Kontrollen basiert, nicht auf vertraglichen Zusagen. Ein TIA, das CLOUD Act-Risiken anerkennt, aber auf Benachrichtigungsverfahren als Lösung setzt, genügt nicht den Post-Schrems II-Anforderungen – die Bewertung muss architektonisch begründet zu dem Schluss kommen, dass eine rechtmäßige Anforderung nicht zur Herausgabe lesbarer EU-Daten führt.

Vom Kunden kontrollierte Verschlüsselung mit Schlüsseln außerhalb der Provider-Infrastruktur. Die EDSA-Empfehlungen 01/2020 benennen dies als erforderliche technische Zusatzmaßnahme: Vom Kunden generierte Schlüssel, die in HSMs unter ausschließlicher Kontrolle des EU-Kunden liegen und nie beim US-Provider gespeichert werden. Ohne diese Maßnahme kann kein TIA, das CLOUD Act-Risiken anerkennt, eine ausreichende Schutzwirkung attestieren.

Durchsetzung der Datenresidenz auf Infrastrukturebene. Vertragliche Datenlokalisierungsklauseln sind ergänzende vertragliche Maßnahmen. Policy-basierte Geofencing-Lösungen, die das Verlassen der EU-Region technisch verhindern, sind technische Maßnahmen. Nach Schrems II ist diese Unterscheidung für die Bewertung durch Aufsichtsbehörden entscheidend.

Unveränderliche Audit-Trails und laufende Nachweisdokumentation. Das DSGVO-Accountability-Prinzip verlangt die fortlaufende Nachweisführung der Compliance. Unveränderliche Audit-Logs, Schlüsselmanagement-Protokolle und regelmäßig überprüfte TIAs sind Mindeststandard. Für DORA und NIS 2 muss diese Dokumentation auf Anfrage den Behörden vorgelegt werden können.

So liefert Kiteworks konforme EU-Datensouveränität

Das Private Data Network von Kiteworks adressiert das strukturelle Problem direkt. Single-Tenant-Bereitstellung am vom EU-Kunden gewählten Standort – On-Premises, europäische Private Cloud oder von Kiteworks gehostete EU-Infrastruktur – stellt sicher, dass Daten europäischer Gerichtsbarkeit und nicht US-Konzernkontrolle unterliegen. Kundengesteuerte Verschlüsselung (BYOK/BYOE) mit FIPS 140-3 Level 1-validierter Verschlüsselung bedeutet: Kiteworks besitzt nie Kundenschlüssel – eine CLOUD Act-Anfrage liefert nur Chiffretext. Die TIA-Schlussfolgerung ist architektonisch begründet – Kiteworks ist technisch nicht in der Lage, lesbare Daten zu liefern, und verlässt sich nicht nur auf vertragliche Zusagen. Policy-basiertes Geofencing setzt Datenresidenz auf Infrastrukturebene für alle Kanäle um – E-Mail, Filesharing, Managed File Transfer, Web-Formulare und APIs. Das CISO-Dashboard liefert unveränderliche Audit-Trails für jede Datenbewegung. Vorgefertigte Compliance-Berichte für DSGVO, NIS 2, DORA und ISO 27001 unterstützen laufende Nachweispflichten und regulatorische Anfragen für die Datenkategorien mit den restriktivsten Souveränitätsanforderungen.

Um die spezifischen Anforderungen Ihres Unternehmens an Datensouveränität und die Lösungen von Kiteworks zu besprechen, vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

• Blogbeitrag
  Datensouveränität: Best Practice oder regulatorische Pflicht?
• eBook 
  Datensouveränität und DSGVO
• Blogbeitrag
  Diese Fallstricke bei der Datensouveränität vermeiden
• Blogbeitrag
  Best Practices für Datensouveränität
• Blogbeitrag
  Datensouveränität und DSGVO [Verstehen von Datensicherheit]