DSVGO-Löschdaten: Endgültig löschen oder anonymisieren?

[Harry Stahl]

Hi, ich arbeite gerade an einer neuen Version meiner Adressenverwaltung, die u.a. auch ein Formular mit DSVGO-spezifischen Feldern mitliefert.

Mir reichen die in der Anlage sichtbaren Verwaltungsdaten für meine Zwecke. Mich würde aber mal interessieren, ob Ihr aus der Praxis weitere spezifische DSVGO-Daten erfasst und wenn ja, welche?

Ferner: Was macht Ihr mit DSVGO-Personendaten, die zur Löschung anstehen? Löscht Ihr die vollständig aus der Datenbank oder anonymisiert Ihr die? Und wenn Ihr die anomymisiert, nehmt ihr die aus der DB raus und speichert die gesondert oder lasst Ihr die z.B. in Eurer DB durch einen permanent-Filter ausblenden?

[jaenicke]

Wir zeigen unseren Kunden an, wenn alte Daten vorhanden sind, die nach der vorgeschriebenen Aufbewahrungsfrist gelöscht werden sollten. Der Kunde hat dann die Wahl diese zu anonymisieren oder ganz zu löschen. Beim Anonymisieren überschreiben wir schlicht alle Felder, die persönliche Daten enthalten, und lassen die restlichen Daten unverändert für Auswertungszwecke in der Datenbank.

[scrat1979]

Zu deiner zweiten Frage: Ich meine gelernt zu haben, dass die Daten vollständig gelöscht werden müssen sobald die Frist (unterscheidet sich ja je nach vorhandenen Daten, Stichwort: Gesetzliche Aufbewahrungsfrist) abgelaufen ist. Da die Daten (in meinem Fall) auch nach der Frist sehr wichtig sein können wird die betroffene Person daran erinnert sich diese Daten ggf. ausgedruckt aushändigen zu lassen oder - gegen Unterschrift - gespeichert zu lassen. Ein Filter, welche die Daten lediglich ausblendet, ist meinem Verständnis nach nicht DSGVO-konform.

[Harry Stahl]

Eine Anonymisierung kommt laut BfDI einer Löschung gleich, nach meinem Rechts-Verständis benötige ich dafür auch kein Einverständnis des Kunden. Ich würde dann eher fragen, ob seine Kundendaten hier weiter vorgehalten werden sollen (somit Einwilligung), z.B. für einen einfachen Nachweis von Update-Berechtigungen oder ob sie gelöscht werden sollen (und dann wäre es meine interne Entscheidung, ob ich lösche oder anonymisiere).

Mit Ausfiltern meine ich natürlich nur die anonymisierten Daten, die gelöschten sind dann tatsächlich weg.

Damit die Anwender nicht auch die Backups manuell anpassen müssen, will ich auch für die neue Version eine Funktion anbieten, die auch die entsprechenden Löschungen / Anonymisierungen in Backups oder Archiven automatisiert vornimmt (die man letztlich heutzutage nicht mehr auf CD brennen darf, sondern anders revisionssicher speichern muss).

[Harry Stahl]

Zitat von jaenicke:

Beim Anonymisieren überschreiben wir schlicht alle Felder, die persönliche Daten enthalten, und lassen die restlichen Daten unverändert für Auswertungszwecke in der Datenbank.

Was mich interessieren würde: Überschreiben einfach nur z.B. mit XXX oder qualiziert, also Erhalt von Geschlecht und PLZ (ggflls. leicht modifiziert oder nur z.B. auf 5 gekürzt), aber Abänderung in ähnliche Werte für Straße Austausch von Namen und Vornamen mit Random_Namen und Vornamen, etc...

[scrat1979]

Okay, dann habe ich das falsch verstanden

Hier noch ein interessanter Link - falls noch nicht bekannt:

[jaenicke]

Zitat von Harry Stahl:

Was mich interessieren würde: Überschreiben einfach nur z.B. mit XXX oder qualiziert

Wir behalten aktuell keinerlei DSGVO-relevante Details, auch nicht in verallgemeinerter Form, sprich überschreiben die alle mit einem Standardwert.

[himitsu]

Alte Daten auf einem revisionssicheren Laufwerk ala WORM zu anonymisieren dürfte doch etwas schwer werden?

Vor Änderungen geschützte Daten ändern zu wollen.

Zitat:

die man letztlich heutzutage nicht mehr auf CD brennen darf, sondern anders revisionssicher speichern muss

CD als Backup war sowieso eines der schlimmsten Medien.
Klar, bei Filmen auf Band gegenüber CD/DVD klingt es erstmal super, aber da die Dinger sich selten lange halten und teilweise schon nach einem Jahr garnicht mehr lesbar sind, ......

[joachimd]

Anonymisierung reicht, diese muss aber so geschehen, dass keine De-Anonymisierung mehr stattfinden kann. Ich meinte in den USA gab es eine Untersuchung, dass anhand von öffentlich verfügbaren Listen (Wahlverzeichnis, Telefonbuch) und wenigen Merkmalen (Alter, Geschlecht usw) die De-Anonymisierung zu einem extrem hohen Anteil möglich war.
hier u.a. gefunden: https://www.heise.de/hintergrund/Tro...n-4479957.html

[sakura]

Zitat von Harry Stahl:

Damit die Anwender nicht auch die Backups manuell anpassen müssen, will ich auch für die neue Version eine Funktion anbieten, die auch die entsprechenden Löschungen / Anonymisierungen in Backups oder Archiven automatisiert ...

Wichtig ist, dass man hier sowohl im System als auch beim Anwender zw. Backups und Archiven unterscheidet.

Backups dienen der vollständigen Systemsicherung und werden vollständig wieder hergestellt. Die explizite Löschung in Backups, welche regelmäßig erstellt werden, ist nicht nötig, wenn es einen Plan gibt, ggf. nach dem Backup gelöschte Daten erneut zu löschen, ergo eine Sicherung der Löschanforderungen, oder, es eine Möglichkeit gibt, potentiell betroffene Kunden zu informieren, dass die Löschung neu beantragt werden muss.

Archive müssen zeitnah bereinigt werden, wenn es zur Löschanforderung kommt, da diese i.A. direkt über das Live-System angesteuert werden können. Auch wenn eine Teilwiederherstellung direkt möglich ist, muss diese Sicherung bei der Bereinigung berücksichtigt werden.

Das ist zumindest mein aktueller Wissensstand, weitere Infos zu dem sich fortlaufend entwickelndem Feld: https://www.kanzlei.de/rechtsgebiete...bezogene-daten

......

P.S.: Wenn anonymisierte Daten intern noch immer mit einem Live-Datensatz verbunden sind, ist es rechtlich anzweifelbar, dass diese wirklich anonymisiert sind. Diese "gelöschten" Vorgänge sollten vom Live-Datensatz vollständig getrennt werden. Haken an der Sache ist, dass beim nächsten Löschvorgang i.A. keine Verbindung zu den zuvor anonymisierten Daten mehr möglich ist, da diese nicht bestehen darf.
P.P.S.: Anonymisierte Daten lediglich auszublenden kann schnell zu einem erheblichen Testaufwand und leicht zu Fehlern in der Live-Software führen, da das i.A. jede Stelle der Datenabfragen betrifft.