App rechtssicher in der EU hosten: die Checkliste

Das Schrems-II-Urteil des Europäischen Gerichtshofs aus dem Juli 2020 hat eine Grundannahme vieler Infrastruktur-Entscheidungen erschüttert: dass es reicht, die Daten irgendwo in Europa zu lagern. Seitdem ist die Rechtslage komplizierter und wer beim Cloud-Anbieter nicht genau hinschaut, kann sich schnell in einer Compliance-Grauzone wiederfinden.

Dieser Artikel erklärt, was das Urteil konkret bedeutet, warum das Thema auch 2025 noch nicht erledigt ist, und gibt eine praktische Checkliste für Entwickler und DevOps-Teams, die rechtssicheres Cloud-Hosting in der EU brauchen.

Was Schrems II bedeutet und warum es noch immer relevant ist

Im Kern hat der EuGH festgestellt, dass das damalige Privacy-Shield-Abkommen zwischen der EU und den USA keinen ausreichenden Datenschutz garantiert. US-Geheimdienste haben weitreichende Zugriffsrechte auf Daten, die bei US-Unternehmen liegen und diese Zugriffsrechte hebeln europäische Datenschutzstandards aus.

Privacy Shield war damit Geschichte. Seitdem ist der Datentransfer in die USA nur noch auf Basis von Standardvertragsklauseln (SCCs) möglich, aber auch nur dann, wenn im Einzelfall geprüft wird, ob das Empfängerland ein gleichwertiges Schutzniveau bietet. Für die USA ist das schwer zu bejahen.

Das Data Privacy Framework und seine Schwächen

Im Juli 2023 trat das EU-US Data Privacy Framework (DPF) in Kraft, gedacht als Nachfolger des Privacy Shield. Es enthält stärkere Einschränkungen für US-Geheimdienstzugriffe und einen Beschwerdemechanismus für EU-Bürger.

Das Problem: Datenschutzaktivisten, allen voran Max Schrems, halten das DPF für strukturell unzureichend. Eine neue Klage ist angekündigt. Wer heute eine Infrastrukturentscheidung auf Basis des DPF trifft, sollte einkalkulieren, dass dieses Abkommen in einigen Jahren erneut gekippt werden könnte, so wie es mit Safe Harbor (2015) und Privacy Shield (2020) passiert ist.

Der CLOUD Act als strukturelles Problem

Selbst wenn ein US-Unternehmen sein Rechenzentrum in Frankfurt betreibt, ändert das nichts an einer zentralen Tatsache: Der CLOUD Act von 2018 erlaubt US-Behörden, von US-Unternehmen Herausgabe von Daten zu verlangen, unabhängig davon, wo diese Daten gespeichert sind.

Das bedeutet: Wer AWS, Azure oder Google Cloud nutzt, hat keine vollständige Kontrolle darüber, wer unter welchen Umständen auf seine Daten zugreifen kann. Für viele Anwendungsfälle ist das kein Problem. Für andere, etwa im Gesundheitswesen, bei Behörden, im Finanzsektor oder überall dort, wo sensible personenbezogene Daten verarbeitet werden, ist es eines.

Warum "EU-Rechenzentrum" allein nicht reicht

Ein häufiger Denkfehler: "Wir nutzen zwar AWS, aber die Region ist eu-central-1, also Frankfurt. Das ist DSGVO-konform."

Das stimmt so nicht. Der Ort des Rechenzentrums ist nur ein Faktor von mehreren – warum Datenresidenz nicht gleich Datensouveränität ist, zeigt unser separater Vergleich. Entscheidend sind:

• Unternehmenssitz des Anbieters: Ist der Anbieter ein US-Unternehmen, gilt der CLOUD Act, egal wo die Server stehen.
• Eigentümerstruktur: Hat der europäische Anbieter eine US-amerikanische Muttergesellschaft, kann über diese ein Hebel angesetzt werden.
• Zugriff durch Subprozessoren: Werden Daten durch Tools, Monitoring-Dienste oder Support-Prozesse an US-Unternehmen übermittelt?

Wann ein Anbieter wirklich europäisch ist

Ein Anbieter ist für Datenschutzzwecke dann als "europäisch" einzustufen, wenn:

1. Er seinen Sitz in der EU hat.
2. Keine US-Muttergesellschaft oder wesentliche US-Tochter existiert, über die ein CLOUD-Act-Zugriff möglich wäre.
3. Alle Subprozessoren ebenfalls diese Kriterien erfüllen oder zumindest unter einem gültigen Transfermechanismus operieren.
4. Der Anbieter einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO abschließt.

Das ist keine theoretische Übung. Im Rahmen einer DSGVO-Prüfung oder eines Audits werden genau diese Punkte abgefragt.

Die Checkliste – rechtssicheres Cloud-Hosting in der EU

Hier ist eine strukturierte Checkliste, die ihr für eure Hosting-Entscheidung nutzen könnt.

