Wo Ihre Daten gespeichert sind: Jurisdiktionale Souveränität beim Filesharing in Unternehmen

Für regulierte Unternehmen in der EU ist die Frage „Wo liegen die Daten?“ längst nicht mehr allein ein Thema für die IT. Juristen, Datenschutzbeauftragte (DPOs) und Einkaufsteams sind heute regelmäßig involviert – denn die Antwort hat direkte Auswirkungen auf die DSGVO-Compliance, NIS 2-Pflichten, DORA-Anforderungen an Drittparteien und das Risiko extraterritorialer Rechtszugriffe aus Nicht-EU-Ländern.

Dieser Beitrag erläutert, was territoriale Souveränität beim Filesharing im Unternehmen tatsächlich bedeutet: Wo liegen die Daten physisch? Wer hat die rechtliche Befugnis, auf sie zuzugreifen? Was passiert, wenn eine Behörde anfragt? Und wie werden grenzüberschreitende Übermittlungen geregelt? Er behandelt die Fragen, die EU-Unternehmen jedem Anbieter stellen sollten – und zeigt, wie Kiteworks diese Themen mit seiner Vertragsstruktur und dokumentierten Compliance-Strategie adressiert.

Executive Summary

Kernaussage: Jurisdiktionale Souveränität beim Filesharing im Unternehmen hat drei Dimensionen: Wo liegen die Daten physisch? Wer hat die rechtliche Befugnis, Zugriff zu erzwingen? Und welche technischen und vertraglichen Schutzmaßnahmen verhindern unbefugte Offenlegung? Diese drei Fragen werden im Einkauf oft getrennt betrachtet – sie sind jedoch voneinander abhängig, und eine Schwäche in einem Bereich untergräbt die anderen beiden.

Warum das relevant ist: NIS 2 und DORA verlangen von Unternehmen, dass sie die juristische Exponierung ihrer Anbieter verstehen und minimieren. Schrems II hat Mechanismen für grenzüberschreitende Übermittlungen zu einem zentralen Beschaffungskriterium gemacht. Und mit dem CLOUD Act, der den Zugriff der US-Regierung auf Daten von US-Muttergesellschaften weltweit ausweitet, ist die Frage, mit wem Sie tatsächlich einen Vertrag schließen – und nach welchem Recht – eine der entscheidendsten Entscheidungen in der Anbieterbeziehung geworden.

5 wichtige Erkenntnisse

1. Datenresidenz und Datensouveränität sind nicht dasselbe. Residenz beschreibt, wo Daten physisch gespeichert werden. Souveränität bedeutet, wer rechtlich Zugriff nehmen oder diesen erzwingen kann. Ein Anbieter kann Daten in Frankfurt speichern und trotzdem durch seine Konzernstruktur US-Rechtszugriff unterliegen. Beide Fragen müssen separat beantwortet werden.
2. Die Vertragspartei ist genauso wichtig wie das Produkt. Mit wem Sie unterschreiben, bestimmt, welches Recht gilt und welchen extraterritorialen Gesetzen der Anbieter unterliegt. Ein Vertrag mit einer US-Gesellschaft setzt Sie dem CLOUD Act aus – selbst wenn die Server in Amsterdam stehen.
3. HYOK- Verschlüsselung ist ein Übertragungsschutz, nicht nur ein Sicherheitsfeature. Hold Your Own Key-Architektur – Schlüssel verbleiben beim Kunden und nicht beim Anbieter – macht aus rechtlich erzwingbaren Daten technisch unzugängliche Informationen. Die EDSA erkennt HYOK-ähnliche Verschlüsselung als zulässige ergänzende Maßnahme für grenzüberschreitende Übermittlungen an – sofern ein starker Algorithmus, Schlüssel außerhalb des Drittlandes und kein Importeur-Zugriff auf die Schlüssel unter jeglichem Rechtszwang vorliegen – sowohl im Schrems II-Rahmen als auch im aktuellen EU–US- Data Privacy Framework, wo ergänzende Maßnahmen weiterhin ratsam sind (wegen anhängiger Berufung C-703/25 P).
4. Offenlegung von Behördenzugriff ist eine Beschaffungsanforderung, kein Entgegenkommen. NIS 2 und DORA verlangen, dass Unternehmen wissen, wie Anbieter bei Behördenanfragen agieren. „Wir halten uns an geltendes Recht“ reicht nicht. Fragen Sie nach Challenge-Prozess und Benachrichtigungspolitik für Kunden.
5. Subprozessor-Jurisdiktion ist ein verstecktes Risiko bei den meisten Filesharing-Lösungen. Die Datenschutzverpflichtungen Ihres Anbieters sind nur so stark wie seine Subprozessor-Kette. Ein Subprozessor in einer Hochüberwachungs-Jurisdiktion kann Daten exponieren, die Ihr Hauptvertrag eigentlich schützt.

