Portabilität und Exit-Rechte beim Enterprise Filesharing: Was Datenschutzbeauftragte und Rechtsabteilungen vor Vertragsabschluss prüfen müssen

Der ehrlichste Test für die Souveränität eines Anbieters ist die Exit-Frage: Kann Ihr Unternehmen im Falle einer Vertragsbeendigung morgen seine Daten, Konfigurationen und Prüfprotokolle innerhalb eines definierten Zeitrahmens wiederherstellen – und eine schriftliche Bestätigung erhalten, dass alles aus der Infrastruktur des Anbieters gelöscht wurde? Die meisten Beschaffungsgespräche konzentrieren sich auf das Onboarding. Nur wenige prüfen das Offboarding mit derselben Sorgfalt. Diese Asymmetrie schafft Risiken.

DSGVO Artikel 28 verlangt, dass Datenverarbeitungsverträge Regelungen zur Rückgabe und Löschung von Daten bei Vertragsende enthalten. NIS 2 erwartet, dass Unternehmen das Risiko der ICT-Konzentration steuern, was von Aufsichtsbehörden zunehmend als Nachweis einer dokumentierten Exit-Fähigkeit interpretiert wird. DORA wendet die gleiche Logik speziell auf Finanzunternehmen an: Artikel 28(8) fordert dokumentierte Exit-Pläne, während Artikel 30 die detaillierten Vertragsinhalte einschließlich Exit-Strategien, Kündigungsrechte und Prüfzugriff spezifiziert. Zusammen schaffen diese Regelwerke eine Compliance-Basis für Exit-Regelungen – und Marketingaussagen von Anbietern zur „Datenportabilität“ entsprechen diesem Standard in der Praxis selten.

Dieser Beitrag richtet sich an Datenschutzbeauftragte (DPOs), Rechtsabteilungen und Einkaufsverantwortliche, die sichere Filesharing– oder Managed File Transfer-Plattformen bewerten. Er erläutert, was Portabilität und Exit-Rechte im regulatorischen Kontext bedeuten, welche technischen und vertraglichen Kontrollen wirklich relevant sind, welche Fragen selbst bei starken Anbietern offenbleiben – und was Kiteworks bereitstellt, einschließlich einer ehrlichen Einordnung, was dokumentiert ist und was vor Vertragsabschluss direkt verifiziert werden sollte.

Executive Summary

Kernaussage: Portabilität und Exit-Rechte sind keine reine Formalität – sie sind ein Souveränitätskontrollmechanismus. Die Fähigkeit, einen Anbieter zu verlassen, mit intakten Daten, portabler Konfiguration und einem definierten Zeitrahmen für die Löschbestätigung, entscheidet darüber, ob Sie echte operative Unabhängigkeit besitzen oder nur vertragliche Formulierungen, die diese ersetzen. Unternehmen, die Exit-Regelungen als Standardklausel behandeln, gehen ein Konzentrationsrisiko ein, das sie nicht kalkuliert haben.

Warum das relevant ist: DSGVO Artikel 28 verlangt Exit-Regelungen in allen Datenverarbeitungsverträgen. NIS 2 Artikel 21 und DORA Artikel 28(8) erwarten, dass Unternehmen eine gemanagte Exit-Fähigkeit für kritische ICT-Abhängigkeiten nachweisen können. Die fehlende Überprüfung der Exit-Bereitschaft vor Vertragsabschluss ist kein Beschaffungsversäumnis mehr – sie wird zur Compliance-Lücke mit direktem regulatorischem Risiko.

5 wichtige Erkenntnisse

