---
name: dpa-review
description: >
  依据你的数据处理协议（DPA）操作手册审查一份DPA——自动检测你是受托处理者
  还是处理者，并应用操作手册正确的半部分。当用户说"审查这份DPA""检查这份
  数据处理附录""客户发来了他们的DPA""这份DPA可以吗"，或附上一份DPA时使用。
argument-hint: "[文件 | 网盘链接 | 粘贴文本]"
---

# /dpa-review

1. 加载 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → DPA 操作手册。如为占位符，停止并提示设置。
2. 获取 DPA。确定方向：我们是受托处理者（客户发来DPA）还是处理者（审供应商的DPA）？不明确时询问。
3. 执行以下工作流——逐条对照相应的操作手册行。
4. 执行个人信息处理规则一致性检查。
5. 输出：带修订标记的审查备忘录。按内部格式保存。

```
/privacy-legal:dpa-review 客户dpa.pdf
```

---

# DPA 审查（数据处理协议审查）

## 事项上下文

**事项上下文。** 检查实践级 CLAUDE.md 中的 `## 事项工作区`。如果 `已启用` 为 `✗`（法务用户的默认值），跳过本段——技能使用实践级上下文，事项机制不可见。如果已启用且无活动事项，询问："这是哪个事项？运行 `/privacy-legal:matter-workspace switch <slug>` 或说 `实践级`。"加载活动事项的 `matter.md` 获取事项特定上下文和覆盖项。将输出写入事项文件夹 `~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/`。除非 `跨事项上下文` 为 `开启`，否则绝不读取其他事项的文件。

---

## 目的

DPA 有两种形态，审查方向几乎完全相反。当客户发来他们的 DPA，我们在捍卫我们的运营灵活性。当我们给供应商发 DPA，我们在保护我们（及我们客户的）数据。两次审查都读同一份 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` 操作手册，但从相反的行读取。

## 首先：哪个方向？

做任何事之前，先确定：

- **我们是受托处理者** → 客户向我们发送他们的 DPA → 读取 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → "当我们是受托处理者时" 表（对应个保法第21条委托处理 `[法条原文]`）
- **我们是处理者** → 我们正向供应商发送 DPA（或审查他们的）→ 读取 "当我们是处理者时" 表

如果不清楚，询问。方向搞错将颠倒每项建议。

## 法域假设

本审查假定你的配置中指定的法域范围。隐私规则、响应期限和合法性基础因法域而异（个保法 vs. GDPR vs. 其他法域）。如果处理者、受托处理者或个人信息主体位于不同于配置的法域，本审查可能不直接适用。

## 加载关于本对方当事人/活动的先前上下文

审查前，检查输出文件夹中关于本对方当事人或处理活动的先前工作。读取 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## 输出` 获取输出文件夹路径。扫描：

- **先前的 `use-case-triage` 结果** 涵盖同一对方当事人/处理活动——分诊产生风险评级和条件，本 DPA 审查应遵守或明确偏离。
- **先前的 `pia-generation` 输出** 涵盖本对方当事人/处理活动——PIA 可能已标注需要 DPA 实施的风险缓解措施。
- **先前的 `dpa-review` 输出** 涵盖同一对方当事人——先前的 DPA 审查设定了关于什么可接受、什么被标注、什么已解决的预期。一份静默地与先前审查相矛盾的新审稿侵蚀对工作产品的信任。

如果找到先前的输出，在审查中引用：

> "先前的分诊（[日期]）将本活动评为[风险等级]，并以[X]为批准条件。本 DPA 审查与该发现一致。"——或——
> "先前的分诊（[日期]）将本活动评为[风险等级]。本 DPA 审查偏离该发现因为[理由——新事实、不同范围、改变了图景的合同条款]。"

**从上游继承严重程度作为底线**，遵循 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## 共享护栏` 中的跨技能严重程度底线规则。被分诊评为🔴的处理活动不能在 DPA 审查中静默降级为🟢；任何降级均应说明和解释。

如果未找到先前的输出（新对方当事人/新活动），在审查中明确说明——"输出文件夹中无关于本对方当事人的先前分诊或PIA"——以便审核律师知道检查已执行。

## 加载操作手册

读取 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## DPA 操作手册`。同时读取 `## 个人信息处理规则承诺`——DPA 不能与处理规则承诺相矛盾。

