GDPR Deletion Request Tracking Paradox - Suppression Lists

Question

I work at a large-ish tech company with hundreds of websites and some large web applications with a very large number of users.

I am planning to propose that we have a central system to track deletion requests to ensure if a person requests we delete their details they are deleted everywhere.

If a database is restored any users deleted record will return so deletion requests cant be one-off requests that are never recorded, we would need a record of users who have asked for their details to be deleted (unless there is a better idea).

It sounds self defeating and likely non-compliant to be storing details of users who have asked for their details to be removed.

It also feels like this is likely a previously invented wheel.

Is there a recommended or widely accepted practice for this?

I was thinking maybe a hash of the users first name, another hash of their surname and lastly a hash of their email address, and development teams could hash emails on their system and check for matches.

Edit: To aid search queries, I found the standard term for this is 'suppression list' after some further googling.

Answer 1

It is exactly the right thing to have a deletion request management system. In fact, given the importance of this function, the timeframes for response, the workflows to coordinate, it is almost certainly necessary.

GDPR does not prevent companies from storing personal details of their users/customers/etc for legitimate purposes. Instead it is intended to generate more thoughtful practices around the management lifecycle typically associated with this sensitive data.

For instance, what teams in companies do to record interactions with different flavors of users is track relevant and often personal details in whatever workflow tool the particular team happens to prefer. Maybe this is Salesforce, or JIRA, or email. Whatever.

This careless sprinkling of personal details around team-specific workflow infrastructure is one of the anti-practices a successful GDPR implementation will ideally deprecate.

So a deletion request management system needs store personal information that is used to match in other systems. It needs to be sufficient to identify the person requesting the deletion. That data can be retained for the duration of its legitimate need. When that need has expired- the deletion workflow is completed- this system is no different from any other. Personal details get deleted from the deletion request management system as well. (The exact policies and timing around this are of course decided by the legal team).

In terms of practices, the likely common practice with databases is scrubbing. IDs of records with scrubbed fields need to be retained, both for future validation and also to support the scrubbing process being applied following a restore of production data from backup.

When it comes to matching, one nit- my understanding as a non-lawyer is that what is considered to be personal information is not just identifying information like first and last name. Personal attributes that may not be identifying but are nevertheless unique and characterizing of a person are also subject to deletion/scrubbing.

Using hashes to efficiently match fields across systems may help, but with names, there are numerous spelling and other variations. Doing this sort of matching is its own data management practice that companies that have had to consolidate customer databases are likely familiar with.