CLOUD-Act-Risiken vermeiden: Europäische Daten architekturbasiert schützen

Wie Sie den Zugriff der US-Regierung auf europäische Daten verhindern: Ein architektonischer Ansatz für das CLOUD-Act-Problem

Europäische Unternehmen, die sensible Daten über US-basierte Cloud-Plattformen verarbeiten, stehen vor einem strukturellen Compliance-Problem, das weder durch Vertragsrecht noch durch Datenresidenz gelöst werden kann.

Der Clarifying Lawful Overseas Use of Data (CLOUD) Act von 2018 verpflichtet US-Unternehmen, weltweit gespeicherte Daten auf Anforderung einer gültigen US-Behörde bereitzustellen – unabhängig vom Speicherort oder bestehenden Datenschutzvereinbarungen.

Für Unternehmen, die der DSGVO, NIS2 und DORA unterliegen, entsteht dadurch ein direkter Konflikt zwischen den genutzten Plattformen und den gesetzlichen Pflichten.

Zusammenfassung

Kernaussage: Der US CLOUD Act schafft einen unauflösbaren Konflikt zwischen den gesetzlichen Verpflichtungen von US-Anbietern und dem europäischen Recht auf Datensouveränität. Maßnahmen wie Standardvertragsklauseln, die Nutzung von EU-Rechenzentren und andere Ansätze beseitigen dieses Risiko nicht, da der CLOUD Act auf die Kontrolle des Anbieters und nicht auf den Speicherort abzielt. Nur kundengesteuerte Verschlüsselungsschlüssel – im Besitz des europäischen Unternehmens, nicht des Anbieters – verhindern technisch, dass US-Behörden Zugriff auf die tatsächlichen Dateninhalte erhalten.

Warum das relevant ist: Artikel 48 der DSGVO verbietet die Übermittlung personenbezogener Daten an Nicht-EU-Behörden allein aufgrund ausländischer Gerichts- oder Verwaltungsanordnungen. Ein Unternehmen, das Daten über eine US-Plattform verarbeitet, die dem CLOUD Act unterliegt, kann sich in einem dauerhaften strukturellen Verstoß befinden – nicht wegen eines konkreten Vorfalls, sondern aufgrund der Architektur. NIS2 und DORA verschärfen dieses Risiko durch zusätzliche Anforderungen an das Management von Drittanbieter-ICT-Lieferketten, insbesondere für kritische Branchen und Finanzdienstleister.

5 Wichtige Erkenntnisse

1. Der CLOUD Act richtet sich nach der Kontrolle des Anbieters, nicht nach dem Speicherort der Daten. Die Speicherung von Daten in einem Frankfurter oder Amsterdamer Rechenzentrum, das von einem US-Unternehmen betrieben wird, stellt die Daten nicht unter deutsche oder niederländische Gerichtsbarkeit. US-Strafverfolgungsbehörden können den Anbieter zur Herausgabe zwingen – unabhängig vom physischen Speicherort.
2. Standardvertragsklauseln und Auftragsverarbeitungsvereinbarungen können US-rechtliche Verpflichtungen nicht aushebeln. Der CLOUD Act verlangt von Anbietern die Erfüllung gültiger US-Anfragen, selbst wenn dies gegen ausländisches Recht verstößt. SCCs und DPAs sind vertragliche Instrumente ohne rechtliche Wirkung gegenüber US-Gerichts- oder Verwaltungsanordnungen an den Anbieter.
3. Das EU-US Data Privacy Framework löst das CLOUD-Act-Risiko nicht. Das DPF regelt die Übermittlung personenbezogener Daten an zertifizierte US-Unternehmen, verhindert aber nicht, dass US-Behörden CLOUD-Act-Anfragen stellen. FISA Section 702, im April 2024 mit erweitertem Geltungsbereich verlängert, bleibt ein eigenständiges und ungelöstes Problem nach europäischem Datenschutzrecht.
4. Ehrliche Transfer Impact Assessments identifizieren das CLOUD-Act-Risiko als ungemindert, wenn keine technischen Maßnahmen getroffen wurden. Die Schrems-II-Empfehlungen des EDPB benennen explizit kundengesteuerte Verschlüsselungsschlüssel, die im EWR verbleiben, als primäre technische Zusatzmaßnahme gegen das Risiko durch US-Überwachungsgesetze.
5. Kundengesteuerte Verschlüsselung macht CLOUD-Act-Anfragen technisch nicht ausführbar für Dateninhalte. Wenn das europäische Unternehmen – nicht der US-Anbieter – die Schlüssel unter Jurisdiktionskontrolle in HSMs hält, kann der Anbieter auch bei rechtlicher Verpflichtung keine lesbaren Daten liefern. Die Architektur löst, was Verträge nicht können.