Datenresidenz: Wo liegen die Daten tatsächlich?

Die Antwort auf „Wo liegen die Daten?“ hängt grundlegend vom Bereitstellungsmodell ab – und On-Premises und SaaS liefern hier sehr unterschiedliche Antworten. Die richtige Wahl ist nicht nur für Compliance, sondern auch für die operative Resilienz entscheidend. Ist die Datenresidenz nicht vertraglich festgelegt, kann sie sich durch Infrastrukturentscheidungen des Anbieters ändern – ohne Ihre Zustimmung.

On-Premises-Bereitstellung: Der Kunde bestimmt die Geografie

Bei einer On-Premises-Bereitstellung betreibt der Kunde die Kiteworks-Appliance auf eigener oder kontrollierter Infrastruktur – im Rechenzentrum und in der Jurisdiktion seiner Wahl. Der Anbieter hat keinen Zugriff auf diese Infrastruktur und entscheidet nicht, wo die Daten liegen. Für regulierte Organisationen in Deutschland, Frankreich, den Niederlanden oder anderen EU-Staaten, die verlangen, dass Daten innerhalb bestimmter Grenzen bleiben, ist dieses Modell die klarste Antwort: Die Daten liegen dort, wo Sie sie platzieren – unter Ihrer physischen und operativen Kontrolle.

Das gehärtete Appliance-Modell von Kiteworks verstärkt dies. Die Appliance ist eigenständig und arbeitet unabhängig von der Cloud-Infrastruktur von Kiteworks. Es gibt keine Pflichtverbindung zu anbieterseitigen Systemen, die Daten außerhalb der gewählten Geografie routen würden. In Kombination mit der Hold Your Own Key (HYOK)-Architektur – der Kunde hält und betreibt die Verschlüsselungsschlüssel unabhängig von Kiteworks – bietet das On-Premises-Modell sowohl physische Residenzkontrolle als auch kryptografische Unabhängigkeit.

SaaS-Bereitstellung: Eine andere Ausgangslage

Bei SaaS-Bereitstellung liegen die Daten auf Infrastruktur, die vom Anbieter betrieben wird. Für EU-Kunden heißt das: Prüfen, welche Regionen verfügbar sind, ob Daten unter allen Betriebsbedingungen in diesen Regionen bleiben und ob es Fallback-Mechanismen gibt, die Daten auf Nicht-EU-Infrastruktur verschieben könnten. Kiteworks bietet SaaS-Optionen mit EU-Region – die konkreten Regionen, deren Zertifizierungsstatus und die vertraglichen Zusagen zur Datenhaltung in diesen Regionen gehören in jedes EU-Beschaffungsgespräch zu SaaS-Bereitstellung.

Fakt ist: On-Premises-Bereitstellung gibt EU-Organisationen die stärkste Kontrolle über die Datenresidenz. SaaS-Bereitstellung bringt anbieterseitige Geografie-Entscheidungen mit sich, die explizite vertragliche Zusagen erfordern.

Die Vertragspartei: Mit wem schließen Sie tatsächlich ab?

Diese Frage ist wichtiger, als viele Beschaffungsteams vermuten. Die juristische Einheit, mit der Sie den Vertrag schließen, bestimmt das anwendbare Recht, die Zuständigkeit bei Streitfällen und – entscheidend – welche Behörden den Anbieter zur Herausgabe von Daten zwingen können. Es gibt zwei Aspekte: die primäre Vertragspartei und die dahinterstehende Muttergesellschaft.

