数据泄露响应流程图（GDPR 72 小时时限）
个人数据泄露响应的泳道流程图：遏制、对个人的风险判断、72 小时内向监管机构报告，以及泄露事件登记册。
什么是数据泄露响应流程图（gdpr 72 小时时限）流程
个人数据泄露，是指任何导致个人数据被销毁、丢失、篡改、泄露或被未经授权访问的安全失效，无论出于意外还是出于故意。其中大多数并不是网络攻击。它们是一封发错收件人的邮件、一份忘了删掉隐藏工作表的电子表格、一台落在火车上的笔记本电脑、一个向所有人开放的文件共享、一份最终证明无法恢复的备份。下面这个流程由怀疑触发，而不是由已确认的结论触发，因为法定时钟从组织意识到可能发生了泄露的那一刻开始走，而不是从调查结束时才开始走。
这刻意不是一个安全事件响应流程。检测、取证、证据保全、清除，以及验证系统已经干净，都属于那个流程，由安全团队负责；在这里，它们只表现为一个遏制步骤，以及一次把修复工作交回安全团队的交接。如果泄露源于网络攻击，就把两个流程一起跑：技术响应负责恢复并加固环境，而本图在旁边按自己的期限运行，回答的是另一个问题——必须告知谁、在什么时候之前告知，以及如果答案是不必告知任何人，你们要写下什么。它也不是 IT 事件管理，后者在服务恢复时就结束了；它同样不是数据主体访问请求流程，那个流程处理的是个人索取自己的数据，而不是组织把数据弄丢了。
有两个决策承担着法律分量，而它们经常被彼此混淆。在欧盟与英国 GDPR 之下，向监管机构报告是默认动作：除非该泄露不太可能对个人的权利与自由构成风险，否则就必须报告。告知受影响的个人则是另一项独立且门槛更高的判断，只有在泄露很可能对他们构成高风险时才需要。一起泄露完全可能需要向监管机构报告，却从未告知涉及其中的那些人。团队第三个容易漏掉的地方是：两条分支最终会合流——每一起泄露都要进入内部登记册，包括你们决定不上报的那些，并连同作出该决定的理由一起记录。
本流程图涵盖的内容
本模板包含
- 五条角色泳道，每个步骤都有明确责任人（发现者／报告人、信息安全、数据保护官、法务、公关），横跨五个阶段列：报告，评估与遏制，报告决策，报告执行，以及记录与复盘。
- 报告阶段：报告人泳道中的“发现可能的数据泄露”与“通过数据泄露报告渠道上报”，随后由信息安全执行“登记上报并启动时间线”，从而确定 72 小时时限赖以起算的知悉时间点。
- 信息安全泳道中的初步评估与遏制，随后是由数据保护官负责的“是否涉及个人数据？”决策，其“否”分支把案件作为纯粹的安全事件关闭，而不是把它一路拖过整条监管路径。
- 数据保护官泳道中的“评估严重程度与对个人的风险”，随后由法务确认究竟哪些报告义务真正适用，然后才是“是否需要向监管机构报告？”这一决策。
- 需报告的分支走“起草报告并经法务审阅”和“在 72 小时内向监管机构报告”；无需报告的分支则改走“记录不予报告的理由”，让决策无论走向哪一边都留有证据。
- 一个独立的“对个人是否构成高风险？”决策，把工作交给公关去起草并发出面向受影响个人的通知；随后是两条分支都会到达的泄露登记册记录、由信息安全执行的补救措施、事后复盘与结案。
何时使用本模板
- 你们正在编写或更新个人数据泄露处理程序，需要一页纸说明谁评估、谁决策、谁上报。
- 你们希望把是否需要报告这件事提前定下来，这样周五下午五点就不会有人还在争论时钟到底有没有开始走。
- 你们正在做数据泄露演练，希望端到端地检验整条 72 小时路径，包括真正耗掉大部分时间的起草与签批步骤。
- 你们正在培训员工该上报什么、上报到哪里——因为几乎每一起真实泄露的第一步，都是一位普通员工注意到了异常。
- 审计师或客户要求你们出示一份成文的数据泄露处理程序（图示是程序的证据，但它本身并不能证明合规）。
运作方式
为角色和上报渠道命名
把这五条泳道换成你们真正拥有的角色。规模较小的组织往往没有数据保护官，会把这条泳道并入法务或某位隐私负责人；也有组织会为外部数据泄露法律顾问或网络保险公司单开一条泳道。然后把实际的上报路径写进“通过数据泄露报告渠道上报”这一步：一个邮箱、一张表单、一个电话号码，以及一条规则——发现可疑就上报，而不是先自己调查。
确定你们的监管机构和你们的期限
修改“确认适用的报告义务”这一步，写明适用于你们的一个或多个监管机构、跨境经营时的主导监管机构，以及你们所处的行业性制度或欧盟以外的其他制度。这些制度按不同的时钟运行，因此把每一个都写下来，而不要假定 72 小时能覆盖一切。同时补上与客户之间的合同通知期限，它们往往比法定期限更短。
把你们的风险判断标准写下来
在“评估严重程度与对个人的风险”上附上你们自己的标准：数据的类型与敏感度、涉及的个人与记录数量、这些人被识别出来的难易程度、数据是否已加密或以其他方式不可用、其中是否包含弱势人群，以及损害的严重程度与发生可能性。事先写好的标准，正是让那两个决策在事后站得住脚的东西。
指定这两个决策和签批人
在图上写明谁负责“是否需要向监管机构报告？”和“对个人是否构成高风险？”，谁有权批准提交给监管机构的报告，以及谁可以批准发给个人的措辞。为每一项都设一位替补——数据泄露不会等人休完年假。
在 72 小时之内设置内部子期限
从最后期限往回推算，为中间各步骤设定目标时间：数据保护官何时必须拿到评估、草稿何时必须送达法务、签批何时截止。法定期限是外沿，不是计划——而小时数真正流失的地方，正是起草与审批。
把登记步骤指向你们真实的登记册，并为图做版本管理
把“在登记册中记录该泄露”连到你们实际维护的那份记录上，并列出它必须包含的字段：泄露的事实经过、造成的影响、已采取的补救措施，以及每一次报告决策的理由，包括那些否定的决策。然后把图发给数据保护官、法务、信息安全和公关审批，并保留获批版本，让你们演练的程序就是你们发布的程序。
常见问题
72 小时的泄露报告时限从什么时候开始计算？
在欧盟与英国 GDPR 之下，控制者必须在知悉发生个人数据泄露之后，不得无故拖延地、并在可行的情况下不迟于 72 小时内向监管机构报告。知悉是指已经有合理程度的确信，认为一起安全事件导致个人数据受到损害，因此短暂的初步核实是被接受的；但你们不能靠拉长调查来推迟时钟。这 72 小时是自然小时，不是工作小时：周末与公众假期都在窗口之内。这也正是本图把“登记上报并启动时间线”放在最前面，并记录谁在什么时候报告了什么的原因。
向监管机构报告和告知个人有什么区别？
它们是门槛不同的两项判断，这也是本图把它们画成两个决策而不是一个的原因。除非该泄露不太可能对个人的权利与自由构成风险，否则必须告知监管机构——所以报告实际上是默认动作。只有当泄露很可能对受影响的个人构成高风险时，才必须告知他们本人，而且存在公认的例外，例如数据已加密且仍然无法解读，或者你们此后已采取措施，使高风险不再可能成为现实。因此一起泄露完全可能被上报给监管机构，却从未告知涉及其中的那些人。
我们决定不上报的泄露，还需要记录吗？
需要。GDPR 要求控制者记录每一起个人数据泄露，包括事实经过、造成的影响和已采取的补救措施，无论是否上报。实际上，你们选择不上报的那一起，其记录反而更重要，因为它是唯一能证明该决定出于论证而非出于省事的证据。这正是本图中“无需报告”分支要经过“记录不予报告的理由”，而两条分支最终都汇入登记册的原因。
这与安全事件响应流程有什么不同？
安全事件响应流程关注的是攻击者和整个环境：检测、分流、保全证据、遏制、清除、验证系统已经干净、恢复服务。本流程关注的是数据受到影响的那些人，以及随之而来的义务；它由任何一起个人数据泄露触发，包括那些根本没有攻击者的情形，例如一封发错的邮件或一份无法恢复的备份。两者在遏制环节和报告分支上重叠；遇到网络事件时，你们会并行运行它们，由安全团队负责技术那条线，由数据保护官负责这一条。
如果我们是处理者而不是控制者呢？
处理者既不向监管机构报告，也不告知个人。它必须在知悉个人数据泄露之后不得无故拖延地告知控制者，之后由控制者进行评估并作出两项报告决策。如果这就是你们的处境，就把本图裁到“是否需要向监管机构报告？”这一决策为止，用你们向控制者发出的通知取而代之，并检查你们的合同——数据处理协议通常会约定一个固定的内部期限，比控制者的 72 小时短得多。