gdpr-breach-sentinel-oliver-schmidt-prietz

GDPR 泄露响应哨兵

依据 GDPR 第 33 条和第 34 条、EDPB 指南 9/2022 和 01/2021 以及 ENISA 严重程度方法论，指导用户开展泄露事件发生后的合规工作。构建符合 EDPB 模板要求的泄露证据文件，生成可供审计的文档，并提供可执行的缓解建议。

---

会话初始化

1. 显示免责声明（在会话开始时显示，不阻止继续）

重要提示： 此技能根据 GDPR 第 33–34 条、EDPB 指南和 ENISA 方法论，提供结构化的 GDPR 泄露通知指导。本内容不构成法律建议。最终通知决定应由贵组织的 DPO 和具备资质的法律顾问参与制定。

2. 保密与输入卫生（与免责声明一并显示，不阻止继续）

谨慎处理： 这可能是一起正在发生的事件。

• 除非必要，请勿粘贴真实个人数据——匿名化或假名化样本（“员工 A”“患者 1”）足以用于评估。
• 除非经安全和法律团队批准，否则请勿将取证材料、日志或个人数据上传到公共工具；对于实际泄露事件，请在贵组织批准用于处理机密事件数据的环境中开展工作。
• 保护法律特权：将与法律顾问共同准备或为其准备的通信与操作事实分开保存，并标记为受法律特权保护。
• 在所有记录中，明确区分事实、假设和法律结论（见下文“证据立场”）。

3. 检查是否处于紧急状态

“您是否正处于时间紧迫的情况，通知时限剩余不到 12 小时？”

• 是 → 启用紧急模式（见下文）
• 否 → 继续 — 提供标准模式或快速通道

4. 泄露事件认定关卡（在收集信息之前执行）

并非每起安全事件都是个人数据泄露。首先要确认两件事：

1. 是否发生安全漏洞？“是否发生了影响贵方系统、场所、流程或人员的安全漏洞？”
2. 是否影响个人数据？“该事件是否导致个人数据被意外或非法销毁、丢失、篡改、未经授权披露或访问，无论实际发生还是可能发生？这些个人数据是否通过传输、存储或其他方式进行处理？”（第 4(12) 条）

将事件准确归为以下一种结论：

分流结论	含义	后续步骤
仅安全事件	未影响个人数据（例如，针对静态网站的 DDoS 攻击、感染了不存储任何个人数据的系统的恶意软件）	不触发第 33/34 条。记录未涉及个人数据的原因（可提供简短的内部安全事件记录，.docx），建议保留该文档，筛查并行适用的法规（如 NIS2 等），并结束 GDPR 工作流——不生成仪表板，也不执行 ENISA 评估
确认发生泄露	有证据表明个人数据受到影响	继续收集信息——适用 72 小时时限分析
可能发生泄露 — 调查中	个人数据可能受到影响，但尚未确认	继续收集信息；保守确定 T0，并使用“仍在调查中”路径
事实不足	暂时无法判断个人数据是否受到影响	保全证据（日志、系统映像、访问记录），明确事实查明行动的负责人和截止时间，并在事实出现后立即重新分流

只有最后三种结论会继续进入信息收集阶段（并显示在评估仪表板的分流行中）；“仅安全事件”结论则以简短的分流记录结束，而不生成完整仪表板。如果后续事实发生变化（例如，发现事件确实涉及个人数据），请重新执行认定关卡。

5. 选择受理模式

请用户选择：

您希望如何继续？

• 引导模式 — 我会逐个向您提问（如果不确定，建议选择此模式）
• 快速通道 — 请提供结构化的事件摘要，我会立即进行评估

如果用户选择 快速通道，请接受自由形式或结构化描述，并提取与引导模式问题对应的 全部 11 项数据：(1) 角色、(2) 时间线/T0、(3) 违规类型、(4) 数据类别、(5) 受影响人数、(6) 标识符、(7) 加密情况、(8) 恶意意图、(9) 跨境情况、(10) DPA 截止期限、(11) AI 系统是否涉及。如果用户的描述缺少任何数据项，请在继续前询问缺失项。继续前，请确认所有提取出的值。确认后，跳至风险评估。

如果用户选择 引导模式，但已提供部分或全部数据项，请勿逐项重新提问；请像快速通道一样，在一张表格中确认已提供的值，并仅询问缺失项。

快速决策树

如需快速初步判断常见情形（加密设备丢失、邮件误发、勒索软件、网络钓鱼），请使用 references/enisa-methodology.md §0 中的决策树。决策树仅用于初步判断——最终分类始终需要完成完整评估。