Kiteworks Europe AG: Die EU-Vertragspartei

Für EMEA-Kunden ist die Vertragspartei die Kiteworks Europe AG, eingetragen in der Bahnhofstrasse 29, Zug, Schweiz. Diese Gesellschaft ist im EMEA-Lizenzvertrag genannt und das aus zwei Gründen relevant.

Erstens ist die Schweiz kein EU-Mitglied, verfügt aber über einen Angemessenheitsbeschluss für Datenübermittlungen aus der EU und genießt einen Ruf für starken Datenschutz. Zweitens – und praktisch wichtiger – bietet die Schweizer Gesellschaft einen wirksamen Schutz vor dem US CLOUD Act. Der CLOUD Act verpflichtet US-Gesellschaften, Daten weltweit auf Anordnung US-amerikanischer Behörden herauszugeben. Eine Schweizer Gesellschaft unterliegt nicht direkt dem CLOUD Act – sie unterliegt Schweizer Recht, das eigene Verfahrensvorschriften und ein Rechtshilfeabkommen (MLAT) vorsieht, bevor ausländische Anordnungen befolgt werden.

Das bedeutet nicht, dass eine Schweizer Gesellschaft gegen jeglichen ausländischen Zugriff immun ist. Es heißt, dass der Rechtsweg enger, klarer definiert und mit größerer Wahrscheinlichkeit ein Verfahren umfasst, das Kundenbenachrichtigung und Anfechtung ermöglicht. Das ist eine deutlich bessere Position als ein Vertrag mit einer US-Gesellschaft, für die CLOUD Act-Compliance eine inländische Pflicht ist.

Was zu prüfen ist: Stellen Sie sicher, dass Ihr Lizenzvertrag die Kiteworks Europe AG als Vertragspartei nennt. Falls Ihr Vertrag älter ist, prüfen Sie, ob die Gesellschaftsbezeichnung aktuell ist – in diesem Markt finden sich gelegentlich Altbezeichnungen, die aktualisiert werden sollten. Bitten Sie Ihr Kiteworks-Team um Bestätigung der aktuellen Vertragspartei für Ihre Jurisdiktion.

Kiteworks USA, die britische Zwischenholding und die Muttergesellschaft

Kiteworks Europe AG ist Teil einer Konzernstruktur mit einer britischen Zwischenholding als unmittelbare Mutter der Schweizer Gesellschaft. Das bringt eine zweite Jurisdiktionsdimension, die EU-Organisationen explizit abklären sollten: den UK Investigatory Powers Act 2016 (IPA) und das UK–US Data Access Agreement (2022).

Der UK IPA gibt britischen Behörden die Befugnis, technische Anordnungen, Massenüberwachungsbefehle und Datenaufbewahrungsanordnungen an britisch verbundene Anbieter zu erlassen. Das UK–US Data Access Agreement (2022) – ein bilaterales Abkommen im Rahmen des CLOUD Act – ermöglicht britischen und US-Behörden direkte Anfragen an Anbieter in der jeweils anderen Jurisdiktion. Die britische Zwischenholding eröffnet damit einen weiteren Zugriffsweg, der sich vom Schweizer MLAT-Verfahren unterscheidet und in manchen Punkten direkter ist.

Was das praktisch bedeutet: Die Schweizer Vertragspartei (Kiteworks Europe AG) reduziert die direkte CLOUD Act-Exponierung für EU-Kunden. Die britische Zwischenholding bringt UK IPA- und UK–US Data Access Agreement-Exponierung als zweiten Vektor. Wie beim CLOUD Act gilt: Die HYOK-Architektur macht jede erfolgreiche rechtliche Anordnung technisch wirkungslos – die britische Holding wie auch die US-Mutter können keine lesbaren Daten liefern, zu denen sie keinen Schlüssel besitzen. Organisationen, deren Risikobewertung die gesamte Konzernstruktur abbilden muss, sollten sich die Holding-Struktur vom Kiteworks-Team bestätigen lassen.

