search

openjverein / jverein

Open JVerein - Open Source Vereinsverwaltung
https://openjverein.github.io
GNU General Public License v3.0
41 stars 15 forks source link

DSGVO-konformes Löschen von Mitgliedern mit Buchungen #213

Open mbmueller opened 4 months ago

mbmueller commented 4 months ago

Discussed in https://github.com/openjverein/jverein/discussions/170

Originally posted by **mbmueller** February 27, 2024 Ich würde gerne meine Mitglieder DSGVO-konform löschen, die geht allerdings nicht, da diesem noch Buchungen zugeordnet sind, alle älter als 10 Jahre, die in einem Abschluss erfasst wurden. Habt ihr da einen Workaround? Im Idealfall sogar ein Script oder so?

Dafür müssten wahrscheinlich die Datenbank Konsistenz-Constraints überarbeitet werden, außerdem sollte zumindest gewarnt werden, wenn für das Mitglied noch Buchungen hinterlegt sind, die jünger als 10 Jahre (gesetzliche Aufbewahrungsfrist) sind.

willuhn commented 4 months ago

Unter Umständen ist ein physisches Löschen rechtlich ja auch gar nicht möglich. Wenn ein Mitglied z.B. austritt, hat er ja auch das Recht, dass seine persönlichen Daten gemäß DSVGO gelöscht werden. Dem stehen dann aber die Aufbewahrungsfristen des Finanzamtes gegenüber. Steuerrechtlich relevante Buchungen werden ja durch den Austritt nicht unwirksam.

Aus meiner Sicht müssen die Datensätze ja nicht physisch gelöscht werden. In meinen beruflichen Projekten würde das dann so gelöst:

Damit können die Buchungen erhalten bleiben und verfälschen die Buchhaltung nicht. Es ist aber kein Bezug mehr zur Person vorhanden.

mbmueller commented 4 months ago

Deswegen spreche ich ja auch davon, dass nur Mitglieder komplett gelöscht werden können, wenn die letzte zugeordnete Buchung länger als 10 Jahre zurück liegt. Dann enden nämlich alle Aufbewahrungsfristen und die MÜSSEN daher gelöscht werden. Theoretisch müsste nach 10 Jahren selbst die Kontoverbindung gelöscht werden, da das auch personenbeziehbare Daten sind.

mbmueller commented 4 months ago

Und, doch die Daten müssen auch physisch gelöscht oder zumindest Anonymisiert werden.

willuhn commented 4 months ago

Aus meiner Sicht wäre es aber sinnvoll, das Problem hier gesamtheitlich zu lösen und nicht nur für den Fall, dass die Daten älter als 10 Jahre sind.

Mir ist auch keine steuerrechtliche Löschpflicht bekannt. Personenbezogene Daten müssen gemäß DSGVO gelöscht werden, sobald sie nicht mehr benötigt werden - also nicht erst nach 10 Jahren (hier geht auch Anonymisierung). Steuerrechtliche Daten dürfen nach 10 Jahren gelöscht werden - müssen aber nicht.

mbmueller commented 4 months ago

Das Problem besteht aber ja nur, wenn Buchungen mit dem Mitglied verknüpft sind, daher nach 10 Jahren irrelevant. Wenn keine Buchung verknüpft ist, kann ich das Mitglied ja jederzeit löschen.

willuhn commented 4 months ago

Genau das sage ich doch. Das Problem besteht, wenn das Mitglied auf der einen Seite gelöscht werden soll (aus welchem Grund auch immer) - aber Buchungen existieren, die nicht gelöscht werden dürfen. Genau dafür würde obiger Lösungsansatz helfen.

Alle anderen Fälle (Mitglied hat keine Buchungen bzw. Buchungen dürfen gelöscht werden, weil älter als 10 Jahre) sind kein Problem.

mbmueller commented 4 months ago

Also der Fall, dass die Buchungen älter als 10 Jahre sind ist schon ein Problem, da ich diese Buchungen ja auch nicht löschen kann.

Außerdem verstehe ich es so, dass im Zweifel auch für die Mitgliederdaten eine Aufbewahrungsfrist bestehen könnte bspw. aufgrund der Beitragszahlungen.

willuhn commented 4 months ago

Ja. Das ändert aber am Problem und an der Lösung nichts.

JohannMaierhofer commented 3 months ago

