Daten-Governance und Klassifizierung beim Filesharing im Unternehmen: Was Datenschutzbeauftragte wissen müssen

Sie können nicht schützen, was Sie nicht klassifiziert haben. Dieses Prinzip bildet die Grundlage jedes ausgereiften Datenschutzprogramms – und ist inzwischen fest in regulatorischen Anforderungen verankert, die direkt auf regulierte Filesharing-Umgebungen abzielen. DSGVO fordert das Prinzip der Datenminimierung, NIS 2 verpflichtet zur Umsetzung angemessener Sicherheitsmaßnahmen für kategorisierte Daten, und das DORA-Rahmenwerk für das Management von IKT-Risiken setzt voraus, dass Unternehmen wissen, welche Daten sie besitzen, wie sensibel diese sind, wer darauf zugegriffen hat und unter welchen Bedingungen sie weitergegeben werden dürfen.

Die operative Herausforderung besteht darin, dass Klassifizierung und Governance häufig als Problem des Dokumentenmanagements und nicht als Plattformsteuerung betrachtet werden. Unternehmen investieren in Klassifizierungstaxonomien, erstellen Sensitivitätsrichtlinien und führen Mitarbeiterschulungen durch – nur um dann festzustellen, dass die Filesharing-Plattform, die ihre sensibelsten Daten verarbeitet, keine Mechanismen zur Durchsetzung dieser Richtlinien bietet, keinen Klassifizierungs- Audit-Trail für Auditoren bereitstellt und keine Kopplung zwischen Datensensitivität und Zugriffsentscheidungen ermöglicht. Das Klassifizierungsprogramm existiert auf dem Papier; die Plattform ignoriert es in der Praxis.

Dieser Beitrag richtet sich an Datenschutzbeauftragte und Verantwortliche für Datenschutz, die verstehen müssen, wie eine moderne Enterprise-Filesharing-Plattform ihre Klassifizierungs- und Governance-Pflichten unterstützen kann – und sollte. Es wird erläutert, wie klassifizierungsbewusste Plattformkontrollen aussehen, welche regulatorischen Anforderungen sie adressieren und wie Kiteworks diese auf Basis dokumentierter Funktionen umsetzt.

Executive Summary

Kernaussage: Datenklassifizierung im Enterprise-Filesharing ist weit mehr als nur ein Etikett auf einer Datei. Effektive Governance erfordert vier miteinander verbundene Fähigkeiten: ein vom Kunden definierbares und pflegbares Klassifizierungsschema, Sensitivitätskennzeichnungen, die bei Datenbewegungen erhalten bleiben, Plattformkontrollen, die Richtlinienentscheidungen auf Basis dieser Labels durchsetzen, und einen Audit-Trail, der jedes Klassifizierungsereignis für regulatorische Prüfungen dokumentiert. Die meisten Plattformen implementieren nur ein oder zwei dieser Aspekte; echte Governance erfordert das Zusammenspiel aller vier.

Warum das relevant ist: DSGVO Artikel 5 und 17, NIS 2 Artikel 21 und Data Sovereignty-Bewertungsrahmen verlangen von Unternehmen, nachzuweisen, dass sensible Daten kategorisiert werden, der Zugriff entsprechend der Sensitivität gesteuert wird, Daten auf Anfrage mit überprüfbarem Nachweis gelöscht werden können und ein vollständiges Aktivitätenprotokoll für Aufsichtsbehörden verfügbar ist. Eine Filesharing-Plattform ohne klassifizierungsbewusste Kontrollen zwingt den DPO, Kompensationskontrollen außerhalb der Plattform zu schaffen – was Audit-Lücken und Compliance-Risiken erzeugt, die ohne plattformnative Governance schwer zu schließen sind.

5 Key Takeaways