1. Exit-Regelungen im DPA sind nicht gleich Exit-Fähigkeit. Ein Anbieter kann DSGVO-konforme Rückgabe- und Löschklauseln aufnehmen, ohne strukturierte Migrationswerkzeuge, definierte Zeitrahmen für Löschbestätigungen oder Klarheit darüber zu bieten, was tatsächlich portabel ist. Vertragliche Verpflichtung und operative Fähigkeit sind getrennte Fragen. Prüfen Sie beides. Fordern Sie die Dokumentation der Migrationswerkzeuge und den Prozess für Löschbestätigungen an – nicht nur die DPA-Klausel.
2. Konfigurationsportabilität ist genauso wichtig wie Datenportabilität. Dateien auf eine andere Plattform zu übertragen, ist mit Standardprotokollen technisch machbar. Die Replikation von Klassifizierungssystemen, Rollenstrukturen, Richtlinien und Workflow-Konfigurationen ist deutlich schwieriger – und wird von Migrationswerkzeugen der Anbieter oft gar nicht abgedeckt. Wenn ein Migrationswerkzeug nur Daten, aber keine Konfiguration überträgt, sind die Migrationskosten wesentlich höher als vom Anbieter suggeriert. Prüfen Sie vor Vertragsbindung, was tatsächlich exportierbar ist.
3. Offene Standards senken die Wechselkosten spürbar. Anbieter, die Inhalte in Standarddateiformaten speichern und Daten über SFTP, REST API, SCIM, SAML und OAuth bereitstellen, ermöglichen einen reibungsloseren Exit als solche, die proprietäre Exportprozesse verlangen. Die Existenz offener Protokolle garantiert keine niedrigen Wechselkosten – sie ist notwendig, aber nicht hinreichend. Fragen Sie explizit, ob auch Konfigurations- und Identitätsdaten über diese Protokolle exportierbar sind, nicht nur die Daten selbst.
4. Krypto-Shredding via BYOK ist ein wirksamer Löschmechanismus – aber nur, wenn Sie die Schlüssel kontrollieren. Wenn Ihr Unternehmen eine Bring Your Own Key (BYOK)- oder Hold Your Own Key (HYOK)-Architektur betreibt, macht die Vernichtung des Verschlüsselungsschlüssels gespeicherte Daten dauerhaft unzugänglich, ohne dass jede einzelne Datei physisch gelöscht werden muss. Für Unternehmen mit DSGVO-Löschpflichten oder strikten Datenvernichtungsanforderungen ist dies ein relevantes Compliance-Instrument. Voraussetzung ist, dass Ihr Unternehmen die Schlüssel tatsächlich selbst hält und kontrolliert – nicht der Anbieter.
5. NIS 2 und DORA machen Exit-Planung zur Vorstandssache, nicht nur zur DPA-Formalität. Beide Regelwerke verlangen, dass Unternehmen ICT-Konzentrationsrisiken identifizieren und steuern. Eine Filesharing-Plattform, die sensible, regulierte oder geschäftskritische Daten und Workflows verarbeitet, stellt eine ICT-Abhängigkeit dar. Exit-Planung – inklusive dokumentierter Migrationsfähigkeit, getesteter Verfahren und vertraglich definierter Exit-Zeiträume – wird zunehmend zur regulatorischen Erwartung an das Governance-Modell dieser Abhängigkeit. Handeln Sie entsprechend.

Das regulatorische Rahmenwerk: Warum Exit-Rechte auf der Agenda stehen

Portabilität und Exit-Rechte beruhen auf einer Vielzahl überlappender regulatorischer Anforderungen, die in den letzten drei Jahren deutlich expliziter geworden sind. Das Verständnis der jeweiligen Anforderungen hilft DPOs und Rechtsabteilungen, gezielt zu prüfen – und echte Compliance-Risiken von bloßen Marketing-Lücken der Anbieter zu unterscheiden.

DSGVO Artikel 28: Die Basis jedes Datenverarbeitungsvertrags

DSGVO Artikel 28(3)(g) verlangt, dass Datenverarbeitungsverträge Regelungen enthalten, die sicherstellen, dass der Auftragsverarbeiter „nach Abschluss der Verarbeitung sämtliche personenbezogenen Daten nach Wahl des Verantwortlichen entweder zurückgibt oder löscht und vorhandene Kopien löscht, sofern nicht Unionsrecht oder das Recht eines Mitgliedstaats eine Speicherung verlangt“. Das ist verpflichtend. Jeder DPA, der personenbezogene Daten abdeckt, muss dies enthalten.

In der Praxis setzt Artikel 28 einen Mindeststandard – keine Obergrenze. Die Klausel muss existieren, ihre operative Bedeutung hängt aber stark davon ab, was der DPA zu Zeitrahmen, Format und Nachweis der Löschung konkret regelt. Ein DPA, der sagt „Daten werden auf Anfrage nach Vertragsende zurückgegeben“, erfüllt die formale Anforderung, lässt aber maximale Unklarheit darüber, was „Rückgabe“ bedeutet, in welchem Format, in welchem Zeitraum und mit welcher schriftlichen Bestätigung der Löschung. DPOs sollten Exit-Klauseln auf Spezifizität prüfen: definierte Maximalfristen, explizite Formatangaben und schriftliche Löschbestätigungen – nicht nur das Vorhandensein der Klausel.