Könnt ihr mir sagen, was ihr mit Buchungen meint? Meint ihr die Sollbuchungen oder die Istbuchungen. Die Sollbuchungen könnte man ja mit dem Mitglied löschen. Dabei bleiben die Istbuchungen erhalten und Buchhaltung stimmt. Wie ich im Diskussionsthread geschrieben habe müßte man nur die Verknüpfung in der DB ändern und man könnte ein Mitglied einfach löschen. Ob das dann ein Schatzmeister macht, egal ob vor oder nach 10 Jahren ist doch seine Verantwortung. Siehe #170

JohannMaierhofer commented 3 months ago

Das mit den Istbuchungen selbst sehe ich als ganz anders Thema. In den Kontoauszügen (Buchungen) tauchen ja auch andere Namen auf die keine Mitglieder sind. Da redet doch auch keiner davon, dass das personenbezogene Daten sind die man irgendwann löschen muss. Man muß die Kontoauszüge eben mindestens die 10 Jahre aufbewahren und ist auch nicht verpflichtet diese danach zu vernichten. Hat man also das Mitglied gelöscht mit all seinen Daten, taucht halt sein Name noch in den Buchungen (Kontoauszug) auf. Dann ist es wie bei jeder anderen Person die in Buchungen auftaucht. Und wenn wir wollen könnten wir natürlich auch zusätzlich einbauen, dass man die Buchungen eines ganzen Geschäftsjahres löschen kann wenn sie älter als 10 Jahre sind und es keine älteren gibt. Also jedes Geschäftsjahr von ganz hinten her löschen. Damit könnte man evtl. Verhindern, dass die Datenbank ins unendliche wächst. Auch zerstört man nicht die Buchhaltung wenn man ein ganzes Geschäftsjahr löscht z.B. Als Kontextmenü der Jahresabschlüsse beim ältesten. Die Frage wäre nur noch bezüglich der Sollbuchungen der Mitglieder aus diesem Geschäftsjahr die dann plötzlich offen sind. Die müsste man dann wohl mit löschen.

willuhn commented 3 months ago

Ein Name allein ist noch nicht DSGVO-relevant, da der nicht hinreichend eindeutig ist. Erst wenn er zusammen mit anderen Daten (z.B. Geburtsdatum) erscheint und damit eindeutig einer Person zugeordnet werden kann, kommen die Anforderungen aus DSGVO zum Tragen. Heisst: Wenn lediglich der Name irgendwo in Buchungen auftaucht, ist das unkritisch. Hier gibt es keinerlei gesetzliche Anforderungen (weder aus steuer- noch datenschutzrechtlichen Gründen) zum Löschen.

Bei den persönlichen Daten des Mitglieds in den Stammdaten handelt es sich hingegen um DSGVO-relevante Daten. Hier gibt es allerdings weder Aufbewahrungs- noch Löschfristen. Sobald ein Mitglied den Verein verlässt oder es aus anderen Gründen nicht mehr mit der Speichrung der Daten einverstanden ist, müssen diese gelöscht werden. Umgehend. Nicht erst nach x Jahren.

Heisst: Bei den Soll-/Istbuchungen ist nur der steuerrechtliche Aspekt der Aufbewahrungspflicht relevant. Sobald hier die Fristen abgelaufen sind, kann man mit den Buchungen machen, was man will. Man kann sie löschen, wenn man möchte, muss aber nicht.

Die offene Frage ist aus meiner Sicht eigentlich nur: Wenn die persönlichen Daten eines Mitgliedes aus o.g. DSGVO-Gründen gelöscht werden müssen, lässt sich das technisch so bewerkstelligen, dass hierbei keine steuerrechtlich relevanten Daten mit gelöscht werden? Wenn ja, kann das Mitglied physisch gelöscht werden. Falls Verknüpfungen zu steuerrechtlichen Daten existieren, muss man schauen, wie man das auflösen kann. Entweder durch NULLen der Fremdschlüssel auf das Mitglied (insofern hierbei keine ungültigen/inkonsistenten Daten entstehen, die dann zu Nullpointern führen) oder andernfalls durch "aus-X-en" der persönlichen Daten, wenn die ID in der Mitgliedstabelle erhalten bleiben muss.

JohannMaierhofer commented 3 months ago