1. Klassifizierung ohne Durchsetzung ist ein Compliance-Risiko, kein Vorteil. Ein Sensitivitätslabel, das zwar auf einer Datei existiert, aber keine Zugriffsentscheidung, Data Loss Prevention (DLP)-Regel oder Freigabebeschränkung beeinflusst, bietet keinen echten Datenschutz. Regulierungsbehörden werden im Vorfall prüfen, ob das Label tatsächlich Auswirkungen hatte – und „wir klassifizieren, aber setzen nicht durch“ ist keine tragfähige Antwort. Die Checkliste des DPO muss die Überprüfung enthalten, dass Labels mindestens eine sichtbare Plattformkontrollentscheidung auslösen.
2. Microsoft Information Protection Label-Support ist nur dann wertvoll, wenn die empfangende Plattform das Label erhält und darauf reagiert. Viele Unternehmen wenden MIP-Sensitivitätslabels in Microsoft 365 an und gehen davon aus, dass diese Labels mit den Daten weitergegeben werden. Ob eine Nicht-Microsoft-Plattform das Label liest, respektiert und durchsetzt – oder es stillschweigend entfernt – sollte explizit hinterfragt werden. Eine plattformseitige MIP-Integration, die den Label-Zustand erhält und Daten durch klassifizierungsbewusste Kontrollen leitet, ist eine andere Fähigkeit als das bloße Akzeptieren gelabelter Dateien.
3. Ein Klassifizierungs-Audit-Trail ist ein regulatorisches Muss, kein internes IT-Protokoll. Nach DSGVO und NIS 2 müssen DPOs gegenüber Aufsichtsbehörden nachweisen, dass Klassifizierungsereignisse – Label gesetzt, geändert, entfernt – mit ausreichender Detailtiefe dokumentiert werden, um die Historie eines bestimmten Datensatzes rekonstruieren zu können. Ein Audit-Log, das 632 verschiedene Ereignistypen einschließlich Klassifizierungsereignissen erfasst, ist für den DPO im regulatorischen Kontext tatsächlich nutzbar. Generische Systemprotokolle reichen nicht aus.
4. Krypto-Shredding via BYOK bietet einen kundengesteuerten, revisionssicheren Löschmechanismus – aber die Anerkennung nach DSGVO Artikel 17 variiert je nach Land. Das Recht auf Löschung erfordert einen überprüfbaren Nachweis. In verschlüsselten Speicherumgebungen macht die Vernichtung des Verschlüsselungsschlüssels die zugehörigen Daten dauerhaft unlesbar, ohne dass ein Nachweis auf Byte-Ebene erforderlich ist. Hält der Kunde den Schlüssel – etwa durch Bring Your Own Key oder Hold Your Own Key –, liegt das Löschereignis vollständig in seiner Kontrolle und die Nachweiskette stammt vom Kunden, nicht vom Anbieter. Die Anerkennung der Schlüsselvernichtung als Löschung ist in der EU nicht einheitlich geregelt; Unternehmen sollten daher länderspezifischen Rechtsrat einholen.
5. Kundeneigene Klassifizierungstaxonomien sind die Governance-Souveränitätsfrage, die im Einkauf selten gestellt wird. Ob ein Kunde eigene Sensitivitätsstufen, Kategorienamen und Klassifizierungshierarchien definieren kann – oder gezwungen ist, das feste Schema des Anbieters zu übernehmen – entscheidet, wer die Data Governance tatsächlich steuert. Ein vom Anbieter vorgegebenes Schema schafft Abhängigkeiten; ein vom Kunden verfasstes und von der Plattform durchgesetztes Schema ist echte Governance-Fähigkeit.

Der regulatorische Hintergrund für klassifizierungsbewusstes Filesharing

Datenklassifizierungspflichten sind nicht neu, aber ihr Durchsetzungskontext hat sich deutlich verändert. Das Prinzip der Datenminimierung und Zweckbindung aus DSGVO Artikel 5, aktiv seit 2018, verpflichtet Unternehmen, nur die für einen definierten Zweck notwendigen personenbezogenen Daten zu speichern und deren Nutzung darüber hinaus zu verhindern. In einer Filesharing-Umgebung ist diese Pflicht nur dann wirksam, wenn die Plattform Aufbewahrungsfristen durchsetzen, den Zugriff auf zweckrelevante Nutzergruppen beschränken und Nachweise für funktionierende Kontrollen liefern kann.

DSGVO, NIS 2 und DORA: Überlappende Klassifizierungspflichten

DSGVO Artikel 5 verlangt, dass personenbezogene Daten „dem Zweck angemessen und erheblich sowie auf das für die Zwecke der Verarbeitung notwendige Maß beschränkt“ sind – das Prinzip der Datenminimierung – und „nur so lange in einer Form aufbewahrt werden, die die Identifizierung der betroffenen Personen ermöglicht, wie es für die Zwecke erforderlich ist“. Das sind keine Dokumentationspflichten, sondern operative Anforderungen: Klassifizierung zur Identifikation personenbezogener Datenkategorien, Zugriffsbeschränkungen entsprechend der Sensitivität und Durchsetzung von Aufbewahrungsfristen, die Daten tatsächlich löschen oder unzugänglich machen, sobald die Frist abgelaufen ist.

