EU-Datensouveränitätsanforderungen: Was die DSGVO verlangt und was echte Souveränität wirklich bedeutet

Fragen Sie die meisten Compliance-Teams, was die EU-Datensouveränität erfordert, verweisen sie auf die DSGVO. Fragen Sie deren Rechtsabteilung, was Schrems II verlangt, sprechen sie über Transfer Impact Assessments und Standardvertragsklauseln. Fragen Sie den CISO, was passiert, wenn eine US-Regierungsanfrage beim Cloud-Anbieter eingeht, herrscht Stille im Raum.

Die Verwirrung ist nachvollziehbar. „Datenresidenz„, „Datenlokalisierung“ und „Datensouveränität“ werden in den meisten Unternehmensgesprächen synonym verwendet – sind aber rechtlich und architektonisch unterschiedlich. Ein Unternehmen kann jede DSGVO-Anforderung zur Datenresidenz auf dem Papier erfüllen und bleibt dennoch strukturell dem Zugriff ausländischer Behörden ausgesetzt. Zu verstehen, wo die DSGVO-Anforderungen enden und wo echte Datensouveränität beginnt, ist keine akademische Frage. Es ist die Compliance-Lücke, die Aufsichtsbehörden inzwischen aktiv durchsetzen.

Executive Summary

Kernaussage: Die DSGVO legt Anforderungen an Datenresidenz und -übertragung für personenbezogene EU-Daten fest – aber DSGVO-Compliance und Datensouveränität sind nicht gleichbedeutend. Datenresidenz gibt vor, wo Daten gespeichert werden müssen. Datensouveränität bestimmt, wer Zugriff darauf hat und unter welcher Rechtsordnung. Für Unternehmen, die US-basierte Cloud-Infrastrukturen nutzen, sorgt DSGVO-konforme Datenresidenz in einem Frankfurter Rechenzentrum für geografische Compliance, lässt die Daten jedoch rechtlich für US-Behörden unter dem CLOUD Act zugänglich – eine strukturelle Schwachstelle, die Standardvertragsklauseln nicht beheben können. Echte Datensouveränität erfordert architektonische Kontrollen – vom Kunden kontrollierte Verschlüsselungsschlüssel, Single-Tenant-Bereitstellung in Europa, durch Richtlinien erzwungenes Geofencing – die unautorisierten Zugriff technisch unmöglich machen, nicht nur vertraglich untersagen.

Warum das wichtig ist: Österreichische, französische und italienische Datenschutzbehörden haben bereits entschieden, dass bestimmte US-Cloud-Konstrukte gegen die DSGVO verstoßen. DSGVO-Bußgelder können bis zu 4 % des weltweiten Jahresumsatzes betragen. Die NIS-2-Richtlinie bringt strafrechtliche Haftung für das Management. Der Kiteworks 2026 Data Security and Compliance Risk Report ergab, dass 33 % der Unternehmen in den letzten 12 Monaten einen Vorfall mit Souveränitätsbezug hatten, obwohl 44 % sich als gut informiert einschätzten. Unternehmen, die Residenz mit Souveränität verwechseln, sind nicht compliant – sie sind exponiert.

wichtige Erkenntnisse

1. Datenresidenz, -lokalisierung und -souveränität sind rechtlich unterschiedlich. Residenz regelt, wo Daten physisch gespeichert werden. Lokalisierung verlangt, dass sie im Land der Erhebung verbleiben. Souveränität regelt, wer Zugriff hat und unter welcher Rechtsordnung. Die Erfüllung einer Anforderung reicht nicht automatisch für die anderen.
2. Die DSGVO legt Residenzanforderungen fest, aber keine vollständige Souveränität. Die Artikel 44–49 beschränken grenzüberschreitende Übermittlungen – aber Compliance verhindert nicht, dass eine US-CLOUD-Act-Anfrage auf Daten zugreift, die von einem US-Anbieter in einem EU-Rechenzentrum gespeichert werden. Standort ist nicht gleich Rechtsraum.
3. Schrems II hat gezeigt, dass Residenz nicht ausreicht. Durch die Verpflichtung zu Transfer Impact Assessments und die Benennung von kundengesteuerter Verschlüsselung als erforderliche ergänzende Maßnahme hat der EuGH klargestellt, dass der geografische Standort keine juristische Kontrolle ersetzt.
4. Architektonische Souveränität schließt Lücken, die Verträge offenlassen. Standardvertragsklauseln binden Parteien, können aber eine US-Behördenanfrage nicht aushebeln. Vom Kunden kontrollierte Verschlüsselungsschlüssel außerhalb der Infrastruktur des Anbieters machen diesen technisch unfähig, lesbare Daten bereitzustellen – unabhängig von rechtlichen Anforderungen.
5. NIS 2 und DORA erweitern die Souveränitätsanforderungen über die DSGVO hinaus. Die NIS-2-Richtlinie und DORA verlangen Souveränitätsbewertungen in der Lieferkette, Meldepflichten und Managementhaftung, die sich auf die DSGVO aufaddieren. Unternehmen in regulierten Branchen müssen alle drei Vorgaben gleichzeitig erfüllen.

