Das Problem der PII-Akkumulation in der Dokumentation
Interne Wissensdatenbanken — Confluence, Notion, SharePoint, GitBook — akkumulieren eine spezifische Art von PII-Problem, das für Standard-Compliance-Tools nahezu unsichtbar ist: persönliche Daten von Kunden, die in Screenshots eingebettet sind, die zur Dokumentation von Prozessen verwendet werden.
Das Szenario spielt sich in Tausenden von Support- und Operationsteams ab:
Ein Support-Mitarbeiter entdeckt eine ungewöhnliche Kontokonfiguration. Er macht einen Screenshot der Kontoseite des Kunden, um das Problem für den zu schreibenden Artikel in der Wissensdatenbank zu dokumentieren. Der Screenshot enthält den Namen des Kunden im UI-Header, seine E-Mail-Adresse in den Kontoeinstellungen und seine Abonnementdetails.
Der Artikel der Wissensdatenbank wird im internen Wiki veröffentlicht. 150 Support-Mitarbeiter können jetzt darauf zugreifen. 12 Auftragnehmer, die vom externen Helpdesk arbeiten, können darauf zugreifen. Der Artikel ist eine nützliche Dokumentation, wie man mit dem Randfall umgeht.
Drei Jahre später hat die Wissensdatenbank 847 solcher Artikel. Jeder enthält Screenshots von Kundenkonten. Die Kunden, deren Kontodaten in den Screenshots erscheinen, haben dieser sekundären Verwendung ihrer Daten nicht zugestimmt. Die meisten wissen nicht, dass ihre Daten im internen Wiki sind.
GDPR-Exposition: Warum dies kein geringfügiges Problem ist
Die GDPR-Analyse für interne Dokumentationsscreenshots:
Datenminimierung (Artikel 5(1)(c)): Personenbezogene Daten müssen "angemessen, relevant und auf das Notwendige beschränkt" sein. Ein Wissensdatenbankartikel über Randfälle der Kontokonfiguration erfordert nicht den echten Namen und die E-Mail-Adresse des Kunden. Ein sanierter Screenshot (Kundenname verschwommen) würde den Dokumentationszweck ebenso gut erfüllen. Die Einbeziehung der echten Kundendaten ist nicht notwendig.
Zweckbindung (Artikel 5(1)(b)): Personenbezogene Daten, die für einen Zweck (Kundenservice-Interaktion) gesammelt wurden, dürfen ohne rechtliche Grundlage nicht für einen anderen Zweck (interne Prozessdokumentation) wiederverwendet werden. Die Kontodaten des Kunden wurden zur Bereitstellung von Dienstleistungen gesammelt, nicht zur Dokumentation interner Randfälle.
Zugriffskontrolle (Artikel 5(1)(f) und Artikel 32): Angemessene technische Maßnahmen müssen personenbezogene Daten schützen. Screenshots von Kundenkonten in einem Wiki, auf das alle 150 Mitarbeiter und Auftragnehmer zugreifen können — einschließlich derjenigen, die möglicherweise keinen Zugang zum zugrunde liegenden Kundensystem haben — stellen einen unangemessenen breiten Zugang zu personenbezogenen Daten dar.
Recht auf Löschung (Artikel 17): Eine betroffene Person, die die Löschung ihrer personenbezogenen Daten beantragt, hat das Recht, diese "ohne unangemessene Verzögerung" löschen zu lassen. Wenn ihre Daten in 23 Wissensdatenbankartikeln als eingebettete Screenshots erscheinen, erfordert die Löschanfrage das Finden und Verarbeiten aller 23 Artikel — eine operationell schwierige Aufgabe ohne systematische Erkennung.
Der Zugriffskontrollumgehung
Das größte Compliance-Problem mit Wiki-Screenshots ist die Zugriffskontrollumgehung, die sie schaffen.
Support-Organisationen verwenden typischerweise RBAC, um zu kontrollieren, wer auf Kundensysteme zugreifen kann. Tier-1-Mitarbeiter haben Zugriff auf grundlegende Kontoinformationen. Tier-2-Mitarbeiter haben Zugriff auf Abrechnungs- und technische Details. Manager und Administratoren haben Zugriff auf das vollständige Kontoprofil.
Wenn ein Tier-2-Mitarbeiter einen Wissensdatenbankartikel mit einem Screenshot des vollständigen Kundenkontoprofiles erstellt, wird dieser Screenshot für alle Wiki-Nutzer zugänglich — einschließlich Tier-1-Mitarbeitern, die keinen Zugriff auf Abrechnungsdetails haben sollten, Auftragnehmern, die überhaupt keinen Systemzugang haben, und neuen Mitarbeitern während der Einarbeitung.
Der Screenshot umgeht die RBAC-Kontrollen im Kundensystem. Die personenbezogenen Daten, die durch die RBAC geschützt werden sollten, sind jetzt für jeden mit Wiki-Zugriff zugänglich.
Praktische Abhilfe: Rückblickend und vorausschauend
Für Organisationen, die dieses Problem während eines GDPR-Audits entdecken:
Rückblickende Abhilfe:
- Identifizieren Sie alle internen Wiki-Seiten, die Bildanhänge enthalten
- Führen Sie eine Bild-PII-Erkennung auf allen Bildanhängen durch
- Triage der Ergebnisse: Bilder mit hochgradigen PII-Erkennungen zur Überprüfung gekennzeichnet
- Für gekennzeichnete Bilder: entweder durch sanierte Versionen ersetzen oder geeignete Zugriffskontrollen zur Wiki-Seite hinzufügen
- Dokumentieren Sie die Abhilfemaßnahmen für die GDPR-Verantwortlichkeitsaufzeichnungen
Der Umfang der rückblickenden Abhilfe hängt von der Größe der Wissensdatenbank ab. Für eine 3 Jahre alte Wissensdatenbank in einem 50-köpfigen Support-Team kann die Bildanzahl in die Tausende gehen. Batch-Bildverarbeitung macht dies machbar; der entscheidende Engpass ist die menschliche Überprüfung der gekennzeichneten Bilder.
Vorausschauende Kontrollen:
- Prozessdokumentation: Alle Mitglieder des Support-Teams werden geschult, Screenshots vor der Nutzung im Wiki zu sanieren
- Technische Unterstützung: Screenshot-Annotierungstools (Verschwommenmachen von Kundennamen vor dem Einfügen)
- Überprüfungsschritt: Ein benannter Prüfer genehmigt Wiki-Artikel vor der Veröffentlichung und überprüft speziell auf Kunden-PII in Bildern
- Periodische Prüfung: vierteljährlicher Batch-Bild-PII-Scan aller Wiki-Anhänge
Minimal lebensfähige Kontrolle (für ressourcenbeschränkte Teams): Eine Wiki-Veröffentlichungscheckliste, die "Entfernen oder Verschwommenmachen aller Kundennamen, E-Mails und Konten-IDs aus Screenshots vor der Veröffentlichung" umfasst. Niedrigtechnisch, nicht automatisiert, schafft aber Dokumentation der Kontrolle.
Warum das Problem im Laufe der Zeit schlimmer wird
Ohne systematische Kontrollen verschärft sich das interne Wiki-PII-Problem im Laufe der Zeit:
Volumen: Jeder neue Wissensdatenbankartikel mit einem Kunden-Screenshot erhöht die gesamte PII-Exposition. Mit dem Wachstum des Support-Teams und der Erweiterung der Wissensdatenbank wächst die akkumulierte PII proportional.
Vergessene Artikel: Artikel, die alte Randfälle dokumentieren, die nicht mehr auftreten, können im Wiki vergessen werden, sind aber weiterhin zugänglich — sie enthalten PII von Kunden, die inzwischen Löschanträge gestellt haben.
Übergreifende Teamverbreitung: Wissensdatenbanken werden häufig funktionsübergreifend. Ein Supportartikel mit Screenshots von Kunden kann mit dem Produktteam, dem Engineering-Team oder externen Auftragnehmern als Kontext für eine Funktionsanforderung oder einen Fehlerbericht geteilt werden.
Rückstand beim Recht auf Löschung: Mit der zunehmenden Ansammlung von Kundendaten im Wiki wird die Beantwortung von Löschanträgen komplexer. Ohne systematische Erkennung gibt es keinen zuverlässigen Weg zu bestätigen, dass alle Instanzen der Informationen einer betroffenen Person identifiziert und gelöscht wurden.
Für die GDPR-Compliance ist die konsistente Erkenntnis, dass PII in der Wissensdatenbank leichter zu verhindern ist als zu beheben. Vorausschauende Kontrollen — jetzt implementiert — vermeiden das exponentiell wachsende Problem der Abhilfe.
Quellen: