Welche Risiken bestehen beim Transfer sensibler Daten über internationale Grenzen hinweg?
Jeder grenzüberschreitende Datentransfer ist ein Vorgang mit rechtlicher Relevanz.
Sobald vertrauliche Daten eine internationale Grenze überschreiten, unterliegen sie einem neuen Rechtsrahmen – dieser kann ausländischen Behörden Zugriffsrechte gewähren, andere Meldefristen bei Datenschutzverstößen vorschreiben und Übertragungsbeschränkungen auferlegen, die mit den Ursprungsrechtsvorschriften kollidieren. Die meisten Unternehmen sind sich dieser Problematik grundsätzlich bewusst. Nur wenige haben jedoch die spezifischen Risikokategorien identifiziert, die daraus entstehen – und noch weniger haben diese Risiken architektonisch statt nur vertraglich geschlossen.
In diesem Beitrag beleuchten wir sieben zentrale regulatorische, geschäftliche und finanzielle Risiken, denen Unternehmen beim grenzüberschreitenden Transfer vertraulicher Daten begegnen, und zeigen, wie sie diese Risiken wirksam minimieren können.
Executive Summary
Kernaussage: Grenzüberschreitende Datentransfers schaffen sieben unterschiedliche Risikokategorien – Compliance-Verstöße, Zugriff durch ausländische Behörden, Abfangen von Daten während der Übertragung, unklare Zuständigkeiten, Versagen des Übertragungsmechanismus, Risiken in der Lieferkette und DLP-Grenzdefizite – die jeweils unterschiedliche technische Kontrollen erfordern. Vertragliche Maßnahmen (SCCs, DPAs, TIAs) dokumentieren zwar die Absicht, können aber architektonische Schwachstellen nicht beheben. Echte Data Sovereignty Compliance erfordert Kontrollen, die unbefugten Zugriff technisch unmöglich machen – nicht nur vertraglich untersagen.
Warum das relevant ist: Fehler bei grenzüberschreitenden Transfers gehören seit Schrems II zu den am häufigsten geahndeten DSGVO-Verstößen. Die NIS-2-Richtlinie, DORA und nationale Souveränitätsgesetze schaffen zusätzliche, sich überschneidende Pflichten mit Bußgeldern bis zu 4 % des weltweiten Umsatzes und – unter NIS 2 – persönlicher Haftung des Managements.
wichtige Erkenntnisse
- Grenzüberschreitende Transfers schaffen sieben unterschiedliche Risikokategorien, die jeweils eigene Kontrollen erfordern. Wer sie als reine Compliance-Checkliste behandelt, hat am Ende vollständige Dokumentation – aber reale Risiken.
- Regulatorische Risiken werden nicht durch eine EU-Rechenzentrumsadresse eliminiert. Die Server eines US-Anbieters in Frankfurt unterliegen weiterhin dem US CLOUD Act über die Muttergesellschaft. Geografie ist nicht gleichbedeutend mit Rechtszuständigkeit.
- Das Risiko des Zugriffs durch ausländische Behörden ist strukturell, nicht zufällig. Nur eine vom Kunden kontrollierte Verschlüsselung mit Schlüsseln außerhalb der Infrastruktur des Anbieters schließt dieses Risiko – so wird Entschlüsselung technisch unmöglich, unabhängig von rechtlichen Anforderungen.
- Das Risiko des Versagens des Übertragungsmechanismus ist seit Schrems II deutlich gestiegen. SCCs ohne dokumentierte technische Zusatzmaßnahmen genügen laut aktueller EDPB-Leitlinie meist nicht mehr. Vor 2020 erstellte TIAs stellen ein aktives Durchsetzungsrisiko dar.
- DLP-Grenzdefizite sind ein unterschätztes operatives Risiko. Kontrollen, die innerhalb einer Jurisdiktion funktionieren, versagen oft an geografischen Grenzen, wenn unterschiedliche Systeme verschiedene Standards über Kanäle hinweg durchsetzen.
Sieben Risiken grenzüberschreitender Datentransfers
1. Verstöße gegen regulatorische Compliance
Wer personenbezogene Daten ohne geeigneten rechtlichen Übertragungsmechanismus über Grenzen hinweg verschiebt, verstößt gegen Kapitel V der DSGVO – mit Bußgeldern bis zu 4 % des weltweiten Umsatzes oder 20 Mio. €, je nachdem, welcher Betrag höher ist. Seit Schrems II erfordern geeignete Mechanismen Transfer Impact Assessments, die CLOUD Act- und FISA 702-Risiken ehrlich adressieren, sowie technische Zusatzmaßnahmen, wenn ein aktives Risiko besteht. Ausschließlich vertragliche Maßnahmen reichen nicht aus. Branchenspezifische Vorgaben verschärfen die Anforderungen: DORA-Compliance für Finanzunternehmen, nationale Gesundheitsdatengesetze und EBA-Outsourcing-Richtlinien legen zusätzliche Transferbeschränkungen auf die DSGVO obendrauf.
2. Zugriff durch ausländische Behörden
Der US CLOUD Act verpflichtet US-Unternehmen zur Herausgabe von Daten, die sie kontrollieren – unabhängig vom Speicherort. Ein EU-Rechenzentrum eines US-Cloud-Anbieters entzieht sich nicht der US-Rechtsordnung – die Anordnung erfolgt über die Konzernstruktur, nicht über den Datenstandort. FISA Section 702 schafft vergleichbare Risiken für Kommunikationsdaten. Chinas Data Security Law und National Intelligence Law erzeugen analoge Risiken für Daten, die dort gespeichert oder durchgeleitet werden. Keine vertragliche Zusicherung kann diese gesetzlichen Verpflichtungen aushebeln. Die einzige wirksame Kontrolle ist eine vom Kunden gesteuerte Verschlüsselung mit Schlüsseln außerhalb der Infrastruktur des Anbieters: Eine CLOUD Act-Anfrage liefert nur verschlüsselte Daten, die der Anbieter nicht entschlüsseln kann – unabhängig vom rechtlichen Zwang.
Eine vollständige Checkliste für die DSGVO-Compliance
Read Now
3. Abfangen von Daten während der Übertragung
Internationale Datenströme verlaufen über Seekabel, Internet-Knotenpunkte und Routing-Infrastrukturen, die Parteien in verschiedenen Rechtsräumen gehören – keine Organisation kontrolliert die gesamte Infrastruktur. TLS während der Übertragung ist nur ein Mindeststandard, aber keine vollständige Lösung: Metadaten werden nicht geschützt, Angriffe auf die Zertifikatsinfrastruktur durch Staaten bleiben möglich, und Datenzugriffe an Endpunkten in Transitländern werden nicht verhindert. MFT-Protokolle mit Ende-zu-Ende-Verschlüsselung, Integritätsprüfung und automatischer Richtlinienkontrolle für zulässige Ziele bieten deutlich stärkeren Schutz als TLS-gesichertes Filesharing. Abgefangene Daten unterliegen möglicherweise den Gesetzen des abfangenden Landes – nicht nur denen von Quelle und Ziel.
4. Unklare Zuständigkeiten
Grenzüberschreitende Transfers führen oft dazu, dass dieselben Daten gleichzeitig unterschiedlichen, teils widersprüchlichen Rechtsansprüchen unterliegen. Die DSGVO verlangt eine Meldung von Datenschutzverstößen binnen 72 Stunden, NIS 2 fordert eine Frühwarnung binnen 24 Stunden, DORA schreibt eigene ICT-Incident-Protokolle vor. Bei Vorfällen mit grenzüberschreitenden Transfers müssen Unternehmen unter Zeitdruck klären, welche Behörde, welche Frist und welche Verpflichtung Vorrang hat. Ohne vordefinierte Verantwortlichkeitsstrukturen werden Meldefristen regelmäßig verpasst. Architektonische Kontrollen, die Daten technisch für Anbieter unzugänglich machen, lösen diese Konflikte im Vorfeld: Wenn eine CLOUD Act-Anordnung und eine DSGVO-Pflicht kollidieren, hat ein Unternehmen, dessen Anbieter die Daten nicht entschlüsseln kann, keinen Konflikt zu lösen.
5. Versagen des Übertragungsmechanismus
Übertragungsmechanismen sind rechtliche Konstrukte, die versagen können. Privacy Shield wurde 2020 für ungültig erklärt; das EU-US Data Privacy Framework ist rechtlich angefochten; SCCs auf Basis von Vor-Schrems-II-Annahmen genügen den EDPB-Leitlinien oft nicht mehr. Das DSGVO-Prinzip der Rechenschaftspflicht verlangt laufende Überprüfung – TIAs müssen bei neuen regulatorischen Vorgaben, Durchsetzungsentscheidungen oder geänderten Anbieterbeziehungen aktualisiert werden. Statische Transferdokumentation ist kein Compliance-Programm, sondern ein Compliance-Risiko. Die architektonische Absicherung ist dieselbe wie beim Zugriff durch ausländische Behörden: Vom Kunden kontrollierte Verschlüsselung stellt sicher, dass die Daten auch bei ungültigem Übertragungsmechanismus für den Anbieter praktisch nie zugänglich waren.
6. Risiken durch Drittparteien und Lieferkette
Grenzüberschreitende Transfers betreffen selten nur zwei Parteien. Cloud-Anbieter setzen Subunternehmer ein; SaaS-Plattformen leiten Daten über Analyse- und Infrastrukturpartner. Jeder Zwischenschritt birgt potenzielle Transfer-Risiken – und nach DSGVO bleibt der Datenverantwortliche für sämtliche Verarbeitungen durch Auftragsverarbeiter und Subunternehmer haftbar, unabhängig von der Tiefe der Vertragskette. Die NIS-2-Richtlinie und DORA verlangen eine Ausweitung der Souveränitätsprüfungen auf die gesamte Lieferkette. Wirksames Drittparteien-Risikomanagement erfordert die Abbildung tatsächlicher Datenflüsse – nicht nur der beabsichtigten. Die meisten Unternehmen stellen bei ernsthafter Prüfung fest, dass ihre Daten durch weit mehr Länder laufen als in der Transferdokumentation abgebildet.
7. DLP-Kontrolllücken an geografischen Grenzen
DLP-Kontrollen, die innerhalb einer Jurisdiktion funktionieren, versagen oft an deren Grenzen. Datenklassifizierungsrichtlinien, die über überwachte Kanäle durchgesetzt werden, erfassen keine Transfers über Cloud-Sync-Apps, persönliche E-Mails auf Arbeitsgeräten oder Filesharing-Plattformen außerhalb des DLP-Perimeters. Unternehmen, die mehrere Cloud-Anbieter mit uneinheitlicher Richtliniendurchsetzung nutzen, stehen vor einem besonderen Problem: Daten, die eine Plattform aufgrund ihrer DLP-Kontrollen nicht verlassen dürfen, können von einer anderen im selben Stack frei exportiert werden. Vereinheitlichte Plattformarchitekturen, die eine konsistente DLP-Policy über alle sensiblen Kanäle hinweg – E-Mail, Filesharing, Managed File Transfer, Web-Formulare – durchsetzen, beseitigen die Lücken, die fragmentierte Toolsets verursachen.
Risikominderung: Kiteworks und architektonische Souveränität
Allen sieben Risikokategorien ist die Lücke zwischen vertraglicher und architektonischer Souveränität gemeinsam. Verträge dokumentieren Absichten. Architektur setzt sie um. Grenzüberschreitende Risiken auf architektonischer Ebene zu adressieren bedeutet, Kontrollen zu implementieren, die unbefugten Zugriff strukturell unmöglich machen – statt die Folgen im Nachhinein zu managen.
Das Private Data Network von Kiteworks adressiert jede Kategorie durch Architektur. Vom Kunden verwaltete Verschlüsselung (BYOK/BYOE) mit FIPS 140-3 Level 1-validierter Verschlüsselung schließt Risiken durch ausländische Behörden und Versagen des Übertragungsmechanismus gleichzeitig – Kiteworks besitzt nie Kundenschlüssel, sodass eine CLOUD Act-Anfrage nur verschlüsselte Daten liefert.
Single-Tenant-Bereitstellung am vom Kunden gewählten Standort – On-Premises, europäische Private Cloud oder von Kiteworks gehostete EU-Infrastruktur – bringt Daten unter die richtige Jurisdiktion und schließt Compliance-Lücken auf Infrastrukturebene. Richtlinienbasierte Geofencing-Kontrollen setzen Datenresidenz technisch statt vertraglich um und schließen so die Lücke zwischen dokumentierten Transfer-Policies und tatsächlichen Datenflüssen.
Ende-zu-Ende-Verschlüsselung über alle Kanäle adressiert das Risiko des Abfangens während der Übertragung. Das einheitliche CISO-Dashboard liefert unveränderliche Audit-Trails für jedes Transferereignis – und löst so das Risiko unklarer Zuständigkeiten, indem jede Bewegung dokumentiert, zuordenbar und in jedes regulatorische Format exportierbar ist. Konsistente DLP-Policy-Durchsetzung über E-Mail, Filesharing, Managed File Transfer, Web-Formulare und APIs eliminiert geografische Lücken, die fragmentierte Plattformen nicht schließen können.
Erfahren Sie, wie Kiteworks das Risikoprofil Ihres Unternehmens bei grenzüberschreitenden Transfers absichert: Fordern Sie jetzt Ihre individuelle Demo an.
Häufig gestellte Fragen
Innerstaatliche Transfers finden innerhalb eines einzigen Rechtsraums statt – ein Datenschutzgesetz, eine Aufsichtsbehörde, ein Zugriffsregime. Grenzüberschreitende Transfers schaffen doppelte rechtliche Risiken: Daten, die in der EU durch EU-Recht geschützt sind, unterliegen nach der Übertragung den Gesetzen des Ziellandes – bleiben aber für Rechenschaftszwecke weiterhin dem EU-Recht unterstellt. Diese gleichzeitigen, oft widersprüchlichen Rechtsansprüche – etwa beim Zugriffsrecht, bei Meldepflichten und bei der Durchsetzung – machen grenzüberschreitende Transfers deutlich komplexer als innerstaatliche.
SCCs sind ein notwendiger Bestandteil eines rechtskonformen EU-Transferrahmens, decken aber nicht das gesamte Risikospektrum ab. Seit Schrems II erfordern Standardvertragsklauseln für US-Transfers Transfer Impact Assessments, die CLOUD Act- und FISA 702-Risiken ehrlich bewerten – und wo ein aktives Risiko besteht, sind technische Zusatzmaßnahmen erforderlich, nicht nur vertragliche. SCCs adressieren zudem weder das Abfangen während der Übertragung, noch Risiken durch Subunternehmer in der Lieferkette, DLP-Grenzdefizite oder das Risiko der Ungültigkeit des Mechanismus. Ein vollständiges Risikomanagement nutzt SCCs als einen Baustein innerhalb eines umfassenden architektonischen Rahmens.
Der US CLOUD Act verpflichtet US-Unternehmen zur Herausgabe von Daten, die sie kontrollieren – unabhängig vom Speicherort. Wer EU-Daten über einen US-Anbieter leitet – selbst in ein EU-Rechenzentrum – schafft Zugriffsrisiken für US-Behörden über die Konzernstruktur. Die Schrems-II-Folgen der DSGVO verlangen, dass dieses Risiko durch technische Zusatzmaßnahmen adressiert wird: Vom Kunden kontrollierte Verschlüsselung mit Schlüsseln außerhalb der Anbieter-Infrastruktur, sodass der Anbieter technisch nicht in der Lage ist, lesbare Daten auf rechtliche Anordnung bereitzustellen.
Ein TIA ist eine dokumentierte Bewertung, ob der Rechtsrahmen des Ziellandes den verwendeten Übertragungsmechanismus – meist Standardvertragsklauseln – untergräbt. Erforderlich bei der Übertragung personenbezogener EU-Daten in Länder ohne EU-Angemessenheitsbeschluss, darunter die USA. Ein TIA nach Schrems II muss insbesondere CLOUD Act und FISA 702 als aktive Offenlegungsrisiken adressieren und dokumentieren, welche technischen Zusatzmaßnahmen sie abdecken. Vertragliche Maßnahmen allein reichen nicht aus. Vor Schrems II erstellte TIAs sind nach aktueller EDPB-Leitlinie meist unzureichend und sollten anhand nationaler DPA-Vorgaben überprüft werden.
Vier Kontrollen adressieren die meisten Risiken gleichzeitig: Vom Kunden kontrollierte Verschlüsselung mit Schlüsseln außerhalb der Anbieter-Infrastruktur (schließt Risiken durch ausländische Behörden und Versagen des Übertragungsmechanismus); Single-Tenant-Bereitstellung im vom Kunden gewählten Rechtsraum (schließt Compliance-Risiken); Richtlinienbasiertes Geofencing auf Infrastrukturebene (schließt DLP-Grenz- und Residenz-Compliance-Lücken); und einheitliche Audit-Trails über alle Transferkanäle (schließt das Risiko unklarer Zuständigkeiten). Kiteworks setzt alle vier um – über E-Mail, Filesharing, Managed File Transfer, Web-Formulare und APIs – durch das Private Data Network von Kiteworks.
Weitere Ressourcen
- Blog Post
Data Sovereignty: a Best Practice or Regulatory Requirement? - eBook
Data Sovereignty und DSGVO - Blog Post
Vermeiden Sie diese Data Sovereignty-Fallen - Blog Post
Data Sovereignty Best Practices - Blog Post
Data Sovereignty und DSGVO [Verstehen Sie Datensicherheit]