Praktischer Leitfaden zur Datensouveränität beim Filesharing mit Drittparteien: Anbieter, Subunternehmer und multinationale Umgebungen

Datenhoheit ist beherrschbar, solange Daten innerhalb einer einzigen Organisation und Gerichtsbarkeit verbleiben. Sie wird jedoch zur Governance-Herausforderung, sobald Daten geteilt werden – mit einem Anbieter, einem Subunternehmer, einer regionalen Tochtergesellschaft oder einem Partner, der unter einem anderen Rechtsrahmen agiert.

Die meisten Organisationen verwalten ihre primäre Compliance-Ebene recht gut, verlieren aber an den Rändern die Hoheit: in der Lieferkette, bei internen, grenzüberschreitenden Transfers innerhalb multinationaler Strukturen sowie in E-Mail- und Filesharing-Kanälen, über die der Großteil sensibler Inhalte außerhalb formaler Kontrollrahmen für Datenhoheit transportiert wird.

Dieser Leitfaden behandelt die regulatorischen Verpflichtungen, die Daten in Drittparteien-Beziehungen begleiten, die Risiken zentralisierter multinationaler Datenmodelle, die oft übersehene Hoheitsfläche unstrukturierter Daten in Bewegung, die Mindestanforderungen an Anbieter-Verträge und die Verschlüsselungsarchitektur, die technische Durchsetzbarkeit von Datenhoheit gegenüber Drittparteien ermöglicht.

Executive Summary

Kernaussage: Der Datenverantwortliche bleibt haftbar für den Umgang mit Daten durch Auftragsverarbeiter und Unterauftragsverarbeiter – unabhängig von der Tiefe der Vertragskette. Die meisten Hoheitsverletzungen entstehen nicht beim primären Cloud-Anbieter, sondern in der Lieferkette, bei internen multinationalen Transfers und in unstrukturierten Datenkanälen – E-Mail, Filesharing und Managed File Transfer –, die erhebliche sensible Inhalte außerhalb formaler Kontrollmechanismen transportieren. Die technische Grundlage bilden vom Kunden gehaltene Verschlüsselungsschlüssel: Wenn der Dateninhaber die Schlüssel besitzt, die der Anbieter niemals erhält, kann der Anbieter auf die Inhalte nicht zugreifen oder sie offenlegen – unabhängig von rechtlichen Anforderungen. So wird die Lücke geschlossen, die Verträge allein nicht schließen können.

Warum das relevant ist: Die Auftragsverarbeiterpflichten gemäß DSGVO Artikel 28, DORAs Anforderungen an das IKT-Drittparteienrisiko (ab Januar 2025) und das NIS 2-Lieferkettensicherheitsgebot schaffen überlappende Haftungsverpflichtungen mit Bußgeldern bis zu 4 % des weltweiten Umsatzes sowie persönlicher Managementhaftung. Diese Pflichten gelten für unstrukturierte Daten in E-Mails und Filesharing ebenso wie für strukturierte Daten in Datenbanken – ein Unterschied, den die meisten Organisationen bislang nicht operationalisiert haben.

wichtige Erkenntnisse

1. Der Datenverantwortliche haftet für die gesamte Verarbeitungskette. DSGVO Artikel 28 macht den Verantwortlichen für die Compliance von Auftragsverarbeitern und Unterauftragsverarbeitern verantwortlich – unabhängig von der Anzahl der dazwischenliegenden Vertragsstufen. Ein Verstoß oder eine Hoheitsverletzung durch einen Subunternehmer in vierter Ebene ist das regulatorische Risiko des Verantwortlichen.
2. Interne Transfers innerhalb multinationaler Unternehmen sind nach DSGVO internationale Transfers. Ein zentraler Datenspeicher in den USA, auf den europäische Tochtergesellschaften zugreifen, ist ein Drittlandtransfer und unterliegt den Anforderungen von Kapitel V. Die Konzernzugehörigkeit schafft keine Ausnahme von der Gerichtsbarkeit.
3. E-Mail und Filesharing unterliegen denselben Hoheitsanforderungen wie strukturierte Daten. DSGVO, NIS 2 und DORA unterscheiden nicht nach Datenformat. Die Durchsetzungslücke ist organisatorisch – die meisten Programme zur Datenhoheit konzentrieren sich auf Datenbanken und ignorieren die Kanäle, über die sensible Daten tatsächlich transportiert werden.
4. Vom Kunden gehaltene Verschlüsselungsschlüssel sind die technische Kontrolle, die Anbieterhoheit durchsetzbar macht. Wenn der Dateninhaber die Schlüssel besitzt, die der Anbieter niemals erhält, kann der Anbieter auf die Inhalte nicht zugreifen oder sie offenlegen – unabhängig von rechtlichen Anforderungen. So entfällt die Notwendigkeit, auf interne Zugriffskontrollen oder Hoheitszusagen des Anbieters zu vertrauen.
5. BYOK- und kundenverwaltete Schlüsselmodelle großer Cloud-Anbieter sind nicht gleichbedeutend mit kundeneigenen Schlüsseln. Bei BYOK/BYOE-Konzepten verarbeitet die Infrastruktur des Anbieters die Entschlüsselung und behält technischen Zugriff. Eine gültige behördliche Anordnung liefert lesbare Daten. Kundeneigene Schlüssel, bei denen der Anbieter nie die Entschlüsselungsmöglichkeit besitzt, sind architektonisch grundlegend anders – und die einzige Lösung, die das Risiko durch den CLOUD Act und staatlichen Zugriff tatsächlich eliminiert.

