data-breach-response

⚠️ 实验性 — 此技能仅用于教育和提供信息，不构成法律建议。用户须对使用承担全部责任。采取任何行动前，请咨询合格的法律专业人士。

数据泄露响应

针对 GDPR 第 33/34 条、CCPA、HIPAA、NIS2、PCI DSS 及其他法规下个人数据泄露的事件响应与法律合规。计算泄露严重程度、跟踪通知截止时间并管理响应时间线。

---

目录

• 工具
  • 泄露严重程度计算器
  • 泄露时间线跟踪器
• 参考指南
• 工作流
• ENISA 严重程度公式
• 通知决策矩阵
• 故障排除
• 成功标准
• 范围与限制
• 反模式
• 工具参考

---

首先澄清

评估泄露事件前，请确认以下信息。若任何信息未知或含糊不清，请询问——不要自行假设：

• T0——知悉事件的时刻——72 小时倒计时从此刻开始；时间线中的每个截止时间和“剩余时间”均据此计算
• 您的角色：控制者还是处理者——这决定您是通知 SA／数据主体（第 33/34 条），还是仅通知控制者（第 33(2) 条）
• 数据类别、规模和识别难易程度——这些是影响 ENISA 严重程度评分和判定结果（LOW/MEDIUM/HIGH/VERY HIGH）的 DPC/EI 输入项
• 适用哪些法规——GDPR、CCPA、HIPAA、PCI DSS、NIS2、AI Act——这决定矩阵生成哪些通知截止时间和主管机构

停止规则：只询问最可能影响结果的 2-3 项。如果用户说“直接起草”，则继续处理，并在评估开头列出您的假设。

工具

泄露严重程度计算器

根据泄露参数计算 ENISA 泄露严重程度评分。根据严重程度判定结果确定通知义务。

# Calculate severity from parameters
python scripts/breach_severity_calculator.py \
  --dpc 3 --ei 0.75 \
  --confidentiality 0.5 --integrity 0.25 --availability 0 \
  --malicious

# JSON output
python scripts/breach_severity_calculator.py \
  --dpc 2 --ei 0.5 --confidentiality 0.5 --json

# With T0 timestamp for countdown
python scripts/breach_severity_calculator.py \
  --dpc 3 --ei 1.0 --confidentiality 0.5 \
  --t0 "2026-04-10T08:00:00" --json

# Generate input template
python scripts/breach_severity_calculator.py --template

输出包括：

• ENISA 严重程度评分（SE）
• 严重程度判定：LOW / MEDIUM / HIGH / VERY HIGH
• 通知义务（SA、数据主体、公众）
• 从 T0 起 GDPR 72 小时通知期限的剩余时间

---

泄露时间线跟踪器

从 T0（知悉事件的时刻）起跟踪泄露响应时间线。记录事件、监控截止时间并生成状态仪表板。

# Initialize a new breach timeline
python scripts/breach_timeline_tracker.py init \
  --breach-id "BR-2026-001" --t0 "2026-04-10T08:00:00" \
  --description "Unauthorized database access" \
  --output breach_timeline.json

# Record an event
python scripts/breach_timeline_tracker.py event \
  --timeline breach_timeline.json \
  --action "Containment team activated" --category containment

# View status dashboard
python scripts/breach_timeline_tracker.py status --timeline breach_timeline.json

# Check deadlines
python scripts/breach_timeline_tracker.py deadlines --timeline breach_timeline.json

# JSON status output
python scripts/breach_timeline_tracker.py status --timeline breach_timeline.json --json

跟踪内容：

• GDPR 72 小时 SA 通知截止时间
• DPA 合同截止时间（处理者通知期限为 24 小时／48 小时）
• NIS2 24 小时预警和 72 小时通知
• 已完成与待处理的响应行动
• 每个截止时间的已用时间和剩余时间

---

参考指南

ENISA 方法

references/enisa_methodology.md

完整的 ENISA 泄露严重程度评估方法：

• DPC（数据处理情境）评分：1-4
• EI（识别难易程度）评分：0.25-1.00
• CB（泄露情形）累加评分
• 公式：SE = (DPC x EI) + CB
• 针对加密、假名化和数据量的调整
• EDPB 案例匹配（18 个参考案例）

通知义务

references/notification_obligations.md

多法规通知要求：

• GDPR 第 33 条（72 小时内通知 SA）和第 34 条（通知数据主体）
• CCPA、HIPAA、PCI DSS、NIS2、州级泄露通知要求
• 控制者与处理者义务矩阵
• 跨境通知规则
• AI Act 第 62 条严重事件报告

---

工作流

工作流 1：标准泄露响应

Step 1: Emergency check — is there <12h remaining on any deadline?
        → If yes, skip to Step 4 (emergency notification)

