mcpField
B
breach-72h-notification

breach-72h-notification

github.com/mukul975安全32345 次安装32 周前更新
代码仓库

关于 breach-72h-notification

用于处理 GDPR 数据泄露监管通报的技能,覆盖从发现事件到后续跟进。内容包括基于风险的通报判断、期限计算、必需信息、分阶段报告和通报后义务。

主要功能

  1. 01泄露知悉时间判断指引
  2. 02基于风险的通报决策流程
  3. 0372 小时期限计算
  4. 04第 33 条通报内容
  5. 05分阶段及逾期通报指引
  6. 06通报后的义务

适用场景

  1. 01判断泄露是否需要向监管机构通报
  2. 02计算通报截止时间
  3. 03准备初次及补充通报
  4. 04记录泄露详情与纠正措施

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/mukul975/privacy-data-protection-skills --skill breach-72h-notification

安装后在 Claude Code 中输入/breach-72h-notification确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

assets/
template.md
references/
standards.md
workflows.md
scripts/
process.py

详细介绍

执行 GDPR 72 小时数据泄露通知

概述

GDPR 第 33 条要求控制者在不无故拖延的情况下,将个人数据泄露事件通知主管监管机构;在可行的情况下,通知时间不得晚于知悉事件后的 72 小时。本技能提供从发现泄露到通知主管监管机构的完整操作工作流,包括兼顾周末和公共假期的期限计算、必须包含的通知内容,以及用于判断是否需要通知的决策框架。

通知触发条件——“知悉”

当控制者有合理把握确认发生了导致个人数据遭到泄露的安全事件时,72 小时倒计时开始。根据 EDPB《指南 9/2022》第 2.3 节:

  • 处理者知悉后必须“在不无故拖延的情况下”通知控制者——控制者收到该通知后,其 72 小时时限随即开始。
  • 对泄露的初步怀疑(例如,异常日志条目)不会启动倒计时。可以进行简短调查,以确定是否确实发生了泄露。
  • 一旦控制者的 IT 安全团队确认数据遭到泄露,无论数据保护官或高级管理层是否已获悉,均视为控制者已“知悉”。

决策树:是否需要通知?

除非泄露事件“很可能不会对自然人的权利和自由造成风险”,否则控制者必须通知主管监管机构(第 33(1) 条)。

步骤 1:对泄露类型进行分类
类型描述示例
保密性泄露未经授权或意外披露个人数据,或未经授权或意外访问个人数据防火墙配置错误导致数据库暴露,泄露了 12,000 条客户记录
完整性泄露未经授权或意外更改个人数据恶意软件篡改临床数据库中的患者用药剂量记录
可用性泄露意外或未经授权地丧失对个人数据的访问权限,或销毁个人数据勒索软件加密包含 3,400 条员工记录的人力资源薪资系统
步骤 2:评估风险可能性

按 1(低)至 4(严重)的等级评估每项因素:

因素评估问题
数据敏感度泄露是否涉及特殊类别数据(第 9 条)、财务数据或政府标识信息?
数量受影响的数据主体有多少?少于 100 / 100-1,000 / 1,000-100,000 / 超过 100,000?
可识别性是否无需付出大量努力即可利用泄露的数据直接识别个人?
后果可能造成哪些具体损害?经济损失、歧视、身份盗用、声誉受损?
弱势主体是否涉及未成年人、患者、员工或其他弱势群体?
控制者特定因素控制者的角色是否会加剧风险(例如,医疗服务提供者、金融机构)?
步骤 3:应用阈值
  • 总分不超过 6 分:泄露不太可能造成风险——根据第 33(1) 条,无需通知,但必须根据第 33(5) 条记录在泄露登记册中。
  • 总分 7-15 分:泄露可能造成风险——必须在 72 小时内通知主管监管机构。
  • 总分 16 分或以上:泄露可能造成高风险——必须在 72 小时内通知主管监管机构,并根据第 34 条通知数据主体。

