GDPR 数据主体权利请求流程图（受理到关闭）
GDPR 数据主体权利请求流程图：登记并启动一个月计时、核验身份、判定所行使的权利、检索系统与受托处理方、遮蔽第三方数据、复杂时延期，最后答复并归档决定。
什么是gdpr 数据主体权利请求流程图（受理到关闭）流程
数据主体权利请求出问题的地方，几乎从来不是大家排练过的那一段。失败发生在最前端。请求以一句话的形式出现在一封投诉邮件的末尾、出现在与客服的一次对话里，或者出现在打给某个网点的电话中，然后停在一个并不知道法定计时已经从收到那一刻开始跑的人手上。等它转到隐私团队，一个月已经过去一半，检索还没开始。第二种失败，是把请求当成一件法律工作来办，而它主要是一件检索与遮蔽的工作：真正吃时间的，是找齐每一个存有这个人数据的系统，再把取回来的材料逐份读一遍，看里面有没有别人的信息。第三种失败藏在身份核验里——与风险相称的核验是在保护数据主体，而不断加码索要证明材料则是一种拖延手段，监管机构一眼就能认出来。把这三件事修好的流程，多数请求都能从容地在一个月之内答复完。
本图画的是组织外部的个人——一位客户、一名离职员工、一位求职者、某个当年填过表单的人——依据 GDPR 行使权利时所走的法定路径。它不是员工为了工作而申请调取某份数据集的内部路径：那是一次普通的业务审批，末端是责任人、使用目的和一份授权，画在 /zh/templates/数据访问申请流程 上的数据访问申请流程图里。它也不是申请某个系统或某个账号的路径——那条路的关键是审批、职责分离与账号开通，见 /zh/templates/访问申请流程 上的访问申请流程。它还是 /zh/templates/数据泄露响应流程 上那张图的镜像：当你方对个人数据失去控制时，那张图按 72 小时跑第 33 条和第 34 条的通知义务；而这一张，是在有人要求你方就自己持有的数据作出交代时，按一个月来跑。本图所依赖的隐私政策、留存期限表和处理活动记录都属于受控文件，它们的起草、审批与复审周期见 /zh/templates/文件控制流程 上的文件控制流程。
多数成文程序留作默认的三件事，在这里被明确画成了框。“身份是否已确认？”有三条分支而不是两条——已确认、需补充材料、无法确认——所以索要材料是绕回同一道判断，而不是悄悄变成一次无限期挂起；始终无法证实的请求也有一个具名的结局“结案：身份无法确认”，而不是在收件箱里慢慢淡出。“是否明显无依据或过度？”被放在早期、公开地回答一次，因为第 12 条第 5 款把举证责任压在控制者身上，而拖到最后一周才做出的拒绝，看上去和“因为一个月用完了才拒绝”并无区别。“请求是否复杂或数量众多？”被放在整理答复之前而不是之后，因为那两个月的延期，只有在第一个月之内告知了请求人并说明理由时才真正存在。下游的一切都汇入同一条收尾主干：全量提供、遮蔽后提供、部分拒绝，或者在“拒绝并说明理由与投诉权利”处整体拒绝——而无论哪一种，请求仍然要在“归档请求与各项决定”处写下来，也仍然可以被升级，因为一次没人记录的拒绝，往往就是监管机构最先听说的那一次。
本流程图涵盖的内容
本模板包含
- 五条泳道——数据主体、隐私受理团队、数据保护官、法务、系统与数据责任人——铺在五个阶段上：受理、身份核验、分类与范围、检索与审阅、答复与关闭。
- 一个默认请求可能出现在任何地方的受理入口：“任意渠道收到请求”接入“登记请求并启动计时”，由它固定下期限赖以起算的收到日期，随后是“确认收到并说明预期”。
- 一道三分支的“身份是否已确认？”决策：补充材料这一支经“索取必要的身份证明材料”绕回同一道判断，而第三条分支给始终无法证实的请求一个诚实的结局——“结案：身份无法确认”。
- 对实际行使的权利做判定，随后是提前回答、且举证责任落在控制者一方的“是否明显无依据或过度？”，其“是”分支经“拒绝并说明理由与投诉权利”走出；以及一道“范围是否足以开展检索？”的判断，它只允许提出一个明确的澄清问题。
- 检索与审阅这条主干：“检索系统、备份与受托处理方”“审阅第三方数据与法律保密特权”“适用豁免与拒绝理由”，以及把请求送往“延长两个月并说明理由”的“请求是否复杂或数量众多？”判断。
- 一条被拒绝的请求也要重新汇入的收尾主干：“是否涉及更正、删除或限制处理？”会加上“执行并通知每一位接收方”，每一件已答复的请求都在“归档请求与各项决定”处留下记录，而“请求人是否对结果提出异议？”把“在期限内完成并关闭请求”与“已升级至监管机构”分开。
何时使用本模板
- 你们要编写或修订数据主体权利请求程序，需要用一页图说清楚谁登记、谁核验、谁检索、谁遮蔽、谁签发答复。
- 请求总是落在客服邮箱、社交账号和前台，而你们需要让计时从收到的那一刻开始，而不是从隐私团队听说这件事的那一刻开始。
- 你们要培训一线员工，而他们在这个流程里唯一的任务，就是认出这是一件权利请求，并在当天转出去。
- 你们曾经逾期，或者延期的决定做得太晚，希望把复杂度判断放在整理答复之前，而不是之后。
- 审计师、客户或监管机构要求你们出示一份成文程序，而你们需要让遮蔽与豁免这两步作为有具体责任人的步骤显现在图上。
运作方式
把泳道改成你们自己的角色
把数据主体、隐私受理团队、数据保护官、法务和系统与数据责任人换成你们真实存在的角色。很多组织既没有数据保护官，也没有内部法务：那就把这两条泳道并成一个隐私负责人，并写明疑难判断时你们会咨询的外部律所，而不是在图上画一个从不评审的评审者。无论规模多大，系统与数据责任人这条泳道都要单独留着，因为检索是由运行这些系统的人来做的，而不是由流程的主人来做的。
把请求可能进入的渠道全部列出来
请求不必是书面的，不必提到 GDPR，也不必直接送到隐私团队。把它真实走过的每一条路写下来——客服邮箱、联系表单、社交媒体、电话、纸质信函、前台、直属上级、律师函——并给每一条指定一个责任人，其指令只有一条：当天转出，不做判断。然后确定登记请求的那唯一一处地方，让收到日期存在于一个系统里，而不是存在于某个人的已发送邮件里。
在用到之前先把身份核验规则写好
提前决定每一类请求人分别要过哪一道核验：已登录的账号持有人、离职员工、持授权委托书代为行使的第三方、替未成年子女提出请求的家长。写明哪种材料能消除哪一种疑点、保存多久、何时删除。然后把你们的立场记录下来：索要身份证明材料期间是否暂停计时——各监管机构在这一点上口径并不一致，你们采取哪一种口径需要保持一致并且落在纸面上，而不是一件一件临时决定。
把检索所依赖的系统清单建起来
“检索系统、备份与受托处理方”这一步的质量，取决于它背后的那份清单。把处理活动记录变成一份检索清单，逐一写明每个应用系统、邮箱、共享盘、工单系统、监控录像范围、通话录音归档和受托处理方，以及由谁执行检索、需要多长时间。再加上你们对备份与归档的既定立场。有清单，同一件请求做两次才会得到同样的结果——而这恰恰是监管机构真正会去追问的地方。
定下遮蔽与豁免的标准
把你们的判断标准挂到“审阅第三方数据与法律保密特权”上，让遮蔽不再靠临场发挥：什么情况下第三方的数据可以提供、什么情况下要去征求同意、什么情况下不经同意提供也属合理，以及法律保密特权由谁、以何种方式主张。列出你们在本地法域实际依据的豁免情形，并要求为每一处扣留的内容记录理由。没有书面理由的遮蔽，几个月之后交给一个当时不在场的人，是解释不清的。
在一个月之内排好内部时点，然后发布
从期限倒推，给每一步各自的目标日期：第十天检索完成，第十八天审阅完成，第二十四天签发。法定的一个月是外沿，不是计划，而延期的决定必须在还来得及告知对方的时候做出。然后带着这张图与受理团队、一位系统负责人和签发答复的那个人一起走一遍，按他们实际的做法改正，再发布该版本并保留此前的版本。
常见问题
GDPR 数据主体权利请求流程包含哪些步骤？
在请求实际到达的任何渠道上接收它，登记并从收到日期开始起算一个月，确认收到，按必要限度核验请求人身份，判定其行使的是哪一项权利，检验该请求是否明显无依据或过度，商定范围、确有必要时才提出一个明确的澄清问题，检索每一个可能存有相关数据的系统、备份与受托处理方，就第三方信息与法律保密特权审阅检索结果，适用相应的豁免并逐条记录理由，判断请求是否复杂到需要那两个月的延期、需要时告知请求人，整理答复与相应理由，安全地交付给已核验的本人，把请求以及在其上做过的每一项决定归档，并告知对方如不满意可以如何投诉。实践中最常被跳过的是权利判定和遮蔽审阅这两步，而投诉恰恰都出在这两步上。
回应数据主体查阅请求的期限是多久？
一个月。GDPR 第 12 条第 3 款要求控制者不得无故拖延，并且无论如何应在收到请求后一个月内就已采取的措施作出答复。这里算的是日历月而不是工作日，因此期限走到次月的对应日——次月没有对应日的，算到该月最后一天；对应日落在周末或法定节假日的，顺延至下一个工作日。当请求复杂、或者同一个人提出了多项请求时，可以再延长两个月，但前提是你在第一个月之内就把延期及其理由告知了请求人。在等待身份证明材料或等待范围澄清期间计时是否暂停，各监管机构口径不一，因此要记录你们遵循的是哪一种口径并一贯适用。实践中期限很少是在检索环节丢掉的，而是丢在请求落到公司某处、到它转交给真正负责答复的那个人之间的那些天里。
可以拒绝数据主体的权利请求吗？
有时可以，但很少能站在大家最先想到的那个理由上。第 12 条第 5 款允许控制者在请求明显无依据或过度时收取合理费用或者拒绝处理，而证明这一点的责任在控制者。范围宽、办起来麻烦、或者是在一场争议当中提出的，都不等于过度。除此之外，各法域的国内法通常另有豁免情形，其作用是让你扣留特定材料，而不是整体拒绝该请求；第 17 条的删除权本身也是有条件的：第 3 款保留了你依法必须保存的数据，以及为提出、行使或抗辩法律主张所必需的数据。拒绝不等于沉默。你仍然要在期限之内答复、说明理由，并告知对方可以向监管机构投诉、也可以寻求司法救济。因此本图把拒绝画成一个会产生答复的步骤，它与其他所有结果一样被归档，也一样可以被升级，而不是让一件被拒绝的请求悄悄从流程里掉出去。
答复里出现的他人数据要怎么处理？
查阅权是对请求人本人个人信息的权利，而不是对每一份提到他的文件的副本的权利——当材料是邮件往来、投诉卷宗或绩效评语时，这两者极易混淆。第 15 条第 4 款规定，获取副本的权利不得对他人的权利与自由造成不利影响。落到操作上，每一处第三方信息都有三个选项：把它遮蔽掉、去征求该他人同意后提供，或者综合数据本身的内容、该他人是否负有保密义务、以及他是否已经明确拒绝，判断不经同意提供是否合理。要记录你选了哪一个以及为什么。审阅要在汇总好的整套材料上做一次，而不是一个系统一个系统地做；由一位具名的人签署确认；并保留一份审阅时的未遮蔽版本，以便日后有人提出异议时还能把这个决定解释清楚。
本页与数据访问申请流程图有什么不同？
两者面对的是不同的对象。/zh/templates/数据访问申请流程 上的数据访问申请流程是对内的：一名员工或一个团队为了完成工作而申请调取某份数据集，组织根据使用目的、数据敏感度、合法性基础和授权条款作出决定，然后授予一份有范围、有期限、可以随时收回的权限。除了你们自己定的时限之外没有别的期限，而且你们完全可以直接说不。本页则是组织外部的个人所行使的一项法定权利：期限来自 GDPR 第 12 条第 3 款而不是某个服务水平约定，结果是交付一整套信息而不是授予一项权限，而对面那个人在你们做错时可以向监管机构投诉。如果你们要治理的是公司内部谁可以查询某张表，请用对内的那份模板；如果是外部的人在问你们究竟持有他的哪些信息，请用这一份。