本文对EDPB发布的个人数据泄漏通知指南《Guidelines 9/2022 On Personal Data Breach Notification Under GDPR (Version 2.0) 》（下称“《9/2022号指南》”）的要求进行提炼，旨在为需要满足GDPR的出海企业提供参考。
一、重要定义
根据GDPR Article 4(12)，“个人数据泄露”（“personal data breach”）是指由于违反安全性（机密性/完整性/可用性）而导致传输、存储、处理中的个人数据被意外或非法损毁、丢失、更改或未经同意而被公开或访问。其中：
1、损毁：个人数据被修改、破坏、或完整性受影响；
2、丢失：控制者失去对数据的控制权、或无法再访问（如数据被勒索软件加密而无法访问，或解密数据的密钥丢失）；
3、未经授权的处理：包括向未经授权的接收方披露了个人数据，或接收方未经授权访问了相关数据。
Q：短暂的数据不可用，算不算data breach？
A：算。在特定场景下，短暂的数据不可用也可能对自然人的权利和自由产生重大影响。比如医院在特定时间内无法获取患者的关键医疗数据，导致手术延期或取消，继而危机患者的生命。
但并非所有的短暂数据不可用都需要通知监管机构或受影响的个人。如新闻媒体系统中断几小时而导致无法推送新闻给到用户，则不太可能对个人的权利和自由产生影响。
依据GDPR Article 33(5)对个人数据泄漏事件进行记录的要求，此类短暂的数据不可用事件也应记录在案，以备监管检查。
Q：计划内的变更、演练导致数据不可用，算不算data breach？
A：不算。计划内的系统维护、演练而导致个人数据不可用，这不是GDPR Article 4(12)所定义的“违反安全性（breach of security）”。
二、处置流程一览
如下是发生泄漏事件时，组织对外通知的流程图：
三、对外通知要求
1、向监管机构报告
1）何时报告
根据GDPR第33条要求，数据控制者应在意识到发生了个人数据泄露后的72小时内向监管机构报告；除非“数据泄露对于个人的权利与自由不太可能会带来风险”。
2）何时算“意识到”泄漏事件
当控制者有合理的确定性认为发生了导致个人数据被泄露的安全事件时，应被视为已经“意识到”事件的发生。例如：1、数据控制者检测到其网络可能被入侵，经初步调查后发现了系统网络被入侵的痕迹，即为“意识到”的时刻。2、当数据控制者被第三方告知可能发生个人数据泄露时，应立即启动事件调查程序，一旦以合理程度的确定性确认发生了个人数据泄露，也应认定为“意识到”。在某些情况下，控制者从一开始就相对清楚地知悉违规行为（如内部误操作或恶意操作）已发生，而在其他情况下可能需要一些时间来确定个人数据是否已被泄露。
3）报告的内容
GDPR Article 33(3) 规定了向监管报告的内容：
a）个人数据泄漏的性质，数据类型，数据量级，受影响的数据主体数量；
b）DPO或其他联系人的姓名、联系方式；
c）个人数据泄漏可能对数据主体造成的后果；
d）拟采取或已采取的减缓措施。在事件排查的早期阶段，如果控制者无法掌握准确的信息（例如受影响的数据主体的确切数量），GDPR允许控制者对受影响的主体数量和相关个人数据的量级进行估算；或者向监管机构说明当前情况，并在后续排查阶段再提供进一步的信息。
2、向数据主体通知
1）是否需要通知？
根据GDPR第34条规定，当个人数据泄露很可能给个人的权利与自由带来高风险时，控制者应当及时（Without Undue Delay）向数据主体通知个人数据泄露。
2）通知形式
可以通过电子邮件、短信、即时消息、显著的网站横幅或通知等方式向受影响的个人发送通知信息。《9/2022号指南》指出，只在新闻稿、公司博客等渠道发布通知，并不是一种有效触达个人的方式。
3）通知内容
在通知受影响用户时，应提供以下信息：
a）事件概述：告知用户发生了什么，包括哪些数据被泄露，泄露的原因以及泄露的时间等。
b）联系方式：提供联系信息，以便用户可以与组织的DPO或其他代表沟通，寻求进一步的帮助和支持。
c）影响范围：明确告知用户哪些数据已经泄露，以及可能会对他们产生的影响，例如身份盗窃或欺诈等。
d）采取的防范措施：说明组织已采取或拟采取哪些措施来降低泄漏的负面影响。
e）措施和建议：向用户提供应对措施和建议，例如更改密码等，以帮助用户尽可能降低事件对其权益的影响。
4）无需通知的情形
GDPR Article 34(3)列出了以下三种情形下，无需通知个人：
a）在发生数据泄漏事件之前，控制者已经采取了适当的技术和组织措施来保护个人数据（例如加密、令牌化等）；
b）在意识到发生数据泄漏事件后，控制者第一时间采取措施，使泄漏不会对个人的权利和自由产生实质的高风险影响；
c）联系个人需要付出不成比例的努力（如相关用户的联系方式因本次事件而丢失）。在此情形下，控制者可以通过公众媒体等方式实行告知。如果控制者因符合上述情形而选择不通知个人，那么控制者应该能够向监管机构证明他们确实符合这些条件。
四、泄露风险判定
如前所述，当控制者意识到数据泄漏事件发生后，应当评估事件对数据主体权利和自由带来的风险。那么，应该如何评估并界定风险的影响程度？
对数据主体造成的损害通常可分为：物理损害（Physical Damage）、物质损害（Material Damage）、以及非物质损害（Non-Material Damage），如歧视、身份盗用或欺诈、财产损失、名誉损失等。
当泄漏的数据可以反映出个人的种族或民族、政治观点、宗教或哲学信仰、工会成员身份，或包括了基因数据、健康数据、性生活数据，或与刑事定罪和犯罪有关时，应认为可能导致高风险的损害，进而需要告知受影响的主体。
评估应考虑的因素
当评估数据泄漏对个人造成的风险时，应考虑以下几个因素：
个人数据泄漏示例
下表列出了个人数据泄漏的示例，以及是否需要通知监管机构/数据主体：
五、事件记录保存
GDPR Article 33(5)要求，数据控制者应记录所有的个人数据泄露事件，包括涉及的个人数据，事件的过程、影响分析、采取的补救措施、告知受影响主体的方式、以及根本原因等，使监管机构能够核实控制者对该法条的遵守情况。
《9/2022号指南》还建议控制者记录事件处置过程中采取相关措施的原因，诸如：
1、如何得出不通知监管/数据主体的决定；
2、如果未在72小时内通知监管，延迟的原因是什么。
六、应急管理组织
Article 32要求数据控制者和处理者建立应急管理机制以防止、监测和应对数据泄漏事件。
本章基于通用实践，对安全事件应急管理组织的构成及职责进行简要分享。应急管理组织自上而下应包括决策方、协调方、执行方。具体应包括如下职能部门：法务合规部门、应急管理部门、安全/技术部门、公共关系部门、GR部门、客服部门等。
1、法务合规部门：
1）维护适用的法律法规清单，明确发生数据泄漏事件时应报告的监管部门及其联系方式；
2）关注各主管或监管机构有关的行政调查、执法动作；
3）参与应急处置过程，评估事件影响性，决策事件是否应向监管报告或向用户通知；
4）审定事件报告，并于要求的时限内向监管部门报告（与GR部门协作）；
5）配合监管后续的调查。
2、应急管理部门：
1）制定组织内统一的风险事件应急响应制度，根据事件的危害程度、社会影响范围以及对组织的影响程度，制定风险事件分级标准；
2）统筹协调包括数据泄漏在内的应急事件，负责应急处置过程中的沟通协调、进展汇报、事件定级、回顾复盘等事务；
3）建立统一的应急事件管理平台，负责舆情监控、风险事件记录等；
4）开展应急响应培训，增强风险事件应急意识，确保员工了解风险事件发生后的内部报告制度、流程以及对应的应对措施等。
3、安全技术部门：
1）持续评估组织的安全水位，建立适宜的防护、监测、响应机制；
2）依据各风险敞口（如DDoS、钓鱼、恶意软件等），制定相应的应急响应步骤，并开展漏洞扫描、渗透测试及红蓝对抗；
3）与业务、技术部门协作，排查数据泄漏的范围和源头，采取必要的措施来止血；
4）分析事件根本原因，提供泄漏修复方案。
4、公共关系部门：
1）识别发现各类媒体对组织安全事件的负面报道、宣传、曝光；
2）制定媒体沟通方案。
5、客服部门：
1）应答用户的咨询、投诉等，执行用户沟通方案。
六、写在最后
要在意识到个人数据泄漏的72小时内摸清影响面并评估风险，不是一件易事。建立完善的应急响应机制，通过持续的演练发现问题、改进响应计划，是一项必不可少的工作。
为帮助企业快速排查事件影响面、做好事件报送与记录，用九智汇即将推出“个人信息画像”与“应急响应平台”，满足企业在安全事件管理上的诉求。
个人信息画像——Privacy Data
隐私合规的保护对象是用户及其个人信息。结构化数据、非机构化数据（图片、文件、音视频等），可能都蕴含着大量的个人信息，需要全面识别和分类分级。
Privacy Data能够从企业大规模的数据中扫描识别出个人信息，形成集中式、可视化的个人信息画像，是做好个人行权响应（DSAR）、个人信息泄漏响应等合规义务的必不可少的输入。
应急响应平台——Data Breach Response
用九智汇应急响应平台集事件监控、影响分析、事件响应与回顾复盘于一体，通过与“数据发现”、“个人信息画像”产品能力联动，快速定位受影响的个人信息类型及其数据主体，评估泄漏事件对用户权益可能造成的风险；支持线上维护监管报送与用户通知模板，编辑通告内容并发起审批流。同时满足事件记录保存要求。