Warum Datenaustausch mit Drittparteien das größte Hoheitsrisiko darstellt

Verlässt ein Datensatz die direkte Kontrolle der Organisation, steigt das Hoheitsrisiko exponentiell. Der Datenverantwortliche trägt gemäß DSGVO Artikel 28 weiterhin die volle regulatorische Haftung für die Verarbeitung über die gesamte Lieferkette – hat aber keine Kontrolle mehr über Infrastruktur, Zugriffsrichtlinien oder Rechtsraum der verarbeitenden Stelle. Die Lücke zwischen Haftung und Kontrolle ist der Entstehungsort der meisten Hoheitsverletzungen.

Das CLOUD-Act-Problem ist besonders in Lieferketten kritisch. Eine EU-Organisation mit sorgfältig aufgebauter souveräner Infrastruktur kann sensible Daten an einen US-basierten Anbieter weitergeben, dessen Infrastruktur vollständig dem CLOUD Act unterliegt. Die Hoheitsarchitektur endet an der Grenze der Organisation; die US-Konzernstruktur des Anbieters schafft genau das Zugriffsrisiko, das die EU-Organisation glaubte, ausgeschlossen zu haben. Effektives Drittparteien-Risikomanagement für Datenhoheit erfordert entweder revisionssichere technische Nachweise gleichwertiger Kontrollen beim Anbieter – oder eine Architektur, bei der der Anbieter niemals lesbare Daten erhält.

Das regulatorische Rahmenwerk: Verpflichtungen, die mit den Daten reisen

DSGVO Artikel 28 verlangt, dass die Verarbeitung durch einen Auftragsverarbeiter nur auf Basis eines verbindlichen Vertrags mit DSGVO-äquivalenten Pflichten erfolgt – auch für Unterauftragsverarbeiter. Verantwortliche müssen die Nutzung von Unterauftragsverarbeitern genehmigen, Pflichten durch die Kette weitergeben und bleiben voll haftbar, wenn Unterauftragsverarbeiter diese nicht erfüllen. Ein Anbieter, der keine prüfbereiten Nachweise für seine Hoheitskontrollen liefern kann, erfüllt die Anforderungen von Artikel 28 nicht – unabhängig von den Vertragsformulierungen.

DORA Artikel 30 verpflichtet EU-Finanzunternehmen, spezifische IKT-Vertragsklauseln zu Datenlokalisierung, Datenresidenz, Schlüsselmanagement, Vorfallzugriff und Exit-Strategien aufzunehmen. DORA verlangt explizit die Bewertung, ob IKT-Anbieter Schutz vor staatlichem Zugriff aus Drittländern nachweisen können – ein direkter Verweis auf das CLOUD-Act-Risiko. Anbieter, die kein konformes Schlüsselmanagement nachweisen können, verursachen aktive DORA-Nichteinhaltung für das Finanzunternehmen.

NIS 2 Artikel 21 verpflichtet Betreiber wesentlicher Dienste, Lieferkettensicherheitsmaßnahmen zu implementieren, die die Hoheitslage direkter Lieferanten und Dienstleister adressieren – und diese Bewertung zu dokumentieren. Die Verpflichtung durchzieht die gesamte Kette: Ein Anbieter, dessen Subunternehmer Hoheitsrisiken einführt, schafft NIS 2-Exponierung für den Betreiber an der Spitze.

Zentralisierte Speicherung in multinationalen Unternehmen: Das verborgene Hoheitsproblem