Begriffsdefinitionen: Was Residenz, Lokalisierung und Souveränität wirklich bedeuten

Datenresidenz bezeichnet den physischen, geografischen Ort, an dem Daten gespeichert und verarbeitet werden. Eine Anforderung an die Datenresidenz bedeutet: Diese Daten müssen auf Servern innerhalb dieser Rechtsordnung gespeichert werden. Die DSGVO schafft faktisch Residenzanforderungen durch ihre Übertragungsbeschränkungen – indem sie einschränkt, wohin personenbezogene Daten fließen dürfen, zwingt sie Unternehmen, Daten in der EU zu halten. Aber Residenz ist eine Frage des Standorts, nicht der Kontrolle. Daten können physisch in Deutschland gespeichert sein und gleichzeitig rechtlich für ausländische Behörden zugänglich bleiben.

Datenlokalisierung ist eine strengere Form der Residenz: Die Anforderung, dass Daten nicht nur lokal gespeichert, sondern das Land der Erhebung nicht verlassen dürfen. Einige nationale Vorschriften und branchenspezifische Regeln innerhalb der EU verlangen über die DSGVO hinausgehende Lokalisierung – insbesondere für Gesundheitsdaten, Finanztransaktionen und öffentliche Register.

Datensouveränität ist der umfassendste Begriff. Sie beschreibt das Prinzip, dass Daten den Gesetzen der Rechtsordnung unterliegen, in der sie gespeichert sind – und dass das kontrollierende Unternehmen tatsächlich rechtliche und technische Kontrolle über den Zugriff hat. Souveränität ist nicht erfüllt, nur weil ein EU-Rechenzentrum gewählt wird. Ein US-Anbieter mit einem Frankfurter Rechenzentrum ist keine souveräne europäische Infrastruktur – es ist eine europäische Adresse mit US-Rechtsrisiko.

Die praktische Folge: Ein Unternehmen kann jede DSGVO-Anforderung zur Datenresidenz erfüllen – EU-Rechenzentren, dokumentierte Übertragungsmechanismen, konforme Subunternehmer – und dennoch keine Datensouveränität erreichen, wenn der Anbieter seinen Hauptsitz in den USA hat und die Verschlüsselungsschlüssel hält.

Was die DSGVO tatsächlich für Datenresidenz und -übertragungen verlangt

Die DSGVO enthält keine pauschale Vorgabe, dass personenbezogene EU-Daten innerhalb der EU gespeichert werden müssen. Kapitel V (Artikel 44–49) beschränkt, wann personenbezogene EU-Daten außerhalb der EU/des EWR übertragen werden dürfen – durch Angemessenheitsbeschlüsse, Standardvertragsklauseln, verbindliche Unternehmensregeln oder andere genehmigte Mechanismen. In der Praxis entsteht dadurch ein starker Residenzdruck: Gibt es keinen gültigen Übertragungsmechanismus für ein bestimmtes Ziel, müssen die Daten in der EU verbleiben.

Für die meisten Unternehmen, die US-Cloud-Anbieter nutzen, sind Standardvertragsklauseln (SCCs) der maßgebliche Mechanismus – ergänzt seit Schrems II durch Transfer Impact Assessments, die bewerten, ob US-Recht die Wirksamkeit dieser SCCs beeinträchtigt. Die Anforderung der DSGVO in Artikel 32 nach „geeigneten technischen und organisatorischen Maßnahmen“ wird nach Schrems II von Aufsichtsbehörden so ausgelegt, dass nachweisbare technische Kontrollen erforderlich sind, die dem identifizierten Risiko angemessen sind. Die Empfehlungen 01/2020 des EDSA benennen vom Kunden kontrollierte Verschlüsselung mit Schlüsseln, die ausschließlich im EWR verbleiben, als technische Maßnahme, um CLOUD-Act-Zugriffe zu verhindern. Hier treffen DSGVO-Residenzanforderungen und Souveränitätsarchitektur aufeinander: Echte Artikel-32-Compliance für US-Anbieter-Übertragungen erfordert dieselbe kundengesteuerte Schlüsselarchitektur, die auch für Souveränität notwendig ist.

Die CLOUD-Act-Lücke: Warum Residenz keine Souveränität ist