Für die meisten regulierten EU-Organisationen reichen die Schweizer Gesellschaftsstruktur und die technischen Schutzmaßnahmen (HYOK, On-Premises-Bereitstellung) aus, um die Souveränitätsanforderungen zu erfüllen. Für Organisationen mit höchsten Anforderungen – etwa an EU-Eigentümerschaft und Governance-Einfluss auf die Technologie – sind US-Mutter und britische Zwischenholding ehrliche Einschränkungen, die dokumentiert werden sollten.

Behördenzugriff: Was passiert bei staatlicher Anfrage?

Diese Frage ist seit Schrems II unumgänglich. Der Europäische Gerichtshof hat Privacy Shield 2020 explizit deshalb für ungültig erklärt, weil US-Überwachungsgesetze – CLOUD Act, FISA 702, Executive Order 12333 – US-Behörden Zugriff auf personenbezogene Daten einräumen, gegen den sich EU-Betroffene nicht wirksam wehren können.

Seit Juli 2023 ersetzt das EU–US Data Privacy Framework (DPF) das Privacy Shield als Angemessenheitsmechanismus für Übermittlungen an DPF-zertifizierte US-Organisationen. Das Gericht der EU bestätigte die DPF-Angemessenheit im September 2025 (Latombe, T-553/23), eine Berufung ist beim EuGH anhängig (C-703/25 P). Das DPF ist damit aktuell der Rechtsmechanismus für EU–US-Übermittlungen – seine weitere Gültigkeit ist jedoch nicht garantiert. Organisationen, die sich auf das DPF als primären Übermittlungsmechanismus verlassen, sollten ergänzende Maßnahmen als Absicherung vor einer möglichen Aufhebung vorhalten.

Jede Organisation mit einem US-muttergeführten Anbieter braucht eine glaubwürdige Antwort auf die Überwachungsfrage – unabhängig vom Übermittlungsmechanismus. Zwei Dinge zählen: das Exponierungsbild verstehen und eine technische Schutzmaßnahme haben, die rechtliche Anordnungen praktisch irrelevant macht.

Das CLOUD Act-Exponierungsbild

Der CLOUD Act gilt für US-Gesellschaften und deren Tochterunternehmen. Für EU-Kunden, die mit Kiteworks Europe AG nach Schweizer Recht kontrahieren, ist die direkte CLOUD Act-Exponierung reduziert – US-Behörden müssten den Schweizer MLAT-Prozess nutzen, statt einen US-Beschluss zuzustellen. Dieses Verfahren ist langsamer, transparenter und leichter anfechtbar.

Das vollständige Exponierungsbild erfordert jedoch auch die Subprozessor-Landschaft. Ist ein Subprozessor von Kiteworks, der EU-Kundendaten verarbeitet, eine US-Gesellschaft, kann der CLOUD Act auch über diesen Subprozessor greifen – selbst wenn die Hauptvertragspartei Schweizerisch ist. Deshalb ist Subprozessor-Jurisdiktion kein theoretisches Risiko, sondern Teil der Transfer Impact Assessment, wie Schrems II sie fordert.

HYOK als technische Schutzmaßnahme unter Schrems II

Die EDSA-Empfehlungen zu ergänzenden Maßnahmen (Empfehlung 01/2020) sehen Verschlüsselung vor, bei der der Datenimporteur keinen Zugriff auf die Schlüssel hat – als zulässige technische Schutzmaßnahme für Datenübermittlungen. Die HYOK-Architektur von Kiteworks ist genau für diesen Anwendungsfall konzipiert.

Bei HYOK hält der Kunde die Verschlüsselungsschlüssel in seiner eigenen Infrastruktur. Kiteworks – und jede Behörde, die Kiteworks verpflichtet – kann die Daten nicht entschlüsseln, da Kiteworks die Schlüssel nicht besitzt. Die Daten, wie sie bei Kiteworks oder Subprozessoren liegen, sind kryptografisch unzugänglich ohne Mitwirkung des Kunden. So wird ein rechtliches Risiko in eine technische Unmöglichkeit umgewandelt – die stärkste derzeit verfügbare ergänzende Maßnahme am Markt.