Danke für die Erklärung, die finde ich sehr gut verständlich. Wenn ich mir die gespeicherten mitgliedsbezogenen Daten anschaue (siehe #170) dann denke ich, dass mann sie alle löschen kann. Das einzige wären Spendenbescheinigungen, aber ich glaube die muss mann sowieso entweder ausgedruckt oder elektronisch z.B. als PDF aufbewahren. Damit spricht meiner Ansicht nichts dagegen die Mitglieder mit den deren personenbezogenen Daten zu löschen. Eben auch Sollbuchungen aber keine Buchungen in den Konten.

Wie ich in #170 geschrieben habe müßte man wohl einige Definitionen ändern. Und meine Frage zur Buchung Tabelle. Warum wird beim Löschen der Spendenbescheinigungen die Referenz in der Buchungen Tabelle automatisch auf null gesetzt, also das löschen erlaubt, aber das Löschen der referenzierten Sollbuchung verhindert. Hier müsste die Referenz genauso automatisch auf null gesetzt werden. In der Datenbank Definitionen der beiden Referenzen sehe ich keinen Unterschied.

mbmueller commented 3 months ago

Selbstverständlich fällt ein Name (zumindest der vollständige) unter die DSGVO, da diese auf jeden Fall Rückschlüsse auf die Person zu lassen, inwiefern aber ein Verein ein berechtigtes Interesse an der Aufbewahrung der Buchungsbelege auch nach Ablauf der Aufbewahrungsfrist hat wäre mMn zu diskutieren, ob es hierzu Urteile gibt kann ich nicht sagen.

Trotzdem sollte die Software zumindest die Löschung aller Daten unterstützen, für die keine Aufbewahrungsfristen bestehen. Hinzu kommt, das wir zumindest in unserem Verein auch alle Buchungsbelege, für die die Aufbewahrungsfrist abgelaufen ist aufgrund eines Beschlusses der Mitgliederversammlung unseres Dachverbandes zu löschen haben, bislang ist dies in JVerein aber nicht möglich.

willuhn commented 3 months ago

Selbstverständlich fällt ein Name (zumindest der vollständige) unter die DSGVO, da diese auf jeden Fall Rückschlüsse auf die Person zu lassen

Dann muss ich bei der Weiterbildung, in der ich zum Datenschutzbeauftragten gemäß DSGVO durch den TÜV Nord ausgebildet wurde (diese Rolle habe ich seither bei meinem Auftraggeber) wohl etwas falsch verstanden haben.

mbmueller commented 3 months ago

https://commission.europa.eu/law/law-topic/data-protection/reform/what-personal-data_de Ich kann mit einem vollen Namen (je nach Einzigartigkeit) ja definitiv eine Person identifizieren.

https://stiftungdatenschutz.org/ehrenamt/datenschutz-im-verein-kompakt/buchhaltung Die Stiftung Datenschutz ist übrigens der Auffassung, das Buchhaltungsdaten, bei denen keine Aufbewahrungspflicht mehr besteht, gelöscht werden MÜSSEN.

JohannMaierhofer commented 3 months ago

Und meine Frage zur Buchung Tabelle. Warum wird beim Löschen der Spendenbescheinigungen die Referenz in der Buchungen Tabelle automatisch auf null gesetzt, also das löschen erlaubt, aber das Löschen der referenzierten Sollbuchung verhindert. Hier müsste die Referenz genauso automatisch auf null gesetzt werden. In der Datenbank Definitionen der beiden Referenzen sehe ich keinen Unterschied.

Ich habe den Grund gefunden. In SpendenbescheinigungImpl wird bei delete explizit die Referenz in der Buchung auf null gesetzt. Für das automatische null setzen der beiden Referenzen beim Löschen des Mitglieds muss also die Definition von Einschränkungen auf null setzen geändert werden.

JohannMaierhofer commented 1 month ago

Gibt es hier noch Diskussionsbedarf? Ich denke, dass es keinen Grund gibt warum man ein Mitglied nicht löschen darf. Teilweise geht es ja auch heute schon.

mbmueller commented 1 month ago

Gibt es hier noch Diskussionsbedarf? Ich denke, dass es keinen Grund gibt warum man ein Mitglied nicht löschen darf. Teilweise geht es ja auch heute schon.

Sollte nach der Implementierung so passen, deswegen schließe ich das Issue mal. Sollte es woanders noch zu Problemen kommen, würde ich ein neues spezifisches Issue öffnen. Wann geht denn die Änderung live auf die Release Version?

JohannMaierhofer commented 1 month ago

Meine Implementierung ist überhaupt noch nicht übernommen. Es fehlen die Reviews. Könntest du eines machen?

mbmueller commented 1 month ago

Meine Implementierung ist überhaupt noch nicht übernommen. Es fehlen die Reviews. Könntest du eines machen?

Im Moment leider nicht, evtl komm ich im August, nach der Klausurenphase dazu. Bei mir hats meine IDEA zerschossen und habe gerade keine Zeit das zu fixen.

mbmueller commented 1 month ago

Lass dann aber das Issue bis dahin offen, bin irgendwie davon ausgegangen, dass deine PRs schon gemerged wären