## 行业监管叠加（在逐条审阅之前先问）

在逐条审阅之前，回答：**通过本 DPA 的数据是否包含任何受行业特别监管的类别？** 个保法和通用数据保护法提供一个底线；行业监管通常提供另一个不出现在通用 DPA 操作手册中的底线。一份个保法完整的 DPA 仍可能在金融、医疗健康、未成年人保护等方面存在盲区。

> **行业监管叠加——首先询问：**
>
> 本处理活动是否涉及：
> - **消费者的个人金融信息**（《个人金融信息保护技术规范》JR/T 0171-2020 + 征信业管理条例）？如为是，DPA 需要：(a) 与金融信息保护技术规范一致的共享限制，(b) 安全保护措施与行业标准对齐，(c) 事件通知机制覆盖金融监管部门时限要求，(d) 明确约定数据接收方的安全保护义务。
> - **健康医疗数据，由医疗机构或健康医疗数据处理者持有**（人口健康信息管理办法 + 个保法）？如为是，DPA 需要：数据接收方须具备相应的安全保护能力和资质，明确使用限制和保密义务，事件通知时限，下游处理者授权条款。
> - **不满十四周岁未成年人的个人信息**（儿童个人信息网络保护规定 + 个保法第31条）`[法条原文]`？如为是，DPA 需要：监护人知情同意流转条款，严格的保留限制和删除机制，禁止用于行为广告（除非有监护人明确同意）。
> - **其他行业性监管制度**（如汽车数据安全管理若干规定、征信业管理条例、关键信息基础设施安全保护条例等）？
>
> 如果任一项为是：行业监管通常提供主导性的实体性限制。检索现行有效的规定并引用。一份"豁免"了个保法某条要求但受行业监管约束的 DPA，仍需满足行业监管的限制——豁免只是转换了适用框架，不消灭合规义务。在红线问题清单中将行业性缺口与通用数据保护缺口并列标注。

如果无行业监管叠加适用，明确说明——"未识别到受行业特别监管的数据类别；行业监管叠加不适用"——以便审核律师看到检查已执行，而非猜测是否被跳过。

## 逐条审查

### 核心条款（每份 DPA 都查）

逐条审查 DPA 的以下条款。*具体*的数值和实体立场（通知期限、泄露时限、可接受/不可接受底线）来自 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` → `## DPA 操作手册`。任何 DPA 必须满足的监管底线来自主源法律——**检索每个适用制度的现行有效规则**并引用主源后再陈述底线。

> **禁止静默补充。** 如果检索查询返回结果很少或为零，报告找到的内容并停止。不要未经询问即从网络搜索或模型知识填补空白。说："搜索返回[N]条结果。覆盖显得薄弱。选项：(1) 扩大搜索查询，(2) 尝试不同的检索工具，(3) 搜索网页——结果将标记为 `[联网检索 — 需复核]`，(4) 标记为未验证并停止。你想选哪个？"由律师决定是否接受可信度较低的来源。
>
> **来源溯源标签分层。** 为审查中每处引用标记来源。对于模型知识引用，使用三层而非单一"验证"标签：
>
> - `[已确定]` — 稳定、众所周知的法定和行政法规引用，不太可能已变更（如个保法第21条委托处理、第57条泄露通知）。提交前仍应验证，但优先级较低。
> - `[需验证]` — 模型知识引用是真实的但应验证：具体实施细则、监管部门指引、案例立场、阈值、生效日期。
> - `[需验证——精准引用]` — 精准引用（具体款号、条号、段落编号）造假风险最高，应始终对照主源验证。
>
> 检索工具获取的引用保留其来源标签；网页搜索引用保留 `[联网检索 — 需复核]`；用户提供的引用保留 `[用户提供]`。分层揭示了真正的验证工作——什么都验证的人什么也没验证。绝不剥离或折叠标签。