Anbieterwahl

• Anbieter hat seinen Hauptsitz in der EU
• Keine US-Muttergesellschaft oder US-Mehrheitsbeteiligung
• Alle genutzten Subprozessoren sind dokumentiert und DSGVO-konform
• Anbieter unterzeichnet einen AVV nach Art. 28 DSGVO
• Zertifizierungen vorhanden (z. B. ISO 27001, BSI C5, SOC 2 – letzteres nur ergänzend)
• Rechenzentren befinden sich physisch in der EU

Vertragswerk

• AVV ist aktuell, vollständig und von beiden Seiten unterschrieben
• Sofern SCCs genutzt werden: Transfer Impact Assessment (TIA) ist dokumentiert
• Subprozessorenliste ist im AVV oder als Anlage verfügbar und wird bei Änderungen aktualisiert
• Vertrag enthält klare Regelungen zur Löschung von Daten nach Vertragsende

Technische Maßnahmen (TOMs)

• Verschlüsselung der Daten in transit (TLS) und at rest (z. B. AES-256)
• Zugriffskontrolle: Nur autorisierte Personen und Dienste haben Zugriff auf produktive Daten
• Logging und Monitoring: Zugriffe auf sensible Daten werden protokolliert
• Backup-Strategie: Backups bleiben innerhalb der EU und unterliegen denselben Zugriffskontrollen
• Incident-Response-Prozess: Datenpannen werden innerhalb von 72 Stunden gemeldet (Art. 33 DSGVO)

Dokumentation

• Das Verzeichnis von Verarbeitungstätigkeiten (VVT) ist aktuell und enthält alle Cloud-Dienste
• Eine Datenschutz-Folgenabschätzung (DSFA) wurde durchgeführt, falls erforderlich (Art. 35 DSGVO)
• Die Checkliste wird regelmäßig überprüft – mindestens jährlich oder bei Anbieterwechsel

Kubernetes und DaaS: Worauf bei der Plattformwahl zu achten ist

Für Teams, die containerbasierte Anwendungen betreiben, ist die Wahl des Kubernetes-Betreibers besonders relevant. Managed-Kubernetes-Dienste von US-Hyperscalern, EKS, AKS, GKE, bringen zwar viel Komfort, aber auch die beschriebenen rechtlichen Risiken mit.

Europäische Kubernetes-DevOps-as-a-Service-Anbieter schließen diese Lücke: Sie bieten ähnliche Abstraktionsebenen und Betriebskomfort, betreiben die Infrastruktur aber ausschließlich in der EU und unterliegen vollständig europäischem Recht. Wann Kubernetes wirklich souverän betrieben wird, hängt vom Betriebsmodell ab.

Bei der Auswahl eines solchen Anbieters lohnt es sich, folgende Punkte zu prüfen:

• Welche Kubernetes-Version wird betrieben, und wie schnell werden Updates eingespielt?
• Wie ist das Zugriffsmodell für Support-Mitarbeiter geregelt?
• Gibt es ein Self-Service-Portal für Konfiguration, Monitoring und AVV-Management?
• Werden Netzwerk-Policies, RBAC und Pod-Security-Standards unterstützt?

Was passiert, wenn ihr es nicht macht

Compliance-Themen werden in Engineering-Teams oft als Bürokratie wahrgenommen, die man irgendwann "auch noch" erledigt. Das ist verständlich, aber riskant.

Wer über die reine DSGVO-Hosting-Frage hinausgehen will, findet in unserer Souveränitäts-Checkliste für KMU einen breiteren Due-Diligence-Rahmen. Die DSGVO sieht Bußgelder bis zu 20 Millionen Euro oder 4 % des weltweiten Jahresumsatzes vor. Bei schweren Verstößen, etwa wenn personenbezogene Daten ohne Rechtsgrundlage in die USA übertragen wurden, sind das keine theoretischen Zahlen. Aufsichtsbehörden wie das BayLDA oder die Berliner Datenschutzbeauftragte haben in den letzten Jahren wiederholt empfindliche Bußgelder verhängt.

Dazu kommen operative Risiken: ein Hosting-Anbieter, der datenschutzrechtlich problematisch ist, kann zu einem Wechselzwang führen, mit allem, was das für laufende Systeme bedeutet. Wer das von vornherein richtig aufstellt, spart sich diese Probleme.

Fazit: Datenschutz ist eine Infrastruktur-Entscheidung

Schrems II ist kein abstraktes Juristenthema. Es betrifft direkt die Frage, wo und bei wem ihr eure Anwendungen betreibt. Die gute Nachricht: Die technischen und vertraglichen Voraussetzungen für rechtssicheres Cloud-Hosting sind gut bekannt und umsetzbar, es braucht eine bewusste Entscheidung und etwas Dokumentationsaufwand.

Die schlechte Nachricht für alle, die das weiter verschieben: Die Aufsichtsbehörden werden aktiver, nicht passiver.