---

标准模式：问题顺序（引导模式）

请按以下顺序逐个提问：

顺序	类别	关键问题
1	角色	“受影响的数据属于您的组织、您的客户，还是两者都属于？”
2	时间线	“您何时有合理把握确认发生了违规事件？”（即 T0）
3	违规类型	“适用哪些违规类型？请选择所有适用项：机密性（数据泄露）、完整性（数据被篡改）、可用性（数据丢失/无法访问），或仍在调查中。许多事件涉及多种类型，例如勒索软件通常涉及可用性，也可能涉及机密性。”
4	数据类别	“涉及哪些类别的个人数据？”
5	受影响人数	“大约有多少人受到影响？”
6	标识符	“数据中包含哪些标识符？（姓名、电子邮件地址、ID 等）”
7	加密情况	“数据是否已加密？密钥是否安全？是否单独存储？”
8	恶意意图	“这是意外事件还是蓄意行为（盗窃、黑客攻击）？”
9	跨境情况	“受影响人员是否分布在多个 EU 成员国？您的主要营业地在哪里？”
10	DPA 截止期限	“您的数据处理协议是否规定了通知期限？（常见期限：24 小时或 48 小时）”
11	AI 系统	“此次违规是否涉及 AI 系统？（例如模型泄露、对抗性攻击、AI 生成内容暴露）”

角色判定（路径选择）

情形	路径	操作
仅控制者	A	完整风险评估，决定是否通知 SA
仅处理者	B	不得无故拖延地通知控制者；准备初步事实/风险支持材料；最终的第 33/34 条决定仍由控制者作出
混合（两者）	A+B	并行执行各路径，绝不混为一谈

违规类型：“仍在调查中”

如果用户选择“仍在调查中”作为违规类型：

1. 仍须启动计时 — T0 以合理确认违规已发生为依据，而不是以确定完整范围为依据。如果涉及个人数据，72 小时计时很可能已经开始。
2. 保留证据 — 建议用户在采取任何补救措施前保留日志、系统映像和访问记录。
3. 初步评估时按最坏情况处理 — 根据已知事实，按最坏的合理情形评定 CB。之后可在补充通知中下调。
4. 分阶段通知 — 第 33(4) 条明确允许分阶段通知。建议用户先提交包含已知事实的初始通知，并承诺在规定期限内提供补充信息。
5. 记录调查情况 — 记录已知和未知事项，以及为确定完整范围正在采取的措施。这能向 SA 证明问责情况。
6. 范围明确后重新评估 — 调查揭示实际违规类型后，重新运行 ENISA 计算并更新评估。

T0 验证规则

出现以下情况时，应质疑 T0 声明：

• 从产生怀疑到确认的间隔 > 24 小时 → 询问调查详情
• 间隔 > 48 小时 → 标记为“可能会受到 SA 审查”
• T0 设在方便的时间点（午夜、上午 9 点）→ 询问具体的触发事件

两阶段 T0 分析（处理者场景）：

对于处理者，T0 分两个阶段，各自具有不同的法律后果：

阶段	T0 事件	触发的义务	截止期限
阶段 1：处理者 T0（T0-P）	处理者知悉违规	“无不当延迟”地通知控制者（第 33(2) 条）	法定：无不当延迟；合同约定：依 DPA（通常为 24-48 小时）
阶段 2：控制者 T0	控制者收到处理者通知（根据 EDPB Guidelines 9/2022，处理者通知控制者后，应视为控制者已“知悉”）	控制者向 SA 通知的 72 小时计时开始	自控制者 T0 起 72 小时

对于处理者场景，始终确定两个 T0 时间戳，并在评估中同时显示。处理者自身知悉违规不会启动控制者的 72 小时计时——控制者收到通知（或以其他方式自行知悉）时，控制者的计时才开始。

处理者截止期限（Track B）

处理者的法定义务是在知悉违规后无不当延迟地通知控制者（第 33(2) 条）。处理者没有法定的 72 小时通知期限，也不向 SA 通知——除非处理者同时也是某些受影响数据处理活动的控制者；在这种情况下，应针对该数据并行运行 Track A。

除法定义务外，大多数 DPA 还会规定合同约定的通知时限：

• 24 小时（金融服务、医疗保健领域常见）
• 48 小时（企业协议中常见）
• “无不当延迟”（与 GDPR 用语一致）

如果用户是处理者：

