Deletion that has to reach everywhere.
The right to erasure, Art. 17, gives people the right to have their personal data deleted in defined circumstances. Where storage limitation is about how long you keep data, erasure is about whether you can actually remove it on request, and that is a property of your delete path: it works only if it reaches every place a person's data lives.
The shapes the same control failure takes.
Erasure breaks when a copy of personal data sits somewhere the delete path does not reach. The recurring shapes:
A new store is not wired into deletion
A change adds a place personal data lives (a cache, a search index, a second database, an export) and the delete-my-account path is not updated to clear it, so a copy survives.
A delete becomes a soft delete
A real delete is changed to a flag (a deleted_at column) so the personal data is still present, which does not satisfy erasure.
Deletion is partial
The main record is deleted but related personal data in other tables, logs, or message queues is left behind.
A processor is never told to delete
Data was sent to a third-party processor, and the deletion is not propagated to them, so a downstream copy persists.
Erasure is not actually reachable
There is no working path to delete a given person's data at all, only a manual or ad-hoc process that does not scale and is easy to get wrong.
A new copy with no path to delete it.
A people-search feature adds a search index of user profiles, written on every update. It works. But the account-deletion path is not updated to clear the index, so after an erasure request the person is gone from the database and still in the index.
async function onUserUpdated(user: User) { await db.users.save(user)+ await searchIndex.upsert({ id: user.id, name: user.name, email: user.email })}This adds a new copy of the user's profile (name, email) to a search index, but the account-deletion path does not clear it, so an erasure request will not reach it. Art. 17 (right to erasure) expects deletion to reach every store of the person's data. Update the delete-account path to remove the user from the index too, and check for any other new copy.
Erasure is tested against every copy.
A data-protection review checks that an erasure request actually removes a person's data everywhere it is held, not just from the primary database: caches, search indexes, backups (subject to their own accepted handling), analytics, and third-party processors. The gap is usually a store added in code without updating the delete path, which is exactly the kind of change a review of the diff can catch before it ships.
A review, not your DPO.
heygrc flags changes that touch the right to erasure and cites the article so the fix happens in the pull request. It does not handle data-subject requests or render a legal determination. It catches the moment a new copy of personal data is added without a path to delete it, at the diff. heygrc is in early access.