Dpa Review

/dpa-review

1. 加载 ~/.claude/plugins/config/claude-for-legal-zh/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-zh/privacy-legal/matters/<matter-slug>/。除非 跨事项上下文 为 开启，否则绝不读取其他事项的文件。

目的

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

首先：哪个方向？

做任何事之前，先确定：

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

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

法域假设

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

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

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

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

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

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

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

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

加载操作手册

读取 ~/.claude/plugins/config/claude-for-legal-zh/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-zh/privacy-legal/CLAUDE.md → ## DPA 操作手册。任何 DPA 必须满足的监管底线来自主源法律——检索每个适用制度的现行有效规则并引用主源后再陈述底线。

禁止静默补充。 如果检索查询返回结果很少或为零，报告找到的内容并停止。不要未经询问即从网络搜索或模型知识填补空白。说："搜索返回[N]条结果。覆盖显得薄弱。选项：(1) 扩大搜索查询，(2) 尝试不同的检索工具，(3) 搜索网页——结果将标记为 [联网检索 — 需复核]，(4) 标记为未验证并停止。你想选哪个？"由律师决定是否接受可信度较低的来源。

来源溯源标签分层。 为审查中每处引用标记来源。对于模型知识引用，使用三层而非单一"验证"标签：

• [已确定] — 稳定、众所周知的法定和行政法规引用，不太可能已变更（如个保法第21条委托处理、第57条泄露通知）。提交前仍应验证，但优先级较低。
• [需验证] — 模型知识引用是真实的但应验证：具体实施细则、监管部门指引、案例立场、阈值、生效日期。
• [需验证——精准引用] — 精准引用（具体款号、条号、段落编号）造假风险最高，应始终对照主源验证。

检索工具获取的引用保留其来源标签；网页搜索引用保留 [联网检索 — 需复核]；用户提供的引用保留 [用户提供]。分层揭示了真正的验证工作——什么都验证的人什么也没验证。绝不剥离或折叠标签。

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

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

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

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

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

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

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

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

修订标记粒度

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

默认使用最小的编辑来实现操作手册立场：

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

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

输出

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

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

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

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

---

## 结论

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

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

---

## 逐条审查

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

---

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

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

---

## 建议修订

[汇总——可直接发回]

---

## 如对方不让步

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

数据出境说明

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

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

关口：签署 DPA

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

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

签署 DPA 是法律行为——它使公司受到具体的数据保护义务约束，这些义务流向监管机构和个人信息主体。你是否已请律师审查过？如已审查，继续。如未审查，以下是你带给律师的简要材料：

[生成1页摘要：对方当事人，方向（我们是受托处理者/处理者），偏离操作手册的条款及如何解决的，任何待定的退让决定，以及签署前应询问律师的三件事。]

如果你需要寻找执业律师或其他经授权的法律专业人士：通过你所在地区的律师协会或司法局的律师查询系统是最快的起点。

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

以下一步决策树结束

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

本技能不做的事

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