Kiteworks dokumentiert seine rechtliche Exponierung im Hinblick auf CLOUD Act, FISA 702 und das relevante Multijurisdiktionsumfeld. Diese Mechanismen unterscheiden sich hinsichtlich der Benachrichtigung: Eine CLOUD Act-Anordnung kann Kundenbenachrichtigung und Anfechtung erlauben, während FISA 702 gesetzliche Schweigepflichten enthält, die eine Benachrichtigung verbieten. Kiteworks stellt für die Zugriffstypen, bei denen Benachrichtigung rechtlich zulässig ist, eine Benachrichtigungspolitik und einen Challenge-Prozess bereit. Die Kombination aus HYOK-Architektur und kundenseitig betriebenem On-Premises-HSM – mit FIPS 140-3-validierter Kryptografie – bietet die technische Grundlage für den Nachweis extraterritorialer Zugriffsprävention, wie sie regulierte Organisationen für ihre Transfer Impact Assessments dokumentieren müssen.

Exportkontrolle und Multijurisdiktions-Compliance

Für Unternehmen aus Verteidigung, Luft- und Raumfahrt oder Dual-Use-Technologien bringt Exportkontroll-Compliance eine weitere Ebene in die Jurisdiktionsfrage. Kiteworks hält die IRAP PROTECTED-Klassifizierung nach dem Australian Information Security Manual – ein Rahmenwerk mit direkter Relevanz für den Verteidigungssektor in NATO-Staaten. Die Plattform erfüllt außerdem ITAR-Compliance-Anforderungen für Unternehmen, die kontrollierte technische Daten verarbeiten.

Das Multijurisdiktions-Zertifizierungsportfolio – BSI C5 Typ 2, ISO 27001, Cyber Essentials Plus, IRAP PROTECTED, FedRAMP High In Process, SOC 2 Typ II – liefert die Compliance-Nachweise, die Beschaffungsteams in regulierten Branchen für ihre Drittparteien-Risikobewertungen benötigen.

Grenzüberschreitende Übermittlungen: DSGVO-Compliance sicherstellen

Für jede Übermittlung personenbezogener Daten aus der EU in ein Drittland verlangt die DSGVO Kapitel V entweder einen Angemessenheitsbeschluss für das Zielland oder geeignete Garantien – meist Standardvertragsklauseln (SCCs). Seit Schrems II reichen SCCs allein für Übermittlungen in die USA nicht mehr aus. Organisationen müssen eine Transfer Impact Assessment durchführen und, wenn das Zielland keinen gleichwertigen Schutz bietet, ergänzende Maßnahmen umsetzen.

Für Übermittlungen in die USA bietet das EU–US Data Privacy Framework (DPF), gültig seit Juli 2023 und vom Gericht der EU im September 2025 (Latombe, T-553/23) bestätigt, einen Angemessenheitsmechanismus für DPF-zertifizierte Organisationen. Da jedoch eine Berufung beim EuGH anhängig ist (C-703/25 P), sollten Organisationen, die sich auf das DPF stützen, ergänzende Maßnahmen als Absicherung vorhalten. Für Übermittlungen über die Schweizer Gesellschaft von Kiteworks bietet die Schweizer Angemessenheit – separat nach Schweizer Datenschutzrecht – einen weiteren Übermittlungsmechanismus, der nicht von der DPF-Gültigkeit abhängt.

Standardvertragsklauseln und das Kiteworks DPA

Das Data Processing Agreement (DPA) von Kiteworks ist auf Basis des SCC-Rahmens aufgebaut und regelt das Controller-Processor-Verhältnis sowie die Übermittlungsmechanismen für alle Daten, die die EU verlassen. Das DPA enthält die in Artikel 46 DSGVO geforderten Übermittlungsmechanismen für eine rechtmäßige Verarbeitung.

Für Organisationen, die eine TIA durchführen – wie Schrems II es verlangt – sind die relevanten Faktoren: das Rechtsumfeld im Land des Datenimporteurs, die Art der übermittelten Daten und die technischen sowie organisatorischen Maßnahmen. Die Schweizer Gesellschaftsstruktur ist dabei relevant: Angemessenheitsbeschluss der Schweiz plus Schweizer Rechtsverfahren für ausländische Zugriffsanfragen schaffen ein anderes Risikoprofil als eine direkte Übermittlung an eine US-Gesellschaft.