Warum der CLOUD Act ein strukturelles Problem für europäische Unternehmen schafft

Der entscheidende Unterschied liegt zwischen Speicherort und Kontrolle der Daten. Die meisten europäischen Unternehmen, die auf US-Cloud-Plattformen umgestiegen sind, beruhigen sich mit dem Argument „Unsere Daten liegen in der EU“. Diese Sicherheit ist weitgehend unbegründet.

Wie der CLOUD Act funktioniert und warum EU-Rechenzentren keinen Schutz bieten

Der CLOUD Act verpflichtet US-Unternehmen, elektronische Kommunikation und Aufzeichnungen in ihrem Besitz, ihrer Obhut oder Kontrolle auf Anforderung zu sichern, zu sichern und offenzulegen – unabhängig vom Speicherort. Maßgeblich ist die Kontrolle, nicht die Geografie. Ein US-Cloud-Anbieter, der ein Rechenzentrum in Frankfurt betreibt, bleibt ein US-Unternehmen mit Kontrolle über die dort gespeicherten Daten. Wenn das US-Justizministerium oder das FBI eine Anforderung stellt, ist der Standort Frankfurt rechtlich irrelevant.

Das Problem wird dadurch verschärft, dass CLOUD-Act-Anfragen häufig mit Geheimhaltungsanordnungen verbunden sind – der US-Anbieter darf den europäischen Kunden, dessen Daten betroffen sind, rechtlich nicht informieren. Ein Unternehmen kann dauerhaft gegen Artikel 48 DSGVO verstoßen, der die Herausgabe personenbezogener Daten an Nicht-EU-Behörden ohne internationales Abkommen verbietet, ohne jemals von einer Anfrage zu erfahren. Der CLOUD Act ist kein solches Abkommen.

Warum vertragliche Schutzmechanismen die Lücke nicht schließen

Der CLOUD Act schreibt explizit vor, dass US-Anbieter auch dann gültigen Anfragen nachkommen müssen, wenn dies gegen ausländisches Recht verstößt. Die vertragliche Zusage eines Anbieters, eine Anfrage anzufechten oder den Kunden zu informieren, ist den US-rechtlichen Pflichten nachgeordnet. Das ist keine Theorie. Das Schrems-II-Urteil des EuGH hat den EU-US Privacy Shield genau aus diesem Grund für ungültig erklärt – weil US-Gesetze Behörden Zugriff auf EU-Personendaten in einer mit der DSGVO unvereinbaren Weise erlaubten und EU-Bürger keinen wirksamen Rechtsschutz hatten. Das Gericht bestätigte, dass auf Standardvertragsklauseln nicht vertraut werden kann, wenn US-Recht ihre Wirksamkeit untergräbt, und dass ergänzende technische Maßnahmen erforderlich sind.

Wie das DSGVO-Transferregime mit dem CLOUD-Act-Risiko zusammenhängt

Kapitel V der DSGVO – Artikel 44–49 – regelt internationale Übermittlungen personenbezogener Daten. Für europäische Unternehmen, die US-Plattformen nutzen, ist das Verständnis dieses Rahmens unerlässlich. Ob die Nutzung eines US-Cloud-Anbieters eine fortlaufende internationale Übermittlung darstellt und auf welcher Rechtsgrundlage, hat direkte Auswirkungen auf die regulatorische Exponierung im Rahmen der DSGVO-Compliance.

