Gdpr Breach Sentinel Oliver Schmidt Prietz

---
name: gdpr-breach-sentinel-oliver-schmidt-prietz
description: |
  面向 GDPR 第 33 条和第 34 条下数据泄露的一流事件响应与法律合规指引。在以下情形使用：(1) 用户报告数据泄露或安全事件——包括"这到底算不算个人数据泄露？"的分诊，(2) 用户询问违规通知义务或截止期限，(3) 用户提及"72 小时"、第 33 条、第 34 条或通知要求，(4) 讨论涉及影响个人数据的安全事件，(5) 用户需要采用 ENISA 方法论的违规风险评估，(6) 用户提及"Data Breach"（数据泄露）或"Incident"（事件）或"Data Leakage"（数据泄漏）或"Ransomware"（勒索软件）或"Exfiltration"（数据外泄），(7) 用户需要确定控制者与处理者的义务，(8) 需要确定主导监管机构（Lead SA）的跨境违规场景，(9) 用户需要缓解行动手册或即时响应建议，(10) 用户需要审计就绪的违规文档（.docx）或与 EDPB 模板对齐的违规通知/证据文件——包括后续跟进和撤回通知，(11) 违规涉及 AI 系统，需要进行 AI 法案第 73 条严重事件筛查。
metadata:
  author: Oliver Schmidt-Prietz
  license: AGPL-3.0
  version: 2026.06.11
---

# GDPR 违规响应哨兵（GDPR Breach Response Sentinel）

引导用户完成违规后合规流程，依据 **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](references/enisa-methodology.md) §0 中的决策树。决策树仅作定位——始终完成完整评估以获得确定性分类。

---

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

按以下顺序**一次一个**提问：

| 顺序 | 类别 | 关键问题 |
|-------|----------|--------------|
| 1 | **角色** | "受影响的数据属于贵组织、贵方客户，还是两者兼有？" |
| 2 | **时间线** | "你何时达到对违规已发生的合理确信？"（这就是 T0） |
| 3 | **违规类型** | "适用哪些违规类型？选择所有适用项：机密性（数据被披露）、完整性（数据被篡改）、可用性（数据丢失/无法访问），或**仍在调查中**。许多事件涉及多种类型——例如勒索软件通常同时涉及可用性和可能的机密性。" |
| 4 | **数据类别** | "涉及哪些类别的个人数据？" |
| 5 | **主体数量** | "大约有多少个体受影响？" |
| 6 | **标识符** | "存在哪些标识符？（姓名、电子邮件、ID 等）" |
| 7 | **加密** | "数据是否加密？密钥是否安全？是否分开存储？" |
| 8 | **恶意意图** | "这是意外的还是故意的（盗窃、黑客攻击）？" |
| 9 | **跨境** | "受影响个体是否分布在多个欧盟成员国？你的主要机构在哪里？" |
| 10 | **DPA 截止期限** | "你的数据处理协议（DPA）是否规定了通知窗口？（常见：24 小时或 48 小时）" |
| 11 | **AI 系统** | "这次违规是否涉及 AI 系统？（例如模型泄露、对抗性攻击、AI 生成输出暴露）" |

### 角色确定（路径选择）

| 场景 | 路径 | 行动 |
|----------|-------|--------|
| **仅控制者** | A | 完整风险评估、监管机构通知决定 |
| **仅处理者** | B | 毫不迟延地通知控制者；准备初步的事实/风险支持包；最终第 33/34 条决定仍由控制者作出 |
| **混合（两者）** | A+B | 并行运行两条路径，绝不混淆 |

### 违规类型："仍在调查中"

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

1. **无论如何都启动计时**——T0 基于对违规*已发生*的合理确信，而非对范围的完整确定。如果涉及个人数据，72 小时时限可能已在运行。
2. **保全证据**——建议用户在采取任何补救措施前保全日志、系统镜像和访问记录。
3. **初始评估按最坏情况假设**——基于已知事实按最坏可能场景计算 CB。可在补充通知中下调。
4. **采用分阶段通知**——第 33(4) 条明确允许分阶段通知。建议用户以已知事实提交初始通知，并承诺在确定时限内提供补充信息。
5. **记录调查过程**——记录已知事项、未知事项以及为确定完整范围正在采取的步骤。这向监管机构展示问责性。
6. **范围更清晰时重新评估**——一旦调查揭示实际违规类型，重新运行 ENISA 计算并更新评估。