DSGVO Artikel 17 – das Recht auf Löschung – stellt eine weitere operative Anforderung dar. Wenn eine betroffene Person ihr Recht auf Löschung ausübt, muss der Verantwortliche nachweisen können, dass die Daten dauerhaft gelöscht oder unzugänglich gemacht wurden. In verteilten Filesharing-Umgebungen mit mehreren Versionen, geteilten Kopien und System-Backups ist „Löschung“ technisch komplex. Plattformen, die kryptografische Löschung ermöglichen – also die Vernichtung des Verschlüsselungsschlüssels, der eine Datei oder einen Dateisatz schützt – bieten einen technisch fundierten und revisionssicheren Mechanismus zur Erfüllung der Artikel-17-Pflicht, sofern die zuständige Aufsichtsbehörde die Schlüsselvernichtung als Löschung anerkennt.

NIS 2 Artikel 21 verlangt von betroffenen Unternehmen die Umsetzung „geeigneter und verhältnismäßiger technischer und organisatorischer Maßnahmen“ zum Risikomanagement, einschließlich „Richtlinien zur Risikoanalyse und Informationssicherheit“. Die ENISA-Leitlinien zur NIS-2-Umsetzung betrachten die Datenklassifizierung als Voraussetzung für die Auswahl angemessener Sicherheitsmaßnahmen: Ohne Kategorisierung der Daten kann keine risikoadäquate Maßnahme gewählt werden. Aufsichtsbehörden werden bei der NIS-2-Prüfung einen funktionierenden Klassifizierungsprozess fordern – nicht nur ein Policy-Dokument.

Das DORA-IKT-Risikomanagement-Rahmenwerk, ab Januar 2025 für Finanzunternehmen und deren kritische IKT-Drittanbieter verpflichtend, verlangt die „Identifikation und Klassifizierung von IKT-Assets“ sowie die Ermittlung aller IKT-Risikoquellen. Für Filesharing-Plattformen, die Finanzdaten verarbeiten, gilt diese Pflicht sowohl für das Unternehmen als auch – über vertragliche Vorgaben – für den Plattformanbieter. Eine Filesharing-Plattform, die keine Klassifizierung der gespeicherten und übertragenen Daten unterstützt, schafft eine DORA-Compliance-Lücke, die das IKT-Risikomanagement des Finanzunternehmens schließen muss.

Daten- und KI-Souveränität: Die Governance-Anforderung

Vorgaben zur Daten- und KI-Souveränität betreffen die Fähigkeit des Kunden, die Kontrolle über die Datenverarbeitung – einschließlich Klassifizierung und Governance – zu behalten. Dazu gehört, dass der Kunde eigene Kategorisierungsschemata definieren, Zugriffsrechte auf Basis der Sensitivität durchsetzen, Audit-Nachweise für Datenverarbeitungsentscheidungen führen und Löschrechte ohne Abhängigkeit vom Anbieter ausüben kann. Eine Filesharing-Plattform, die diese Anforderungen unterstützt, liefert dem DPO dokumentierte, überprüfbare Nachweise, dass die Klassifizierungsstrategie des Unternehmens bis zur Filesharing-Ebene reicht – nicht nur bis zu den Dokumentenmanagement- oder CRM-Systemen, die üblicherweise im Fokus stehen.

Regulatorischer Hinweis: Dieser Beitrag bietet allgemeine Informationen zu regulatorischen Pflichten. Für verbindliche Auskünfte, wie DSGVO-, NIS-2- oder DORA-Anforderungen auf Ihr Unternehmen zutreffen, konsultieren Sie bitte Ihre Rechts- oder Datenschutzberatung. Die regulatorische Auslegung variiert je nach Land, Branche und Aufsichtsbehörde.

Klassifizierungsarchitektur: Was Governance auf Plattformebene erfordert

Um zu verstehen, wie Kiteworks Klassifizierungs-Governance umsetzt, muss man wissen, wie eine vollständige Klassifizierungsarchitektur aussieht – und warum Teilimplementierungen Restrisiken erzeugen. Klassifizierungs-Governance in einer Filesharing-Plattform umfasst vier Ebenen: Taxonomiedefinition, Label-Anwendung und -Vererbung, durch Labels gesteuerte Kontrolle und Audit-Nachweise. Eine Lücke auf einer Ebene schwächt die anderen.

Taxonomiedefinition: Kundeneigene Klassifizierungsschemata

Die Grundlage jeder Governance ist die Klassifizierungstaxonomie – also die vom Unternehmen definierten Sensitivitätsstufen, Datenkategorien und Handhabungsvorgaben, die die tatsächlichen Datentypen und das Risikoprofil abbilden. Die Taxonomie eines Finanzdienstleisters unterscheidet sich grundlegend von der eines Gesundheitsdienstleisters oder eines Rüstungsunternehmens. Eine Plattform mit fest vorgegebener Taxonomie zwingt alle Kunden, ihre Governance-Anforderungen in ein Schema zu pressen, das möglicherweise weder zur regulatorischen Umgebung, zu den eigenen Datentypen noch zu den Erwartungen der Aufsichtsbehörde passt.