Step 2: Initialize breach timeline
        → python scripts/breach_timeline_tracker.py init --breach-id "BR-2026-001" \
          --t0 "2026-04-10T08:00:00" --description "Description"

Step 3: Calculate severity
        → python scripts/breach_severity_calculator.py --dpc N --ei N \
          --confidentiality N --integrity N --availability N [--malicious]

Step 4: Based on severity verdict, determine notifications
        → LOW (<2): Internal log only, no external notification
        → MEDIUM (2 to <3): Notify supervisory authority within 72h
        → HIGH (3 to <4): Notify SA + individual data subjects
        → VERY HIGH (>=4): Notify SA + data subjects + consider public notice

Step 5: Execute containment and record events
        → python scripts/breach_timeline_tracker.py event --timeline breach.json \
          --action "Action taken" --category containment

Step 6: Monitor deadlines continuously
        → python scripts/breach_timeline_tracker.py deadlines --timeline breach.json

Step 7: Complete notification obligations and document

工作流 2：紧急模式（剩余时间 <12 小时）

Step 1: Calculate severity immediately
        → python scripts/breach_severity_calculator.py --dpc N --ei N \
          --confidentiality N --t0 "original-t0" --json

Step 2: If MEDIUM or higher, prepare phased notification
        → Art. 33(4) allows phased notification when full information unavailable
        → Initial notification: what is known + promise of update
        → Supplementary notification: full details when available

Step 3: File initial SA notification before deadline expires

Step 4: Initialize timeline for ongoing tracking
        → Continue gathering information for supplementary notification

Step 5: Document emergency timeline and decisions

工作流 3：处理者泄露通知

Step 1: Processor becomes aware of breach
        → T0 for processor = moment of awareness

Step 2: Processor must notify controller "without undue delay"
        → Check DPA for specific contractual deadline (24h/48h common)

Step 3: Controller's T0 starts when controller becomes aware
        → Controller's 72h clock starts at this point