Der US CLOUD Act verpflichtet US-Unternehmen, Daten, die sie kontrollieren, auf behördliche Anforderung hin bereitzustellen – unabhängig davon, wo diese Daten physisch gespeichert sind. Ein US-Anbieter mit einem Frankfurter Rechenzentrum ist kein europäisches Unternehmen – sondern ein US-Unternehmen mit europäischer Immobilie. Die Anforderung benötigt keinen europäischen Gerichtsbeschluss, informiert weder Verantwortliche noch Betroffene, und der Anbieter muss unabhängig vom Vertrag mit dem europäischen Kunden reagieren. Standardvertragsklauseln dokumentieren, was der Anbieter tun möchte; sie ändern nicht, was US-Recht verlangt.

Der EU-US Data Privacy Framework (2023) stellt einen Übertragungsmechanismus bereit, hebt den CLOUD Act aber nicht auf. Er ändert die Überwachung durch US-Geheimdienste, verhindert aber nicht, dass CLOUD-Act-Anfragen auf vom Anbieter kontrollierte Daten zugreifen. Datenschützer klagen bereits dagegen. Wer Compliance-Infrastruktur dauerhaft auf DPF stützt, akzeptiert fortwährende Rechtsunsicherheit.

Die einzige Kontrolle, die diese Lücke schließt, ist architektonisch: kundengesteuerte Verschlüsselung mit Schlüsseln, die vollständig außerhalb der Infrastruktur des Anbieters liegen. Kann der Anbieter die Schlüssel nicht erreichen, liefert eine CLOUD-Act-Anfrage nur Chiffretext – rechtmäßig beschafft, aber nicht lesbar. Der Anbieter ist technisch nicht in der Lage, entschlüsselte Daten bereitzustellen, egal wie der Rechtsrahmen aussieht. Architektur verhindert, was Verträge nicht verhindern können. Genau das meint der EDSA mit einer „technischen ergänzenden Maßnahme“ gegen CLOUD-Act-Risiken – und genau diesen Standard setzen europäische Aufsichtsbehörden inzwischen durch.

Der erweiterte EU-Souveränitätsrahmen: NIS 2 und DORA

Die DSGVO ist die Grundlage, aber für die meisten Unternehmen mit Geschäft in der EU ist sie nicht das einzige Souveränitäts-Regelwerk. Zwei weitere EU-Vorschriften legen zusätzliche Souveränitätsanforderungen auf – und gehen zum Teil darüber hinaus.

Die NIS-2-Richtlinie, die von den EU-Mitgliedstaaten im Oktober 2024 umgesetzt wird, betrifft kritische Sektoren – Energie, Transport, Banken, Gesundheitswesen, digitale Infrastruktur – und wichtige Sektoren wie Fertigung und professionelle Dienstleistungen. Ihr Souveränitätsaspekt ist das Lieferkettensicherheitsgebot in Artikel 21: Betroffene Unternehmen müssen Cyberrisiken in ihrer IKT-Lieferkette bewerten, einschließlich der Souveränitätslage von Cloud-Anbietern. Ein US-Anbieter, der dem CLOUD Act unterliegt, ist ein Souveränitätsrisiko in der Lieferkette, das NIS 2 dokumentiert und adressiert sehen will. Verstöße gegen NIS 2 können mit bis zu 10 Mio. € oder 2 % des weltweiten Jahresumsatzes geahndet werden – mit direkter persönlicher Haftung für das Management, die die DSGVO nicht vorsieht.

DORA-Compliance-Anforderungen, ab Januar 2025 für Finanzdienstleister in der EU verbindlich, gehen noch weiter: Artikel 30 verlangt ausdrücklich, dass Verträge mit IKT-Anbietern Datensouveränität, Schlüsselmanagement und Exit-Strategien regeln. Für Finanzdienstleister schaffen DSGVO, DORA und nationale Bankgeheimnisgesetze eine dreifache Souveränitätsverpflichtung, die rein DSGVO-zentrierte Compliance-Programme nicht erfüllen können.

Was echte EU-Datensouveränität in der Praxis erfordert

Vom Kunden kontrollierte Verschlüsselungsschlüssel. Der EDSA nennt dies als wichtigste technische ergänzende Maßnahme für US-Anbieter-Übertragungen. Schlüssel im eigenen HSM des Kunden, außerhalb der Anbieter-Infrastruktur, sorgen dafür, dass CLOUD-Act-Anfragen nur Chiffretext liefern. Diese eine architektonische Kontrolle erfüllt gleichzeitig die Anforderungen aus DSGVO Artikel 32, DORA Artikel 30 Schlüsselmanagement und die NIS-2-Lieferkettensouveränitätsbewertung – in allen drei Regelwerken.