HYOK als Schrems II-Antwort

Für Organisationen, die die stärkstmögliche Position zur Rechtmäßigkeit grenzüberschreitender Übermittlungen benötigen, ist HYOK die am besten vertretbare ergänzende Maßnahme. Sind die Daten mit Schlüsseln verschlüsselt, die der Kunde hält und auf die Kiteworks keinen Zugriff hat, stellt selbst die Übermittlung verschlüsselter Daten keine relevante Offenlegung personenbezogener Daten dar – der Empfänger kann sie nicht lesen.

Das ist kein Workaround, sondern genau die Architektur, die die EDSA in ihren Empfehlungen zu ergänzenden Maßnahmen vorsieht. Organisationen, die Kiteworks mit HYOK und On-Premises-Bereitstellung nutzen, haben eine solide Grundlage für ihre Transfer Impact Assessments.

Subprozessoren: Das juristische Risiko, das Sie vielleicht nicht kennen

Die Datenschutzverpflichtungen eines Anbieters sind nur so stark wie seine Subprozessor-Kette. Jeder Subprozessor, der EU-Kundendaten verarbeitet oder darauf zugreifen könnte, bringt eigene juristische Exponierung mit – Gründungsland, lokale rechtliche Pflichten und das daraus resultierende Behördenzugriffsrisiko.

Das DPA von Kiteworks enthält eine Subprozessorliste (Anhang 1) mit allen Unternehmen, die EU-Kundendaten verarbeiten. Das ist die Grundlage eines konformen Artikel 28 DSGVO-Rahmens – ein Anbieter, der seine Subprozessoren nicht benennen kann, kann keine glaubwürdige Datenschutz-Compliance zusagen.

Aktueller Stand der Subprozessor-Transparenz: Die Liste im DPA-Anhang 1 dokumentiert die aktuellen Subprozessoren, aber ein Echtzeit-Register mit automatischer Änderungsbenachrichtigung für Kunden ist noch nicht veröffentlicht. Das ist eine anerkannte Lücke. Für Organisationen, die laufende Transparenz zu Subprozessor-Änderungen benötigen – wie Artikel 28 DSGVO über das Widerspruchsrecht gegen neue Subprozessoren vorsieht – ist die direkte Abstimmung mit Kiteworks und eine vertragliche Benachrichtigungsregelung der aktuelle Weg.

Für Beschaffungsteams lautet die Frage nicht nur „Wer sind Ihre Subprozessoren heute?“, sondern „Wie werden wir über Änderungen informiert und wie viel Vorlaufzeit erhalten wir, bevor ein neuer Subprozessor aktiv wird?“ Artikel 28(2) DSGVO gibt Kunden ein Widerspruchsrecht – aber nur, wenn die Benachrichtigung rechtzeitig erfolgt.

Jurisdiktionale Souveränität: Was Sie Ihren Anbieter fragen sollten

Nutzen Sie diese Tabelle für Beschaffungsgespräche, DPA-Verhandlungen und Drittparteien-Risikobewertungen. Die Fragen sind so strukturiert, dass sie die für die EU- regulatorische Compliance entscheidenden Unterschiede sichtbar machen.

Jurisdiktionale Due Diligence: Umsetzung in der Praxis

Zu wissen, wie die richtigen Antworten aussehen, ist das eine. Sie systematisch im Beschaffungsprozess zu prüfen – und die Prüfung über die gesamte Vertragslaufzeit aufrechtzuerhalten – ist das andere. Jurisdiktionale Due Diligence hat zwei Phasen: die Arbeit vor Vertragsabschluss und das laufende Monitoring, das den Status aktuell hält. Beides ist erforderlich; die meisten Organisationen sind im ersten besser als im zweiten Schritt.

Im Vertragsstadium