Kiteworks unterstützt kundendefinierte Klassifizierungsschemata. Kunden können eigene Datenkategorien und Sensitivitätsstufen über die Administrationsoberfläche definieren. Inwieweit die Taxonomiedefinition vollständig per API verfügbar ist – also eine programmatische Verwaltung im Rahmen der Governance-Toolchain ermöglicht – sollte für spezifische Deployment-Anforderungen mit dem Kiteworks-Team geklärt werden. Für Unternehmen, die Klassifizierungstaxonomien über mehrere Systeme hinweg verwalten, reduziert API-gesteuertes Taxonomiemanagement manuellen Verwaltungsaufwand und verhindert Abweichungen zwischen der Plattform-Taxonomie und der Master-Taxonomie des Unternehmens.

Zu prüfen: Kann die Klassifizierungstaxonomie Ihres Unternehmens – inklusive eigener Sensitivitätsstufen, Kategorienamen und Handhabungsregeln – vollständig über das Kiteworks-Admin-Interface gepflegt werden, ohne dass Kiteworks-Entwicklung involviert ist? Für Unternehmen mit komplexen oder häufig aktualisierten Schemata kann API-gesteuertes Taxonomiemanagement erforderlich sein. Prüfen Sie den Umfang der Self-Service-Taxonomieverwaltung für Ihr Deployment-Modell, bevor Sie die Governance-Architektur finalisieren.

Microsoft Information Protection Label-Integration

Für Unternehmen, die bereits Microsoft 365 und dessen native Sensitivitätskennzeichnung nutzen, stellt sich nicht die Frage nach einem neuen Klassifizierungsschema, sondern ob die Filesharing-Plattform die bereits vergebenen Labels anerkennt. MIP-Sensitivitätslabels – vergeben über Microsoft Purview Information Protection – werden als persistente Metadaten mit Dokumenten übertragen. Verlässt ein gelabeltes Dokument das Microsoft-365-Ökosystem und gelangt in eine Drittanbieter-Plattform, treten häufig zwei Fehler auf: Die Plattform entfernt das Label stillschweigend und erzeugt eine unklassifizierte Kopie, oder sie speichert das Label als Metadatum, trifft aber keine darauf basierende Entscheidung.

Kiteworks liest, respektiert und erhält MIP-Sensitivitätslabels. Ein Dokument, das mit einem MIP-Label in Kiteworks gelangt, behält dieses Label; der Label-Zustand ist sichtbar, im Audit-Log nachvollziehbar und fließt in die attributbasierte Zugriffskontrolle der Plattform ein. Labels können zudem innerhalb von Kiteworks automatisch oder durch Nutzer manuell vergeben oder vererbt werden – etwa wenn ein Dokument bestimmten Inhaltsmustern entspricht. So kann eine Sensitivitätskennzeichnung auch automatisiert erfolgen, ohne dass Nutzer aktiv werden müssen. Die manuelle Vergabe durch Nutzer ist ebenfalls möglich, sodass menschliches Ermessen dort greift, wo die automatische Klassifizierung nicht ausreicht oder eine Re-Klassifizierung erforderlich ist.

Für Unternehmen, die nicht in einer Microsoft-365-Umgebung arbeiten, bietet Kiteworks ein eigenes Tagging-System – Kiteworks Tags –, das die gleiche Governance-Funktion unabhängig von MIP erfüllt. Kiteworks Tags können pro Deployment definiert, automatisch durch Policy-Regeln beim Upload oder Empfang vergeben und als ABAC-Bedingungen und DLP-Auslöser genauso genutzt werden wie MIP-Labels. Unternehmen ohne Microsoft-Umgebung können so eine vollständige, policy-basierte Klassifizierungsarchitektur innerhalb der Kiteworks-Plattform aufbauen – ohne Abhängigkeit von externen Labelling-Systemen.

Die Kopplung zwischen Klassifizierungslabels – egal ob MIP oder Kiteworks Tags – und der DLP-Engine von Kiteworks ist eine besonders wichtige Governance-Fähigkeit. Als sensibel klassifizierte Daten – egal ob durch MIP-Label, Kiteworks Tag, manuelle oder automatisierte Klassifizierung – können DLP-Regeln auslösen, die Freigaben blockieren, Genehmigungen verlangen, Wasserzeichen anwenden oder nur Lesezugriff erlauben. Das Sensitivitätslabel beschreibt die Daten also nicht nur, sondern steuert aktiv, was damit geschehen darf. Das Klassifizierungsschema wird so zur operativen Kontrolle – nicht nur zur Dokumentation.