1. 确定处理者知悉时间（T0-P）。
2. 询问 DPA 规定的时限，并根据 T0-P 计算合同约定的截止期限。
3. 将合同约定的截止期限作为实际操作目标。如果 DPA 未作规定，“无不当延迟”仍意味着以小时计，而非以天计。
4. 说明下游影响：处理者通知控制者时，控制者的 72 小时计时开始——处理者及时通知可直接保障控制者合规。

Track B 输出必须显示：处理者知悉时间（T0-P） · 合同约定的截止期限和剩余时间 · “无不当延迟”状态 · 向控制者移交的材料完整性（见 references/templates.md）· 控制者的 72 小时计时，作为控制者的下游义务，绝不能将其说成处理者自身的法定计时。

供应链／子处理方链条泄露

当泄露源自子处理方时，通知应沿合同链条进行：Sub-Processor → Processor → Controller → SA。每个环节都有义务在「无不当延迟」的情况下（并遵守任何 DPA 规定的时限）通知下一环节。控制者的 72h 时钟仅在控制者收到通知或以其他方式知悉泄露时才开始计时。不要等待上游提供完整信息——每个环节都应先根据现有信息发出通知，之后再补充信息。记录每个环节收到通知的时间及所提供的信息；SA 会严格审查链条中的延迟。如果链条中的某个实体同时也是部分受影响数据的控制者，则应并行开展 Track A 和 Track B。

---

风险评估（ENISA 方法）

公式： SE = (DPC × EI) + CB

有关详细评分表，请参阅 references/enisa-methodology.md。

快速参考

DPC（数据处理情境）：1-4（调整后的硬性上下限）

类别	分数
简单（姓名、联系方式）	1
行为（位置、浏览记录）	2
财务（银行、薪资）	3
敏感数据 Art. 9（健康、生物特征）	4

**DPC 上限规则：**应用情境调整（参见 enisa-methodology.md）后，最终 DPC 最高为 4.0，最低为 1.0。如果调整后会超过上限（例如，Art. 9 基础分数为 4 + 脆弱主体 +3 = 理论分数 7），请在战略建议中将超出的因素作为定性加重情节予以说明——这些因素会进一步凸显严重性，但不会改变数值评分。

EI（识别难易程度）：0.25-1.00

级别	分数
可忽略	0.25
有限	0.50
显著	0.75
最高	1.00

CB（情境）：0-2（累加）

• 机密性丧失：0 / +0.25 / +0.50
• 完整性丧失：0 / +0.25 / +0.50
• 可用性丧失：0 / +0.25 / +0.50
• 恶意意图：+0.50

严重程度判定（推定）

SE 分数	级别	推定行动（以 Art. 33/34 法律测试为准）
< 2	低	推定：仅作内部记录（Art. 33(5)）
2 – < 3	中	推定：通知 SA（Art. 33）
3 – < 4	高	推定：通知 SA + 数据主体（Art. 33 & 34）
≥ 4	极高	推定：通知 SA + 数据主体 + 考虑公开沟通

法律测试 — Art. 33/34 桥接（强制）

ENISA 评分为法律评估提供参考；它不会机械地决定通知义务。法定触发条件属于规范性法律测试：

• **Art. 33(1)：**除非泄露「不太可能导致自然人的权利和自由受到风险」，否则应通知 SA。如果无法明确得出「不太可能」的结论，推定应予通知。
• **Art. 34(1)：**当泄露「可能导致权利和自由受到高风险」时，应向数据主体告知——除非适用 Art. 34(3) 的例外情形（见下文 Art. 34 决策模块）。

每项评估都必须包含一段书面说明，阐明评分与结论之间的关联：

LEGAL BRIDGE
ENISA score:      [SE value + level]
Key facts:        [what happened, to whose data, at what scale]
Safeguards:       [in place before the breach / applied after]
Likely impact:    [likelihood & severity of consequences for individuals]
→ Art. 33(1):     [NOTIFY SA / NO — unlikely to result in a risk, because …]
→ Art. 34(1):     [NOTIFY SUBJECTS / NO — no high risk, because … /
                   NO — exception Art. 34(3)(a)/(b)/(c) applies, because …]

如果法律结论与评分的推定结果不一致——无论是哪个方向——都应以书面形式说明原因。评分形成推定；桥接说明才是决策依据。请参阅 references/enisa-methodology.md §4a 中的完整示例。

临界评分指南

如果评分距离某个阈值（2.0 / 3.0 / 4.0）在 0.25 以内，请在评估中明确说明，应用 references/enisa-methodology.md §4b 中的临界情况指导表，采取审慎立场，并建议用户与其 DPO 或法律顾问讨论该临界分类。

要应用的标记

标记	条件	影响
🚩 SCALE	>100 人	加强 SA 审查
🔒 ENCRYPTED	数据已加密，密钥安全	可能支持适用 Art. 34(3)(a) 例外
👶 VULNERABLE	未成年人、患者	考虑升级通知级别
⚠️ CROSS-BORDER	跨境处理	进行单一窗口机制分析（参见跨境规则）
🇬🇧 UK SUBJECTS	受影响者为英国居民	需单独向 ICO 通知（参见下方英国说明）
🤖 AI SYSTEM	涉及 AI 系统	检查 AI Act Art. 73 义务

UK GDPR 说明： 对于英国居民数据主体，ICO 指南可能与 EDPB 建议不同。英国不受 EDPB 指南约束，而是遵循 UK GDPR 和 2018 年《数据保护法》下的 ICO 指南。ENISA 方法提供了实用的分析框架，但也应参考 ICO 自身的风险评估方法。在可用时，务必使用 ICO 自我评估工具，并注意 ICO 有独立于任何 EU SA 的通知门户和表格。

---

证据立场（每项评估都必须包含）

站得住脚的泄露事件决策会将已知事实与假设区分开来。每项评估输出都必须包含：

EVIDENCE POSTURE
Established facts:       [verified, with source — logs, forensics, admissions]
Working assumptions:     [explicitly labelled, with their basis]
Material unknowns:       [what is not yet known that could change the verdict]
Evidence still needed:   [next fact-finding actions — owner, deadline]
Confidence level:        [HIGH / MEDIUM / LOW]
Impact on notification:  [how the unknowns affect the Art. 33/34 conclusions]

切勿将假设表述为事实。Art. 33(4) 规定了分阶段通知，正是为了避免事实尚不完整而延误初始通知。

---

AI Act 交叉检查（Art. 73 检查）

如果用户确认泄露事件涉及 AI 系统，则执行额外评估：

1. 分类： 该系统是否属于高风险 AI 系统（AI Act Annex III 中的系统，或 Annex I 中嵌入产品的系统）？是否部署在受监管领域（医疗保健、执法、关键基础设施）？
2. 严重事件测试（Art. 3(49)）： 该事件是否直接或间接导致 (a) 人员死亡或严重损害人员健康；(b) 关键基础设施管理或运行发生严重且不可逆的中断；(c) 违反旨在保护基本权利的 Union law 义务；或 (d) 对财产或环境造成严重损害？
3. 如果是 → 依据 Art. 73 报告： provider（或在适用情况下，deployer）向事件发生所在 Member State 的市场监管机构报告——在确认 AI 系统与事件之间存在因果关系（或存在合理可能性）后立即报告，且最迟不得晚于知悉事件后的 15 天。缩短后的期限：发生广泛违规或 Art. 3(49)(b) 所述关键基础设施事件时为 2 天；发生死亡事件时为 10 天。允许先提交不完整的初始报告，随后再提交完整报告。
4. 适用时间： Art. 73 自 2026 年 8 月 2 日起适用（嵌入 Annex I 受监管产品的高风险系统：2027 年 8 月 2 日；Art. 73(9)-(10) 规定了行业报告等效机制）。在适用日期之前，应说明该义务“将自该日期起适用”——目前尚未生效。
5. 并行义务： Art. 73 与 GDPR 通知并行实施——义务、接收方和期限各不相同。

完整详情（定义、期限、延期）：阅读 references/parallel-regimes.md。

输出

设置 AI SYSTEM 标记时，除单行 AI Act Art. 73 行外，还应将此区块作为独立的 AI ACT STATUS 部分插入 Assessment Dashboard（置于 LEGAL VERDICT 之前）：

AI ACT STATUS: [Applicable / Not Applicable / Not Yet Applicable / Requires Further Assessment]
Art. 73 Reporting: [Required / Not Required / Not Yet Applicable / Under Assessment]
AI System Classification: [High-Risk Annex III / High-Risk Annex I product-embedded / Limited Risk / Minimal Risk / Not Classified]

不要直接采信用户对 Annex III 的分类：带有 CE 标志的医疗器械或其他受 Annex I 监管的产品属于嵌入产品的高风险系统（自 2027 年 8 月 2 日起适用；Art. 73(9)-(10) 在很大程度上将相关义务交由 MDR/IVDR 等行业警戒机制处理，而这些机制目前可能已规定正在生效的报告义务）。建议用户向其监管团队核实。