必须包含的通知内容——第 33(3) 条

向主管监管机构提交的通知至少必须包含:

(a) 违规性质
  • 个人数据违规的性质说明。
  • 涉及的数据主体类别(例如,客户、员工、患者)。
  • 涉及的数据主体的大致人数。
  • 涉及的个人数据记录类别(例如,姓名、电子邮件地址、金融账户号码)。
  • 涉及的个人数据记录的大致数量。
(b) DPO 联系方式
  • 数据保护官姓名:Dr. Elena Vasquez
  • 电子邮件:[email protected]
  • 直拨电话:+49 30 7742 8001
  • 邮寄地址:Stellar Payments Group, Friedrichstraße 191, 10117 Berlin, Germany
(c) 可能造成的后果
  • 按以下类别详细说明违规可能造成的后果:
    • 身体伤害(如适用)
    • 物质损害(经济损失、欺诈风险)
    • 非物质损害(精神痛苦、歧视、声誉受损)
    • 失去对个人数据的控制
    • 权利受限
(d) 已采取或拟采取的措施
  • 已实施的即时遏制措施
  • 减轻对数据主体不利影响的措施
  • 计划中的长期补救措施
  • 是否已或将依据第 34 条通知数据主体

分阶段通知

第 33(4) 条允许在无法同时提供所有详细信息时分阶段提供信息。初始通知必须:

  1. 声明将随后提供更多信息。
  2. 说明延迟提供完整信息的原因。
  3. 包含初始通知时可获得的所有信息。
  4. 随着更多详细信息的获取及时补充,且不得造成不必要的进一步延迟。

监管机构的通知渠道

监管机构管辖范围通知方式
BfDI德国(联邦)在 bfdi.bund.de 在线门户提交电子表单
CNIL法国通过 notifications.cnil.fr/notifications 在线通知
ICO英国在 ico.org.uk/for-organisations/report-a-breach 填写在线表单
DPC爱尔兰通过 forms.dataprotection.ie 提交在线违规通知表单
AEPD西班牙通过 sedeagpd.gob.es 电子提交
Garante意大利通过 PEC(认证电子邮件)发送至 [email protected]
AP荷兰在 autoriteitpersoonsgegevens.nl/meldplicht-datalekken 填写在线表单

72 小时期限的计算规则

  1. 72 小时期限按连续小时计算,包括周末和公共假日。
  2. 如果在周五 CET 时间 14:30 发现违规,截止时间为下周一 CET 时间 14:30。
  3. 第 33(1) 条使用了“可行时”这一表述——如果通知超过 72 小时,控制者必须在提交通知时一并说明延迟原因。
  4. EDPB 已确认,72 小时期限从控制者“知悉”违规时开始计算,而非从违规发生时开始计算。

逾期通知——说明延迟原因

如果通知超过 72 小时,第 33(1) 条要求控制者在提交通知时一并说明延迟原因。根据 EDPB 指引,可接受的理由包括:

  • 需要进行复杂的取证调查,以确定影响范围和受影响的数据类别
  • 大规模违规需要在通知前与执法部门协调
  • 在关键人员无法履职且未作出适当授权安排的期间发现违规(不过,这种情况本身可能表明存在合规缺口)

不可接受的理由:

  • 内部审批流程导致签署延迟
  • DPO 正在休年假,且未指定副手
  • 组织希望先完成自身的公开沟通,再通知监管机构

通知后的义务

  1. 补充信息:一旦可以获得初始通知中尚未提供的详细信息,请及时补充。
  2. 更新违规记录:在第 33(5) 条规定的记录中,记录违规事件的完整详情、影响及补救措施。
  3. 数据主体通知评估:确定是否还需要依据第 34 条向个人发出通知。
  4. 与监管机构沟通:及时回应监管机构的任何后续问询。
  5. 补救措施证明材料:记录已实施的所有纠正措施,并在监管机构要求时提供证明材料。

评论

支持 Markdown