NIS 2: ICT-Konzentrationsrisiko und Exit-Planung

NIS 2 Artikel 21 verlangt von wesentlichen und wichtigen Einrichtungen, risikoadäquate Managementmaßnahmen umzusetzen. Aufsichtsbehörden in mehreren Mitgliedstaaten interpretieren dies inzwischen so, dass die Exit-Fähigkeit für kritische ICT-Abhängigkeiten nachgewiesen werden muss. Die Logik ist klar: Kann ein Unternehmen einen kritischen Anbieter nicht gemanagt verlassen, besteht ein ungemindertes Konzentrationsrisiko – genau die Art von Resilienzlücke, die NIS 2 adressieren will.

Für Unternehmen, die Filesharing- oder Managed File Transfer-Plattformen als Teil kritischer Geschäftsprozesse nutzen – Finanzinstitute, Gesundheitsdienstleister, Betreiber kritischer Infrastrukturen – reicht es nicht, eine DPA-Exit-Klausel zu haben. Erwartet wird ein glaubwürdiger, getesteter Exit-Plan. Das erfordert dokumentierte Migrationsfähigkeit, nicht nur vertragliche Formulierungen.

DORA: Vertragliche Exit-Rechte als regulatorische Pflicht für Finanzunternehmen

DORA Artikel 30 ist das expliziteste der drei Regelwerke bezüglich der konkreten Inhalte von ICT-Drittanbieter-Verträgen. Gefordert werden unter anderem: Kündigungsrechte und Mindestkündigungsfristen (Art. 30(2)(e)), Rechte zur „Inspektion, Prüfung und Bewertung“ des ICT-Anbieters (Art. 30(2)(f)) und Regelungen zu Exit-Strategien (Art. 30(3)). Die generelle Pflicht zur Aufrechterhaltung von Exit-Plänen steht in Artikel 28(8). DORAs RTS zu ICT-Drittpartnerrisiken geht noch weiter und verlangt, dass Exit-Strategien dokumentiert, getestet und alternative Anbieter identifiziert werden.

Für Finanzunternehmen unter DORA ist Exit-Planung für Filesharing-Plattformen keine Best Practice – sie ist regulatorische Pflicht. Die von DORA geforderte Dokumentation, das Testen und die Analyse alternativer Anbieter gehen deutlich über das hinaus, was die meisten DPA-Exit-Klauseln abdecken. Finanzinstitute sollten dokumentierte Exit-Prozesse und Zeitrahmen fordern – nicht nur eine Prüfung der DPA-Formulierungen.

Operative und technologische Souveränität: Das Exit-Bewertungsmodell

Zwei Dimensionen der Exit-Fähigkeit müssen unabhängig bewertet werden. Erstens die operative Exit-Bereitschaft – ob ein Unternehmen den Wechsel praktisch ohne unzumutbare Kosten oder Datenverluste vollziehen kann. Zweitens die technologische Souveränität – ob die technische Architektur des Anbieters proprietäre Abhängigkeiten schafft, die die Wechselkosten über das wirtschaftlich Vertretbare hinaus erhöhen.

Ein Anbieter kann bei vertraglichen Exit-Regelungen gut abschneiden, aber in beiden Dimensionen schlecht, wenn seine Migrationswerkzeuge unzureichend oder seine Datenformate proprietär sind. Umgekehrt kann ein Anbieter mit starker Open-Standards-Architektur trotzdem Exit-Risiken bergen, wenn die vertraglichen Fristen für die Datenrückgabe unklar sind. Beide Dimensionen müssen unabhängig geprüft werden.

Technische Exit-Kontrollen: Was tatsächlich bestimmt, ob Sie wechseln können

Compliance mit Exit-Klauseln ist Voraussetzung für eine akzeptable Anbieterpositionierung, aber nicht ausreichend. Die praktische Exit-Fähigkeit hängt von technischen Kontrollen ab, die unabhängig von der DPA-Formulierung wirken. Dieser Abschnitt erläutert die vier Dimensionen technischer Exit-Fähigkeit, die DPOs und Rechtsabteilungen bei der Beschaffung prüfen sollten – und worauf zu achten ist, wenn die Anbieterdokumentation lückenhaft ist.