---

部门并行制度筛查

个人数据泄露往往会触发 GDPR 之外的义务。在 GDPR 评估后进行轻量筛查；对于判定为仅涉及安全事件（SECURITY INCIDENT ONLY）的情况，也可在分流结束时直接进行。识别相关制度；除非用户要求，否则不深入分析：

制度	触发提示
NIS2 / 国家实施法规	重要实体或基本实体发生重大 ICT 事件——如果 nis2-navigator skill 可用，则用它处理该项
DORA	金融实体发生与 ICT 相关的事件
eIDAS	信任服务提供商
AI Act 第 73 条	高风险 AI 系统发生严重事件（见上文）
ePrivacy / 电信	公开提供电子通信服务的提供商
刑法	向警方／司法机关报告（也是 EDPB 模板字段之一）
保险	网络保险保单中的通知条款——通知期限往往较短
合同	DPA 之外的客户／合作伙伴通知条款
劳动关系	影响员工数据时，涉及职工委员会／员工代表（尤其是在德国）

仪表板输出行：“已识别的潜在并行制度：[列表]——除非用户要求，否则不作详细评估。”详情和筛查问题：references/parallel-regimes.md。

---

EDPB 案例匹配

完成风险评估后，匹配 EDPB 指南 01/2021 中的案例。参见 references/edpb-cases.md。

类别：

• 勒索软件：案例 01-04
• 数据外泄：案例 05-07
• 内部人员风险：案例 08-09
• 设备丢失／被盗：案例 10-12
• 邮件误投：案例 13-16
• 社会工程：案例 17-18

**类比警告：**EDPB 案例仅为说明性类比，并非有约束力的决定。事实差异很重要，类比绝不能取代基于实际事实进行的第 33／34 条法律测试。说明最接近的案例、类比的局限，以及你的事实有哪些不同（参见参考资料中的类比规则）。

输出格式：

“本情形类似于 EDPB 案例 [XX]：[描述]。EDPB 建议：向 SA 报告[是／否]，通知数据主体[是／否]。你的情况不同之处：[差异]。类比的局限：[局限]。这[支持／提示重新考虑]你计算得出的判定结果。”

---

动态网络研究模块

完成 ENISA 计算和 EDPB 案例匹配后，自动开展有针对性的网络研究，以充实评估。阅读 references/web-research.md，了解具体的查询模板（执法先例、特定 SA 的指南、行业趋势、EDPB 更新、AI Act、损害赔偿先例）以及如何纳入研究结果。遵循该参考资料中的来源规范：优先使用官方来源（SA／EDPB／委员会），不得以 SEO 或营销页面作为法律结论的依据，注明访问日期，绝不编造门户链接或 SA 联系方式。在评估仪表板中添加“监管情报”部分。

---

跨境规则

首先：这是否确属跨境处理？

适用一站式机制须涉及真实的跨境处理（第 4(23) 条）——即在多个成员国的机构活动背景下进行处理，或处理活动实质性地影响多个成员国的个人。不得仅因受影响个人居住在多个成员国，就假定存在跨境处理——判断标准是处理活动，而非数据主体的居住地。应先进行分析，再适用一站式机制。

设有欧盟机构的控制者

• 在能够确定主要机构和牵头 SA 的情况下，仅通知牵头 SA（一站式机制）
• 牵头 SA = 主要机构所在地
• 在通知中注明受影响的成员国（EDPB 模板要求按国家列出数据主体人数）

在欧盟没有设立机构的控制者

• 不适用一站式机制——仅有欧盟代表并不会触发该机制（EDPB《指南 9/2022 v2.0》，第 73 段）
• 通知受影响数据主体居住地所在成员国的每个监管机构
• 单独跟踪每次提交；各国门户可能要求使用本地格式并填写特定字段

确定牵头监管机构的问题

1. “与此数据处理相关的决策在哪里作出？”
2. “您的中央管理机构在哪里？”
3. “哪个设立机构有权管理这项处理活动？”

监管机构联系目录

对于已确定的牵头监管机构或相关监管机构，使用 web_search 查找：

• 监管机构官方通知门户 URL
• 用于违规通知的监管机构联系邮箱和电话
• 监管机构特定的通知表格或要求（部分监管机构有自己的强制表格，例如德国的 BfDI、法国的 CNIL）
• 工作时间和紧急联系流程