Artikel 44–49, Schrems II und was Transfer Impact Assessments leisten müssen

Unternehmen, die sich auf Artikel-46-SCCs stützen, müssen nach Schrems II Transfer Impact Assessments durchführen, um zu bewerten, ob US-Recht die Wirksamkeit der SCCs für die jeweiligen Übermittlungen beeinträchtigt. Die Empfehlungen 01/2020 des EDPB beschreiben diesen Prozess im Detail. Entscheidend ist, dass der EDPB starke Verschlüsselung vor der Übertragung – bei der die Entschlüsselungsschlüssel ausschließlich unter Kontrolle im EWR verbleiben – als technische Zusatzmaßnahme identifiziert hat, die das Risiko durch US-Überwachungsgesetze adressieren kann. Standardmäßige Cloud-Verschlüsselung, bei der der Anbieter die Schlüssel als Teil seines Dienstes verwaltet, genügt diesem Standard nicht: Der Anbieter behält technischen Zugriff auf Klartextdaten und bleibt CLOUD-Act-Anfragen ausgesetzt.

Warum das EU-US Data Privacy Framework das Problem nicht löst

Das DPF, im Juli 2023 von der Europäischen Kommission angenommen, erlaubt zertifizierten US-Unternehmen den Empfang von EU-Personendaten ohne separate SCCs. Es verhindert jedoch nicht, dass US-Behörden CLOUD-Act- oder FISA-Section-702-Anfragen an zertifizierte Unternehmen stellen. FISA Section 702 wurde im April 2024 mit erweitertem Geltungsbereich verlängert. Das Europäische Parlament warnte im Mai 2023, das DPF „schafft keine wesentliche Gleichwertigkeit“. Der EDPB forderte im November 2024 in seinem Prüfbericht eine Neubewertung innerhalb von drei Jahren. Anfang 2025 entfernte die Trump-Regierung drei von fünf Mitgliedern des US Privacy and Civil Liberties Oversight Board – des Gremiums, das die DPF-Geheimdienstverpflichtungen überwacht – und machte es damit beschlussunfähig. Die beiden Vorgänger des DPF, Safe Harbour und Privacy Shield, wurden beide vom EuGH für ungültig erklärt. Unternehmen, die sich primär auf die DPF-Zertifizierung zur CLOUD-Act-Risikominderung verlassen, bauen auf nachweislich fragilen Grundlagen.

NIS2 und DORA verschärfen die Exponierung

Die DSGVO ist nicht das einzige Regelwerk mit Pflichten im Zusammenhang mit dem CLOUD-Act-Risiko. Für Unternehmen in kritischer Infrastruktur und Finanzdienstleistungen fügen NIS2 und DORA spezifische Anforderungen an das Management von Drittanbieterrisiken hinzu, die direkt von der Abhängigkeit von US-Anbietern betroffen sind.

NIS2-Lieferkettensicherheit und DORA-ICT-Drittrisiko

NIS2, gültig ab Oktober 2024, verpflichtet wesentliche und wichtige Einrichtungen, die Sicherheit der ICT-Lieferkette zu bewerten – einschließlich der Exponierung ihrer Anbieter gegenüber Zugriffen von Nicht-EU-Regierungen nach Artikel 21. Ein Unternehmen, das nicht geprüft hat, ob das CLOUD-Act-Risiko seines US-Cloud-Anbieters ein Lieferkettenrisiko darstellt, ist potenziell nicht konform mit den NIS2-Risikomanagementpflichten – unabhängig davon, ob eine konkrete Anfrage vorliegt. Die Bußgelder betragen bis zu 10 Mio. € oder 2 % des weltweiten Jahresumsatzes für wesentliche Einrichtungen.