| 条款 | 关注点 | 操作手册字段 | 常见争议 |
|---|---|---|---|
| **角色** | 清晰的处理者/受托处理者指定；匹配实际 | — | 对方将关系标签为（如"共同处理者"）与实际不符 |
| **处理范围** | 限于书面指示；定义目的 | — | 开放式范围扩展（"及相关目的"） |
| **下游处理者** | 当前名单已披露，变更机制已定义 | 下游处理者变更 | 一揽子批准 vs. 否决权 vs. 仅通知 |
| **安全措施** | 附件引用具体控制措施或标准 | 安全标准 | "适当的技术和组织措施"无附件 = 空洞承诺 |
| **泄露通知** | 已定义触发（"发现" vs. "确认"），已定义时限 | 泄露通知 | 时限紧迫度；计时起点；"及时"的模糊性；个保法第57条要求立即通知网信办和个人 `[法条原文]` |
| **审计权** | 方式（报告 vs. 现场），频率，通知期限，费用分配 | 审计权 | 短通知期限的现场审计 |
| **数据出境** | 出境机制已识别，补充措施，出境安全评估参照 | 数据出境 | 缺失或过时的出境机制；是否已通过安全评估/签署标准合同/获得认证（个保法第38条） `[法条原文]` |
| **删除/返还** | 合同终止后时限，认证，备份例外 | 终止后删除 | "商业上合理的"删除 = ??? |
| **责任** | 在主合同责任上限内或单独核算；例外 | 数据责任 | 数据泄露无上限责任 = 公司存亡风险 |

### 当我们是受托处理者时：防御性审查

客户的 DPA 试图将运营负担推向我们。对以下每一条，将客户的要求与操作手册对比。当客户要求超出操作手册时，推回至团队标准立场（来自配置 CLAUDE.md），并准备好退至可接受立场。

| 条款 | 风险 | 检索 / 操作手册查询 |
|---|---|---|
| 下游处理者批准权（否决权） | 每次新增基础设施需逐客户审批 | 应用操作手册关于下游处理者变更的立场 |
| 短通知期限的现场审计 | 大规模下不可操作 | 应用操作手册关于审计权的立场 |
| 激进的数据泄露通知窗口 | 通常在我们知晓发生什么之前要求通知 | 检索各适用制度的监管底线（引用主源——个保法第57条要求"立即"通知）；对比操作手册立场 |
| 硬性数据本地化（单一城市/数据中心） | 可能不匹配架构 | 应用操作手册关于数据位置的立场；确认我们实际能承诺什么 |
| 受托处理者责任无上限 | 赌公司 | 应用操作手册关于数据责任的立场 |
| 客户可发出有约束力的"指示" | 开放式运营控制 | 将指示定义为"合同约定或书面同意" |
| 极短期限内的删除 | 备份和日志保留使此不可能 | 应用操作手册关于终止后删除的立场；记录备份循环例外 |

### 当我们是处理者时：保护性审查

供应商的 DPA 试图什么都给我们。但对我们：不给。对以下每一条，对比处理者侧操作手册。

| 条款 | 缺口 | 检索 / 操作手册查询 |
|---|---|---|
| 无下游处理者名单 | 不知道谁接触我们的数据 | 要求公开当前名单 + 按操作手册要求的事先通知 |
| "行业标准安全" | 毫无意义 | 要求附具体控制措施的附件，或引用指定的标准（如等级保护三级、ISO 27001） |
| 无泄露通知时限 | 他们随便什么时候告诉我们 | 检索适用监管底线（个保法第57条作为参照 `[法条原文]`）；要求操作手册立场 |
| 完全没有审计权 | 无法核实任何事 | 至少要求按操作手册的独立审计报告 |
| 供应商可将数据用于"服务改进" | 可能在我们数据上训练模型 | 删除；处理限于向我们提供服务 |
| 无数据出境机制 | 无合法出境机制 | **检索当前有效的出境机制**适用于相关路径（数据来源地/目的地，适用制度，任何充分性认定，任何补充措施）。引用主源并验证时效。 |
| 无删除承诺 | 数据永远存在 | 要求操作手册关于删除的立场 + 按请求认证 |

## 一致性检查：个人信息处理规则

你签署的 DPA 不能承诺处理规则未涵盖的内容，反之亦然。

- 如果 DPA 承诺仅为 X、Y、Z 目的处理——处理规则是否列出这些目的？
- 如果处理规则说"我们从不向第三方提供数据"——DPA 中是否有任何条款看起来像向第三方提供或共享？
- 如果处理规则指定了特定的下游处理者类别——DPA 的下游处理者名单是否匹配？

标示不匹配。通常是处理规则陈旧，而非 DPA 错误，但必须有人修复其中之一。

## 修订标记粒度

