GDPR规定个人数据必须:
这些措施可能包括假名,只要这些目的能够以这种方式实现。如果通过不允许或不再允许识别数据主体的进一步处理来实现这些目的,则应以这种方式实现这些目的。
在正常的工作流程中,这些数据通常是假名的,因为数据库上有一个表格,其中包含个人数据,其ID将在其他数据中用作外键,但如果发生安全漏洞,则数据库被盗个人数据不再是假名。
这是否意味着我们需要另一个包含个人数据的数据库?
修改
增加了第32条
考虑到现有技术水平,实施成本以及处理的性质,范围,背景和目的,以及自然人权利和自由的可能性和严重程度各不相同的风险,控制者和处理方应实施适当的技术和组织措施,以确保适合风险的安全水平,包括酌情包括:
(a)个人资料的假名加密及加密; ......
[除其他外,酌情]
答案 0 :(得分:3)
<强>声明:强> 我不是这个主题的律师或权威,只是从与“假名”用户数据库合作的开发人员的角度分享我对此的看法。
牛津英语词典对假名的定义是:
虚构的名称,尤其是作者使用的名称。 “我是用Evelyn Hervey的笔名写的”
因此,在GDPR的背景下,假名似乎可能意味着某个人的名字由一个不识别个人的个人组成,除非与其他信息相结合。正如您所建议的那样,一个有形的例子可能是用户ID,该用户ID将某个表中的个人数据编入索引。
好的,那么对于你的问题,这个表应该在自己的数据库中隔离吗?
该规定提供了自己的假名定义,在此提供了一些说明:
(5)'假名化'是指个人数据的处理方式,使得个人数据不再能够在不使用其他信息的情况下归属于特定数据主体,只要保留此类附加信息单独进行,并采取技术和组织措施,以确保个人数据不会归因于已识别或可识别的自然人;
为什么要强调分离?
我们知道GDPR关注的是保护用户隐私。
如果假名仅用于允许在假名和他们引用的个人之间进行对应的上下文中,则不提供隐私。
因此需要一些分离。我的解读是,所需的分离程度和执行所需的安全级别应该取决于您持有的数据的敏感性以及系统中某些孤立部分受到损害时所产生的后果减轻。
因此,对于您的示例,如果将个人数据存储在单独的数据库中,无论出于何种原因,允许您将系统的某些离散部分限制为仅访问用户ID,那么如果系统的该部分遭到入侵,则您只暴露用户ID,我们可能期望在GDPR眼中更有利地看待它。