Multinationale Unternehmen zentralisieren häufig ihre Datenspeicherung – ein zentrales Data Warehouse, einheitliches CRM, zentrale HR-Plattform –, auf die Tochtergesellschaften in verschiedenen Ländern zugreifen. Jeder Zugriff auf EU-Personendaten aus einem zentralen, nicht in der EU befindlichen Speicher ist ein internationaler Transfer und unterliegt den Anforderungen von DSGVO Kapitel V. Die Konzernzugehörigkeit schafft keine Ausnahme: Greift eine EU-Tochter auf Daten im zentralen Speicher des US-Mutterkonzerns zu, ist dies ein Transfer, der eine Angemessenheitsentscheidung, SCCs mit TIAs oder einen anderen gültigen Mechanismus erfordert. Das CLOUD-Act-Risiko gilt für den US-Anbieter des zentralen Speichers – unabhängig davon, von welcher Tochtergesellschaft die Daten stammen.

Zentralisierte Modelle bündeln zudem Risiken: Eine einzige CLOUD-Act-Anordnung oder behördliche Durchsetzung betrifft gleichzeitig die Daten aller Tochtergesellschaften. Für multinationale Unternehmen, die in mehreren Mitgliedstaaten NIS 2 oder DORA unterliegen, löst ein einzelner zentralisierter Hoheitsverstoß regulatorische Risiken in mehreren Jurisdiktionen gleichzeitig aus. Die souveräne Lösung ist nicht zwangsläufig die Aufgabe der Zentralisierung – sondern die Anwendung von kundeneigener Verschlüsselung auf der Datenebene, sodass der zentrale Speicher nur Chiffretext enthält und die Entschlüsselungsschlüssel bei den datenhaltenden Einheiten in ihren jeweiligen Rechtsräumen verbleiben.

E-Mail und Filesharing: Die übersehene Hoheitsfläche

Datenhoheitsprogramme konzentrieren sich fast ausschließlich auf Datenbanken und strukturierte Daten – und übersehen die Kanäle, über die der Großteil sensibler Daten tatsächlich transportiert wird: E-Mail-Anhänge, Filesharing-Plattformen und Managed File Transfer-Workflows. Ein Vertrag, der per E-Mail an einen Anbieter gesendet wird, ein Finanzbericht, der über eine Kollaborationsplattform geteilt wird, eine Due-Diligence-Datei, die ins Ausland übertragen wird – all das sind grenzüberschreitende Datentransfers, die denselben Anforderungen aus DSGVO, NIS 2 und DORA unterliegen wie eine Datenbankreplikation.

Die DSGVO gilt für jede Verarbeitung personenbezogener Daten – unabhängig vom Format, also auch für E-Mail-Übertragungen. Die Durchsetzungslücke ist organisatorisch: Werden Hoheitskontrollen auf Datenbanken angewendet, aber nicht auf die E-Mail- und Filesharing-Kanäle, die diese mit der Außenwelt verbinden, entstehen erhebliche Perimeterrisiken. Die praktischen Hoheitsanforderungen für unstrukturierte Daten in Bewegung sind identisch mit denen für strukturierte Daten: Verschlüsselung während der Übertragung und im ruhenden Zustand, Zugriffskontrollen bei grenzüberschreitender Übermittlung, Audit-Trails für jedes Transferereignis und Richtliniendurchsetzung zur Verhinderung von Übertragungen an nicht-konforme Ziele – angewendet auf Plattformebene, da die Daten beim Teilen mit Drittparteien die Infrastruktur der Organisation vollständig verlassen.

Was Anbieter-Verträge enthalten müssen – und was sie nicht ersetzen können

Verträge mit Anbietern für hoheitskritische Daten müssen Folgendes enthalten: Zweckbindung und Weisungsbeschränkungen für die Verarbeitung; Verschlüsselungsstandards und Schlüsselmanagementarchitektur (mit Angabe, ob der Anbieter Entschlüsselungsfähigkeit besitzt); Autorisierung von Unterauftragsverarbeitern und Durchleitung der Pflichten; Meldefristen bei Datenschutzverletzungen; Prüfungsrechte mit konkretem Umfang; Rückgabe oder Löschung der Daten bei Vertragsende; und – für DORA-regulierte Unternehmen – Vorgaben zu Datenlokalisierung, Schlüsselmanagement und Exit-Strategien gemäß Artikel 30.