Datenportabilität: Format, Protokoll und Abdeckung

Datenportabilität bedeutet, dass kundeneigene Daten aus der Infrastruktur des Anbieters in einem nutzbaren Format, innerhalb eines angemessenen Zeitrahmens und mit dokumentierten, zuverlässigen Methoden extrahiert werden können. Drei Fragen entscheiden, ob die Portabilitätsversprechen eines Anbieters in der Praxis Bestand haben.

Erstens: In welchem Format werden die Daten gespeichert? Ein Anbieter, der Inhalte in Standarddateiformaten – PDF, DOCX, XLSX, Bilder, Videodateien in offenen Containerformaten – speichert, ermöglicht die sofortige Nutzung extrahierter Daten auf jeder Zielplattform. Ein Anbieter, der Inhalte in proprietären Containern ablegt oder für den Zugriff spezielle Entschlüsselungswerkzeuge verlangt, schafft eine Abhängigkeit, die den vertraglichen Exit überdauert. Kiteworks speichert Inhalte in Standarddateiformaten: Die von Kunden hochgeladenen Dateien sind die Dateien, die extrahiert werden können – ohne Formatkonvertierung oder proprietäre Entschlüsselungswerkzeuge.

Zweitens: Welche Extraktionsprotokolle stehen zur Verfügung? SFTP und FTPS sind Standardprotokolle für den Massendatentransfer und als Kernfunktion der Plattform verfügbar. AS2 (Applicability Statement 2, weit verbreitet im B2B-Managed File Transfer) wird ebenfalls unterstützt, erfordert aber das Kiteworks MFT-Server-Add-on. Eine REST API ermöglicht programmatische, authentifizierte Extraktion mit granularer Steuerung. Kiteworks unterstützt diese Transferprotokolle sowie eine REST API und bietet so mehrere Extraktionswege, die keine anbieterabhängigen Werkzeuge auf der Empfängerseite erfordern.

Drittens: Gibt es ein Migrationswerkzeug – und was deckt es tatsächlich ab? Hier wird die Dokumentation vieler Anbieter oft dünn. Kiteworks stellt Migrationswerkzeuge für gängige Szenarien bereit, statt Kunden zu zwingen, eigene Extraktionsprozesse zu entwickeln. Der Umfang dieser Werkzeuge – ob sie nur Daten, auch Konfigurationen oder beides abdecken – hängt vom jeweiligen Migrationsszenario ab und sollte direkt mit Kiteworks für Ihre Umgebung besprochen werden. Anbieter-Migrationswerkzeuge sind ein deutlich reibungsärmerer Exit-Weg als die Eigenentwicklung individueller Extraktionsprozesse auf Basis von API-Zugriffen.

Hinweis für die Beschaffung: Der konkrete Umfang der Kiteworks-Migrationswerkzeuge – einschließlich der Portabilität von Konfigurationen neben den Daten – hängt von Ihrer Bereitstellung und dem Migrationsszenario ab. Klären Sie die Details direkt mit Kiteworks im Rahmen der Beschaffung.

Konfigurationsportabilität: Der versteckte Wechselkostenfaktor

Inhalte sind nur ein Teil dessen, was ein Unternehmen in einer Filesharing-Plattform ansammelt. Der andere – oft praktisch wichtigere – Teil ist die Konfiguration: Zugriffsrichtlinien, Rollenstrukturen, Klassifizierungssysteme, Ordnerhierarchien, Workflows, Integrations- und Administrationskonfigurationen, die über Jahre aufgebaut wurden. Können diese nicht in einem nutzbaren Format exportiert werden, muss beim Wechsel alles neu aufgebaut werden.

Das Wiederaufbauen von Konfigurationen ist teuer, fehleranfällig und zeitaufwendig. Es birgt zudem ein Sicherheitsrisiko: Unternehmen, die ihre bestehende Zugriffsstruktur auf einer neuen Plattform nicht replizieren können, haben während der Umstellung eine Phase reduzierter Kontrolle. Für Unternehmen mit komplexen Klassifizierungsschemata oder regulatorisch geforderten Access Controls ist das kein theoretisches Risiko – solche Projekte dauern Monate und kosten oft mehr als die eigentliche Datenmigration.