### T0 验证规则

在以下情形质疑 T0 主张：
- 怀疑与确信之间的间隔 > 24 小时 → 询问调查细节
- 间隔 > 48 小时 → 标记为"可能受到监管机构审查"
- T0 设定在便捷的时间边界（午夜、上午 9 点）→ 询问具体触发事件

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

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

| 阶段 | T0 事件 | 触发的义务 | 截止期限 |
|-------|----------|---------------------|----------|
| **阶段 1：处理者 T0（T0-P）** | 处理者得知违规 | "毫不迟延"通知控制者（第 33(2) 条） | 法定：毫不迟延；合同：按 DPA（通常 24-48 小时） |
| **阶段 2：控制者 T0** | 控制者获处理者告知（依 EDPB《指南 9/2022》，处理者告知后控制者应被视为"已知情"） | 控制者向监管机构通知的 72 小时时限启动 | 自控制者 T0 起 72 小时 |

处理者场景始终要确定两个 T0 时间点并在评估中同时显示。处理者自身的知情*不*启动控制者的 72 小时时限——控制者的时限在其被告知（或以其他方式自行得知）时启动。

### 处理者截止期限（B 路径）

处理者的**法定**义务是在得知后**毫不迟延**地通知控制者（第 33(2) 条）。处理者**没有法定的 72 小时截止期限**，且处理者不通知监管机构——除非它同时是受影响处理中部分数据的控制者，此情形下对该数据并行运行 A 路径。

在法定义务之外，大多数 DPA 增加了**合同性**通知窗口：
- **24 小时**（金融服务、医疗保健中常见）
- **48 小时**（企业协议中常见）
- **"毫不迟延"**（镜像 GDPR 措辞）

如果用户是处理者：
1. 确定处理者知情时间（T0-P）。
2. 询问 DPA 窗口，并自 T0-P 计算合同截止期限。
3. 将合同截止期限视为运营目标。如 DPA 未作规定，"毫不迟延"仍意味着数小时而非数天。
4. 解释下游后果：控制者的 72 小时时限在处理者告知时启动——及时的处理者通知直接保护控制者的合规。

**B 路径输出必须显示：** 处理者知情时间（T0-P）· 合同截止期限及剩余时间 · "毫不迟延"状态 · 控制者交接包完整性（见 [references/templates.md](references/templates.md)）· 控制者的 72 小时时限作为**下游控制者义务**，绝非处理者自身的法定时限。

### 供应链/次级处理者链条违规

当违规源于次级处理者时，通知沿合同链条进行：`次级处理者 → 处理者 → 控制者 → 监管机构`。每一环对下一环负有"毫不迟延"告知义务（外加任何 DPA 窗口）。控制者的 72 小时时限仅在其被告知或以其他方式得知时启动。不要等待上游细节齐全——每一环以现有信息通知，稍后补充。记录每一环被通知的时间和所提供的内容；监管机构会审查链条延误。如果链条中的某实体也是部分受影响数据的控制者，并行运行 A 和 B 路径。

---

## 风险评估（ENISA 方法论）

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

详细评分表见 [references/enisa-methodology.md](references/enisa-methodology.md)。

### 快速参考

**DPC（数据处理情境）：1-4（调整后硬性边界）**
| 类别 | 分值 |
|----------|-------|
| 简单（姓名、联系方式） | 1 |
| 行为性（位置、浏览记录） | 2 |
| 财务（银行、工资） | 3 |
| 第 9 条敏感数据（健康、生物识别） | 4 |

**DPC 上限规则：** 应用情境调整后（见 [enisa-methodology.md](references/enisa-methodology.md)），最终 DPC **上限为 4.0**、**下限为 1.0**。当调整会超出上限时（例如第 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 分值 | 级别 | 推定行动（受第 33/34 条法律测试约束） |
|----------|-------|-------------------------------------------------------|
| < 2 | 低 | 推定：仅内部记录（第 33(5) 条） |
| 2 – < 3 | 中 | 推定：通知监管机构（第 33 条） |
| 3 – < 4 | 高 | 推定：通知监管机构 + 数据主体（第 33 条和第 34 条） |
| ≥ 4 | 极高 | 推定：监管机构 + 主体 + 考虑公开沟通 |

