GDPR合规疑问：现有假名化方案失效后是否需单独存储个人数据？

GDPR对个人数据处理有明确要求：

若相关处理目的可通过假名化实现，则可将假名化纳入措施范畴。若处理目的可通过无法识别或不再能够识别数据主体的后续处理实现，则应采用该方式达成目的。

在日常业务流程里，我们常用的假名化做法是：把个人数据存储在数据库（db）的单独表中，以ID作为其他表的外键（foreign key）进行关联。但这里存在一个关键隐患——一旦数据库因安全漏洞被盗，这种关联结构会让攻击者轻易将ID与个人数据对应起来，此时数据就不再具备假名化的属性了。

很多从业者会有这样的疑问：这是否意味着我们需要单独搭建数据库来存储个人数据？

我们结合GDPR第32条（Article 32）的补充内容来分析：

控制者和处理者应结合技术发展水平、实施成本、处理的性质、范围、情境及目的，以及对自然人权利和自由的不同可能性与严重程度的风险，采取适当的技术和组织措施，确保与风险相匹配的安全水平，其中酌情包括：
(a) 个人数据的假名化与加密；……

注意条款里的酌情包括这个核心表述——这说明单独搭建数据库并非强制要求，而是需要结合你的业务实际情况综合判断：

• 如果业务数据泄露风险极高，且单独建库的成本在可接受范围内，那么拆分存储（比如将个人数据放在独立的、权限管控更严格的数据库中，甚至与业务库物理隔离）确实是有效的措施，能大幅降低数据被盗后被关联识别的概率。
• 若单独建库成本过高，也可以通过其他技术/组织措施弥补：比如对个人数据字段进行加密（而非仅依赖ID关联的假名化）、严格限制数据库访问权限、定期开展安全审计、在非必要场景下实现数据脱敏等。

核心逻辑是：GDPR要求的是与风险匹配的安全水平，而非固定的技术方案。单独建库是可选方案之一，但绝非唯一解。你需要先评估自身业务的数据处理风险，再选择最适配的措施组合。

内容的提问来源于stack exchange，提问作者Prescol