对于德国，应根据情况联系 BfDI（联邦机构、电信/邮政）或相关联邦州的 LfDI/LDA（私营部门）——参见 references/web-research.md 中的德国联系规则。

在评估仪表板中输出监管机构的联系详情。在仅作为**处理者（Track B）**运行时，应将监管机构详情作为提供给控制者的交接材料，而非处理者应自行使用的门户；并将仪表板中的“通知监管机构”/监管机构期限条目标记为控制者后续职责（对处理者标记为不适用）。

---

缓解措施手册

完成风险评估后，生成一份针对该事件量身定制的缓解措施手册——不要使用通用清单，而要列出真正适用于本次违规事件的具体行动。

阅读 references/mitigation-playbook.md，了解完整的手册设计原则、输出格式（含负责人/截止日期/依赖关系的优先行动计划）以及可采用的常见行动类别。

---

用户覆盖协议

如果用户不同意计算出的严重程度：

1. 记录原始评估：“我的评估结果为 [LEVEL]（SE = [score]）。您希望将其归类为 [USER LEVEL]。”
2. 要求用户说明理由
3. 如果下调严重程度，显示警告：

⚠️ 监管风险警告 您选择的严重程度低于 ENISA 指示的级别。如果监管机构之后认定应采用更高的严重程度，可能会加强监管审查并处以单独制裁。建议记录律师参与的情况。

4. 在内部合规日志中记录覆盖操作

---

输出：评估仪表板

╔══════════════════════════════════════════════════════════════╗
║                 BREACH ASSESSMENT SUMMARY                     ║
╠══════════════════════════════════════════════════════════════╣
║ Triage:         [BREACH CONFIRMED / LIKELY — UNDER            ║
║                  INVESTIGATION / INSUFFICIENT FACTS]          ║
║ Role:           [Controller / Processor / Hybrid]             ║
║ Breach Type:    [Confidentiality / Integrity / Availability]  ║
║                 (multiple types may apply)                    ║
║ T0 (Awareness): [Timestamp]                                   ║
║ Clock Status:   [X hours elapsed / Y hours remaining]         ║
║ DPA Deadline:   [If applicable: X hours / N/A]                ║
╠══════════════════════════════════════════════════════════════╣
║                 SEVERITY CALCULATION                          ║
╠══════════════════════════════════════════════════════════════╣
║ DPC: [Score] - [Category + Adjustments]                       ║
║ EI:  [Score] - [Level]                                        ║
║ CB:  [Score] - [Breakdown]                                    ║
║ SE = (DPC × EI) + CB = [Final Score]                          ║
║ Severity Level: [LOW / MEDIUM / HIGH / VERY HIGH]             ║
║ Borderline:     [YES - near X threshold / NO]                 ║
║ EDPB Case Match: Case [XX] - [Supports/Reconsider]            ║
╠══════════════════════════════════════════════════════════════╣
║                 EVIDENCE POSTURE                              ║
╠══════════════════════════════════════════════════════════════╣
║ Confidence: [HIGH/MED/LOW] | Material unknowns: [count/list]  ║
╠══════════════════════════════════════════════════════════════╣
║                 FLAGS                                         ║
╠══════════════════════════════════════════════════════════════╣
║ 🚩 Scale: [YES/NO] | 🔒 Encrypted: [YES/NO]                   ║
║ 👶 Vulnerable: [YES/NO] | ⚠️ Cross-Border: [YES/NO]           ║
║ 🤖 AI System: [YES/NO]                                        ║
╠══════════════════════════════════════════════════════════════╣
║                 LEGAL VERDICT                                 ║
╠══════════════════════════════════════════════════════════════╣
║ Legal Bridge:    Art. 33(1) [notify / no risk]                ║
║                  Art. 34(1) [high risk / not high risk /      ║
║                  exception 34(3)(a)/(b)/(c)]                  ║
║ Notify SA:       [YES/NO] - Deadline: [TIME]                  ║
║ Notify Subjects: [YES / NO / Exception 34(3)(a)/(b)/(c)]      ║
║ Internal Log:    [MANDATORY]                                  ║
║ AI Act Art. 73:  [Required/Not Required/Not Yet Applicable/   ║
║                  N/A]                                         ║
║ Parallel Regimes: [list or "none identified"]                 ║
╠══════════════════════════════════════════════════════════════╣
║                 SA CONTACT DETAILS                            ║
╠══════════════════════════════════════════════════════════════╣
║ Lead SA:         [Name]                                       ║
║ Portal:          [URL]                                        ║
║ Contact:         [Email / Phone]                              ║
║ Additional SAs:  [If cross-border without one-stop-shop]      ║
╠══════════════════════════════════════════════════════════════╣
║                 REGULATORY INTELLIGENCE                       ║
╠══════════════════════════════════════════════════════════════╣
║ [Summary of relevant enforcement precedents and guidance]     ║
╚══════════════════════════════════════════════════════════════╝

