Screenshot-PII in internen Wissensdatenbanken
Interne Wissensdatenbanken — Confluence, Notion, SharePoint, GitBook — bergen eine spezifische Art von PII-Problem, die Standard-Compliance-Tools übersehen: persönliche Kundendaten, die in Screenshots für Prozessdokumentationen eingebettet sind.
Das Muster wiederholt sich in Tausenden von Support- und Betriebsteams.
Ein Support-Mitarbeiter entdeckt eine ungewöhnliche Kontoeinstellung. Er macht einen Screenshot der Kundenkontoseite, um das Problem zu dokumentieren. Der Screenshot zeigt den Namen des Kunden im UI-Header, seine E-Mail-Adresse in den Kontoeinstellungen und seine Plandetails.
Der Artikel wird in der internen Wissensdatenbank veröffentlicht. Einhundertfünfzig Support-Mitarbeiter können ihn nun einsehen. Zwölf Auftragnehmer beim externen Helpdesk können ihn ebenfalls sehen. Der Artikel ist nützlich. Er zeigt, wie dieser Sonderfall zu behandeln ist. Jeder Mitarbeiter, der künftig auf diese Einstellung trifft, wird ihn lesen.
Drei Jahre später enthält die Wissensdatenbank 847 solcher Artikel. Jeder enthält Screenshots von Kundenkonten. Die abgebildeten Kunden haben dieser Zweitnutzung ihrer Daten nicht zugestimmt. Die meisten wissen nicht, dass ihre Daten dort gespeichert sind.
Das ist kein kleines Problem. Es wächst mit jedem neuen Artikel.
DSGVO-Risiken: Warum das wichtig ist
Die DSGVO-Analyse für Screenshots in Wissensdatenbanken ist klar.
Datensparsamkeit (Art. 5 Abs. 1 lit. c): Personenbezogene Daten müssen „dem Zweck angemessen und erheblich sowie auf das notwendige Maß beschränkt" sein. Ein Wissensdatenbank-Artikel über Kontoeinstellungen benötigt nicht den echten Namen und die E-Mail-Adresse des Kunden. Ein verpixelter Screenshot erfüllt den Zweck ebenso gut. Die Aufnahme echter Kundendaten ist nicht erforderlich.
Zweckbindung (Art. 5 Abs. 1 lit. b): Daten, die für einen Zweck — Kundenservice — erhoben wurden, dürfen ohne Rechtsgrundlage nicht für einen anderen Zweck — interne Prozessdokumentation — weiterverwendet werden. Kontodaten wurden für die Leistungserbringung erhoben, nicht für interne Dokumentation. Das sind zwei verschiedene Verarbeitungszwecke. Die Nutzung derselben Daten für beide erfordert eine Rechtsgrundlage, die die meisten Teams nicht eingerichtet haben.
Zugriffskontrolle (Art. 5 Abs. 1 lit. f und Art. 32): Geeignete technische Maßnahmen müssen personenbezogene Daten schützen. Kundenkonto-Screenshots in einer Wissensdatenbank, die für alle 150 Mitarbeiter und Auftragnehmer — auch für solche ohne Zugang zum zugrunde liegenden Kontosystem — zugänglich ist, stellen einen zu breiten Zugang dar.
Recht auf Löschung (Art. 17): Eine betroffene Person hat das Recht, ihre Daten „unverzüglich" löschen zu lassen. Wenn ihre Daten in 23 Wissensdatenbank-Artikeln als eingebettete Screenshots erscheinen, erfordert der Antrag das Auffinden und Aktualisieren aller 23 Artikel. Das ist ohne ein System schwer. Unser DSGVO-Leitfaden zum Recht auf Löschung erläutert die Schritte im Detail.
Das sind keine Randfall-Interpretationen. Es sind direkte Anwendungen des Verordnungstexts auf eine gängige Praxis.
Der Umgehung der Zugriffskontrollen
Das gravierendste Compliance-Problem mit Confluence-Screenshots ist die Umgehung der Zugriffskontrolle.
Support-Teams nutzen rollenbasierte Zugriffskontrolle (RBAC), um den Zugang zu Kundenkonten einzuschränken. Tier-1-Mitarbeiter sehen grundlegende Kontodaten. Tier-2-Mitarbeiter sehen Abrechnungs- und technische Daten. Manager sehen das vollständige Kontoprofil.
Wenn ein Tier-2-Mitarbeiter einen Wissensdatenbank-Artikel mit einem Screenshot des vollständigen Kundenkontos erstellt, wird dieser Screenshot für alle Nutzer des Tools sichtbar. Tier-1-Mitarbeiter, die keine Abrechnungsdaten sehen sollten, können sie nun einsehen. Auftragnehmer ohne Systemzugang können sie einsehen. Neue Mitarbeiter im Onboarding können sie einsehen.
Der Screenshot umgeht die RBAC-Kontrollen des Kundenkontos. Die persönlichen Daten, die RBAC schützen sollte, sind nun für alle zugänglich.
Das ist kein theoretisches Risiko. Es ist das normale Ergebnis des Dokumentations-Workflows. Der Screenshot liegt dort ohne Ablaufzeit, ohne Zugriffsprotokoll und ohne Prüfpfad.
Praktische Maßnahmen zur Behebung
Für Teams, die dieses Problem bei einem DSGVO-Audit entdecken:
Rückwirkende Behebung:
- Alle Wissensdatenbank-Seiten mit Bildanhängen identifizieren
- PII-Erkennung für alle Bildanhänge durchführen
- Markierte Bilder prüfen: Hochkonfidenz-Treffer kommen in die Prüfwarteschlange
- Für jedes markierte Bild: durch eine bereinigte Version ersetzen oder den Seitenzugang einschränken
- Maßnahmen für die DSGVO-Dokumentation protokollieren
Der Umfang der rückwirkenden Arbeit hängt von der Größe der Wissensdatenbank ab. Bei einer drei Jahre alten Wissensdatenbank eines 50-köpfigen Support-Teams kann die Anzahl der Bilder in die Tausende gehen. Batch-Bildverarbeitung macht dies praktikabel. Die manuelle Prüfung markierter Bilder ist der entscheidende Engpass.
Präventive Kontrollen:
- Alle Support-Mitarbeiter schulen, Screenshots vor der Veröffentlichung zu bereinigen
- Technische Tools bereitstellen: Screenshot-Annotationstools, die Kundennamen vor dem Einfügen unkenntlich machen
- Prüfschritt hinzufügen: ein bestimmter Prüfer überprüft Artikel vor der Veröffentlichung, mit Fokus auf Kunden-PII in Bildern
- Vierteljährlichen Batch-Bildscan aller Confluence-Anhänge durchführen
Mindestvorgabe: Eine Veröffentlichungs-Checkliste: „Alle Kundennamen, E-Mail-Adressen und Konto-IDs in Screenshots vor der Veröffentlichung entfernen oder unkenntlich machen." Nicht automatisiert, aber schafft eine dokumentierte Kontrolle. Für kleine Teams ist das der Ausgangspunkt.
Unsere DSGVO-Compliance-Übersicht bietet den rechtlichen Rahmen. Warum reine Checklisten-Ansätze im großen Maßstab versagen, erklärt dieser Artikel über Richtlinien ohne technische Kontrollen.
Warum das Problem im Laufe der Zeit wächst
Ohne systematische Kontrollen potenziert sich die PII-Exposition in der Wissensdatenbank.
Volumen: Jeder neue Artikel mit einem Kunden-Screenshot erhöht die Gesamtexposition. Je mehr das Support-Team wächst und die Wissensdatenbank sich ausdehnt, desto mehr PII akkumuliert sich. Die Eigenschaften, die diese Tools nützlich machen — einfache Veröffentlichung, Beständigkeit, breiter Zugang — sind genau das, was das PII-Problem verschlimmert.
Vergessene Artikel: Artikel über alte Sonderfälle, die nicht mehr auftreten, bleiben zugänglich. Sie enthalten PII von Kunden, die inzwischen Löschanträge gestellt haben. Niemand prüft einen Artikel, der zuletzt 2022 aktualisiert wurde.
Teamübergreifende Verbreitung: Wissensdatenbanken werden oft abteilungsübergreifend genutzt. Ein Support-Artikel mit Kunden-Screenshots kann als Kontext für eine Feature-Anfrage oder einen Fehlerbericht an das Produktteam, das Engineering-Team oder externe Auftragnehmer weitergegeben werden. Jede Weitergabe vergrößert den Empfängerkreis der persönlichen Daten.
Rückstand bei Löschanträgen: Je mehr Kundendaten sich in der Wissensdatenbank ansammeln, desto komplexer wird die Bearbeitung von Löschanträgen. Ohne ein System gibt es keine zuverlässige Möglichkeit zu bestätigen, dass alle Vorkommen der Daten einer betroffenen Person gefunden und entfernt wurden.
PII in Wissensdatenbanken ist einfacher zu verhindern als zu beheben. Präventive Kontrollen vermeiden das sich verschärfende Sanierungsproblem. Jeder Artikel, der ohne bereinigten Screenshot veröffentlicht wird, ist eine auf die Zukunft verschobene Sanierungsaufgabe.