**以尽可能最小的粒度编辑。** 修订标记是谈判工件，不是重写。整条替换信号"我们抛掉了你们的起草"——这是侵略性的，它迫使对方重新阅读整条，并丢弃了他们起草中那部分没问题的内容。手术式的修订标记——删除一个词、插入一个短语、重构一个子条款——信号"我们有具体的诉求"，更容易阅读、理解和接受。

默认使用最小的编辑来实现操作手册立场：
- 先替换一个**词**，而非短语。（"十二（12）" → "二十四（24）"）
- 先替换一个**短语**，而非句子。（"由买方支付" → "由买方支付且应付"）
- 先重构一个**子条款**，而非替换句子。（添加"(a)"和"(b)"以拆分复合条件。）
- 先替换一个**句子**，而非替换整条。
- 仅当对方的版本离你的立场太远、手术式编辑比重新起草更难阅读时，才替换**整条**——此时在传递函中说明："我们替换了第8.2条而非逐处修订，因为变更范围广泛。愿意带您逐项过一遍变化。"

存疑时，用更小的。收到手术式修订标记的客户信任你仔细阅读了。收到整体替换的客户怀疑你根本就没读。

## 输出

冠以 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` `## 输出` 中的工作成果抬头（因用户角色不同而异——见 `## 谁在使用`）。

```markdown
[工作成果抬头 — 按插件配置 ## 输出]

# DPA 审查：[对方当事人]

**方向：** [我们是受托处理者 / 我们是处理者]
**审阅日期：** [日期]
**所附于：** [主合同 / 独立文件]

---

## 结论

[两句话。能否签署？什么必须变更？]

**问题：** [N]🟢 [N]🟡 [N]🟠 [N]🔴

---

## 逐条审查

[对每个核心条款，使用标准偏差备忘录格式：对方 DPA 怎么写的，我们操作手册怎么说的，差距，风险，以及提议的修订语言。每条保持为简短的独立块，以便审核人可以略读。]

---

## 个人信息处理规则一致性

[🟢 一致 | 🟡 提示：列出]

---

## 建议修订

[汇总——可直接发回]

---

## 如对方不让步

[对每个问题：来自配置 CLAUDE.md 的退让立场，或如无退让立场则升级路径]
```

## 数据出境说明

如果 DPA 涉及数据出境，**检索当前有效的出境机制要求**适用于相关通道。对每个来源地/目的地对，识别：适用制度，是否需要进行安全评估（《数据出境安全评估办法》）、签署标准合同（《个人信息出境标准合同办法》）或获得认证（个保法第38条），是否需要出境安全评估报告，以及可能需要哪些补充措施。引用主源（法律、行政法规、网信办指引）附精准引用并验证时效——安全评估门槛、标准合同版本和所需补充措施因新规出台而变化。不确定时标示，供律师核实。

如果缺失出境机制且确实有数据出境，这是 🔴——无合法出境机制。

## 关口：签署 DPA

审查 DPA 是研究。*签署*它——或指示某人代表我们签字盖章——是具有法律后果的行为。

**在签署 DPA（包括返回已签署版本、在对方平台上同意自动执行、或指示签字人签署）之前：** 读取 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` 中的 `## 谁在使用`。如果角色为非律师：

> 签署 DPA 是法律行为——它使公司受到具体的数据保护义务约束，这些义务流向监管机构和个人信息主体。你是否已请律师审查过？如已审查，继续。如未审查，以下是你带给律师的简要材料：
>
> [生成1页摘要：对方当事人，方向（我们是受托处理者/处理者），偏离操作手册的条款及如何解决的，任何待定的退让决定，以及签署前应询问律师的三件事。]
>
> 如果你需要寻找执业律师或其他经授权的法律专业人士：通过你所在地区的律师协会或司法局的律师查询系统是最快的起点。

未经明确同意，不得越过此关口。

## 以下一步决策树结束

以符合 CLAUDE.md `## 输出` 的下一步决策树结束。根据本技能刚刚产出的内容定制选项——五个默认分支（起草X、升级、获取更多事实、观察和等待、其他）是起点，而非锁定。决策树即输出；律师选择。

## 本技能不做的事

- 不从头起草 DPA。如果答案是"用我们的模板"，从配置 CLAUDE.md 中的种子文档路径提取模板。
- 不做出境安全评估本身——它标注何时需要一个。
- 不决定是否接受超出退让立场的条款。它按升级表路由这些决策。