Offene Identitätsstandards adressieren dies teilweise für Benutzer- und Gruppendaten. SCIM (System for Cross-domain Identity Management) ist ein Standardprotokoll für das Provisioning und De-Provisioning von Benutzern und Gruppen. Ein Anbieter, der SCIM-konformen Export ermöglicht, erlaubt die Migration von Identitäts- und Verzeichnisdaten auf eine Zielplattform mit SCIM-Unterstützung – ohne manuelle Neueingabe. Kiteworks unterstützt SCIM für Benutzer- und Gruppenmanagement, das heißt, die Identitätsschicht einer Kiteworks-Umgebung ist über einen offenen Standard exportierbar.

Policy- und Klassifizierungskonfigurationen sind schwieriger und werden von Anbietern meist weniger dokumentiert. Kiteworks nutzt Microsoft Information Protection (MIP)-Sensitivity Labels für die Klassifizierung, sodass Metadaten, die in Kiteworks vergeben werden, auch von anderen Plattformen mit MIP-Unterstützung lesbar sind – das reduziert einen Teil des Konfigurations-Lock-ins. Die Portabilität von Workflows und Administrationsrichtlinien hängt vom Migrationsszenario ab und sollte direkt mit Kiteworks abgestimmt werden.

Prüfprotokolle und Datenherkunft

Exit-Planung sollte den Audit-Trail einbeziehen. Für Compliance-Zwecke – DSGVO-Rechenschaftspflichten, Audit-Anforderungen im Finanzsektor, branchenspezifische Aufbewahrungspflichten – muss ein Unternehmen beim Anbieterwechsel seine Aktivitätsprotokolle mitnehmen oder zumindest vor Vertragsende exportieren können.

Kiteworks führt ein Prüfprotokoll mit 632 Ereignissen, das Zugriffe, Freigaben, Berechtigungsänderungen, administrative Aktionen und Authentifizierungen plattformweit erfasst. Dieses Protokoll ist via Syslog-Integration mit SIEM-Plattformen exportierbar. Unternehmen, die Audit-Events während der Vertragslaufzeit an ein SIEM weiterleiten, verfügen bereits unabhängig von der Anbieterinfrastruktur über ihre Aktivitätsprotokolle. Für Unternehmen ohne Syslog-Export sollte ein Massendatenexport des Prüfprotokolls vor Vertragsende explizit eingeplant werden.

Datenherkunft – ein vollständiger, strukturierter Nachweis, woher jede Information stammt, wie sie bewegt und verändert wurde – ist anspruchsvoller als ein Aktivitätsprotokoll. Relevant ist dies für Unternehmen mit regulatorischen Anforderungen an Datenherkunft (z. B. im Finanzsektor) oder für solche, die Data Governance-Frameworks mit Herkunftsnachweis umsetzen. Ob das 632-Ereignisse-Protokoll von Kiteworks für spezifische regulatorische Zwecke ausreicht, hängt von den jeweiligen Vorgaben ab. Unternehmen mit expliziten Herkunftspflichten sollten dies direkt prüfen und nicht davon ausgehen, dass ein umfassendes Aktivitätsprotokoll automatisch genügt.

Löschbestätigung: Schriftlicher Nachweis innerhalb eines definierten Zeitrahmens

DSGVO Artikel 28(3)(g) verlangt die Löschung personenbezogener Daten nach Vertragsende. Die operative Frage – wie schnell und mit welchem schriftlichen Nachweis? – wird nicht durch den Gesetzestext, sondern durch den DPA beantwortet. Die Spezifizität dieser Antwort variiert stark zwischen den Anbietern.

Nach Vertragsende gewährt Kiteworks Administratoren für einen definierten Zeitraum weiterhin Zugriff auf ihre Daten – so bleibt Zeit für die Datenübernahme und Migration, bevor die Umgebung abgeschaltet wird. Die genaue Dauer dieses Zugriffsfensters und der anschließende Löschzeitraum sollten im DPA-Verhandlungsprozess festgelegt und als vertragliche Zusage behandelt werden – nicht als Annahme auf Basis allgemeiner Dokumentation. DPOs sollten auf Spezifizität achten: ein definiertes Zugriffsfenster, explizite Löschfristen und eine schriftliche Bestätigung über die erfolgte Löschung.