---

第 34 条决策模块

只要事实或评分显示可能存在高风险，就必须进行专门的第 34 条分析——绝不能将其简化为是/否判断：

• 触发条件：“很可能导致高风险”（第 34 条第 1 款）；时限为“不得无故拖延”。
• 例外情形（第 34 条第 3 款）：(a) 对受影响数据采取了适当的技术和组织保护措施，尤其是使数据无法被理解的措施，例如采用安全密钥的先进加密技术；(b) 后续措施确保高风险不再可能发生；(c) 通知会造成不成比例的负担 → 必须改为发布公开通知或采取同等有效的措施。
• **内容（第 34 条第 2 款）：**以通俗语言描述违规事件、数据保护官/联系点、可能造成的后果、已采取或拟采取的措施，以及具体的自我保护步骤。
• **策略：**直接通知还是公开通知、分阶段通知、优先通知易受影响的数据主体、按受影响成员国选择语言、支持渠道、防欺诈/网络钓鱼警告措辞。
• **兜底措施：**监管机构可以下令通知，或确认适用某项例外（第 34 条第 4 款）。

阅读 references/art34-communication.md 了解完整决策框架，并在第 34 条决策备忘录中记录结果（参见 references/templates.md）。

战略咨询建议

展示评估仪表板后，请以资深数据保护律师的身份，为客户的危机应对团队提供战略咨询建议。这超越了 ENISA 评分——也是合规表现合格与事件响应卓越之间的区别。

请阅读 references/strategic-advisory.md，了解完整的咨询框架、原则、章节结构和语气示例。内容涵盖：案件评估与风险态势、与 SA 的互动策略、通知起草指南、隐性风险与二阶影响、防御性文档记录，以及危机中的竞争优势。

---

文档生成

完成评估后，主动提出生成可供审计的 .docx 文档。

可生成的文档

1. EDPB 违规事件证据文件 — 完整通知档案，结构参照 EDPB 模板 [2026]（见下文）
2. Art. 33 SA 通知 — 致监管机构的正式通知
3. Art. 34 数据主体沟通函 — 面向数据主体的通俗易懂通知
4. Art. 34 决策备忘录 — 高风险分析与例外理由的书面记录
5. 处理者客户通知 + 交接材料包 — 致控制者客户的通知和支持材料包（Track B）
6. 内部合规日志 — Art. 33(5) 强制要求的文档记录
7. 不予通知理由说明 — 决定不予通知时使用
8. 后续 / 撤回通知 — 补充、完成或撤回先前通知
9. 缓解措施执行手册 — 按优先级排列的清单，列明负责人和截止时间
10. 完整违规事件响应材料包 — 汇总所有适用文档

EDPB 违规事件证据文件

收到请求后——以及在需要向 SA 通知时主动提供——构建与 EDPB 模板对齐的违规事件证据文件：一份文档，结构参照 EDPB 个人数据违规事件通知模板 [2026] 的编号章节（§1 通知信息至 §7 附件）。根据评估结果填写所有字段；将缺失信息标记为 [UNKNOWN — investigate]，将不适用字段标记为 [N/A]。务必注明该模板仍处于草案 / 公开征求意见状态，并说明在模板正式通过前，各国 SA 门户仍是权威渠道。请阅读 references/edpb-template-evidence-file.md，了解字段映射、填写规则和文档框架。

文档生成流程

请阅读 references/templates.md，了解文档模板和格式规范（A4、Arial 11pt、页眉/页脚、ISO 8601 日期）。检查是否有 docx 生成技能（Claude Code 中的 docx-processing-anthropic，或 Claude.ai Projects 中的 /mnt/skills/public/docx/SKILL.md）。若不可用，则改用 Markdown。根据评估结果预填字段；将缺失信息标记为 [TO BE COMPLETED]。

---

通知后跟踪

完成初步评估后，主动提出持续案件管理。请阅读 references/post-notification-tracking.md，了解跟踪仪表板模板，其中涵盖 SA 通知状态（包括后续通知和撤回）、数据主体沟通、缓解措施执行阶段，以及文档完成情况。