Sensitivitätslabels und Zugriffskontrolle: Von der Klassifizierung zur Durchsetzung

Klassifizierungs-Governance entfaltet ihren Wert erst durch Durchsetzung. Ein Sensitivitätslabel, das keine Plattformentscheidung beeinflusst, ist eine administrative Übung ohne regulatorische Substanz. Die Governance-Frage für DPOs lautet nicht „unterstützt die Plattform Labels?“, sondern „was macht die Plattform anders, weil das Label gesetzt ist?“

Attributbasierte Zugriffskontrolle: Label-gesteuerte Autorisierung

Kiteworks implementiert Attributbasierte Zugriffskontrolle (ABAC) neben Rollenbasierter Zugriffskontrolle (RBAC). Der Unterschied ist für die Klassifizierungs-Governance entscheidend: RBAC steuert, was ein Anwender aufgrund seiner Rolle tun darf; ABAC steuert, worauf ein Anwender zugreifen kann – basierend auf Attributen des Nutzers und des Inhalts. Werden Klassifizierungslabels als Inhaltsattribute im ABAC-Modell genutzt, können Zugriffsentscheidungen direkt durch die Sensitivität gesteuert werden.

Konkret bedeutet das: Die Rolle eines Anwenders kann den Zugriff auf einen Ordner erlauben, aber eine ABAC-Policy kann den Zugriff auf einzelne Dateien im Ordner je nach Sensitivitätslabel einschränken – ohne manuelle Einzelberechtigungen. Ein als „Eingeschränkt“ oder „Vertraulich“ gelabeltes Dokument kann anderen Zugriffsbeschränkungen unterliegen als ein „Unklassifiziertes“ im selben Ordner. So entsteht eine Governance-Ebene, die auf Inhaltsattributen basiert – flexibler und regulatorisch präziser, da viele Vorgaben den Schutz nach Sensitivität und nicht nach Speicherort verlangen.

Zu prüfen: Klären Sie mit Kiteworks die konkreten ABAC-Policies für Ihr Deployment – insbesondere, ob ein Sensitivitätslabel direkt eine Zugriff-Verweigern-Entscheidung für Nutzer auslösen kann, die die Handhabungsanforderungen des Labels nicht erfüllen, unabhängig von Ordner-RBAC-Berechtigungen. Die Integration von MIP-Labels, ABAC-Attributen und Zugriffsbeschränkungen ist die Governance-Kopplung, die Klassifizierung zur Durchsetzung macht. Die Architektur unterstützt dieses Modell; die konkreten Konfigurationsoptionen sollten Sie im Implementierungsdesign prüfen.

DLP-Integration: Klassifizierung als Policy-Auslöser

Data Loss Prevention im Filesharing-Kontext bedeutet, dass sensible Daten nicht an Empfänger oder Ziele gelangen, die die Handhabungsanforderungen nicht erfüllen. Die DLP-Integration von Kiteworks nutzt Klassifizierungslabels als Policy-Auslöser. Als sensibel gelabelte Daten können Regeln unterliegen, die externe Freigaben blockieren, eine Managementgenehmigung vor Versand verlangen, Wasserzeichen auf exportierte Kopien anwenden oder den Empfänger auf Lesezugriff mit deaktiviertem Download beschränken.

Das sind keine kosmetischen Kontrollen. Eine DLP-Regel, die verhindert, dass ein Mitarbeiter ein als „Eingeschränkt“ gelabeltes Dokument ohne Genehmigung an Externe weitergibt, ist eine operative Umsetzung des Zweckbindungsprinzips der DSGVO – das Dokument darf nur an Empfänger und in Kontexte gelangen, die mit dem ursprünglichen Zweck vereinbar sind. Das Klassifizierungslabel kodiert die Sensitivitätsentscheidung (durch Policy, Regel oder Autor); die DLP-Regel setzt sie beim Teilen durch. Der Audit-Nachweis des DPO umfasst sowohl die Label-Historie als auch die DLP-Durchsetzungsereignisse.

Residenzbewusste Klassifizierung