Hinweis für die Beschaffung: Eine schriftliche Löschbestätigung ist bei Kiteworks auf Kundenanfrage erhältlich – sie wird nicht automatisch als Standarddokument ausgestellt. Unternehmen in Jurisdiktionen oder Branchen, in denen ein schriftlicher Löschnachweis erforderlich ist (z. B. für DSGVO-Rechenschaftspflichten oder regulatorische Audits), sollten dies explizit im DPA fordern und Format sowie Zeitpunkt der Ausstellung im Vertrag klären.

Für Unternehmen mit Anforderungen an Krypto-Shredding – bei denen nicht nur gelöscht, sondern Daten dauerhaft unzugänglich gemacht werden müssen – bietet die BYOK- und HYOK-Architektur von Kiteworks eine Lösung. Bei einer BYOK-Bereitstellung liegen die Verschlüsselungsschlüssel für Kundendaten beim Kunden, nicht bei Kiteworks. Die Vernichtung dieser Schlüssel macht alle verschlüsselten Daten dauerhaft unzugänglich – eine effektive Löschung ohne Zutun von Kiteworks. Krypto-Shredding ist technisch robust und wird von einigen Aufsichtsbehörden als adäquater Löschmechanismus anerkannt; die Akzeptanz variiert jedoch innerhalb der EU – CNIL und mehrere deutsche Datenschutzbehörden äußern Vorbehalte – und Unternehmen sollten spezifisch-juristischen Rat einholen, bevor sie sich darauf als primären Löschmechanismus verlassen. Wo akzeptiert, erhält der Kunde die alleinige Kontrolle über die Irreversibilität dieser Maßnahme. Voraussetzung ist, dass der Kunde BYOK tatsächlich betreibt und die Schlüssel selbst kontrolliert – das muss bei der Implementierung geprüft werden, nicht als gegeben angenommen werden.

Vertragliche Exit-Regelungen: Den DPA auf operative Spezifizität prüfen

Die Vertragsprüfung von Exit-Regelungen sollte über das bloße Vorhandensein einer Rückgabe- und Löschklausel hinausgehen. DPOs und Rechtsabteilungen, die DPAs für eine Filesharing-Plattform prüfen, sollten für jede exit-relevante Klausel eine Checkliste operativer Spezifizität anwenden.

Wie eine robuste DPA-Exit-Regelung aussieht

Eine DPA-Exit-Regelung, die die operativen Anforderungen von DSGVO Artikel 28, NIS 2 und DORA erfüllt, sollte sieben Elemente abdecken. Erstens: ein definiertes Format für die Datenrückgabe – entweder im Originalformat oder in einem explizit benannten offenen Format, nicht nach Ermessen des Anbieters. Zweitens: ein definiertes maximales Abruffenster – der Zeitraum, in dem der Kunde nach Kündigung Zugriff und Downloadmöglichkeiten hat. Drittens: ein definiertes maximales Löschzeitfenster – der Zeitraum, in dem der Anbieter die Löschung auf allen Systemen inklusive Backups zusichert. Viertens: eine schriftliche Löschbestätigung – ein formelles, datiertes Dokument über die erfolgte Löschung. Fünftens: Umfang der Löschung – explizite Abdeckung von Primärspeicher, Backups, Disaster-Recovery-Kopien und Kopien bei Sub-Prozessoren. Sechstens: Sub-Prozessor-Verpflichtungen – Bestätigung, dass die Löschpflichten an alle Sub-Prozessoren weitergegeben werden. Siebtens: Kontinuität des Datenzugriffs während der Kündigungsfrist – Bestätigung, dass der Service im Abruffenster normal weiterläuft.

Inwieweit der Kiteworks-DPA explizit Backup-Umfang, Sub-Prozessor-Löschung und schriftliche Bestätigung regelt, sollte im Vertragsgespräch geprüft werden. Diese Punkte sind keine Sonderwünsche – Aufsichtsbehörden unter DSGVO, NIS 2 und DORA erwarten zunehmend, dass sie explizit adressiert werden.

Exit-Regelungen verhandeln: Was sich stärken lässt

Standardformulierungen im DPA sind ein Ausgangspunkt, kein Limit. Unternehmen mit spezifischen regulatorischen Anforderungen – insbesondere Finanzunternehmen unter DORA, Gesundheitsorganisationen mit branchenspezifischen Aufbewahrungspflichten oder öffentliche Einrichtungen mit behördlichen Datenanforderungen – können und sollten DPA-Anpassungen verhandeln, die ihren Bedürfnissen entsprechen.