• Vertragspartei explizit prüfen. Nicht annehmen – kontrollieren Sie Unterschriftsblock und Definition von „Kiteworks“ im Vertrag. Bestätigen Sie, dass die EU- oder Schweizer Gesellschaft genannt ist, nicht die US-Mutter. Ist Ihr Vertrag älter als eine Konzernumstrukturierung, lassen Sie sich die aktuelle Vertragspartei schriftlich bestätigen.
• Transfer Impact Assessment-Anhang oder Zusicherung verlangen. Fordern Sie vom Anbieter das Standard-TIA oder eine Zusicherung im DPA, dass ein TIA durchgeführt wurde und ergänzende Maßnahmen bestehen. „Wir haben SCCs“ reicht nicht ohne TIA für die relevanten Übertragungswege.
• Vorab-Benachrichtigung bei Subprozessor-Änderungen verhandeln. Artikel 28 DSGVO gibt Ihnen ein Widerspruchsrecht gegen neue Subprozessoren. Das ist nur nutzbar, wenn Sie rechtzeitig informiert werden. Legen Sie die Benachrichtigungsfrist im DPA fest – 30 Tage sind ein guter Ausgangspunkt.
• HYOK-Architektur im Risikoregister dokumentieren. Wenn Sie HYOK einsetzen, dokumentieren Sie dies explizit im Transfer Impact Assessment und Ihrer DPIA als von der EDSA anerkannte ergänzende Maßnahme. So entsteht ein revisionssicherer Nachweis, dass das Risiko erkannt und adressiert wurde.

Laufendes Monitoring

• Subprozessorenliste mindestens jährlich prüfen. Änderungen bei Subprozessoren verändern Ihr Risikoprofil. Legen Sie eine Kalendereintragung im Rhythmus der Anbieterbenachrichtigung an und benennen Sie eine verantwortliche Person in Ihrer Rechts- oder Compliance-Abteilung.
• Rechtsentwicklungen in Anbieter-Jurisdiktionen verfolgen. Schweizer und EU-Recht entwickeln sich weiter. Angemessenheitsbeschlüsse können angefochten werden (Schrems II ist das Paradebeispiel). Beobachten Sie wesentliche Änderungen im Rechtsumfeld der für Ihre Anbieterbeziehungen relevanten Jurisdiktionen.
• TIA neu bewerten, wenn sich die Konzernstruktur des Anbieters ändert. Eine Übernahme, Fusion oder ein Wechsel der Muttergesellschaft kann das Exponierungsbild grundlegend verändern. Vereinbaren Sie einen vertraglichen Auslöser, der den Anbieter verpflichtet, Sie bei relevanten Strukturänderungen zu informieren.

Geschäftliche, finanzielle und Reputationskosten bei falscher Jurisdiktion

Fehler bei der juristischen Souveränität unterscheiden sich von den meisten Sicherheitsvorfällen. Sie werden selten durch einen Vorfall entdeckt – sondern im Audit, bei einer behördlichen Prüfung oder im Rechtsstreit. Dann besteht die Lücke meist schon länger. Die Folgen betreffen regulatorische, operative und Reputationsaspekte und verstärken sich oft gegenseitig.

Regulatorisches und rechtliches Risiko

DSGVO-Artikel 46-Compliance für grenzüberschreitende Übermittlungen ist eine harte gesetzliche Pflicht, kein Best Practice. Die Übertragung von Daten in ein Drittland ohne angemessene Sicherung – oder mit SCCs ohne TIA und ergänzende Maßnahmen – schafft direkte regulatorische Exponierung unter der DSGVO. Aufsichtsbehörden haben bereits erhebliche Bußgelder für unzureichende Übermittlungsmechanismen verhängt, und das Durchsetzungsumfeld ist seit Schrems II deutlich aktiver geworden.

NIS 2 Artikel 21 verlangt angemessene Sicherheitsmaßnahmen in der Lieferkette. Eine Anbieterbeziehung, in der die juristische Exponierung der Subprozessor-Kette nicht abgebildet ist, ist eine Sicherheitslücke in der Lieferkette – eine, nach der eine Aufsichtsbehörde bei der NIS 2-Compliance fragen würde. DORA stellt ähnliche Anforderungen an Finanzunternehmen, inklusive spezifischer Überwachungspflichten für Drittparteien, zu denen auch die Kenntnis der juristischen Ansässigkeit des Anbieters gehört.

Geschäftliches und operatives Risiko