### 法律测试——第 33/34 条衔接（强制）

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

- **第 33(1) 条：** 除非违规"**不太可能对自然人权利和自由造成风险**"，否则应通知监管机构。如果你无法肯定地得出"不太可能"的结论，推定为通知。
- **第 34(1) 条：** 当违规"**可能对权利和自由造成高风险**"时，应向数据主体告知——除非适用第 34(3) 条例外（见下文第 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](references/enisa-methodology.md) §4a。

### 临界分值指引

当分值在阈值（2.0 / 3.0 / 4.0）0.25 以内时，在评估中明确注明，适用 [references/enisa-methodology.md](references/enisa-methodology.md) §4b 的临界指引表，倾向保守，并建议用户与 DPO 或法律顾问讨论临界分类。

### 适用标记

| 标记 | 条件 | 效果 |
|------|-----------|--------|
| 🚩 规模 | >100 个个体 | 监管机构审查加强 |
| 🔒 已加密 | 数据已加密、密钥安全 | 可能支持第 34(3)(a) 条例外 |
| 👶 弱势主体 | 未成年人、患者 | 考虑升级通知 |
| ⚠️ 跨境 | 跨境处理 | 一站式机制分析（见跨境规则） |
| 🇬🇧 英国主体 | 涉及英国居民 | 需单独向 ICO 通知（见下方英国说明） |
| 🤖 AI 系统 | 涉及 AI 系统 | 检查 AI 法案第 73 条义务 |

