Verwijdering die overal moet bereiken.
Het recht op vergetelheid, Art. 17, geeft mensen het recht om hun persoonsgegevens te laten wissen in gedefinieerde omstandigheden. Waar bewaartermijnen gaan over hoe lang je gegevens bewaart, gaat vergetelheid over of je ze daadwerkelijk kunt verwijderen op verzoek, en dat is een eigenschap van je delete-pad: het werkt alleen als het elke plek bereikt waar de persoonsgegevens van een persoon staan.
The shapes the same control failure takes.
Vergetelheid mislukt als een kopie van persoonsgegevens ergens staat waar het delete-pad niet bij kan. De terugkerende patronen:
Een nieuwe opslag is niet gekoppeld aan verwijdering
Een wijziging voegt een plek toe waar persoonsgegevens worden opgeslagen (een cache, een zoekindex, een tweede database, een export) en het pad voor 'mijn account verwijderen' is niet bijgewerkt om deze leeg te maken, waardoor een kopie blijft bestaan.
Een verwijdering wordt een soft delete
Een echte verwijdering wordt veranderd in een vlag (een kolom deleted_at), waardoor de persoonsgegevens nog steeds aanwezig zijn, wat niet voldoet aan het recht op vergetelheid.
Verwijdering is gedeeltelijk
Het hoofdrecord wordt verwijderd, maar gerelateerde persoonsgegevens in andere tabellen, logs of berichtenwachtrijen blijven achter.
Een verwerker wordt niet op de hoogte gesteld om te verwijderen
Gegevens zijn verzonden naar een derde verwerker, en de verwijdering wordt niet doorgegeven, waardoor een kopie stroomafwaarts blijft bestaan.
Vergetelheid is niet bereikbaar
Er is helemaal geen werkend pad om de gegevens van een bepaalde persoon te verwijderen, alleen een handmatig of ad-hocproces dat niet opschaalbaar is en gemakkelijk fout gaat.
Een nieuwe kopie zonder pad om deze te verwijderen.
Een functie voor het zoeken naar personen voegt een zoekindex toe met gebruikersprofielen, die bij elke update wordt bijgewerkt. Het werkt. Maar het pad voor accountverwijdering is niet bijgewerkt om de index leeg te maken, dus na een verzoek tot vergetelheid is de persoon verdwenen uit de database en nog steeds aanwezig in de index.
async function onUserUpdated(user: User) { await db.users.save(user)+ await searchIndex.upsert({ id: user.id, name: user.name, email: user.email })}Dit voegt een nieuwe kopie van het gebruikersprofiel (naam, e-mail) toe aan een zoekindex, maar het pad voor accountverwijdering verwijdert deze niet, waardoor een verzoek tot vergetelheid deze niet bereikt. Art. 17 (recht op vergetelheid) verwacht dat de verwijdering elke opslag van de persoonsgegevens bereikt. Werk het pad voor accountverwijdering bij om de gebruiker ook uit de index te verwijderen en controleer op andere nieuwe kopieën.
Vergetelheid wordt getest tegen elke kopie.
Een review voor gegevensbescherming controleert of een verzoek tot vergetelheid de persoonsgegevens van een persoon daadwerkelijk overal verwijdert waar deze worden opgeslagen, niet alleen uit de primaire database: caches, zoekindexen, back-ups (onderhevig aan hun eigen geaccepteerde afhandeling), analytics en derde verwerkers. De leemte is meestal een opslag die in code is toegevoegd zonder het delete-pad bij te werken, en dat is precies het soort wijziging dat een review van de diff kan opvangen voordat deze wordt geïmplementeerd.
Een review, niet je FG.
heygrc markeert wijzigingen die het recht op vergetelheid raken en verwijst naar het artikel, zodat de oplossing in de pull request wordt doorgevoerd. Het verwerkt geen verzoeken van betrokkenen of doet geen juridische beoordeling. Het vangt het moment op waarop een nieuwe kopie van persoonsgegevens wordt toegevoegd zonder pad om deze te verwijderen, in de diff.