Single-Tenant-Bereitstellung in Europa. Dedizierte Infrastruktur in einem bestimmten EU-Rechenzentrum unter Kontrolle des Kunden bietet dokumentierte Datenresidenz, die DSGVO-Kapitel V und die von Aufsichtsbehörden geforderte Evidenz bei Transfer Impact Assessments erfüllt. Rechtsraum folgt der Kontrolle, nicht den Koordinaten.

Richtlinienbasiertes Geofencing. Geofencing-Kontrollen, die technisch verhindern, dass Daten definierte Regionen verlassen – auf Infrastrukturebene durchgesetzt, nicht nur per Richtlinie – gelten laut EDSA als „technische ergänzende Maßnahme“ und nicht als „vertragliche ergänzende Maßnahme“. Nur erstere gelten als ausreichend für CLOUD-Act-exponierte Übertragungen.

Unveränderbare Audit-Trails. DSGVO Artikel 30, NIS-2-Incident-Reporting und DORA-ICT-Risiko-Dokumentation verlangen alle dieselbe Basis: manipulationssichere Aufzeichnungen jeder Datenzugriffs-, Übertragungs- und Verarbeitungstätigkeit mit dokumentiertem geografischem Bezug. Dritte müssen nachweisen können, dass Anbieter diese Nachweise auf Anfrage liefern – nicht nur behaupten, sie zu führen.

Wie Kiteworks architektonische Souveränität für EU-Compliance liefert

Die Grenze zwischen DSGVO-Datenresidenz und echter EU-Datensouveränität ist die Grenze zwischen dem Ort Ihrer Daten und der tatsächlichen Zugriffskontrolle. Ein Unternehmen kann Daten in Frankfurt speichern, Standardvertragsklauseln unterzeichnen und ein konformes Transfer Impact Assessment führen – und ist dennoch nur eine CLOUD-Act-Anfrage davon entfernt, dass Daten europäischer Kunden US-Ermittlern ohne Benachrichtigung übergeben werden. Das ist die strukturelle Realität bei US-kontrollierter Infrastruktur für europäische Daten – und genau das setzen europäische Aufsichtsbehörden jetzt durch.

Echte EU-Datensouveränität erfordert Architektur, die schließt, was Verträge nicht verhindern können: Vom Kunden kontrollierte Verschlüsselungsschlüssel, die Anbieter technisch unfähig machen, lesbare Daten bereitzustellen, Single-Tenant-Bereitstellung in Europa, die Daten unter europäische Gerichtsbarkeit stellt, und durch Richtlinien erzwungenes Geofencing, das Residenz zu einer technischen Realität macht. Kiteworks liefert genau diese Architektur. Ihre Daten, Ihre Gerichtsbarkeit, Ihre Kontrolle.

Kiteworks wurde nach einem einzigen Prinzip entwickelt: Ihre Daten sollen unter Ihrer Kontrolle bleiben – in Ihrer Gerichtsbarkeit, verschlüsselt mit Ihren Schlüsseln, unzugänglich für Unbefugte, einschließlich Kiteworks selbst. Das ist architektonische Souveränität in der Praxis.

Das Private Data Network von Kiteworks bündelt alle Kanäle für sensible Inhaltskommunikation – E-Mails, Filesharing, Managed File Transfer, Web-Formulare und APIs – auf einer einzigen Plattform mit einheitlichen Souveränitätskontrollen. Kundengesteuerte Verschlüsselung (BYOK/BYOE) mit FIPS 140-3 Level 1-validierter Verschlüsselung und AES-256 im ruhenden Zustand stellt sicher, dass Kiteworks Kundendaten nicht entschlüsseln kann – nicht durch ein Versprechen, sondern durch Architektur. Wir halten die Schlüssel nie. Wenn eine Behördenanfrage bei Kiteworks eingeht, liefern wir nur Chiffretext. Das ist die vom EDSA geforderte ergänzende Maßnahme – umgesetzt auf Infrastrukturebene.

Europäische Bereitstellungsoptionen – On-Premises, Private Cloud mit europäischem Anbieter oder von Kiteworks gehostete EU-Infrastruktur – setzen Datenresidenz technisch durch. Richtlinienbasiertes Geofencing hält Inhalte in definierten Regionen. Zero trust-Sicherheitskontrollen regeln den Zugriff, jede Interaktion wird in einem einheitlichen, unveränderbaren Audit-Trail dokumentiert, der über das CISO-Dashboard einsehbar ist. Vorgefertigte Compliance-Berichte für DSGVO, NIS 2, DORA und ISO 27001 liefern Nachweise für Transfer Impact Assessments, Artikel-30-Aufzeichnungen und Schlüsselverwaltungsdokumentation – Souveränität, die Sie gegenüber Behörden belegen können, nicht nur Kunden zusichern.

Erfahren Sie, wie Kiteworks Compliance mit Datensouveränität für Unternehmen in der EU unterstützt – vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

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