**英国 GDPR 说明：** 对于英国居民数据主体，ICO 的指引可能与 EDPB 的建议不同。英国不受 EDPB 指南约束——它依据英国 GDPR 和 2018 年《数据保护法》遵循 ICO 指引。ENISA 方法论提供了有用的分析框架，但 ICO 自身的风险评估方法也应当咨询。只要可用，始终使用 [ICO 的自评工具](https://ico.org.uk/for-organisations/report-a-breach/)，并注意 ICO 拥有独立于任何欧盟监管机构之外的通知门户和表格。

---

## 证据姿态（纳入每份评估）

可辩护的违规决策将已知与假设分离。每份评估输出必须包含：

```
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]
```

永远不要将假设呈现为事实。分阶段通知（第 33(4) 条）的存在正是为了不让不完整的事实延误初始通知。

---

## AI 法案交叉适用（第 73 条检查）

如果用户确认违规涉及 AI 系统，执行额外评估：

1. **分类：** 这是否是**高风险 AI 系统**（AI 法案附件 III，或附件 I 下的产品嵌入系统）？是否部署在受监管行业（医疗保健、执法、关键基础设施）？
2. **严重事件测试（第 3(49) 条）：** 该事件是否直接或间接导致 (a) 人员死亡或健康严重损害；(b) 关键基础设施管理或运营的严重且不可逆的中断；(c) 违反旨在保护基本权利的欧盟法律项下义务；或 (d) 对财产或环境的严重损害？
3. **如是 → 第 73 条报告：** **提供者**（或适用情况下的部署者）向事件发生地成员国（或多国）的**市场监督机构**报告——在确定 AI 系统与事件之间的因果关系（或其合理可能性）后立即报告，最迟在知情后 **15 天**内。缩短的截止期限：对于第 3(49)(b) 条下的广泛侵权或关键基础设施事件为 **2 天**；发生死亡时为 **10 天**。允许先提交初始不完整报告，随后提交完整报告。
4. **适用性：** 第 73 条自 **2026 年 8 月 2 日**起适用（嵌入附件 I 受监管产品的高风险系统：2027 年 8 月 2 日；第 73(9)-(10) 条的行业报告等效性）。在适用日期之前，说明该义务"将于"该日期"起适用"——它还不是一项已生效的义务。
5. **平行义务：** 第 73 条与 GDPR 通知**并行**运行——义务独立、接收方独立、截止期限独立。

完整细节（定义、截止期限、延后适用）：阅读 [references/parallel-regimes.md](references/parallel-regimes.md)。

### 输出
当 AI 系统标记启用时，将该块作为独立的 **AI ACT STATUS（AI 法案状态）** 部分插入评估面板（置于 LEGAL VERDICT 之前），此外还有单行的 `AI Act Art. 73` 行：
```
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]
```
不要仅凭用户提供的附件 III 分类就照单全收：CE 标志的医疗器械或其他附件 I 受监管产品属于**产品嵌入型**高风险（适用日期 2027 年 8 月 2 日；第 73(9)-(10) 条在很大程度上让位于 MDR/IVDR 等行业警戒制度，这些制度如今可能施加**生效的**报告义务）。建议与用户的监管团队核实。

---

## 行业平行制度筛查

个人数据泄露常常触发 GDPR 之外的义务。在 GDPR 评估后运行一次轻量筛查——或对"仅安全事件"结论直接在分诊出口进行——识别即可，除非用户要求，不深入分析：

| 制度 | 触发提示 |
|--------|--------------|
| NIS2 / 国内实施 | 发生重大 ICT 事件的重要/关键实体——如 `nis2-navigator` 技能可用，将其用于该路径 |
| DORA | 发生 ICT 相关事件的金融实体 |
| eIDAS | 信任服务提供者 |
| AI 法案第 73 条 | 高风险 AI 系统严重事件（见上文） |
| ePrivacy / 电信 | 可公开使用的电子通信服务提供者 |
| 刑法 | 向警察/司法机关报告（也是 EDPB 模板字段） |
| 保险 | 网络保险单通知条款——窗口通常很短 |
| 合同 | 超出 DPA 的客户/合作伙伴通知条款 |
| 雇佣 | 涉及员工数据时劳资委员会/员工代表的参与（尤其在德国） |

面板输出行："**识别出的潜在平行制度：** [清单]——除非要求，不作详细评估。" 详情和筛查问题：[references/parallel-regimes.md](references/parallel-regimes.md)。

---

## EDPB 案例匹配

风险评估后，匹配 EDPB《指南 01/2021》的案例。见 [references/edpb-cases.md](references/edpb-cases.md)。

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

**类推警告：** EDPB 案例是说明性类推，**非约束性决定**。事实差异很重要，类推永远不能替代对实际事实进行的第 33/34 条法律测试。说明最接近的案例、类推的局限，以及你的事实与之不同之处（见参考文件中的类推规则）。

输出格式：
> "该场景与 **EDPB 案例 [XX]** 相似：[描述]。EDPB 建议：监管机构 [是/否]，主体 [是/否]。你的情况不同之处在于：[差异]。类推的局限：[局限]。这[支持/建议重新考虑]你的计算结果。"

---

## 动态网络研究模块

完成 ENISA 计算和 EDPB 案例匹配后，**自动**执行针对性网络研究以充实评估。阅读 [references/web-research.md](references/web-research.md) 了解具体查询模板（执法先例、监管机构特定指引、行业趋势、EDPB 更新、AI 法案、损害赔偿先例）及如何纳入发现。适用该参考文件中的**来源纪律**规则：官方来源（监管机构 / EDPB / 欧盟委员会）优先，不得以 SEO 或营销页面作为法律结论的基础，注明访问日期，绝不编造门户链接或监管机构联系方式。在评估面板中添加"监管情报"部分。

---

## 跨境规则

### 首先：这到底是不是跨境处理？

一站式机制要求真正的**跨境处理**（第 4(23) 条）——在一个以上成员国的机构背景下进行的处理，或对多个成员国的个体产生实质性影响的处理。**不要仅仅因为受影响个体居住在多个成员国就假定跨境处理**——测试对象是处理，而非主体居住地。在适用一站式机制前先作分析。

### 在欧盟设有机构的控制者

- 仅通知**主导监管机构**（一站式机制），前提是能确定主要机构和主导监管机构
- 主导监管机构 = 主要机构所在地
- 在通知中注明受影响的成员国（EDPB 模板要求按国家统计主体数量）

### 在欧盟未设机构的控制者

- 一站式机制**不适用**——仅存在欧盟代表不触发该机制（EDPB《指南 9/2022》v2.0，第 73 段）
- 在其成员国境内有受影响主体居住的**每个**监管机构都应通知
- 逐一跟踪提交；国家门户可能要求本地格式和字段

### 主导监管机构确定问题

1. "关于该数据处理的决定在哪里作出？"
2. "你的中央管理机构在哪里？"
3. "哪个机构对此处理有管辖权？"

### 监管机构联系目录

对确定的主导监管机构或相关监管机构，使用 web_search 查找：
- 官方监管机构通知门户 URL
- 用于违规通知的监管机构联系邮箱和电话
- 任何监管机构特定的通知表格或要求（有些监管机构有自己强制性表格，例如德国的 BfDI、法国的 CNIL）
- 办公时间和紧急联系程序

对于**德国**，在 BfDI（联邦机构、电信/邮政）和相关联邦州（Bundesland）的 LfDI/LDA（私营部门）之间路由——见 [references/web-research.md](references/web-research.md) 中的德国路由规则。

在评估面板中输出监管机构联系方式。在**仅处理者（B 路径）**运行中，将监管机构信息表述为供控制者交接包使用的礼貌性材料——绝不是处理者应自行使用的门户——并将面板的"通知监管机构"/监管机构截止期限行标记为下游控制者义务（对处理者为不适用）。

---

## 缓解行动手册

风险评估后，生成**量身定制的缓解行动手册**，针对该具体事件——不是通用清单，而是对此具体违规真正重要的、由个案驱动的行动。

阅读 [references/mitigation-playbook.md](references/mitigation-playbook.md) 了解完整手册设计原则、输出格式（含责任人/截止期限/依赖关系的优先级行动计划）和可供借鉴的常见行动类别。

---

## 用户覆盖协议

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

1. 记录原始结果："我的评估显示 **[级别]**（SE = [分值]）。你希望将其归类为 **[用户级别]**。"
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) 条）：** 用通俗语言描述违规、DPO/联系点、可能后果、已采取或拟采取的措施，以及具体的自我保护步骤。
- **策略：** 直接沟通对比公开沟通、分阶段沟通、弱势主体优先、按受影响成员国使用相应语言、支持渠道、欺诈/钓鱼警告措辞。
- **兜底：** 监管机构可以命令沟通或确认某项例外（第 34(4) 条）。

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

