Die Datenschutzerklärung steht. Der „Account löschen"-Knopf funktioniert. Der Nutzer klickt, sein Konto verschwindet, alles gut.
Nur: Sind seine Daten wirklich weg? Bei einer App mit vielen Datenbank-Collections lautet die Antwort erschreckend oft nein. Und meistens hat niemand geschlampt; die Lücke entsteht beim Wachsen, ganz von allein.
Wie die Lücke entsteht
Der Ablauf ist immer derselbe, und er ist völlig unspektakulär:
- Ein neues Feature wird gebaut. Es schreibt Nutzerdaten in eine neue Collection.
- Das Feature funktioniert. Tests grün. Ausgeliefert.
- Der Löschpfad wurde nicht angefasst — er kennt die neue Collection schlicht nicht.
Niemand hat einen Fehler gemacht. Es hat nur niemand daran gedacht. Und weil nichts kaputtgeht, fällt es auch nicht auf — der Löschknopf tut ja was, nur eben nicht alles.
Art. 17 DSGVO — das Recht auf Löschung — verlangt nicht, dass der Account verschwindet. Es verlangt, dass die personenbezogenen Daten verschwinden. Das ist ein Unterschied, den der Code kennen muss.
Was ein Scan über eine echte App fand
Wir haben unsere eigene App geprüft — systematisch, nicht stichprobenartig. Das Ergebnis war ernüchternd: rund 140 Collections, die Nutzerdaten schreiben, ohne dass der Löschpfad sie mitnimmt.
In einem Projekt, das von Anfang an mit Datenschutz im Blick gebaut wurde. Von jemandem, der weiß, was Art. 17 verlangt. Mit Unkenntnis hat das nichts zu tun. Es ist das Wachstum: Jedes neue Feature ist eine neue Gelegenheit, den Löschpfad zu vergessen.
Warum man das nicht manuell prüfen kann
Der naheliegende Ansatz — „schauen wir mal durch" — skaliert nicht. Bei über 200.000 Zeilen Code ist Durchschauen kein Prüfen, sondern Hoffen. Man braucht zwei Listen und einen Abgleich:
- Liste A: Alle Stellen, die Nutzerdaten schreiben — welche Collection, welches Feature.
- Liste B: Alles, was der Löschpfad tatsächlich anfasst.
- Die Differenz ist die Lücke.
Genau das machen wir automatisiert, vor jedem Release. Ein Skript überliest keine Collection Nummer 137, weil ihm langweilig wird — ein Mensch, der 200 Ordner durchklickt, schon.
Ein Befund ist ein Prüfauftrag, kein Urteil
Wichtig, sonst erzeugt so ein Scan nur Rauschen: Ein statischer Scan sieht nicht alles. Wenn eine serverseitige Funktion beim Löschen aufräumt, taucht das im App-Code nicht auf — der Scan meldet trotzdem eine Lücke.
Deshalb behandeln wir jeden Treffer als „das muss jemand anschauen", nicht als„das ist kaputt". Ein Werkzeug, das Fehlalarme als Fakten verkauft, wird nach zwei Wochen ignoriert — und dann nützt es niemandem mehr.
Der zweite blinde Fleck: Auskunft und Export
Art. 17 bekommt die Aufmerksamkeit. Art. 15 und Art. 20 — Auskunftsrecht und Datenübertragbarkeit — werden oft ganz vergessen. Ein Nutzer darf nicht nur verlangen, dass seine Daten gelöscht werden. Er darf auch verlangen, sie zu bekommen.
Wenn diese Anfrage kommt und es keinen Export-Pfad gibt, wird aus einer Ein-Klick-Sache ein manueller Datenbank-Ausflug. Deshalb prüfen wir im selben Durchgang mit, ob der Pfad überhaupt existiert.
Kurz gesagt
Wenn Ihre App mehr als eine Handvoll Datenbank-Collections hat, ist Ihr Löschpfad wahrscheinlich lückenhaft. Der Grund ist banal: Feature und Löschpfad werden von verschiedenen Leuten zu verschiedenen Zeiten gebaut, und beim Wachsen fällt die Lücke niemandem auf. Sie meldet sich ja nicht.
Der Scan dafür ist einmal Arbeit und läuft danach automatisch mit. Oder man wartet, bis jemand fragt. Das ist meistens der schlechtere Zeitpunkt.