CLOUD Act: Welche Daten dürfen bei US-Anbietern liegen?
Was der CLOUD Act für Fachverfahren bedeutet
71 Prozent der Unternehmen in Deutschland nutzen Cloud-Angebote aus den USA, bevorzugen würden das nur 8 Prozent. Gemeint ist mit dem CLOUD Act ein US-Gesetz, das amerikanische Anbieter zur Herausgabe von Kundendaten zwingt, auch bei Speicherung in Europa.
Der CLOUD Act, ausgeschrieben Clarifying Lawful Overseas Use of Data Act, ist ein US-Gesetz aus dem Jahr 2018. Es verpflichtet Anbieter elektronischer Kommunikations- und Datendienste mit Sitz oder Geschäftstätigkeit in den USA, gespeicherte Kundendaten auf Anordnung einer US-Strafverfolgungsbehörde herauszugeben. Der Speicherort ist dabei unerheblich, auch Daten in europäischen Rechenzentren sind erfasst. Tochtergesellschaften unterliegen der Pflicht ebenfalls.
Warum ein Serverstandort in Deutschland nicht genügt
Die Lücke zwischen Nutzung und Präferenz erklärt sich weniger aus Bequemlichkeit als aus fehlenden Alternativen für einzelne Anwendungsfälle. Wichtiger für die Bewertung ist eine andere Erkenntnis: Der Standort des Rechenzentrums entscheidet die Frage nicht. Maßgeblich ist, welcher Rechtsordnung der Betreiber und seine Muttergesellschaft unterliegen. Genau hier setzt digitale Souveränität in der Softwareentwicklung an, weil sie den Betriebsort als eine Eigenschaft unter mehreren behandelt. Für die Nachweisführung gegenüber Aufsicht und Rechnungsprüfung zählt am Ende, wer administrativen Zugriff hat und welche Unterauftragnehmer beteiligt sind. Das ist eine Frage der IT-Compliance und keine der Technik allein.
Vier Merkmale bestimmen, ob ein Angebot überhaupt in den Anwendungsbereich fällt:
- Sitz des Anbieters oder seiner Muttergesellschaft in den USA
- Geschäftstätigkeit in den USA, auch ohne dortigen Sitz
- Börsennotierung in den USA
- Administrativer Zugriff durch Personal außerhalb der EU
FISA Section 702 als zweiter Zugriffsweg
Der CLOUD Act ist nicht die einzige Grundlage für einen Zugriff. Section 702 des Foreign Intelligence Surveillance Act zielt auf Auslandsaufklärung statt auf Strafverfolgung und arbeitet mit jährlichen Zertifizierungen anstelle eines Beschlusses im Einzelfall. Für europäische Stellen ist dieser Weg der unangenehmere, weil er keinen konkreten Tatverdacht voraussetzt. Ob der Betriebsort später noch wechselbar bleibt, klärt der Abschnitt zur Wirkung von Verschlüsselung, denn dort entscheidet sich, ob ein Zugriff überhaupt lesbare Daten erreicht.
Schrems II und der heutige Rechtsstand
Beide Zugriffswege waren der Grund, aus dem der Europäische Gerichtshof 2020 im Urteil Schrems II das damalige Privacy Shield für unwirksam erklärte. Seit Juli 2023 trägt ein Angemessenheitsbeschluss der EU-Kommission den Datentransfer in die USA wieder, sofern das empfangende Unternehmen dem EU-US Data Privacy Framework beigetreten ist. Am zugrunde liegenden US-Recht hat sich dadurch nichts geändert. Ein Angemessenheitsbeschluss ersetzt die Anbieterprüfung nicht, denn die Kriterien einer souveränen Cloud umfassen auch operative Kontrolle und Transparenz.
Ist der US CLOUD Act DSGVO-konform?
Die beiden Regelwerke stehen in einem Zielkonflikt, den auch Schrems II nicht abschließend geklärt hat. Der CLOUD Act verlangt eine Herausgabe, die Datenschutz-Grundverordnung erlaubt eine Übermittlung in Drittstaaten nur auf einer klaren Rechtsgrundlage. Die Stiftung Datenschutz hat 2025 dokumentiert, dass ein großer Anbieter einen Zugriff auf europäische Daten nicht ausschließen konnte. Ob eine konkrete Verarbeitung zulässig ist, beurteilen die zuständige Datenschutzaufsicht und der Rechtsbeistand, nicht der Anbieter.
Der Unterschied zum EU-Rechtsakt gleichen Namens
Eine Verwechslung tritt regelmäßig auf, weil die EU seit Juni 2026 einen eigenen Cloud-Rechtsakt vorbereitet. Der Cloud and AI Development Act der EU regelt Souveränitätsstufen für die Beschaffung, während das US-Gesetz Zugriffsrechte begründet. Beide betreffen dieselben Systeme aus unterschiedlicher Richtung. Was das EU-Souveränitätspaket für Vergabestellen bedeutet, ist deshalb eine eigene Frage und keine Antwort auf den CLOUD Act.
Welche Daten dürfen bei US-Anbietern liegen?
Ein Fachverfahren ist selten durchgängig kritisch. Ein Bürgerportal verarbeitet andere Daten als ein Melderegister, und beide liegen häufig auf derselben Plattform. Statt einer Entscheidung für das ganze Verfahren führt eine Aufteilung nach Datenarten schneller zu einem tragfähigen Ergebnis, weil sie den Teil benennt, der wirklich Schutz braucht.
Datenklassifizierung statt Anbieterdebatte
Die gute Nachricht für Behörden: Die Vorarbeit existiert meist schon. Wer nach BSI IT-Grundschutz arbeitet, hat für jedes Verfahren eine Schutzbedarfsfeststellung, die Vertraulichkeit, Integrität und Verfügbarkeit einordnet. Eine Datenklassifizierung ergänzt diese Einordnung um eine weitere Spalte, nämlich die Verträglichkeit mit einem Zugriff durch Drittstaaten. Das ist kein neues Verfahren, sondern eine Erweiterung eines vorhandenen. Die Klassifizierung kostet Tage, nicht Monate, und sie liefert die Begründung, die ein Vergabevermerk ohnehin braucht.
Vier Fragen, die die Klasse bestimmen
Die folgenden Fragen lassen sich pro Datenart ohne technische Vorkenntnisse beantworten. Sie ersetzen keine Rechtsprüfung, ordnen aber die Diskussion und machen sichtbar, wo überhaupt Handlungsbedarf besteht.
❓ Sind personenbezogene Daten betroffen, und in welcher Kategorie?
❓ Würde eine Offenlegung Betroffene oder das Verfahren gefährden?
❓ Gibt es eine gesetzliche Bindung an eine Verarbeitung in Deutschland?
❓ Wäre der Datensatz ohne Schlüssel für Dritte verwertbar?
Aus den Antworten ergeben sich in der Praxis vier Gruppen, die verschiedene Betriebsorte vertragen:
- Offene Daten, etwa Geodaten oder Bekanntmachungen: ohne Einschränkung
- Interne Daten ohne Personenbezug, etwa Protokolle: Public Cloud vertretbar
- Personenbezogene Verfahrensdaten: europäische Verarbeitung, Schlüssel getrennt
- Besondere Kategorien und Sicherheitsdaten: eigene Infrastruktur
Was die Datenklassifizierung nicht leistet
Zur Datenklassifizierung gehören zwei Grenzen, und beide betreffen ihre Reichweite. Sie beurteilt keine Rechtmäßigkeit, sondern strukturiert eine Entscheidung, und sie ersetzt keine Prüfung des einzelnen Anbietervertrags. Kommunale Stellen stoßen zusätzlich auf eine Abhängigkeit, die sie selbst nicht auflösen können, weil ihr IT-Dienstleister die Plattform betreibt. In der kommunalen Digitalsouveränität bündelt sich dieses Risiko bei wenigen Rechenzentren.
Architektur, die den CLOUD Act überdauert
Rechtslagen ändern sich schneller als Fachverfahren. Das Privacy Shield hielt fünf Jahre, bis Schrems II es beendete, und sein Nachfolger steht seit 2023 unter Beobachtung. Eine Anwendung, die auf einen bestimmten Rechtsstand gebaut ist, wird mit ihm veralten. Wirtschaftlich sinnvoller ist eine Architektur, die den Betriebsort als austauschbaren Parameter behandelt statt als Fundament.
Schützt Verschlüsselung vor dem CLOUD Act?
Die Antwort hängt daran, wer die Schlüssel hält. Verschlüsselung im Ruhezustand, deren Schlüssel der Anbieter verwaltet, schützt gegen Diebstahl von Datenträgern, nicht gegen eine Herausgabeanordnung an denselben Anbieter. Anders liegt der Fall bei getrennter Schlüsselhoheit, im Markt als Bring Your Own Key oder Hold Your Own Key geführt: Bleibt das Schlüsselmaterial in einem Hardware-Sicherheitsmodul unter eigener Kontrolle, erhält eine anordnende Behörde Chiffrate ohne Klartext. Damit verschiebt sich die Frage vom Speicherort zur Schlüsselverwaltung. Vollständig entkoppeln lässt sich beides allerdings nicht, weil Daten für die Verarbeitung im Arbeitsspeicher entschlüsselt vorliegen.
Wie der Betriebsort wechselbar bleibt
Vier Eigenschaften entscheiden darüber, ob ein Wechsel später ohne Neubau möglich bleibt. Sie kosten während der Entwicklung wenig und sind nachträglich teuer, weshalb sie in die Leistungsbeschreibung gehören statt in die Betriebsphase:
- Dokumentierte Datenformate und ein vollständiger Export ohne Anbieterwerkzeug
- Schnittstellen nach offenen Standards statt nach Produktspezifikation
- Trennung von Anwendung und Plattformdiensten des Anbieters
- Ein getesteter Rückholvorgang, nicht nur eine Vertragsklausel
Zusammen ergibt das dieselbe Zielrichtung, aus der sich auch Vendor Lock-in vermeiden lässt, nur mit rechtlichem statt kaufmännischem Anlass. Der praktische Unterschied liegt im Zeitpunkt, denn eine Herausgabeanordnung kündigt sich nicht an.
TenMedia entwickelt Individualsoftware für Behörden und KRITIS-Betreiber und betreibt sie auf Wunsch, zertifiziert nach ISO/IEC 27001:2022 durch den TÜV SÜD für Entwicklung, Hosting und Maintenance von Cloud-Anwendungen. Der Betriebsort wird dabei je Datenklasse festgelegt, von Azure-Rechenzentren in der EU bis zu einem Betrieb auf eigener Infrastruktur. Das Notfallhandbuch für die Berliner Feuerwehr koordiniert die Gefahrenabwehr über mehrere Stellen hinweg. Quellcode und Datenformate liegen in jedem Fall beim Auftraggeber.