DORA, gültig ab Januar 2025, verpflichtet Finanzunternehmen, das Konzentrationsrisiko durch die Abhängigkeit von ICT-Anbietern zu bewerten, Vertraulichkeitszusagen zu prüfen und dokumentierte Exit-Strategien für kritische ICT-Beziehungen vorzuhalten. Der CLOUD Act schafft ein spezifisches Konzentrationsrisiko, das DORA von Finanzunternehmen verlangt zu bewerten und zu adressieren. Der Leitfaden der EZB vom Juli 2025 zum Outsourcing von Cloud-Diensten unterstreicht dies und betont die risikobasierte Bewertung der rechtlichen Exponierung von Cloud-Anbietern für von der EZB beaufsichtigte Banken.

Die architektonische Lösung: Kundengesteuerte Verschlüsselung

Die EDPB-Leitlinien definieren die Anforderung präzise: Der US-Anbieter darf niemals Zugriff auf unverschlüsselte Daten oder die Verschlüsselungsschlüssel haben. Dies ist eine architektonische, keine vertragliche Vorgabe. Sie erfordert Plattformen, bei denen die Einhaltung der Datensouveränität bereits auf der Verschlüsselungsebene verankert ist – mit Schlüsseln unter Kontrolle des europäischen Kunden, gespeichert in HSMs innerhalb der eigenen Jurisdiktion.

Wie kundengesteuerte Verschlüsselung das CLOUD-Act-Risiko adressiert

Kundengesteuerte Verschlüsselung folgt einem einfachen Prinzip: Die Daten werden verschlüsselt, bevor sie die Infrastruktur des US-Anbieters erreichen – mit Schlüsseln, die der Kunde selbst erzeugt und unabhängig speichert. Wenn eine US-Behörde eine CLOUD-Act-Anfrage stellt, kann der Anbieter die verschlüsselten Daten liefern – aber nicht den lesbaren Inhalt, da er die Schlüssel nicht besitzt. Die Anforderung ist technisch nicht ausführbar für die eigentlichen Informationen. Für DSGVO-Zwecke erfüllt diese Architektur direkt die Zusatzmaßnahme des EDPB. Der Datenexporteur – das europäische Unternehmen – behält die alleinige Kontrolle über die Entschlüsselungsschlüssel im EWR. Der Datenimporteur – der US-Anbieter – verarbeitet nur Chiffretext. Genau diese Konfiguration hat der EDPB als geeignet zur Adressierung des US-Überwachungsrisikos identifiziert.

Jurisdiktionsspezifische Schlüsselbereitstellung für multinationale Unternehmen

Für Unternehmen mit Standorten in Deutschland, Frankreich, den Niederlanden und Großbritannien ermöglicht kundengesteuerte Verschlüsselung eine jurisdictionsspezifische Schlüsselbereitstellung. Deutsche Unternehmen betreiben HSMs in Deutschland und erfüllen damit DSGVO-Anforderungen sowie die strafrechtliche Vertraulichkeitspflicht nach §203 StGB. Französische Unternehmen kontrollieren Schlüssel in Frankreich und wahren das Berufsgeheimnis nach Code de la Santé Publique. Niederländische Unternehmen halten Schlüssel in den Niederlanden und erfüllen die Erwartungen der AP. Britische Unternehmen betreiben HSMs im Vereinigten Königreich und erfüllen die ICO-Leitlinien zu ergänzenden Transfermaßnahmen. Diese Architektur erfordert keinen Verzicht auf US-Cloud-Plattformen – sondern stellt sicher, dass die Verschlüsselungsebene unter europäischer Kontrolle liegt, bevor Daten US-Infrastruktur erreichen.

Dokumentation für Aufsichtsbehörden aufbauen

Die richtige Architektur einzusetzen ist notwendig, aber nicht ausreichend. Datenschutzbehörden, NIS2-Aufsichtsstellen und DORA-Zuständige erwarten dokumentierte Nachweise. Für Unternehmen, die das CLOUD-Act-Risiko durch kundengesteuerte Verschlüsselung adressieren, folgt die Dokumentation einer klaren Struktur.