Für Unternehmen mit Data Residency-Pflichten – verbreitet in EMEA unter DSGVO, dem deutschen BSI C5 und branchenspezifischen Vorgaben – kann Klassifizierung mit Residenzkontrollen verknüpft werden. Inhalte, die bestimmten juristischen Vorgaben unterliegen, können gezielt in Speicherorten abgelegt werden, die diese Anforderungen erfüllen. Die Multi-Instanz- und geografisch verteilten Deployment-Optionen von Kiteworks ermöglichen Residenzdurchsetzung auf Plattformebene, ohne nachträgliche Kontrolle, wo klassifizierte Daten gelandet sind. Die Kombination aus Klassifizierung, Residenzbewusstsein und Zugriffskontrolle schafft einen Governance-Rahmen, in dem regulierte Daten ohne ständige manuelle Überwachung bewegt werden können.

Klassifizierungs-Audit-Trail: Nachweis für regulatorische Prüfungen

Im Audit-Trail treffen Governance-Anspruch und regulatorische Kontrolle aufeinander. Wenn eine Aufsichtsbehörde, ein interner Auditor oder ein DPO bei der jährlichen Überprüfung fragt, was mit bestimmten klassifizierten Daten geschehen ist, muss die Antwort aus einem manipulationssicheren, strukturierten Protokoll stammen – nicht aus rekonstruierter Vermutung oder Erinnerungen von Administratoren.

632-Ereignisse-Audit-Log: Klassifizierungsereignisse im Kontext

Kiteworks führt ein umfassendes Audit-Log mit 632 verschiedenen Ereignistypen. Klassifizierungsereignisse – Label gesetzt, geändert, entfernt – werden zusammen mit dem vollständigen Aktivitätskontext protokolliert: Nutzeridentität, Zeitstempel, Inhaltskennung, Quelle und Ziel sowie Sitzungsinformationen. Das bedeutet: Das Audit-Protokoll für ein sensibles Dokument ist nicht nur eine Klassifizierungshistorie, sondern ein vollständiges Aktivitätenprotokoll, das zeigt, wer das Label gesetzt hat, welche Aktionen vor und nach der Klassifizierung erfolgten und ob Policy-gesteuerte Ereignisse (DLP-Auslöser, Zugriffsbeschränkung, Freigabeworkflow) mit dem Klassifizierungsstatus verknüpft waren.

Für DPOs ist das ein entscheidender Vorteil. Im regulatorischen Verfahren reicht es nicht, das aktuelle Label einer Datei zu zeigen. Es muss die Historie nachgewiesen werden: Wann wurde das Label gesetzt, von wem, wurde es geändert, welche Zugriffsentscheidungen wurden beeinflusst und gab es DLP-Ereignisse aufgrund der Klassifizierung? Das 632-Ereignisse-Audit-Log liefert die Basis für diese Rekonstruktion. Policy-gefilterte Audit-Log-Reports – mit denen Compliance-Administratoren Ereignisse nach Policy oder Tag isolieren können – sind mit einer Advanced-Governance-Lizenz verfügbar. Ob das Log in einem für die Aufsichtsbehörde direkt einreichbaren Format exportiert werden kann – strukturiert, signiert und formatiert –, ist eine Konfigurations- und Implementierungsfrage, die zu klären ist.

Hinweis zum Audit-Trail: Das 632-Ereignisse-Audit-Log ist ein aktivitätsbasiertes Protokoll – es dokumentiert, wer was, wann, mit welchen Daten getan hat. So entsteht eine Art Inhaltsherkunftsnachweis auf Filesharing-Ebene: ein vollständiges Protokoll von Zugriff, Änderung, Teilen und Klassifizierung über den gesamten Lebenszyklus der Inhalte auf der Plattform. Es ist keine Data-Lineage-Map im Datenengineering-Sinn (Verfolgung von Datenveränderungen über Systeme und Verarbeitungsschritte hinweg). Unternehmen, die vollständige, systemübergreifende Data Lineage benötigen, müssen den Kiteworks-Audit-Trail mit weiteren Tools auf Infrastrukturebene ergänzen.

Manipulationssichere Protokollierung und regulatorische Verwertbarkeit

Ein Audit-Log hat nur dann regulatorischen Wert, wenn seine Integrität nachweisbar ist. Ein Protokoll, das ein Administrator ändern, kürzen oder selektiv exportieren kann, ist keine verlässliche Basis für die Prüfung durch eine Aufsichtsbehörde. Der Audit-Trail von Kiteworks ist auf manipulationssichere Protokollierung ausgelegt. Bei On-Premises-Deployments liegt die Log-Infrastruktur in der Kontrolle des Kunden – dieser kann eigene Integritätskontrollen (Write-Once-Speicher, externes Log-Forwarding, kryptografische Signierung) anwenden, ohne auf Zusicherungen des Anbieters angewiesen zu sein. Die Möglichkeit, Audit-Ereignisse in Echtzeit an ein kundengesteuertes Security Information and Event Management (SIEM) weiterzuleiten, verschafft der Security- und Compliance-Funktion ein unabhängiges, unveränderbares Protokoll.

