我在一家拥有数百个网站和一些拥有大量用户的大型 Web 应用程序的大型科技公司工作。
我计划建议我们有一个中央系统来跟踪删除请求，以确保如果有人要求我们删除他们的详细信息，他们会在任何地方被删除。
如果数据库恢复，任何用户删除的记录都将返回，因此删除请求不能是从未记录过的一次性请求，我们需要记录要求删除其详细信息的用户（除非有更好的主意）。
存储要求删除其详细信息的用户的详细信息听起来很自欺欺人，并且可能不合规。
感觉这很可能是以前发明的轮子。
是否有推荐或广泛接受的做法？
我在想可能是用户名字的哈希值，他们姓氏的另一个哈希值，最后是他们的电子邮件地址的哈希值，开发团队可以在他们的系统上对电子邮件进行哈希处理并检查匹配项。
编辑：为了帮助搜索查询，经过进一步的谷歌搜索，我发现这个标准术语是“抑制列表”。
拥有一个删除请求管理系统是完全正确的。事实上，鉴于此功能的重要性、响应的时间框架、协调的工作流程，几乎可以肯定它是必要的。
GDPR 不会阻止公司出于合法目的存储其用户/客户/等的个人详细信息。相反，它旨在围绕通常与此敏感数据相关的管理生命周期生成更周到的实践。
例如，公司中的团队为记录与不同类型用户的交互所做的工作是在特定团队碰巧喜欢的任何工作流工具中跟踪相关的并且通常是个人详细信息。也许这是 Salesforce、JIRA 或电子邮件。任何。
围绕团队特定的工作流基础设施粗心地散布个人细节是成功实施 GDPR 理想情况下会弃用的反做法之一。
因此，删除请求管理系统需要存储个人信息，以便在其他系统中进行匹配。它需要足以识别请求删除的人。该数据可以在其合法需要期间保留。当该需求到期时-删除工作流程完成-该系统与其他系统没有什么不同。个人详细信息也会从删除请求管理系统中删除。（这方面的确切政策和时间当然由法律团队决定）。
在实践方面，数据库可能的常见做法是擦洗。需要保留具有已清理字段的记录 ID，以供将来验证以及支持在从备份恢复生产数据后应用的清理过程。
在匹配方面，我作为非律师的一个基本理解是，被认为是个人信息的不仅仅是识别信息，如名字和姓氏。可能无法识别但仍然是唯一的个人属性和一个人的特征也可能会被删除/擦洗。
使用散列有效地匹配跨系统的字段可能会有所帮助，但是对于名称，存在许多拼写和其他变体。进行这种匹配是必须整合客户数据库的公司可能熟悉的自己的数据管理实践。