breach-documentation

维护数据泄露文档记录

概述

GDPR 第 33(5) 条要求每位控制者记录所有个人数据泄露事件，无论该事件是否触发向监管机构通报。文档必须包含“与个人数据泄露事件有关的事实、其影响以及已采取的补救措施”，并且必须“使监管机构能够核实是否遵守了本条规定”。因此，需要建立全面的数据泄露登记册，将其作为 Art. 5(2) 下主要的问责文件。

强制性文档要求 — Art. 33(5)

与数据泄露事件有关的事实

每条数据泄露登记记录都必须包含：

字段	说明	示例
数据泄露事件参考编号	唯一的顺序标识符	SPG-BREACH-2026-003
发现日期和时间	控制者知悉事件的 UTC 时间戳	2026 年 3 月 13 日，14:30 UTC
数据泄露发生日期和时间	数据泄露事件本身的 UTC 时间戳（如与发现时间不同）	2026 年 3 月 13 日，11:15 UTC
数据泄露类型	保密性、完整性、可用性或组合类型	可用性（主要）；保密性（调查中）
数据泄露事件描述	对所发生事件的事实叙述	LockBit 3.0 勒索软件加密了生产环境中的客户数据库集群。攻击途径：攻击者通过鱼叉式网络钓鱼获取了被入侵的服务账户。
受影响的系统	涉及数据泄露事件的系统	db-prod-eu-west-01 至 db-prod-eu-west-04
数据主体类别	受影响的人员类型	个人账户持有人、企业账户持有人、联合账户持有人
数据主体人数	受影响人员的大致人数	15,230
个人数据类别	被泄露的数据类型	姓名、邮寄地址、电子邮件地址、支付卡末 4 位、交易记录、账户余额
记录数量	受影响记录的大致数量	48,720
根本原因	已查明的数据泄露原因	过期的特权服务账户 + 网络钓鱼 + 疲劳式推送 MFA 绕过
遏制时间戳	数据泄露事件得到遏制的时间	2026 年 3 月 13 日，12:45 UTC

数据泄露事件的影响

字段	说明	示例
风险评估得分	根据风险评估方法得出的综合得分	18/24
风险等级	得出的风险判定	接近高风险
已确认的实际损害	对数据主体造成的任何已确认损害	截至评估日期，尚未确认有任何损害
潜在损害	数据遭到滥用时可能造成的后果	金融欺诈、身份盗窃、定向网络钓鱼
影响持续时间	数据主体受到影响的时长	36 小时（数据库不可用）；仍在持续（潜在的保密性影响）

已采取的补救措施

字段	说明	示例
遏制措施	为制止数据泄露事件而立即采取的措施	网络隔离、撤销凭据、从备份恢复
补救措施	长期纠正措施	将 MFA 升级至 FIDO2、服务账户生命周期管理、网络分段
补救状态	各项措施的当前状态	7 项措施中已完成 4 项；3 项正在进行
补救期限	目标完成日期	2026 年 6 月 15 日

通知决定文档

每条泄露记录还必须记录通知决定及其理由：

字段	描述
Art. 33 SA 通知决定	必需 / 不需要
Art. 33 通知理由	说明为何需要或不需要通知（参照风险评估）
Art. 33 通知日期	向 SA 通知的日期和时间（如适用）
SA 参考编号	监管机构分配的参考编号
SA 后续跟进状态	监管机构的任何后续询问或行动
Art. 34 DS 通知决定	必需 / 不需要 / 根据 Art. 34(3) 豁免
Art. 34 通知理由	说明为何需要或不需要通知 DS
Art. 34 通知日期	通知 DS 的日期（如适用）
Art. 34 通知方式	使用的渠道（电子邮件、邮寄、公开通知）

登记册结构与维护

单一集中式登记册

所有泄露事件都必须记录在由 DPO 办公室维护的单一集中式登记册中。Stellar Payments Group 在 OneTrust Privacy Management Platform 中使用专用模块，并设置以下访问控制：

• 写入权限：DPO、副 DPO、隐私事件协调员
• 读取权限：CISO、总法律顾问、内部审计、董事会审计委员会
• 无访问权限：业务部门经理、IT 运营人员（仅在有必要知情的情况下，通过单独报告提供对个别泄露记录的访问权限）

记录所有泄露事件——包括无需通知的事件

登记册必须包含所有个人数据泄露事件，无论严重程度如何，也无论是否触发 SA/DS 通知。明确包括：

• 含有个人数据的电子邮件误发（即使只涉及单个收件人的事件）
• 通过备份恢复的临时可用性泄露
• 针对个人数据但未访问数据的未遂外泄
• 影响控制者数据的处理者泄露事件
• 实体安全泄露（设备丢失、未经授权进入办公室）

保留期限

泄露登记册中的记录自泄露事件结案之日起至少保留 7 年。此期限考虑了：

• 大多数欧盟成员国对 GDPR 执法行动适用的 5 年诉讼时效
• 向监管机构证明相关事件存在（或不存在）规律的需要
• 根据 Art. 82 提出的数据主体赔偿索赔的诉讼时限

7 年保留期结束后，记录将进行匿名化处理（保留数据主体人数，移除具体标识符），并无限期保存以进行趋势分析。

审计准备

监管机构访问权限——Art. 33(5)

泄露登记册必须能够在监管机构“提出要求时”提供。为做好审计准备，必须：

1. 即时提供：在收到监管机构请求后的 24 小时内，必须能够以结构化格式（CSV、JSON、PDF）导出登记册。
2. 完整性验证：每月进行自查，确认所有已报告的安全事件均已评估其对个人数据的影响，并在适用时添加到登记册中。
3. 交叉引用完整性：每条登记册记录都必须链接至支持性文档（风险评估表、SA 通知副本、DS 通知副本、调查报告、补救措施证据）。
4. 趋势报告：登记册必须支持生成趋势报告，显示：一段时间内的泄露频率、泄露类型、根本原因类别、通知率和补救措施完成率。

年度泄露登记册审查

DPO 每年审查泄露登记册，内容包括：

1. 完整性：所有已知泄露事件是否均有记录？与安全事件管理系统交叉核对。
2. 准确性：抽查 20% 的条目，并根据源文件核实其准确性。
3. 及时性：是否在发现泄露事件后的 72 小时内创建条目？
4. 补救措施结项：是否跟踪补救措施直至完成？标记逾期措施。
5. 模式识别：是否存在反复发生的泄露类型或根本原因，表明存在系统性问题？
6. 董事会报告：为董事会审计委员会编制年度泄露事件摘要报告。

与其他记录的整合

相关记录	整合方式
第 30 条 RoPA	将受影响的处理活动关联到泄露条目
DPIA 登记册	更新受影响处理活动的 DPIA，将泄露事件列为风险事件
供应商登记册	如果泄露事件源自处理者，则更新处理者风险评估
培训记录	记录向相关人员开展的泄露事件后培训
审计日志	引用与泄露事件相关的内部审计发现
保险记录	关联网络保险理赔参考编号（如适用）

常见的文档记录缺陷

1. 在安全事件系统中记录了泄露事件，但未记录在第 33(5) 条登记册中：安全事件工单不能替代泄露登记册条目。
2. 缺少通知决策依据：仅记录“未通知”，却未说明为何评估认为该泄露不太可能导致风险。
3. 补救措施跟踪不完整：列出了补救措施，却从未更新其完成状态。
4. 文档记录延迟：泄露事件发生数周后才创建条目，难以证明及时知悉并作出响应。
5. 没有处理者泄露事件条目：处理者处发生的泄露事件影响到控制者的数据，却未记录在控制者的登记册中。