个人数据泄露会启动一个监管计时器，它不会因周末、节假日或高管是否在岗而停止。根据GDPR第33条，您有自知悉起72小时向监管机构发出通知。DPDPA规则7、PDPA第26B条以及LGPD第15/2024号决议设定了类似的时限。

本行动手册将72小时分为五个命名阶段——检测、遏制、评估、记录、提交——并在每个关口设定具体的交付成果。请将其作为操作手册使用：当事态紧急时，您不希望临时编写流程。您希望的是执行它。

第33条规定「不得迟于知悉后72小时」。知悉是指控制者已有合理程度的确定性认为发生了安全事件且涉及个人数据。它不是：

• 事件实际发生的时刻。
• 自动告警触发的时刻。
• 第一位分析师开始调查的时刻。
• 供应商报告子处理者事件的时刻——但计时通常在您掌握足够信息以评估控制者的数据是否在范围之内时开始。

EDPB关于个人数据泄露通知的9/2022号指南允许有一段短暂的调查期以达到知悉，但该期间应当短暂——以小时计，而非以天计。

目标：确认已发生事件，保全取证证据，启动响应团队。

• 分诊信号。告警是否真实？IDS命中、可疑导出、供应商披露、客户报告。
• 保全取证完整性。对受影响系统进行快照，冻结日志，若内存证据重要则不要关机。
• 建立案卷。发放事件ID。此后的每一项行动都针对其进行记录。
• 启动作战室。DPO、CISO/安全主管、法律顾问、传播部门以及指定的事件指挥官。
• 确定负责的处理者/子处理者（若事件源自外部）；联系其事件响应联络人。

T+6小时交付成果：一页式事件摘要——发生了什么、何时发生、涉及哪些系统、可能涉及哪些数据类别、有哪些已知的未知项。

目标：止血，隔离受影响系统，并通知对时间敏感的外部各方。

• 阻断持续的数据外泄。轮换凭据，撤销OAuth令牌，终止会话，阻断出口流量。
• 隔离受影响系统，同时保全证据。
• CERT-In / 行业通知。印度：对指定事件需在6小时内通知CERT-In。美国行业性：HHS OCR（HIPAA）、FTC、各州总检察长。
• 聘请外部法律顾问（若可能存在重大风险敞口）——尽早确立特免权为佳。
• 联系网络保险承保人，按保单通知要求（通常在48小时内；部分承保人提供7×24小时热线）。
• 开始受害者识别工作——数据主体类别、大致数量、地理分布。

T+24小时交付成果：遏制确认；初步范围声明。

目标：确定规模和可能的损害——这将驱动后续每一项决策。

• 受影响的个人数据类别。标识符？联系数据？财务数据？特殊类别（GDPR第9条）？儿童数据？
• 数量。若已知则提供精确记录数；否则提供合理估算。
• 受影响的数据主体。员工、客户、供应商联系人、最终用户？在哪些司法管辖区？
• 损害的可能性和严重程度。采用第33条第(3)款第(c)项的框架——身份盗用、欺诈、财务损失、声誉损害、歧视、职业保密性丧失。
• 适用通知门槛。GDPR：除非「不太可能对自然人的权利和自由造成风险」，否则通知监管机构。LGPD：对可能造成「相关风险或损害」的泄露通知ANPD。PDPA-SG：500人及以上或重大损害。
• 就监管机构方面做出决定。跨境GDPR的主导监管机构。若处理跨越多个地区则涉及多个监管机构。

T+48小时交付成果：损害风险评估；通知决策矩阵；填写好的通知模板草稿。

目标：构建您将提交的文件，锁定内部记录，向利益相关方简报。

• 提交监管机构所需的第33条第(3)款内容集：
  1. 泄露的描述（性质、类别、数据主体和记录的大致数量）。
  2. DPO或其他联络点的姓名和联系方式。
  3. 泄露可能造成的后果。
  4. 为应对泄露并减轻可能的不利影响而已采取或拟采取的措施。
• 第33条第(5)款内部记录。即使您不进行通知，也应在内部记录该泄露；监管机构在审计时会索取此类记录。
• 高级管理层简报。按您的事件响应政策，向首席执行官、董事会、审计委员会简报。
• 传播计划定稿。客户沟通模板、FAQ、高管谈话要点、社交媒体监测待命。
• 子处理者协调。若泄露源自上游，统一通知信息和时机。

T+72小时交付成果：可供提交的通知；完整的内部记录。

目标：在法定时限内通知监管机构，并在需要时向数据主体进行沟通。

• 向监管机构提交，通过官方门户（大多数欧盟数据保护机构有网络表单；ICO使用在线表单；ANPD使用电子协议）。保存回执——这是时间的唯一证明。
• 多司法管辖区提交。若您有多个主导监管机构（罕见），则适用一站式机制；否则需分别通知各主管机关。
• 数据主体沟通（若高风险，第34条）：清晰、平实的语言，DPO的姓名 + 联系方式，可能的后果，缓解措施，建议。
• 公开声明（若对投资者重大或受行业规则约束，如SEC 8-K、SAR式报告）。
• 内部全员大会在公开宣布之前召开，以掌控叙事。

T+72小时之后交付成果：提交确认函；已发出数据主体沟通（或已记录不沟通的决定）；已安排在14天内进行事件后复盘。

• 事件指挥官——掌控节奏，宣布阶段转换，升级处理阻碍。
• DPO / 隐私官——负责监管机构通知的决策和内容。
• CISO / 安全主管——负责遏制、取证、根因分析。
• 总法律顾问 / 外部法律顾问——负责特免权、沟通审查、监管机构沟通策略。
• 传播部门——负责对外信息、社交监测、媒体应对。
• 首席执行官 / 高级领导层——负责声誉决策、面向客户的致歉、事件后的承诺。

最常见的组织失误是DPO与总法律顾问之间对实际监管机构提交的归属不清。应提前理清——大多数团队默认由DPO在法律顾问特免权下起草，并由DPO作为提交文件中的指定联络人。

当对权利和自由存在高风险时，GDPR第34条触发对数据主体的沟通。其标准高于监管机构通知门槛。需要通知的示例：

• 未加密的财务账户详情、用于身份验证的标识符。
• 特殊类别数据（健康、基因、生物识别、政治、宗教）。
• 可导致身份盗用或财务欺诈的信息。
• 具有任何实质敏感性的儿童数据。

第34条第(3)款列出了直接沟通的三项豁免：使数据对未授权人员不可读的加密、消除高风险的措施，或可由公开沟通替代的不成比例的努力。

通知内容（第34条第(2)款）：泄露的性质、DPO的姓名和联系方式、可能的后果、已采取的措施。须使用平实语言。

• 在错误的时刻开始计时。监管机构会严格审查何时达到「知悉」。如果您的事件响应团队在宣布事件前调查了5天，这段间隔看起来就像延误。
• 低估范围。失去监管机构善意最快的方式，就是低报初始数字，然后大幅向上修正。
• 缺乏书面评估。如果您决定不通知，第33条第(5)款仍要求保留有关泄露及其理由的内部记录。
• 通知了错误的监管机构。一站式机制仅适用于GDPR下的跨境处理。仅限本地的处理必须通知当地监管机构——而非您的主导机构。
• 在向监管机构提交之前进行客户沟通。实践中次序很重要：监管机构将其视为善意配合，而客户并不在意孰先孰后。
• 忘记印度CERT-In的6小时时限。不熟悉印度行业性叠加规则的全球团队常常遗漏这一点。
• 未保全取证证据。关闭被入侵的主机可能销毁驻留于内存的恶意软件指标。