Retention, Löschung und die Umsetzung von DSGVO Artikel 17

Retention und Löschung gehören zu den operativ anspruchsvollsten Aspekten der Data Governance in Filesharing-Umgebungen. Inhalte wachsen schnell an; Versionen vervielfachen sich; gelöschte Dateien bleiben in Backups erhalten; und wenn eine betroffene Person ihr Recht auf Löschung nach Artikel 17 ausübt, reicht ein Löschbefehl als Nachweis nicht aus.

Konfigurierbare Aufbewahrungsrichtlinien

Kiteworks unterstützt kundenspezifisch konfigurierbare Aufbewahrungsrichtlinien. Die Vereinbarung zur Datenverarbeitung enthält Regelungen zu Rückgabe und Löschung von Daten bei Vertragsende – eine Grundvoraussetzung für jede DSGVO-konforme Verarbeitung. Für das operative Retention-Management – also die Festlegung von Aufbewahrungsfristen nach Datentyp, Sensitivitätsstufe oder Ordner – sollte der Umfang der Self-Service-Konfiguration im Implementierungsdesign geprüft werden. Unternehmen mit komplexen Aufbewahrungsplänen (mehrere Kategorien mit unterschiedlichen Fristen, Legal Hold, automatische Löschtrigger) sollten sicherstellen, dass die Plattformfunktionen zur Retention-Policy passen, bevor sie in den Produktivbetrieb gehen – und nicht erst bei der Audit-Prüfung Lücken entdecken.

Zu prüfen: Klären Sie mit Kiteworks die Granularität der konfigurierbaren Aufbewahrungsrichtlinien für Ihr Deployment – insbesondere, ob Fristen pro Datenkategorie oder Sensitivitätsstufe gesetzt werden können und ob automatisierte Löschung (statt manueller Markierung) für Daten möglich ist, deren Aufbewahrungsfrist abgelaufen ist.

Krypto-Shredding: BYOK und HYOK als Löschmechanismen

Für Unternehmen mit Bring Your Own Key (BYOK) oder Hold Your Own Key (HYOK) unterstützt Kiteworks einen kryptografischen Löschansatz, der sowohl technisch robust als auch auditierbar ist. Bei BYOK hält der Kunde die Verschlüsselungsschlüssel für gespeicherte Daten. Daten, die gelöscht werden müssen – etwa weil eine betroffene Person ihr Recht nach Artikel 17 ausübt oder die Aufbewahrungsfrist abgelaufen ist – können per Krypto-Shredding gelöscht werden: Der Schlüssel wird vernichtet, die verschlüsselten Daten werden dauerhaft und irreversibel unlesbar.

Krypto-Shredding bietet mehrere Governance-Vorteile gegenüber herkömmlicher Löschung. Erstens liegt das Löschereignis vollständig in der Kontrolle des Kunden – es besteht keine Abhängigkeit vom Plattformanbieter und kein Zeitfenster, in dem die Daten nach Löschanfrage noch für den Anbieter zugänglich wären. Zweitens ist die Nachweiskette kundengeneriert: Das Schlüsselvernichtungsereignis wird im Key-Management-System des Kunden protokolliert und ist für Auditoren überprüfbar – ohne Anbieterbescheinigung. Drittens löst es das Restdaten-Problem: Selbst wenn verschlüsselte Bytes in Backups verbleiben, sind sie ohne Schlüssel nicht mehr rekonstruierbar – die Daten sind faktisch gelöscht.

Die Kombination aus klassifizierungsbasierter Identifikation (welche Daten müssen gelöscht werden?) und BYOK-gestütztem Krypto-Shredding (wie wird gelöscht und nachgewiesen?) bildet eine technisch fundierte, revisionssichere Basis für die Umsetzung von DSGVO Artikel 17 auf Filesharing-Ebene. Da die Anerkennung von Krypto-Shredding als Löschung in der EU nicht einheitlich geregelt ist, sollten Unternehmen die Rechtslage für ihr Land mit juristischem Beistand klären, bevor sie sich primär auf diesen Mechanismus verlassen.

Wie Kiteworks Data Governance umsetzt: Differenzierungsmerkmale

Mehrere Merkmale unterscheiden die Data-Governance-Architektur von Kiteworks von Plattformen, die Klassifizierung nur als Zusatzfunktion betrachten.

Klassifizierung als Plattform-Infrastruktur, nicht als Integration

