GDPR化名

Question

GDPR规定，个人数据必须：

这些措施可以包括化名，但条件是这些目的可以以这种方式实现。如果这些目的可以通过不允许或不再允许识别数据主体的进一步处理来实现，则应以这种方式实现这些目的。

在正常工作流程中，这些数据通常是化名的，因为数据库上有一个带有ID的数据库表，该表的ID将在其他数据库中用作外键，但在发生安全漏洞时，如果数据库被窃取，则个人数据不再是化名。

，这是否意味着我们需要另一个带有个人数据的数据库？

编辑

增加第32条

考虑到技术现状、执行费用、处理的性质、范围、背景和目的，以及自然人权利和自由可能和严重程度不同的风险，控制器和处理器应采取适当的技术和组织措施，确保适当程度的安全，除其他外，包括酌情： (a)个人资料的化名及加密；.

，除其他外，包括适当的

Answer 1

免责声明:我不是这个话题的律师或权威，我只是从一个使用“化名”用户数据库的开发人员的角度来分享我对这个问题的想法。

“牛津英语词典”对化名的定义是：

假名虚构的名字，尤指作者使用的名字“我用伊芙琳·埃尔维的笔名写的”

因此，在GDPR的背景下，一个化名似乎意味着某个人的化名，除非与其他信息相结合，否则不会识别此人。如您所建议的那样，一个具体的例子可能是一个用户ID，它在某个表中索引个人数据。

好的，那么对于您的问题，这个表应该在它自己的数据库中隔离吗？

该条例对化名作了自己的定义，在此作了一些澄清：

(5)“化名”是指处理个人数据的方式，即不使用附加信息就不能再将个人数据归于某一特定数据主体；规定，此类补充信息必须单独保存，并须采取技术和组织措施，以确保个人数据不属于可识别或可识别的自然人；

为什么强调分离？

我们知道，GDPR关注的是保护用户隐私。

如果假名仅在允许化名与所提及的个人之间进行对应的上下文中使用，则不提供任何隐私。

所以我们需要分开。我的解读是，所需的分离程度和强制执行所需的安全级别应该取决于您所持有的数据的敏感性，以及在系统某些孤立部分受到损害时所能提供的辐射缓解效果。

因此，对于您的例子，如果将个人数据存储在单独的数据库中，不管出于什么原因，您可以将系统中的某些独立部分限制在只访问用户ID的范围内，那么如果系统的该部分受到破坏，您只公开了用户ID，我们可能会期望在GDPR的眼里，用户ID会被更好地查看。