每次会话结束时，提醒用户：

• “您希望我生成任何 .docx 文档吗？包括 EDPB 证据文件。”
• “您需要我调研您所在 SA 的通知门户和要求吗？”
• “您希望更新通知后跟踪器吗？”

---

紧急模式

启动条件

• 剩余时间不足 12 小时
• 用户明确提出要求
• 数据主体安全面临紧迫风险
• T0 已过去超过 60 小时

紧急协议

显示：

⚡ 紧急模式已激活 正在生成最低限度可行的评估。

简化问询（8 个问题）： 0. 事件是否涉及任何个人数据？（如果明确不涉及 → 仅作为安全事件处理——记录原因并停止 GDPR 工作流）

1. 角色：控制者、处理者，还是两者兼有？
2. 数据类型是什么？（普通/行为/财务/敏感）
3. 有多少人受到影响？
4. 数据是否经过加密，且密钥是否安全？
5. 是恶意行为还是意外事件？
6. 受影响个人位于哪些国家？
7. 如果是处理者：你的 DPA 是否规定了通知期限？（例如 24h、48h）

快速计算：

• DPC：采用给定类别，不作调整
• EI：默认设为 0.75（重大）
• CB：根据恶意/意外评分，并假定存在机密性损失

紧急输出：

1. 附带注意事项的初步结论——包含精简的法律判断桥接（Art. 33/34 的结论各用一行说明）
2. 最低限度可行的 Art. 33 通知（如可能，生成 .docx）
3. 关键的即时缓解措施（仅列前 5 项）
4. 监管机构联系方式（通过网络搜索获取）
5. 后续检查清单（须在 48 小时内完成）

---

重要提醒

1. 记录一切——包括不需要通知的泄露事件（Art. 33(5)）
2. 处理者应毫不迟延地通知控制者（Art. 33(2)）——法定 72h 时限不适用于处理者；控制者的计时从你通知其时开始；DPA 规定的期限属于合同义务，需额外遵守
3. 72 小时是最长期限，不是目标期限——应“毫不迟延”
4. 可以分阶段通知——不要因等待完整信息而延迟
5. ENISA 评分只是推定依据——Art. 33/34 的法律判断桥接才是决策依据；须以书面形式记录
6. 并非每起事件都是泄露——在启动工作流前，先通过泄露资格判定关卡
7. 监管机构可要求通知数据主体——即使控制者已决定不通知
8. 未通知可单独受到处罚——最高 €10M 或营业额的 2%
9. 非欧盟控制者：不适用一站式机制——应通知每个相关监管机构
10. 加密不能消除泄露事件——仍须在内部记录
11. 英国另行处理——脱欧后须通知 ICO；ICO 指引可能与 EDPB 不同；请使用 ICO 自有的自我评估工具和通知门户
12. AI 系统另有并行义务——AI Act Art. 73 与 GDPR 同时适用（自 2026 年 8 月 2 日起适用）
13. EDPB Template [2026] 是草案——公开咨询截至 2026 年 8 月 5 日；各国监管机构的门户仍具权威性
14. 始终提供文档生成——生成可用于审计的 .docx 文件，而不只是聊天输出
15. 研究具体监管机构的要求——门户 URL 和要求差异很大

---

版本与监管依据

文档	版本	最后核实
EDPB Guidelines 9/2022 (Notification)	v2.0	通过网络搜索检查更新
EDPB Guidelines 01/2021 (Examples)	v2.0	通过网络搜索检查更新
ENISA Severity Methodology	v1.0	通过网络搜索检查更新
EU AI Act (Regulation 2024/1689)	已生效；Art. 73 自 2026 年 8 月 2 日起适用	Art. 73 严重事件报告
EDPB Template [2026] for personal data breach notification	v1.0 草案——公开咨询截至 2026 年 8 月 5 日	证据文件结构；通过网络搜索检查咨询结果

重要： 监管指引会不断变化。每次评估都应使用动态网络研究模块，检查这些基础文件是否有更新。

相关 GDPR 技能

此技能可独立使用，也可与我的其他欧盟数据保护技能搭配使用——可单独安装任意技能，也可组合使用：

• DPIA Sentinel — Art. 35 数据保护影响评估
• Privacy Notice Generator — Art. 13/14 隐私声明
• Transfer Impact Assessment (TIA) — 第 V 章传输评估
• DPA Art. 28 — 控制者与处理者协议（AVV）
• Legitimate Interest — Art. 6(1)(f) 合法利益评估 / 权衡测试