Source: https://www.bfdi.bund.de/bfdi_forum/showthread.php?t=9001&s=57cd6a3c87f60144c6b2083378548ee3&p=54928
Timestamp: 2018-11-19 22:08:23
Document Index: 367447064

Matched Legal Cases: ['Art. 6', 'Art. 6', 'Art. 6', 'Art. 6', 'Art. 6', 'Art. 11', '§ 35']

Logs und Dumps in der Knowledgebase eines Ticketsystems
Thema: Logs und Dumps in der Knowledgebase eines Ticketsystems
26.10.2018, 14:44 #1
Ich bin auf eine, wie ich finde, interessante Rechtsfrage gestoßen.
Nehmen wir mal den Sachverhalt an, dass es einen IT-Dienstleister gibt, der für seine Kunden Supportleistungen anbietet und dies über ein Ticketsystem koordiniert. Zur Diagnose werden Logs und/oder Dumps erzeugt und den Tickets als Anhang beigefügt. In diesen Dateien können auch personebezogene Daten von Betroffenen stecken, die man zur Bearbeitung nicht braucht, aber aus technischen Gründen nicht rausbekommt, weil man nicht im Vorfeld weiß, wo welche Art von Daten auftauchen können und/oder die Datei schlicht als Binary Blob (z.B. Core Dump) vorliegt, bei dem eine Modifizierung dann die Nutzbarkeit zur Fehlerdiagnose aufheben würde.
So weit würde ich noch sagen, das hält sich alles im Rahmen einer klassischen AV, kann man dokumentieren und vertraglich absichern, alles ok.
(1) Wie ist das aber zu beurteilen, wenn der Dienstleister die Tickets im Rahmen einer KnowledgeBase aufbewahren möchte, oder sogar muss, um bei zukünftigen Problemen die Lösungswege aus älteren Tickets rekonstruieren zu können - und wenn hierfür auch die angehängten Logs/Dumps erforderlich sind?
(2) Und was passiert, wenn ein Betroffener beim Kunden einen Anspruch auf Löschung geltend macht - aber weder der Dienstleister noch der Kunde wissen, ob dessen Daten auch in Dumps oder Logs enthalten sind?
Meine bisherigen Überlegungen dazu (ich will mir ja nicht vorwerfen lassen, nicht selbst nachgedacht zu haben):
zu (1): Für mich stellt sich hier zunächst die Frage, ob die KnowledgeBase noch Teil der AV mit dem Kunden ist oder ob sie nicht vielmehr eine eigene Verarbeitung des Dienstleisters darstellt. Ich tendiere zu Letzterem, da in der KnowledgeBase die Daten sämtlicher Kunden zusammenfließen und der Zweck der Verarbeitung doch primär dem Dienstleister selbst zugute kommt - und erst mittelbar dem Kunden. Es gibt eine gewisse Nähe zu der Facebook Fanseiten-Konstellation (auch hier kommt dem Kunden mittelbar das zugute, was der Dienstleister mit Daten anstellt, die auf Betreiben des Kunden an den Dienstleister gelangen). Im Ergebnis könnte man daher wohl eine gemeinsame Verantwortlichkeit zwischen dem Dienstleister und dem Kunden jedenfalls für die vom Kunden bereitgestellten Daten konstruieren (und vertraglich absichern).
Bei der Bestimmung der Rechtsgrundlage komme ich ins Straucheln: Art. 6 (I) f DSGVO ist wie immer sehr zugänglich, aber liegt hier nicht eine Zweckänderung vor? Überhaupt, rechtlich gesehen findet ja ein Wechsel der verantwortlichen Stelle statt, haben wir dann an dieser Stelle auch eine eigene Erhebung durch den Dienstleister? Oder kann man ggf sogar Art. 6 (IV) DSGVO hinzuziehen - nur, was wäre dann die ursprüngliche Rechtsgrundlage?
Ich würde hier argumentieren, dass keine neue Erhebung vorliegt, sondern dass die Daten durch den Dienstleister schlicht auf der Grundlage von Art. 6 (I) f DSGVO verarbeitet werden. Der Wechsel der verantwortlichen Stelle müsste m.E. ein "Herüberstrahlen" der Rechtsgrundlage des Kunden im Wege der AV verhindern. Das würde dann aber auch den Rückgriff auf Art. 6 (IV) DSGVO verwehren. Denn für den Absatz 4 bräuchten wir ja eine ursprüngliche Rechtsgrundlage, die originär beim Dienstleister als bis dato Auftragsverarbeiter ja gar nicht vorlag.
Ich würde daher (gefühlt recht wackelig) zu dem Ergebnis kommen, dass die weitere Verarbeitung der Daten durch den Dienstleister als eigene Verarbeitungstätigkeit nach Art. 6 (I) f DSGVO grundsätzlich möglich ist, sofern nicht die Interessen des Betroffenen überwiegen.
Wie das ganze mit den Transparenzpflichten in Einklang zu bringen ist, sehe ich derzeit aber noch nicht (wer muss von wem wie informiert werden - und wie soll das überhaupt gehen?).
zu (2): Das Interessante an dieser Konstellation ist für mich, dass die personenbezogenen Daten letztlich nur unerwünschtes aber notwendiges Beiwerk sind und die Beteiligten einen unverhältnismäßigen Aufwand betreiben müssten, herauszufinden, was für Daten und wessen Daten in welchen Dateien stecken. In diesem Prozess würden dann allein zum Zweck der Einhaltung der DSGVO die personenbezogenen Daten erst herausgearbeitet und überhaupt aktiv zur Kenntnis genommen werden. Das wirkt für mich etwas widersinnig und erinnert etwas an den Gedanken hinter Art. 11 (I) DSGVO, wobei es hier aber nicht um die Re-Identifizierung geht. Um einen Löschungsanspruch effektiv durchsetzen zu können, müsste der Dienstleister aber wissen, wo welche Daten sind. Eine Ausnahme wegen Unverhältnismäßigkeit habe ich nur für die nicht automatisierte Speicherung gefunden (§ 35 BDSG). Da man einem Löschungsanspruch nicht sinnvoll entsprechen kann, scheitert der Prozess wohl an dieser Stelle.
Zusammengefasst neige ich daher dazu, von einer Aufbewahrung von Logs/Dumps in Tickets als KnowledgeBase abzuraten, solange man die Betroffenenrechte nicht gewährleisten kann. Wie seht Ihr den Sachverhalt?
Das Thema in ähnlicher Form (Bereitstellung von Datensicherungen zur Fehleranalyse) hatten wir bei uns auch schon dikutiert mit dem aus meiner Sicht recht eindeutigen Ergebnis:
Es handelt sich um eine Zweckänderung (wie auch oben schon steht). Dafür bedarf es wieder einer Rechtsgrundlage, z.B. Einwilligung und Einhaltung Informationspflichten sowie Beachtung Widerruf/Widerspruch. Das ist uns die Sache nicht wert, Datensicherungen zu horten.
Mit Abschluss der Fehleranalyse ist der ursprüngliche Zweck der Verarbeitung entfallen und die Daten sind zu löschen. Wenn für eigene Zwecke (Knowledge-Base) weiterverarbeitet wird, kann man das zwar machen - aber vorher anonymisieren. Damit sind die personenbezogenen Daten raus, es wäre nun allerdings noch abzuklären, ob das Aufbewahren der restlichen Daten nicht gegen vertragliche Pflichten verstößt (Geschäftsgeheimnisse enthalten u.ä.).
Wir handhaben das so, dass für Fälle einer längeren Bearbeitungsdauer vom Kunden die Genehmigung für eine längere Aufbewahrung eingeholt wird, ansonsten wird täglich automatisch gelöscht. Für die KB reichen auch kleine Muster ohne pbD oder einfach die Beschreibung des Problems + Lösung.
29.10.2018, 14:30 #3
Vielen Dank für Ihre Einschätzung. Im Ergebnis würde ich natürlich gerne einen Weg finden, die Informationen zur Fehleranalyse im Rahmen der KnowledgeBase rekonstruierbar (und damit verfügbar) zu halten... aber ich sehe derzeit auch keine Möglichkeit, das datenschutzkonform umzusetzen.
Einführung eines Datawarehouse in der öffentlichen Verwaltung
Von CUEBALL im Forum Arbeitnehmerdatenschutz
Letzter Beitrag: 09.10.2017, 02:56
Bestellung eines betrieblichen Datenschutzbeauftragten in der Schweiz
Von iNerd im Forum Europa, Internationales
Letzter Beitrag: 27.01.2016, 12:08
Fragen rund um den Einsatz eines Task- und Projekt-Management-Tools in der Cloud
Von a.b.2015 im Forum AV Auftragsverarbeitung
Letzter Beitrag: 28.07.2015, 02:46
Wichtigkeit der europäischen Werte und eines internationalen Konsens
Von Feingeistnotwendigkeit im Forum Europa, Internationales
Letzter Beitrag: 22.05.2015, 12:06
US Provider sollen zwei Jahre die Logs aufbewahren
Von AnneBeck im Forum Europa, Internationales
Aktuelle Uhrzeit: Es ist jetzt 23:08 Uhr.