Ebenso wichtig ist, was Verträge nicht leisten können. Eine Vertragsklausel, die einen US-Anbieter verpflichtet, EU-Daten vor staatlichem Zugriff zu schützen, ändert nichts an der gesetzlichen Pflicht des Anbieters, einer gültigen CLOUD-Act-Anordnung nachzukommen. Eine Datenresidenzklausel begründet eine Haftung bei Verstoß – verhindert aber technisch nicht das Verlassen der Gerichtsbarkeit. Verträge dokumentieren Verpflichtungen, schaffen aber keine technischen Kontrollen. Die zentrale Frage ist daher nicht, ob der Vertrag vollständig ist, sondern ob der Anbieter architektonisch nachweisen kann, dass EU-Daten unabhängig von rechtlichen Anforderungen vor Offenlegung geschützt sind.

Kundeneigene Verschlüsselungsschlüssel: Die technische Grundlage

Kundeneigene Verschlüsselungsschlüssel lösen das Hoheitsrisiko in der Lieferkette an der Wurzel. Der Dateninhaber hält die Schlüssel, die der Anbieter nie erhält – so ist der Anbieter technisch nicht in der Lage, auf die Inhalte zuzugreifen oder sie offenzulegen, unabhängig von rechtlichen Anforderungen. Das unterscheidet sich architektonisch grundlegend von BYOK- oder kundenverwalteten Schlüsselmodellen, bei denen die Infrastruktur des Anbieters die Entschlüsselung übernimmt und Zugriff behält. In einem BYOK-Modell liefert eine gültige behördliche Anordnung lesbare Daten. Bei kundeneigenen Schlüsseln hält der Anbieter nur Chiffretext, den er nicht entschlüsseln kann.

Auf den Datenaustausch mit Anbietern angewendet bedeutet das: Sensible Daten erreichen den Anbieter bereits verschlüsselt – mit Schlüsseln, die der Anbieter nie erhält. Der Anbieter kann sie speichern, übertragen und verarbeiten – aber nicht lesen, offenlegen oder einer staatlichen Anordnung nachkommen, die lesbare Inhalte verlangt. Die Datenhoheit bleibt nicht wegen Zusagen des Anbieters erhalten, sondern weil ihm die technische Möglichkeit zur Verletzung fehlt. Das vereinfacht auch die Bewertung der Anbieterhoheit: Statt jeden Anbieter auf Zugriffskontrollen, Gerichtsbarkeit und Unterauftragskette zu prüfen, behält der Dateninhaber die Hoheit durch eine einzige architektonische Kontrolle, die vor dem Verlassen der eigenen Infrastruktur greift.

Wie Kiteworks die Hoheitslücke bei Drittparteien schließt

Das Private Data Network von Kiteworks ermöglicht Datenhoheit gegenüber Drittparteien über alle Kanäle, über die sensible Daten eine Organisation verlassen – E-Mail, Filesharing, Managed File Transfer, Web-Formulare und APIs – unter einem einheitlichen Richtlinienrahmen. Vom Kunden kontrollierte Verschlüsselungsschlüssel, die ausschließlich beim Dateninhaber liegen und für Kiteworks niemals zugänglich sind, bedeuten: Kiteworks kann nicht auf Kundendaten zugreifen, keine lesbaren Inhalte auf behördliche Anordnung herausgeben und kann von keiner Regierung zur Offenlegung entschlüsselter Daten gezwungen werden.

Die Hoheitsgarantie ist architektonisch: Sie gilt unabhängig davon, welche rechtlichen Anforderungen an Kiteworks gestellt werden oder welcher Anbieter die geteilten Daten erhält. Die Single-Tenant-Bereitstellung am vom Kunden gewählten Standort bringt die Daten unter die Kontrolle der Infrastruktur und Gerichtsbarkeit des Dateninhabers. Zero trust-Sicherheitsarchitektur steuert alle Zugriffe von Anbietern und Subunternehmern, wobei jedes Ereignis in unveränderlichen Audit-Trails über das CISO Dashboard erfasst wird – und so die für Artikel 28, DORA und NIS 2 geforderte Nachweisführung gegenüber Aufsichtsbehörden liefert. Vorgefertigte Compliance-Berichte für DSGVO, NIS 2, DORA und ISO 27001 unterstützen die Dokumentationspflicht, die kein Anbieter-Vertrag allein erfüllen kann.

Erfahren Sie, wie Kiteworks den Datenaustausch Ihrer Organisation mit Drittparteien über alle Kanäle und Gerichtsbarkeiten hinweg absichert – vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

• Blogbeitrag
  Datenhoheit: Best Practice oder regulatorische Pflicht?
• eBook
  Datenhoheit und DSGVO
• Blogbeitrag
  Diese Fallstricke bei der Datenhoheit vermeiden
• Blogbeitrag
  Best Practices für Datenhoheit
• Blogbeitrag
  Datenhoheit und DSGVO [Daten­sicherheit verstehen]