Typische Verhandlungspunkte sind: ein explizites Datenabruffenster, das für komplexe Migrationen ausreicht; schriftliche Löschbestätigung als Standarddokument statt auf Anfrage; die Ausdehnung der Löschung auf alle Sub-Prozessoren; und Übergangshilfe, die den Anbieter zur Kooperation bei der Migration auf eine benannte Zielplattform verpflichtet. Kiteworks verfügt über BSI C5 Typ 2 Attestierung und ISO 27001-Zertifizierung – beide enthalten Kontrollbereiche zu Datenportabilität und Exit-Prozessen, die unabhängig geprüft werden. Die Existenz solcher Drittatteste bietet eine Grundsicherheit, dass Exit-Kontrollen nicht nur vertraglich, sondern auch operativ umgesetzt sind.

Offene Standards und Wechselkosten: Die Technologie-Souveränitäts-Perspektive

Technologische Souveränität misst, ob die Abhängigkeit eines Unternehmens von einem Anbieter durch proprietäre Technologien verstärkt wird, die Wechselkosten erzeugen, die über die eigentliche Funktionalität der Plattform hinausgehen. Im Kontext von Filesharing und Managed File Transfer sind relevante offene Standards jene, die Identität, Authentifizierung, Datentransfer und Speicherung regeln.

Standards für Identität und Authentifizierung

SAML 2.0 und OAuth sind offene Standards für föderierte Authentifizierung. Eine Plattform, die beides unterstützt, ermöglicht Unternehmen die Anbindung ihres bestehenden Identity Providers – ob Microsoft Entra ID, Okta, Ping Identity oder ein anderes SAML/OAuth-kompatibles System – ohne plattformspezifische Integrationsarbeit. Beim Wechsel auf eine neue Plattform können diese Verbindungen einfach umgeleitet werden, ohne den Identity Provider selbst neu zu konfigurieren. Kiteworks unterstützt SAML 2.0 und OAuth für Authentifizierungsföderation sowie SCIM für das Benutzer- und Gruppenmanagement. Das bedeutet, die Identitätsschicht einer Kiteworks-Umgebung basiert auf offenen, weit verbreiteten Standards und erzeugt kein Vendor-Lock-in auf Authentifizierungsebene.

Standards für Datentransfer und Speicherung

Für die Datenextraktion und Kompatibilität mit Zielsystemen sind SFTP (SSH File Transfer Protocol), FTPS (FTP Secure), REST APIs nach HTTP-Standard und S3-kompatible Object-Storage-APIs relevant. AS2 (Applicability Statement 2, weit verbreitet im B2B-Managed File Transfer) wird über das Kiteworks MFT Server-Add-on unterstützt. Kiteworks bietet SFTP und FTPS als Kernprotokolle für den ein- und ausgehenden Transfer, AS2 für MFT-Server-Kunden sowie eine REST API für programmatischen Zugriff. S3-Kompatibilität – relevant für Unternehmen, die auf Cloud-Object-Storage migrieren – ist durch die Unterstützung von S3-kompatiblen Backends gegeben, aber die explizite Dokumentation der S3-Exportfähigkeit sollte für spezifische Migrationsszenarien geprüft werden.

Die praktische Bedeutung dieser Standards ist asymmetrisch: Sie werden vor allem dann wichtig, wenn etwas schiefgeht. Im Normalbetrieb funktionieren proprietäre Integrationen oft ausreichend, sodass der Mangel an offenen Standards nicht auffällt. Im Notfall – etwa bei finanziellen Problemen des Anbieters, regulatorischen Vorgaben oder Sicherheitsvorfällen – wird das Fehlen dokumentierter, standardbasierter Extraktionswege zum kritischen Problem. Die Prüfung offener Standards vor Vertragsabschluss ist einfaches Risikomanagement.

Wie Kiteworks Portabilität und Exit handhabt: Eine ehrliche Einschätzung

Der Ansatz von Kiteworks zu Portabilität und Exit ist in einigen Bereichen stärker als in anderen. Eine ehrliche Einschätzung unterscheidet zwischen gut dokumentierten Aspekten, architekturbedingt gegebenen Merkmalen und Punkten, die vor Vertragsabschluss direkt verifiziert werden sollten.

