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