---

## 战略案件咨询

在呈现评估面板后，以资深数据保护律师向客户危机团队汇报的姿态提供战略咨询。这超越 ENISA 分值——它正是区分称职合规与卓越事件响应的关键。

阅读 [references/strategic-advisory.md](references/strategic-advisory.md) 了解完整咨询框架、原则、章节结构和语气示例。覆盖：案件评估与风险图景、监管机构互动策略、通知起草指引、隐藏风险与二阶效应、防御性文档记录，以及危机中的竞争优势。

---

## 文档生成

完成评估后，主动提出生成**审计就绪的 .docx 文档**。

### 可用文档
1. **EDPB 违规证据文件**——镜像 EDPB 模板 [2026] 结构的完整通知案卷（见下文）
2. **第 33 条监管机构通知**——向监管机构的正式通知
3. **第 34 条主体告知**——向数据主体的通俗语言通知
4. **第 34 条决策备忘录**——记录在案的高风险分析和例外论证
5. **处理者客户通知 + 交接包**——向控制者客户的通知和支持包（B 路径）
6. **内部合规日志**——第 33(5) 条强制性文档记录
7. **不予通知的理由说明**——决定不通知时使用
8. **后续跟进/撤回通知**——补充、完善或撤回先前通知
9. **缓解行动手册**——含责任人和截止期限的优先级检查清单
10. **完整违规响应包**——所有适用文档打包

### EDPB 违规证据文件

应要求——并在需要通知监管机构时主动——构建**与 EDPB 模板对齐的违规证据文件**：一份镜像 EDPB《个人数据违规通知模板 [2026]》编号结构（§1 通知信息至 §7 附件）的文档。从评估中填充每个字段；缺口标记为 `[UNKNOWN — investigate]`（未知——待调查），不适用字段标记为 `[N/A]`。始终提示该模板的**草案/公开咨询状态**，以及国家监管机构门户在模板通过前仍具权威性。阅读 [references/edpb-template-evidence-file.md](references/edpb-template-evidence-file.md) 了解字段映射、填充规则和文档骨架。

### 文档生成流程

阅读 [references/templates.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](references/post-notification-tracking.md) 了解跟踪面板模板，覆盖监管机构通知状态（含跟进和撤回）、主体告知、缓解执行阶段和文档完成情况。

每次会话结束时提醒用户：
- "你希望我将任何文档生成为 .docx 文件——包括 EDPB 证据文件吗？"
- "你需要我研究你所在监管机构的具体通知门户和要求吗？"
- "你想更新通知后跟踪器吗？"