Die stärksten Elemente der Portabilitätsstrategie von Kiteworks sind das Inhaltsformat (Standarddateien, keine proprietären Container), die Protokollabdeckung (SFTP, FTPS, REST API; AS2 via MFT Server-Add-on), die Identitätsstandards (SAML 2.0, OAuth, SCIM), die vertraglichen Exit-Regelungen (Administratorzugriff nach Vertragsende; Löschzeitraum im DPA zu klären) und die Krypto-Shredding-Fähigkeit via BYOK/HYOK. Diese stellen eine deutlich bessere Exit-Position dar als Anbieter, die Inhalte in proprietären Formaten speichern, keine Migrationswerkzeuge bieten oder nur generische DPA-Formulierungen ohne Zeitrahmen bereitstellen.

Kiteworks verfügt über eine BSI C5 Typ 2 Attestierung – das Cloud-Sicherheits-Framework des Bundesamts für Sicherheit in der Informationstechnik, das Kontrollbereiche zu Datenportabilität und Exit-Prozessen umfasst. Die ISO 27001-Zertifizierung deckt Datenverarbeitung und Beendigungsprozesse als Teil der Annex-A-Anforderungen ab. Beide werden von externen Prüfern unabhängig attestiert, sodass die Kontrollen an externen Standards gemessen werden, nicht an Eigenerklärungen. Für Unternehmen in regulierten Branchen bietet diese Kombination von EMEA-relevanten Attesten eine belastbarere Evidenzbasis als reine Anbieter-Dokumentation. Kiteworks besitzt zudem den Status FedRAMP High In Process, Cyber Essentials Plus, IRAP (Australien) und SOC 2 Typ II – ein Zertifizierungsportfolio, das eine konsistente unabhängige Prüfung über mehrere regulatorische Jurisdiktionen hinweg widerspiegelt.

Einige Bereiche sollten im Beschaffungsprozess direkt adressiert werden, statt sie aus allgemeinen Dokumenten abzuleiten. Die schriftliche Löschbestätigung ist auf Anfrage erhältlich – Unternehmen, die sie als Standarddokument benötigen, sollten dies explizit im DPA verankern. Der genaue Umfang der Migrationswerkzeuge für Ihre Umgebung sollte direkt mit Kiteworks abgestimmt werden, da er vom Migrationsszenario abhängt. Datenherkunft als konsolidierter, strukturierter Export ist öffentlich nicht dokumentiert, das 632-Ereignisse-Protokoll bietet jedoch eine Basis, die manche regulatorische Anforderungen erfüllen kann. Unternehmen, für die einer dieser Punkte zwingend ist, sollten vor Vertragsabschluss schriftliche Antworten einholen.

Exit-Planungs-Checkliste: Was Sie vor Vertragsabschluss tun sollten

Die folgende Tabelle ordnet jede Exit-Fähigkeitsdimension dem jeweiligen Prüfpunkt und dem relevanten regulatorischen Anker zu. DPOs und Rechtsabteilungen können sie als strukturierten Prüfrahmen im Beschaffungsprozess nutzen.

Fazit

Portabilität und Exit-Rechte erreichen einen Wendepunkt in der regulatorischen Erwartung: Was früher eine DPA-Formalität war, wird zur nachweisbaren operativen Fähigkeit, die Aufsichtsbehörden unter DSGVO, NIS 2 und DORA zunehmend von Unternehmen verlangen. Anbieter mit dokumentierten Migrationswerkzeugen, definierten vertraglichen Exit-Zeiträumen, offenen Standards für Identität und Transfer sowie unabhängiger Drittattestierung der Exit-Kontrollen sind sowohl für den Datenschutz als auch für die regulatorische Position ihrer Kunden deutlich besser aufgestellt als solche, die nur vertragliche Formulierungen bieten. Der konkrete Umfang der Migrationswerkzeuge sowie die exakten Bedingungen für Löschfristen und Bestätigungen sind Details, die direkt mit Kiteworks geklärt werden sollten – sie hängen vom Bereitstellungsszenario und der Vertragsverhandlung ab. Die Gesamtposition zur Portabilität ist stark; die verbleibende Aufgabe ist die Klärung der kundenspezifischen Details, die nur ein direktes Gespräch mit Kiteworks leisten kann.

Häufig gestellte Fragen