In vielen Enterprise-Plattformen wird Klassifizierung durch die Integration eines externen DLP- oder Klassifizierungstools abgedeckt, das neben der Plattform läuft und Daten nachgelagert prüft. Die Klassifizierungsentscheidung fällt extern; die Plattform erhält ein Signal und reagiert möglicherweise darauf. Die Kopplung ist fragil, nur über Systemgrenzen auditierbar und abhängig davon, dass die Integration funktioniert.

Kiteworks betrachtet Klassifizierung als Teil des eigenen Datenmodells. Der MIP-Label-Zustand ist ein natives Attribut, das die Plattform direkt liest, zusammen mit den Daten speichert, im Audit-Log anzeigt und in ABAC-Entscheidungen einbezieht. DLP-Policies werden innerhalb der Plattform definiert und direkt beim Datenzugriff – Teilen, Download, Übertragung – durchgesetzt, nicht erst an einer Perimeter-Inspektionsstelle. Die Klassifizierungsarchitektur ist die Plattformarchitektur – kein aufgesetzter Layer.

Governance über den gesamten Content-Lebenszyklus

Data Governance im Filesharing-Kontext umfasst den gesamten Datenlebenszyklus: Aufnahme (woher stammt die Datei, mit welchem Label?), Speicherung (welchen Klassifizierungsstatus hat sie?), Zugriff (wer greift zu, unter welcher Policy, mit welcher ABAC-Entscheidung?), Übertragung (wohin geht sie, unter welcher DLP-Governance?) und Löschung (wann und wie wurde sie vernichtet, mit welchem Nachweis?). Eine Governance, die nur einzelne Phasen abdeckt, hinterlässt Lücken – gerade dann, wenn regulatorische Kontrolle am höchsten ist und eine vollständige Audit-Rekonstruktion gefordert wird.

Kiteworks verbindet MIP-Label-Integration, ABAC-gesteuerte Zugriffskontrolle, DLP-unterstützte Übertragungskontrolle, 632-Ereignisse-Audit-Logging über alle Lebenszyklusphasen und BYOK-gestütztes Krypto-Shredding zu einer vollständigen Abdeckung. Das bedeutet nicht, dass jede Konfigurationsoption in jedem Deployment-Modell verfügbar ist – Details sollten im Beschaffungsprozess geklärt werden –, aber die Architektur deckt alle Phasen ab, was viele Wettbewerber nicht leisten.

Zertifizierungen und regulatorische Einordnung

Die Governance-Funktionen von Kiteworks werden nach verschiedenen unabhängigen Standards für regulierte Umgebungen in EMEA und international geprüft und zertifiziert. BSI C5 (Cloud Computing Compliance Controls Catalogue des BSI) bewertet Datenverarbeitung, Zugriffskontrolle und operatives Logging – direkt relevant für Klassifizierungs-Governance. Die ISO 27001 zertifiziert das Informationssicherheitsmanagementsystem, in dem Klassifizierungs- und Governance-Kontrollen wirken. Cyber Essentials Plus ist die britische Regierungs-Baseline. Das australische IRAP unterstützt Behörden- und regulierte Sektoren. FedRAMP High In Process deckt US-Bundesanforderungen ab. SOC 2 Typ II bietet unabhängige Prüfung von Sicherheitskontrollen wie Zugriffsmanagement und Audit-Logging.

Für DPOs, die regulatorische Dokumentation vorbereiten, liefern Drittanbieter-Auditberichte zu diesen Frameworks unabhängige Bestätigung der Governance-Fähigkeiten der Plattform – Nachweise, die nicht allein auf Anbieterangaben beruhen.

Fazit

Data Governance und Klassifizierung in einer Filesharing-Umgebung sind keine Features, die man beim Einkauf abhakt – sie sind das Fundament, auf dem alle weiteren Datenschutzkontrollen aufbauen. Da Aufsichtsbehörden unter DSGVO, NIS 2 und DORA ihre Anforderungen an nachweisbar durchgesetzte Governance verschärfen, kann die Filesharing-Ebene nicht länger außerhalb des Datenschutzprogramms betrachtet werden. Die Klassifizierungsarchitektur von Kiteworks – mit kundendefinierten Taxonomien, MIP-Label-Erhalt und -Durchsetzung, ABAC-gesteuerter Zugriffskontrolle, DLP-Integration, umfassendem Audit-Logging und BYOK-gestütztem Krypto-Shredding – liefert die Bausteine für eine DPO-sichere Governance über den gesamten Datenlebenszyklus. Unternehmen, die ihre Filesharing-Governance bewerten, sollten nicht nur fragen, ob die Plattform Klassifizierung unterstützt, sondern ob sie diese auch durchsetzt – und ob die Nachweiskette regulatorischer Prüfung standhält.

Häufig gestellte Fragen