Step 4: Controller assesses severity independently
        → python scripts/breach_severity_calculator.py (controller's assessment)

Step 5: Controller makes notification decisions
        → Processor provides information; controller decides on SA/subject notification

---

ENISA 严重性公式

SE = (DPC x EI) + CB

组成部分	范围	描述
DPC	1-4	数据处理情境 — 数据的性质和敏感性
EI	0.25-1.0	识别难易程度 — 识别个人的难易程度
CB	-0.5 to +1.0	泄露情形 — 附加因素（恶意意图、数据量、损失类型）

严重性判定

分数范围	判定	通知义务
<2	低	仅记录在内部日志中。无需通知 SA 或数据主体
2 to <3	中	在 72 小时内通知监管机构（第 33 条）
3 to <4	高	在 72 小时内通知 SA，并通知个人数据主体（第 34 条）
>=4	极高	通知 SA 和数据主体，并考虑发布公告；开展危机管理

---

通知决策矩阵

按法规和严重程度划分的通知义务速查表。

法规	向监管机构通知	向个人通知	触发条件
GDPR 第 33 条	72 小时内通知 SA	不适用	除非不太可能对权利和自由造成风险
GDPR 第 34 条	不适用	不得无故拖延	可能造成高风险时
CCPA	州检察长	受影响的消费者	未加密的个人信息遭到泄露
HIPAA	60 天内通知 HHS	受影响的个人	未受保护的 PHI；超过 500 人时通知媒体
PCI DSS	24 小时内通知卡组织	持卡人（由发卡机构通知）	持卡人数据遭到泄露
NIS2 第 23 条	24 小时内向 CSIRT 提交预警，72 小时内提交通知	不适用	重大事件
AI Act 第 62 条	15 天内通知市场监管机构	不适用	涉及 AI 系统的严重事件

控制者与处理者的义务

义务	控制者	处理者
通知监管机构	是（第 33 条）	否（仅通知控制者）
通知数据主体	是（第 34 条）	否
记录所有泄露事件	是（第 33(5) 条）	是（协助控制者）
通知控制者	不适用	是，不得无故拖延（第 33(2) 条）
开展严重性评估	是	协助（提供信息）
时间线起点（T0）	控制者知悉时	处理者知悉时

---

故障排除

问题	可能原因	解决方案
严重性分数处于中与高之间的临界点	参数位于阈值边界	采用保守评分 — 若接近 3.0，则按高严重性处理并通知数据主体；记录临界情况分析
72 小时期限将至，但信息仍不完整	泄露事件复杂，仍在调查中	使用第 33(4) 条规定的分阶段通知 — 先向 SA 通知现有信息，之后再补充
处理者发现泄露事件后，延迟通知控制者	可能错过了 DPA 合同约定的期限	记录延迟情况；评估处理者的延迟是否影响控制者履行义务；审查 DPA 条款
跨境泄露 — 不清楚应通知哪个 SA	涉及多个司法管辖区的处理活动，且主导 SA 不明确	通知主要营业机构所在地的 SA（单一窗口机制）；若不明确，则通知受影响数据主体居住地最多的地区对应的 SA
泄露事件涉及加密数据 — 不清楚是否需要通知	加密可能降低严重性或免除通知义务	若加密有效（算法强度高，密钥未遭泄露），根据第 34(3)(a) 条，可能无需通知；记录分析过程
泄露事件涉及 AI 系统 — 不清楚是否存在其他义务	除 GDPR 外，AI Act 第 62 条也可能适用	评估 AI 系统是否属于 AI Act 下的高风险系统；若属于严重事件，除履行 GDPR 义务外，还应在 15 天内通知市场监管机构

---

成功标准

• 在知悉后 2 小时内计算违规严重程度 —— 应用 ENISA 方法，并记录参数和评分依据
• 在 T0 后 72 小时内提交 SA 通知 —— 对于严重程度为 MEDIUM 或更高的违规事件，在信息不完整时采用分阶段通知
• 及时完成对数据主体的通知 —— 对于严重程度为 HIGH 或更高的违规事件，清楚说明影响和保护措施
• 跟踪所有响应操作及其时间戳 —— 从 T0 到结案持续维护违规事件时间线，并记录所有事件
• 识别并履行跨法规义务 —— 根据适用法律评估并履行 GDPR、CCPA、HIPAA、PCI DSS、NIS2 和 AI Act 规定的义务
• 完整保存违规事件事后文档 —— 无论是否决定通知，均须按照 Art. 33(5) 维护内部违规事件日志

---

范围与限制

范围内：

• 支持完整参数的 ENISA 违规严重程度计算
• GDPR Art. 33/34 通知时间线跟踪
• 多法规通知义务评估（GDPR、CCPA、HIPAA、PCI DSS、NIS2、AI Act）
• 控制者与处理者义务指南
• 跨境违规通知路由
• 根据 Art. 33(4) 提供分阶段通知指南
• 违规响应事件跟踪和期限监控

范围外：

• 技术事件遏制（网络隔离、取证、恶意软件清除）
• 向监管机构提交通知（仅准备文档）
• 保险理赔处理或保障范围分析
• 执法部门协调
• 公共关系或危机沟通策略
• 取证调查方法

---

反模式

• 延迟确定 T0 以争取更多时间 —— T0 是控制者“知悉”违规事件的时刻，而非掌握完整详情的时刻；故意延迟知悉以延长 72 小时时限属于违规行为，监管机构也会如此认定
• 未记录分析便默认不通知 —— 必须记录并评估每起违规事件，即使结论是不需要通知；没有记录严重程度分析，仅称“我们决定不通知”是无法辩护的
• 将处理者通知视为控制者通知 —— 处理者向其自身的 SA 发出通知，并不能满足控制者根据 Art. 33 承担的义务；控制者必须独立作出通知决定并自行提交
• 将加密视为自动豁免通知的理由 —— Art. 34(3)(a) 的豁免要求加密数据已变得无法读取，且加密密钥未遭泄露；弱加密或密钥遭泄露均不符合条件
• 忽视涉及 AI 的违规事件所产生的 AI Act 义务 —— 如果违规事件涉及高风险 AI 系统，则除 GDPR 之外还适用 Art. 62 规定的严重事件报告义务（须在 15 天内向市场监管机构报告）；两者是时间要求不同的独立义务

---

工具参考

breach_severity_calculator.py

计算 ENISA 违规严重程度评分并确定通知义务。

标志	必填	说明
--dpc <1-4>	是	数据处理情境：1=简单人口统计信息，2=行为/财务信息，3=敏感个人信息，4=特殊类别/高度敏感信息
--ei <0.25-1.0>	是	识别难易程度：0.25=可忽略，0.5=有限，0.75=显著，1.0=最高
--confidentiality <0/0.25/0.5>	否	机密性丧失评分（默认值为 0）
--integrity <0/0.25/0.5>	否	完整性丧失评分（默认值为 0）
--availability <0/0.25/0.5>	否	可用性丧失评分（默认值为 0）
--malicious	否	标记恶意意图（CB 增加 +0.5）
--t0 <ISO datetime>	否	用于计算期限的 T0 时间戳
--template	否	生成输入模板
--json	否	以 JSON 格式输出

breach_timeline_tracker.py

跟踪数据泄露响应时间线、事件和监管截止日期。

子命令	描述
init	初始化数据泄露时间线（必须提供 --breach-id、--t0、--description，--output 可选）
event	记录事件（必须提供 --timeline、--action、--category）
status	查看状态仪表板（必须提供 --timeline，--json 可选）
deadlines	检查截止日期状态（必须提供 --timeline，--json 可选）