GDPR 数据主体权利请求流程图(受理到关闭)

GDPR 数据主体权利请求流程图:登记并启动一个月计时、核验身份、判定所行使的权利、检索系统与受托处理方、遮蔽第三方数据、复杂时延期,最后答复并归档决定。

运作方式

  1. 把泳道改成你们自己的角色

    把数据主体、隐私受理团队、数据保护官、法务和系统与数据责任人换成你们真实存在的角色。很多组织既没有数据保护官,也没有内部法务:那就把这两条泳道并成一个隐私负责人,并写明疑难判断时你们会咨询的外部律所,而不是在图上画一个从不评审的评审者。无论规模多大,系统与数据责任人这条泳道都要单独留着,因为检索是由运行这些系统的人来做的,而不是由流程的主人来做的。

  2. 把请求可能进入的渠道全部列出来

    请求不必是书面的,不必提到 GDPR,也不必直接送到隐私团队。把它真实走过的每一条路写下来——客服邮箱、联系表单、社交媒体、电话、纸质信函、前台、直属上级、律师函——并给每一条指定一个责任人,其指令只有一条:当天转出,不做判断。然后确定登记请求的那唯一一处地方,让收到日期存在于一个系统里,而不是存在于某个人的已发送邮件里。

  3. 在用到之前先把身份核验规则写好

    提前决定每一类请求人分别要过哪一道核验:已登录的账号持有人、离职员工、持授权委托书代为行使的第三方、替未成年子女提出请求的家长。写明哪种材料能消除哪一种疑点、保存多久、何时删除。然后把你们的立场记录下来:索要身份证明材料期间是否暂停计时——各监管机构在这一点上口径并不一致,你们采取哪一种口径需要保持一致并且落在纸面上,而不是一件一件临时决定。

  4. 把检索所依赖的系统清单建起来

    “检索系统、备份与受托处理方”这一步的质量,取决于它背后的那份清单。把处理活动记录变成一份检索清单,逐一写明每个应用系统、邮箱、共享盘、工单系统、监控录像范围、通话录音归档和受托处理方,以及由谁执行检索、需要多长时间。再加上你们对备份与归档的既定立场。有清单,同一件请求做两次才会得到同样的结果——而这恰恰是监管机构真正会去追问的地方。

  5. 定下遮蔽与豁免的标准

    把你们的判断标准挂到“审阅第三方数据与法律保密特权”上,让遮蔽不再靠临场发挥:什么情况下第三方的数据可以提供、什么情况下要去征求同意、什么情况下不经同意提供也属合理,以及法律保密特权由谁、以何种方式主张。列出你们在本地法域实际依据的豁免情形,并要求为每一处扣留的内容记录理由。没有书面理由的遮蔽,几个月之后交给一个当时不在场的人,是解释不清的。

  6. 在一个月之内排好内部时点,然后发布

    从期限倒推,给每一步各自的目标日期:第十天检索完成,第十八天审阅完成,第二十四天签发。法定的一个月是外沿,不是计划,而延期的决定必须在还来得及告知对方的时候做出。然后带着这张图与受理团队、一位系统负责人和签发答复的那个人一起走一遍,按他们实际的做法改正,再发布该版本并保留此前的版本。

常见问题

GDPR 数据主体权利请求流程包含哪些步骤?

在请求实际到达的任何渠道上接收它,登记并从收到日期开始起算一个月,确认收到,按必要限度核验请求人身份,判定其行使的是哪一项权利,检验该请求是否明显无依据或过度,商定范围、确有必要时才提出一个明确的澄清问题,检索每一个可能存有相关数据的系统、备份与受托处理方,就第三方信息与法律保密特权审阅检索结果,适用相应的豁免并逐条记录理由,判断请求是否复杂到需要那两个月的延期、需要时告知请求人,整理答复与相应理由,安全地交付给已核验的本人,把请求以及在其上做过的每一项决定归档,并告知对方如不满意可以如何投诉。实践中最常被跳过的是权利判定和遮蔽审阅这两步,而投诉恰恰都出在这两步上。

回应数据主体查阅请求的期限是多久?

一个月。GDPR 第 12 条第 3 款要求控制者不得无故拖延,并且无论如何应在收到请求后一个月内就已采取的措施作出答复。这里算的是日历月而不是工作日,因此期限走到次月的对应日——次月没有对应日的,算到该月最后一天;对应日落在周末或法定节假日的,顺延至下一个工作日。当请求复杂、或者同一个人提出了多项请求时,可以再延长两个月,但前提是你在第一个月之内就把延期及其理由告知了请求人。在等待身份证明材料或等待范围澄清期间计时是否暂停,各监管机构口径不一,因此要记录你们遵循的是哪一种口径并一贯适用。实践中期限很少是在检索环节丢掉的,而是丢在请求落到公司某处、到它转交给真正负责答复的那个人之间的那些天里。

可以拒绝数据主体的权利请求吗?

有时可以,但很少能站在大家最先想到的那个理由上。第 12 条第 5 款允许控制者在请求明显无依据或过度时收取合理费用或者拒绝处理,而证明这一点的责任在控制者。范围宽、办起来麻烦、或者是在一场争议当中提出的,都不等于过度。除此之外,各法域的国内法通常另有豁免情形,其作用是让你扣留特定材料,而不是整体拒绝该请求;第 17 条的删除权本身也是有条件的:第 3 款保留了你依法必须保存的数据,以及为提出、行使或抗辩法律主张所必需的数据。拒绝不等于沉默。你仍然要在期限之内答复、说明理由,并告知对方可以向监管机构投诉、也可以寻求司法救济。因此本图把拒绝画成一个会产生答复的步骤,它与其他所有结果一样被归档,也一样可以被升级,而不是让一件被拒绝的请求悄悄从流程里掉出去。

答复里出现的他人数据要怎么处理?

查阅权是对请求人本人个人信息的权利,而不是对每一份提到他的文件的副本的权利——当材料是邮件往来、投诉卷宗或绩效评语时,这两者极易混淆。第 15 条第 4 款规定,获取副本的权利不得对他人的权利与自由造成不利影响。落到操作上,每一处第三方信息都有三个选项:把它遮蔽掉、去征求该他人同意后提供,或者综合数据本身的内容、该他人是否负有保密义务、以及他是否已经明确拒绝,判断不经同意提供是否合理。要记录你选了哪一个以及为什么。审阅要在汇总好的整套材料上做一次,而不是一个系统一个系统地做;由一位具名的人签署确认;并保留一份审阅时的未遮蔽版本,以便日后有人提出异议时还能把这个决定解释清楚。

本页与数据访问申请流程图有什么不同?

两者面对的是不同的对象。/zh/templates/数据访问申请流程 上的数据访问申请流程是对内的:一名员工或一个团队为了完成工作而申请调取某份数据集,组织根据使用目的、数据敏感度、合法性基础和授权条款作出决定,然后授予一份有范围、有期限、可以随时收回的权限。除了你们自己定的时限之外没有别的期限,而且你们完全可以直接说不。本页则是组织外部的个人所行使的一项法定权利:期限来自 GDPR 第 12 条第 3 款而不是某个服务水平约定,结果是交付一整套信息而不是授予一项权限,而对面那个人在你们做错时可以向监管机构投诉。如果你们要治理的是公司内部谁可以查询某张表,请用对内的那份模板;如果是外部的人在问你们究竟持有他的哪些信息,请用这一份。

使用此模板

流程图模板中的更多内容