Venvera 中的泄露登记册子模块提供一套结构化的系统，用于按照 GDPR 第 33 条和第 34 条的要求，记录、管理和跟踪个人数据泄露。个人数据泄露是指因安全遭到破坏，导致所传输、存储或以其他方式处理的个人数据被意外或非法销毁、丢失、篡改、未经授权披露或访问。本文介绍泄露记录中的每个字段、通知工作流，以及泄露管理相关的合规要求。
根据 Art. 33(1)，控制者必须在知悉个人数据泄露后无不当延迟地，并在可行的情况下不迟于 72 小时，将泄露情况通知主管监管机构（即数据保护机构，DPA）。如果未能在 72 小时内发出通知，则必须同时说明延迟的理由。唯一的例外情形是该泄露不太可能对自然人的权利和自由造成风险；此时无需通知，但仍必须在内部泄露登记册中记录该泄露。
打开泄露登记册
在侧边栏中展开 GDPR，然后点击泄露登记册。主视图以表格列出所有泄露记录，包含标题、泄露类型、风险级别、发现日期、状态以及是否需要通知监管机构等列。
未关闭的泄露（调查中或已控制）显示在最上方，按发现日期排序（最新的在前）。待通知监管机构的泄露会以红色通知图标突出显示，并显示距 72 小时截止期限的剩余时间。已关闭的泄露以灰色显示在下方。
点击右上角的报告泄露，打开泄露报告表单。时间至关重要：一旦发现泄露，请立即登记，以便准确开始 72 小时通知计时。请填写所有已知信息；随着调查推进，您可以随时更新记录。
按泄露生命周期逐步处理：调查原因和范围，实施遏制措施，确定通知义务，发出所需通知，并在所有行动完成后关闭该泄露。
泄露记录表单字段
| 字段 | 类型 | 是否必填 | 说明 |
|---|---|---|---|
| 标题 | 文本输入框 | 必填 | 简洁且具描述性的标题，让人一眼就能看出泄露的性质和范围。示例：“未经授权访问客户数据库”“HR 文件服务器遭勒索软件攻击”。请避免使用“数据泄露”之类的笼统标题。 |
| 描述 | 富文本框 | 必填 | 对泄露的详细叙述，内容包括：发生了什么（事件经过）、如何发现（监控告警、用户报告、第三方通知）、时间线（发生、发现、遏制）、涉及的系统和地点、涉及的人员或第三方，以及已采取的即时行动。这些内容构成 Art. 33(5) 所要求记录的一部分，并可纳入向监管机构提交的通知中。请随着调查推进及时更新。 |
| 泄露类型 | 下拉选择框 | 必填 | 按 CIA 三要素对泄露进行分类：
|
| 风险级别 | 下拉选择框 | 必填 | 泄露对数据主体权利和自由造成的风险，决定了通知义务：
|
| 发现日期 | 日期/时间选择器 | 必填 | 组织知悉该泄露的日期和时间。根据 EDPB 的指引，当控制者有合理程度的把握确认已发生导致个人数据受损的安全事件时，即视为已“知悉”。72 小时通知截止期限从这一时刻开始计算。请尽可能精确地记录（日期和时间）。注意：泄露实际发生的日期可能与发现日期不同，请在“描述”字段中同时记录两者。 |
| 受影响的数据类别 | 多选 / 标签 | 必填 | 受影响的个人数据类别（姓名、电子邮件、财务数据、健康数据、生物识别数据、登录凭据等）。特殊类别数据（Art. 9）会显著提高风险评估结果以及需要发出通知的可能性。 |
| 数据主体数量 | 数字 | 必填 | 受影响数据主体的大致数量（根据 Art. 33(3)(a)，向监管机构发出的通知中必须包含此信息）。最初请填写最佳估计值，并随着调查推进进行更新。相关信息可以分阶段提供（Art. 33(4)）。 |
| 遏制措施 | 富文本框 | 必填 | 为应对泄露并减轻其不利影响而采取的措施（Art. 33(3)(d)）。请记录即时遏制措施（撤销访问权限、隔离系统、封锁账户）、短期补救措施（修补漏洞、重置密码、从备份恢复）、长期预防措施（新的安全控制措施、策略更新、培训）以及沟通行动（内部通知、事件响应合作伙伴）。 |
| 根本原因 | 多行文本框 | 可选 | 经调查确定的泄露根本原因。常见的根本原因包括：网络钓鱼攻击、未修补的漏洞、访问控制配置错误、人为错误（意外披露）、内部威胁（恶意员工）、设备丢失或被盗、第三方或供应商泄露、社会工程攻击、加密不足、备份程序不完善。找出根本原因对于实施有效的预防措施、避免再次发生至关重要。 |
| 需通知监管机构 | 切换按钮（是/否） | 必填 | 根据 Art. 33 是否需要通知监管机构。风险级别为中、高或严重时选择“是”；仅当风险为低时选择“否”。请记录判断理由：即使未发出通知，Art. 33(5) 也要求记录这一点。 |
| 需通知数据主体 | 切换按钮（是/否） | 必填 | 根据 Art. 34 是否需要通知数据主体。风险为高或严重时选择“是”。Art. 34(3) 规定的豁免情形包括：数据已被处理为无法识读（加密）、后续措施已消除风险，或通知需付出不成比例的努力（改为公开通报）。请记录所依据的任何豁免。 |
| 通知截止日期 | 日期/时间（自动计算） | 必填 | 自动计算为发现日期后的 72 小时。以倒计时方式显示通知监管机构的截止期限。如果截止期限已过但仍未发出通知，将显示红色警告。在特殊情况下可以手动调整；根据 Art. 33(1)，必须记录延迟的理由。 |
| 状态 | 下拉选择框 | 必填 | 泄露的当前状态：
|
Art. 33(5) 要求控制者记录任何个人数据泄露，而不仅仅是需要通知的泄露。记录内容必须包括与泄露相关的事实、其影响以及已采取的补救措施。这些记录是合规的证据，必须可供监管机构检查。Venvera 泄露登记册为每一起泄露保存完整、带时间戳且具备审计追踪的记录，从而满足这一记录要求。
泄露响应工作流
发现泄露后立即创建泄露记录。准确记录发现日期（72 小时计时由此开始），并填写标题、描述、泄露类型和初始风险级别。将状态设置为“调查中”。
确定泄露的范围、数据类别、数据量以及受影响数据主体的数量。更新记录，并依据 EDPB 标准（泄露类型、数据敏感度、可识别性、严重程度、数据主体特征、规模）重新评估风险级别。
实施遏制措施并在记录中加以记录；一旦眼前的威胁被消除，即将状态更新为“已控制”。
根据风险评估，确定是否需要通知监管机构和数据主体。确保在 72 小时截止期限前通知监管机构。通知必须包括：泄露的性质、数据主体的类别和数量、DPO 联系方式、可能的后果以及已采取的措施。
对于风险为高或严重的泄露，请以清晰易懂的语言通知受影响的个人，内容包括：泄露的性质、DPO 联系方式、可能的后果以及缓解措施。请记录沟通方式和内容。
调查根本原因，记录调查结果，实施预防措施，并在记录中更新长期补救行动。
所有行动完成后，将状态设置为“已关闭”。开展经验教训复盘，并更新程序和控制措施。该记录将被永久保留。
如果个人数据泄露源自 Venvera 事件模块中跟踪的某一 ICT 事件或与之相关，请在泄露记录的“描述”字段中引用该 ICT 事件的 ID。这种交叉引用可确保 ICT 事件响应（侧重技术恢复）与 GDPR 泄露管理（侧重数据保护合规和通知义务）之间具有完整的可追溯性。
导出与报告
泄露登记册可导出为 CSV 或 PDF 格式。单条泄露记录也可以导出为独立的 PDF 文档，其中包含所有字段以及状态变更的完整时间线。这些导出文件适用于向监管机构提交、编制内部审计报告、向董事会汇报以及归档合规证据。系统还提供汇总统计数据（每个周期的泄露总数、平均遏制时间、通知合规率），用于趋势分析和管理报告。