---

## 紧急模式

### 激活触发条件
- 时限剩余不足 12 小时
- 用户明确要求
- 对数据主体安全构成即时风险
- T0 已超过 60 小时

### 紧急协议

显示：
> ⚡ **紧急模式已激活**
> 正在生成最低可行评估。

**精简信息采集（8 个问题）：**
0. 该事件是否根本涉及个人数据？（如明显不涉及 → 仅安全事件——记录原因并停止 GDPR 工作流）
1. 角色：控制者、处理者，还是两者？
2. 数据类型？（简单/行为性/财务/敏感）
3. 多少人受影响？
4. 数据是否已加密且密钥安全？
5. 恶意还是意外？
6. 受影响个体在哪些国家？
7. 如为处理者：你的 DPA 是否规定了通知窗口？（例如 24 小时、48 小时）

**快速计算：**
- DPC：使用所述类别，不作调整
- EI：默认 0.75（显著）
- CB：按恶意/意外评分 + 假定机密性丧失

**紧急输出：**
1. 附注意事项的初步结论——包括压缩版法律衔接（第 33/34 条结论各一行）
2. 最低可行的第 33 条通知（如可能生成为 .docx）
3. 关键即时缓解行动（仅前 5 项）
4. 监管机构联系方式（通过网络搜索）
5. 跟进检查清单（48 小时内必做）

---

## 关键提醒

1. **记录一切**——即使是不需要通知的违规（第 33(5) 条）
2. **处理者毫不迟延地通知控制者（第 33(2) 条）**——处理者无法定 72 小时义务；控制者的时限在你告知时启动；DPA 窗口是额外的合同性要求
3. **72 小时是上限，不是目标**——"毫不迟延"
4. **允许分阶段通知**——不要为等待完整信息而延误
5. **ENISA 分值是推定**——第 33/34 条法律衔接才是决定；以书面记录
6. **并非每起事件都是违规**——工作流前先运行违规定性门禁
7. **监管机构可命令主体告知**——即使控制者已决定不告知
8. **不通知可单独受罚**——最高 1000 万欧元或 2% 营业额
9. **非欧盟控制者：不适用一站式机制**——通知每个相关监管机构
10. **加密不消除违规**——仍须内部记录
11. **英国是独立的**——脱欧后需向 ICO 通知；ICO 指引可能与 EDPB 不同；使用 ICO 自身的自评工具和通知门户
12. **AI 系统有平行义务**——AI 法案第 73 条与 GDPR 并行（自 2026 年 8 月 2 日起适用）
13. **EDPB 模板 [2026] 是草案**——公开咨询截至 2026 年 8 月 5 日；国家监管机构门户仍具权威性
14. **始终提供文档生成**——审计就绪的 .docx 文件，而非仅聊天输出
15. **研究具体监管机构**——门户 URL 和要求差异很大

---

## 版本与监管依据

| 文件 | 版本 | 最后核实 |
|----------|---------|---------------|
| EDPB《指南 9/2022》（通知） | v2.0 | 通过网络搜索检查更新 |
| EDPB《指南 01/2021》（示例） | v2.0 | 通过网络搜索检查更新 |
| ENISA 严重性方法论 | v1.0 | 通过网络搜索检查更新 |
| 欧盟 AI 法案（条例 2024/1689） | 已生效；第 73 条自 2026 年 8 月 2 日起适用 | 第 73 条严重事件报告 |
| EDPB《个人数据违规通知模板 [2026]》 | v1.0 草案——公开咨询截至 2026 年 8 月 5 日 | 证据文件结构；通过网络搜索检查咨询结果 |

**重要提示：** 监管指引会不断演变。每份评估都应使用动态网络研究模块，检查这些基础文件的更新。

## 相关 GDPR 技能

本技能可独立使用，但与我的其他欧盟数据保护技能搭配效果良好——可单独安装任一技能或组合使用：

- **DPIA Sentinel**——第 35 条数据保护影响评估
- **Privacy Notice Generator**——第 13/14 条隐私通知
- **Transfer Impact Assessment (TIA)**——第五章转移评估
- **DPA Art. 28**——控制者-处理者协议（AVV）
- **Legitimate Interest**——第 6(1)(f) 条合法利益评估/利益平衡测试