Nachweis im Transfer Impact Assessment und laufende Compliance

Ein Schrems-II-konformes Transfer Impact Assessment für US-Anbieterbeziehungen sollte dokumentieren: die relevanten US-Gesetze (CLOUD Act, FISA 702); eine Bewertung, wie sie die SCCs beeinträchtigen; die eingesetzten technischen Zusatzmaßnahmen; die Begründung, warum diese Maßnahmen einen im Wesentlichen gleichwertigen Schutz bieten; sowie eine Monitoring-Verpflichtung bezüglich Änderungen der DPF-Angemessenheitsentscheidung. Nachweise umfassen Architekturdiagramme, Schlüsselmanagementverfahren, HSM-Bereitstellungsprotokolle und Audit-Trails, die zeigen, dass Zugriffskontrollen funktionieren. Für NIS2 und DORA kommen Lieferkettenrisikobewertungen zum CLOUD-Act-Risiko des Anbieters, Konzentrationsrisikobewertungen, Exit-Strategien und RBAC-Matrizen hinzu, die zeigen, wer was entschlüsseln kann.

Wie Kiteworks europäischen Unternehmen hilft, das CLOUD-Act-Risiko architektonisch zu adressieren

Das CLOUD-Act-Problem ist real, strukturell und lässt sich nicht vertraglich aus der Welt schaffen. Europäische Unternehmen, die sensible Daten über US-Plattformen ohne kundengesteuerte Verschlüsselungsschlüssel verarbeiten, haben eine Compliance-Lücke, die ehrliche Transfer Impact Assessments offenlegen, die DSGVO-Aufsichtsbehörden zunehmend adressieren und die NIS2- und DORA-Rahmen für Drittanbieterrisiken fordern. Die vom EDPB empfohlene architektonische Lösung ist heute verfügbar. Sie erfordert, dass die Verschlüsselungsebene dort sitzt, wo sie hingehört: unter europäischer Kontrolle, bevor Daten US-Infrastruktur erreichen.

Kiteworks bietet europäischen Unternehmen ein Private Data Network, das das CLOUD-Act-Risiko durch kundengesteuerte Verschlüsselung direkt adressiert. Die Verschlüsselungsschlüssel bleiben unter der exklusiven Kontrolle des europäischen Kunden und werden in HSMs innerhalb der eigenen Jurisdiktion gespeichert. Wenn Kiteworks Daten verarbeitet, verarbeitet es Chiffretext – Klartext ist für US-Behörden technisch nicht zugänglich, selbst bei einer Anforderung an Kiteworks.

Die Plattform unterstützt jurisdictionsspezifische Bereitstellung – deutsche Unternehmen kontrollieren Schlüssel in Deutschland, französische in Frankreich, niederländische in den Niederlanden, britische im Vereinigten Königreich – und erfüllt damit die Schrems-II-Zusatzmaßnahmen des EDPB sowie die Dokumentationsanforderungen für Transfer Impact Assessments. Kiteworks integriert Kiteworks Secure Email, Kiteworks Secure File Sharing, Secure MFT und Kiteworks Secure Data Forms in einer einheitlichen Architektur – sodass kundengesteuerte Verschlüsselung für alle Datenbewegungen durchgängig gilt.

Erfahren Sie mehr darüber, wie Kiteworks europäische Unternehmen beim Umgang mit dem CLOUD-Act-Risiko unterstützt – vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen 

• Blog-Beitrag  
  Datensouveränität: Best Practice oder regulatorische Pflicht?
• eBook  
  Datensouveränität und DSGVO
• Blog-Beitrag  
  Vermeiden Sie diese Fallstricke bei der Datensouveränität
• Blog-Beitrag  
  Best Practices für Datensouveränität
• Blog-Beitrag  
  Datensouveränität und DSGVO [Verständnis von Datensicherheit]