Der US CLOUD Act und Artikel 48 der DSGVO stehen in einem direkten rechtlichen Zielkonflikt bei internationalen Datentransfers und behördlichen Zugriffen[1][2].
1. Das Grundproblem: Welches Prinzip gilt?
- Der US CLOUD Act ( Jurisdiction-by-Ownership ): Der 2018 erlassene Clarifying Lawful Overseas Use of Data Act ermächtigt US-Behörden, von US-Unternehmen (und deren Tochtergesellschaften) die Herausgabe von elektronischen Daten zu verlangen – unabhängig davon, wo die Daten physisch gespeichert sind[3]. Entscheidend ist nicht der Serverstandort (z. B. ein Rechenzentrum in Frankfurt oder Amsterdam), sondern die rechtliche Beherrschung durch den US-Mutterkonzern[3].
- Artikel 48 DSGVO ( Rechtshilfevorbehalt ): Art. 48 DSGVO legt fest, dass Urteile oder Entscheidungen von Verwaltungsbehörden aus einem Drittland (wie den USA), die die Herausgabe personenbezogener Daten verlangen, in der EU grundsätzlich nicht anerkannt werden. Eine Datenübermittlung an eine ausländische Behörde ist nach der DSGVO nur dann rechtmäßig, wenn sie auf einer wirksamen internationalen Übereinkunft beruht – etwa einem bilateralen Rechtshilfeabkommen (Mutual Legal Assistance Treaty / MLAT)[1][2].
2. Warum entsteht der direkte Konflikt?
- Bypassing von Rechtshilfeabkommen (MLAT): Der CLOUD Act umgeht das klassische MLAT-Verfahren, bei dem sich US-Behörden an europäische Gerichte wenden müssten[2][9]. Stattdessen verpflichtet die US-Justiz den US-Anbieter direkt[2][10].
- Fehlende Rechtsgrundlage nach DSGVO: Da zwischen der EU und den USA derzeit kein exekutives Abkommen unter dem CLOUD Act besteht, stellt eine alleinige Anordnung nach dem CLOUD Act aus Sicht der EU keine gültige Rechtsgrundlage für eine Datenübermittlung gemäß Art. 48 DSGVO dar[2][9].
- Die Zwickmühle ( Conflict of Laws ):
- Befolgt der US-Cloud-Anbieter (oder seine europäische Tochter) die US-Anordnung, verstößt er gegen die DSGVO, da eine rechtswidrige Drittlandübermittlung ohne zulässiges Instrument vorliegt[1][2].
- Verweigert der Anbieter die Herausgabe, riskiert er erhebliche Sanktionen nach US-Recht wegen Missachtung von Gerichtsentscheidungen[2].
- Geheimhaltungsanordnungen ( Gag Orders ): US-Herausgabeanordnungen sind häufig mit Stillschweigen belegt[11][12]. Der europäische Kunde (sowie die betroffenen Personen) erfährt in vielen Fällen nicht, dass seine Daten herausgegeben wurden, was zusätzlich gegen die Transparenz- und Betroffenenrechte der DSGVO verstößt[1][11].
3. Keine Lösung durch das Data Privacy Framework (DPF)
Das EU-US Data Privacy Framework (Angemessenheitsbeschluss der EU-Kommission) erleichtert zwar die allgemeine Übermittlung personenbezogener Daten für geschäftliche Zwecke an zertifizierte US-Empfänger, löst das Problem des CLOUD Acts jedoch nicht[13][14]. Das DPF bildet keine Rechtsgrundlage für behördliche Zwangszugriffe nach dem CLOUD Act[14].
4. Was bedeutet das für Unternehmen in der Praxis?
Da Verträge und Standardvertragsklauseln ein US-Gesetz nicht außer Kraft setzen können, greifen zur Risikoreduktion vor allem technische und organisatorische Maßnahmen:
- Kundenseitige Verschlüsselung (CMEK / BYOK): Wird der Dateninhalt so verschlüsselt, dass die Schlüssel ausschließlich beim EU-Kunden verbleiben, kann der Cloud-Anbieter im Falle einer CLOUD-Act-Anordnung technisch nur unlesbaren Chiffretext bereitstellen[15][16].
- Europäische Alternativen für Hochschutzbedarf: Für besonders sensible Daten oder Kernprozesse wählen viele Organisationen Anbieter ohne US-Konzernbezug, um das Zugriffsrisiko von vornherein auszuschließen[13].
Welche Rolle spielt die EU Data Boundary genau?
Die EU Data Boundary (sowie vergleichbare Initiativen anderer US-Hyperscaler) spielt eine wichtige technische Rolle für die Datenresidenz, bietet jedoch keinen vollständigen rechtlichen Schutz vor extraterritorialen Zugriffen[1][2].
Die konkrete Rolle und Wirkungsweise lässt sich anhand folgender Kernaspekte zusammenfassen:
1. Zusage zur regionalen Datenhaltung (Datenresidenz)
Mit der EU Data Boundary sichern Anbieter zu, dass Kundeninhalte und personenbezogene Daten vorrangig in Rechenzentren innerhalb der Europäischen Union bzw. des EWR gespeichert und verarbeitet werden[2][3]. Dies vereinfacht die primäre Risikobewertung nach der DSGVO und reduziert unnötige grenzüberschreitende Routine-Datenflüsse[4][5].
2. Die Grenze der Schutzwirkung: „Jurisdiction-by-Ownership“ vs. „Location“
Die physische Speicherung in einer EU-Region hebt die Anwendbarkeit ausländischer Gesetze wie des US CLOUD Acts nicht auf[2][6]. Für den CLOUD Act ist nicht der physische Serverstandort entscheidend (Jurisdiction-by-Location), sondern die rechtliche Beherrschung durch den US-Mutterkonzern (Jurisdiction-by-Ownership)[2]. Wenn eine US-Behörde eine rechtmäßige Herausgabeanordnung erlässt, ist der US-Mutterkonzern verpflichtet, auf die Daten zuzugreifen – selbst wenn diese in europäischen Rechenzentren liegen[2].
3. Technische Schutzschichten und Restrisiken
Obwohl die EU Data Boundary das juristische Grundproblem des CLOUD Acts nicht löst[2][10], bringt sie wertvolle technische Schutzmechanismen mit sich[2]:
- Erweiterte Verschlüsselungsoptionen: Sie ermöglicht den effektiven Einsatz von kundenkontrollierter Verschlüsselung (Customer-Managed Encryption Keys / CMEK oder Bring Your Own Key)[11][12]. Wenn der Schlüssel ausschließlich beim Kunden verbleibt, kann der Anbieter im Falle einer Herausgabeanordnung technisch nur unlesbaren Chiffretext bereitstellen[11][12].
- Support- und Administrationsschranken: Durch Funktionen wie Customer Lockbox können Support- und Wartungszugriffe aus Drittstaaten eingeschränkt und steuerbar gemacht werden[13].
- Verbleibendes Restrisiko bei Telemetrie & Support: Die EU Data Boundary stellt keine vollständig isolierte „EU-only Cloud“ dar[4]. Bei globalen Sicherheitsmonitoren, Telemetrie-/Diagnosedaten oder international angefordertem Support können weiterhin begrenzte Metadaten oder Zugriffe über die Regionsgrenzen hinaus anfallen[14].
Fazit für die Praxis
Die EU Data Boundary ist ein nützlicher Baustein in einem modernen Sicherheits- und Vertragskonzept, aber kein automatischer „Persilschein“[4][5]. Unternehmen dürfen sie nicht mit einer vollständigen Befreiung von Drittlandrisiken verwechseln, sondern müssen bei hochschutzbedürftigen Daten zusätzlich auf starke kundenkontrollierte Verschlüsselung (CMEK) setzen oder für kritische Kernprozesse reine EU-Anbieter ohne US-Konzernbezug evaluieren[5]
Quellenverzeichnis
- Dr. Datenschutz / intersoft consulting: DPIA des niederländischen Justizministeriums zur Google Cloud (Oktober 2026)[7].
- Privacy Company: DPIA on the use of Google Cloud Platform (GCP) & Dutch Government Consults Data Protection Authority on Privacy Risks of Google Workspace Enterprise (Juni 2026 / Feb. 2021)[11].
- Woelke IT-Solution GmbH: EU-Region reicht nicht mehr: Diese Cloud-Fallen übersehen viele (Mai 2026)[5].
- Netherlands Court of Audit (Algemene Rekenkamer): Dutch central government in the cloud – Dark clouds are looming (Januar 2025)[1].
- iBestuur: Publieke sector mag Google Cloud gebruiken (Juli 2026)[9].
- Cloud.nl Editorial Team: The CLOUD Act and your data: What Dutch businesses need to know (März 2026)[13].
- Google Cloud Blog (Marc Crandall, Joost Smit): Google Cloud confirmed to offer a safer choice for EU public sector organizations with Dutch DPIA approval (Juli 2026)[8].
- Ministerie van Justitie en Veiligheid (D. Yeşilgöz-Zegerius): Kamerstuk 26643, nr. 859 – Brief van de Minister van Justitie en Veiligheid (Mai 2022)[45].
- Xcademia: Google Cloud Wins Dutch DPIA Approval for EU Public Sector (Juli 2026)[14][69].
- University of Glasgow (G. Elena, C. W. Johnson): Factors Influencing Risk Acceptance of Cloud Computing Services in the UK Government (IJCCSA, 2015)[3].