Eine Behördenanordnung, die zur Offenlegung von Kundendaten führt – oder eine Dienstabschaltung, die eine Plattform offline nimmt – kann für Unternehmen, die für regulierte Prozesse auf Filesharing angewiesen sind, katastrophale Folgen haben. Verträge, Studiendaten, Verteidigungsdokumente, Finanzunterlagen: Genau diese Daten sind für Regierungen mit weitreichenden Überwachungsbefugnissen besonders interessant. Dieses Risiko zu verstehen und zu minimieren ist kein Compliance-Checkbox, sondern Teil der operativen Kontinuitätsplanung.

Reputationsrisiko

Für Unternehmen, die ihren eigenen Kunden Souveränitätszusagen machen – Banken, die versichern, dass Daten die EU nicht verlassen, Gesundheitsorganisationen, die Patientendatenresidenz zusagen, Regierungsauftragnehmer mit Compliance-Garantien – kann ein Fehler in der Anbieterjurisdiktion diese Zusagen entwerten. Der Reputationsschaden durch „Wir wussten nicht, dass unser Filesharing-Anbieter eine US-Mutter hat“ ist durch keine Pressemitteilung zu beheben.

Warum Kiteworks für juristische Souveränität?

Die Position von Kiteworks zur juristischen Souveränität unterscheidet sich von den meisten US-Softwareunternehmen durch die Kombination aus Schweizer Vertragspartei, HYOK-Architektur und einem breit aufgestellten, unabhängig validierten Compliance-Portfolio.

Die Schweizer Gesellschaftsstruktur (Kiteworks Europe AG, Bahnhofstrasse 29, Zug, Schweiz) bietet EU-Kunden eine vertraglich relevante Barriere gegen den direkten CLOUD Act-Zugriff – kein absoluter Schutz, aber eine deutlich besser vertretbare Position als ein Vertrag mit einer US-Gesellschaft. HYOK macht aus dieser rechtlichen Abschirmung eine technische Garantie: Selbst wenn ein Rechtszugriff besteht, sind die Daten ohne Mitwirkung des Kunden kryptografisch unzugänglich. Diese Kombination – Schweizer Gesellschaft plus HYOK plus On-Premises-Bereitstellung – ist die derzeit stärkste verfügbare Souveränitätsposition im Markt für Filesharing im Unternehmen.

Das Compliance-Portfolio umfasst Rahmenwerke aus mehreren Jurisdiktionen: BSI C5 Typ 2 und ISO 27001 für EU-relevante unabhängige Prüfungen, Cyber Essentials Plus für den britischen Markt, IRAP PROTECTED für Australien, FedRAMP High In Process für den US-Bundesmarkt und SOC 2 Typ II als Basis-Attestierung. Für Beschaffungsteams, die Drittparteien-Risikobewertungen nach NIS 2 oder DORA durchführen, reduziert diese Bandbreite unabhängiger Attestierungen den Nachweisaufwand gegenüber Anbietern, die individuelle Sicherheitsfragebögen ohne Zertifizierung verlangen.

Die ehrlichen Einschränkungen gehören dazu: Die Muttergesellschaft sitzt in den USA; das Subprozessorenregister ist derzeit ein DPA-Anhang und kein öffentliches Echtzeitregister. Beides sind produktive Themen für das Gespräch mit den Rechts- und Vertragsteams von Kiteworks vor Vertragsabschluss.

Fazit

Für regulierte EU-Unternehmen ist juristische Souveränität beim Filesharing längst kein Thema mehr, das einmalig bei der Beschaffung gelöst wird. Sie ist eine laufende operative und Compliance-Aufgabe – von Vertragspartei über Datenresidenz, Behördenzugriff, Übermittlungsmechanismen bis zur Subprozessor-Kette – die über die gesamte Anbieterbeziehung aktiv gemanagt werden muss.

Kiteworks bietet dafür einen dokumentierten, unabhängig validierten Ausgangspunkt: Schweizer Vertragspartei, HYOK-Architektur als Schrems II-Maßnahme, SCC-gestütztes DPA und ein multijurisdiktionales Zertifizierungsportfolio, das die für EMEA-regulierte Unternehmen relevanten Rahmenwerke abdeckt.

Häufig gestellte Fragen