Dpa Clause Reviewer

---
name: dpa-clause-reviewer
title: 数据处理协议条款审查
description: 当需要对照内部 DPA 立场清单逐条审查一份数据处理协议时使用；自动判定己方是处理者还是控制者并据此审查，产出含红线修改的审查备忘录；不适用于从零起草 DPA、独立的传输影响评估（TIA）或决定是否接受清单外条款（这些应升级转交律师）；触发词：审查DPA、数据处理协议、数据处理附录、DPA review、data processing agreement、子处理者、违约通知、跨境传输、SCC。
domain: 领域/legal
triggers: [审查DPA, 数据处理协议, 数据处理附录, DPA review, data processing agreement, 子处理者, 违约通知, 跨境传输, SCC]
tags: [legal, privacy, dpa, gdpr, data-protection, contract-review, compliance]
level: 精通
status: stable
agents: [claude-code, codex, cursor, gemini-cli]
tools: [DPA playbook (内部立场清单), 法律检索工具/MCP (Westlaw 等), primary-source 引用]
requires: []
related: [gdpr-data-handler, dsar-response-builder, privacy-impact-assessor, nda-triage-reviewer]
combines_with: [gdpr-data-handler, privacy-impact-assessor]
license: Apache-2.0
source: anthropics/claude-for-legal
source_license: Apache-2.0
---
## 何时使用

- 用户说"审查这份 DPA / 数据处理协议 / 数据处理附录"，或"客户发来了他们的 DPA""这份 DPA 行不行"，或直接附上一份 DPA 文件/链接/文本时。
- 核心前提：你有一份**内部 DPA 立场清单（playbook）**，记录了通知期、违约时限、可接受/不可接受底线等具体数值与立场。没有立场清单则先要求配置，不要凭空编造立场。

**不该用的边界：**
- 不从零起草 DPA。若结论是"用我们的模板"，去取模板而非生成。
- 不亲自做传输影响评估（TIA）——只标注何时需要做。
- 不替人决定是否接受立场清单之外的条款——这类按升级路径转交律师。

## 步骤

1. **加载立场清单**：读取内部 DPA playbook；同时读取隐私政策承诺（DPA 不能与隐私政策互相矛盾）。若是占位符未配置，停止并提示配置。
2. **先定方向（最关键）**：判定己方角色——
   - 我们是**处理者**（客户把他们的 DPA 发给我们）→ 用"作为处理者"那一栏，做**防御性审查**，守住运营灵活性。
   - 我们是**控制者**（我们把 DPA 发给供应商，或审查供应商的）→ 用"作为控制者"那一栏，做**保护性审查**，守住数据。
   - 不清楚就问。**搞错方向会让每一条建议反向。**
3. **加载历史上下文**：检查输出文件夹中针对同一对手方/处理活动的既往产出（用例分流、PIA、过往 DPA 审查）。命中则在备忘录中引用，并**把上游严重级别作为下限**——分流评为🔴的活动不能在本次审查中被悄悄降为🟢，任何降级都要写明理由。无历史则明确写"输出文件夹中无此对手方的既往分流或 PIA"，让审阅律师知道这步跑过了。
4. **联邦/行业叠加层（在逐条审查前先问）**：本协议流经的数据是否含受联邦/行业专门法监管的类别？GDPR 与各州消费者隐私法是一道底线，行业专门法往往是通用清单里没有的另一道。逐项确认（见下方指令）。无则明确写"未识别到受专门法监管的数据类别；行业叠加层 n/a"。
5. **逐条审查**：对照立场清单逐条款走核心条款表。监管底线必须**检索当前生效的规则并引用一手来源**，不得凭模型知识填补。
6. **隐私政策一致性检查**：DPA 承诺的处理目的、子处理者类别等是否与隐私政策一致；是否有条款在 CCPA 下构成"出售"而与"绝不出售数据"的政策冲突。标注不一致项。
7. **出具产物**：含红线的审查备忘录，按内部文体保存到对应目录。

## 指令

**核心条款逐条走查表**（具体数值/底线来自立场清单，监管底线来自一手法律）：

| 条款 | 关注点 | 常见争点 |
|---|---|---|
| 角色 | 控制者/处理者界定清晰且与事实相符 | 对手方标成"联合控制者"等不符实际 |
| 处理范围 | 限于书面指示、目的明确 | 开放式扩张（"及相关目的"） |
| 子处理者 | 现有清单已披露、变更机制明确 | 概括批准 vs 否决权 vs 仅通知 |
| 安全措施 | 附件引用具体控制或标准 | "适当技术与组织措施"却无附件＝空头承诺 |
| 违约通知 | 触发点（"发现"vs"确认"）与时限明确 | 时限松紧、计时起点、"不无故拖延"太模糊 |
| 审计权 | 方式（报告 vs 现场）、频率、通知、费用分担 | 短通知期的现场审计 |
| 跨境传输 | 传输机制已指明、补充措施、TIA 引用 | 机制过时或缺失 |
| 删除/返还 | 终止后时限、证明、备份豁免 | "商业上合理"的删除＝？ |
| 责任 | 在 MSA 上限内或单列、例外 | 数据泄露责任不封顶＝致命 |

**作为处理者（防御）**：子处理者逐客户否决权→套用清单立场；短通知现场审计→不可行；激进违约通知窗口→检索各适用法域监管底线并引一手来源对比清单；硬性数据驻留→确认架构能承诺什么；处理者责任不封顶→赌上公司；客户可发约束性"指示"→定义为"协议中书面记载或书面另行约定"；删除时限过短→记录备份轮换豁免。

**作为控制者（保护）**：无子处理者清单→要求公布现行清单＋提前通知；"行业标准安全"→要求附件列具体控制或指名标准（SOC 2、ISO 27001）；无违约通知时限→检索监管底线并要求清单立场；无审计权→至少要求独立审计报告；供应商可将数据用于"服务改进"→删除，处理仅限向我们提供服务（防止拿我们数据训练）；无跨境传输机制→**检索该走廊当前生效的传输机制**并引一手来源；无删除承诺→要求清单立场＋按需出具删除证明。

**联邦/行业叠加层逐项问**：GLBA/Reg P（金融账户数据、消费者 NPI）；HIPAA（受保护健康信息 PHI，需 BAA 与 DPA 叠加并下沉至分包商）；FERPA（教育记录，"学校官员"框架、家长同意流转）；COPPA（13 岁以下儿童数据，需可验证家长同意流转、留存限制、按需删除）；其他（VPPA/CPNI/DPPA/TCPA 等）。**关键**：CCPA § 1798.145(e) 的"豁免"只是移动了治理框架而非消除义务——GLBA 覆盖的数据仍受 GLBA 约束。

**两条硬规矩：**
- **不得静默填补**：检索工具对某监管底线返回结果稀少时，报告所得并**停下来问**，不要用网络搜索或模型知识私自补全。
- **来源分级标注**：每条引用打标签——`[settled]`（GDPR 第28条、第33条72小时通知等稳定引用，仍需核但优先级低）、`[verify]`（具体实施细则、监管指南、判例、充分性决定、SCC 模块版本、阈值、生效日期）、`[verify-pinpoint]`（具体小节字母、SCC 内条款号、段落号等精确定位，伪造风险最高，**必须**对照一手来源核验）。工具来源保留 `[Westlaw]`/`[监管机构站点]` 标签，网络搜索为 `[web search — verify]`，用户提供为 `[user provided]`。**绝不剥除或合并标签。**

**红线粒度——以能达成立场的最小改动为默认。** 红线是谈判物，不是重写。整条替换显得"把你的起草全推翻"。优先级：改一个词（"twelve (12)"→"twenty-four (24)"）＞改短语＞重构子条款＞替换整句＞替换整条。只有当对手方版本离立场太远、外科式修改反而更难读时才整条替换，并在转送函中说明原因。

**签署闸门**：审查 DPA 是研究，**签署**才是有后果的行为。在签署/会签/同意平台自动执行前，若使用者角色是非律师，须提示："签署 DPA 是法律行为，会让公司承担流向监管者和数据主体的特定数据保护义务。是否已与律师审过？"并生成一页摘要（对手方、方向、偏离清单的条款及其处理、未决回退决定、签前要问律师的三件事）。**未得到明确"是"不得越过此闸门。**

## 示例

```
用户：客户发来了他们的 DPA，帮我看看能不能签。customer-dpa.pdf
```

处理路径：
1. 加载立场清单与隐私政策承诺。
2. 定方向：客户发来他们的 DPA → **我们是处理者** → 走防御性审查。
3. 扫输出文件夹：找到该客户 3 个月前的用例分流，评级🟡——本次审查须不低于此下限。
4. 联邦叠加层：数据含消费者金融账户信息 → 触发 GLBA/Reg P，DPA 需要安全保障规则对齐措施与 NPI 共享限制；标为缺陷。
5. 逐条走查：违约通知要求"24 小时内"但立场清单底线是"发现后 72 小时" → 红线改回；子处理者逐客户否决权 → 推回至概括通知＋异议机制。
6. 隐私政策一致性：DPA 列的子处理者类别与政策一致 → 🟢。
7. 出具备忘录骨架：

```markdown
# DPA 审查：[对手方]
**方向：** 我们是处理者
**审查日：** [日期]    **附属于：** MSA

## 结论
[两句话：能签吗？必须改什么？]
**问题：** [N]🟢 [N]🟡 [N]🟠 [N]🔴

## 逐条
[每个核心条款一块：对手方怎么写／我们清单怎么说／差距／风险／拟议红线]

## 隐私政策一致性
[🟢 一致 | 🟡 标记：列出]

## 建议红线
[已整合，可直接回传]

## 若对方不让步
[每个问题的回退立场，或无回退时的升级路由]
```

## 注意事项

- **方向定错＝全盘反向**，这是第一优先级，模棱两可必须先问。
- **法域假设**：本审查假定配置中指定的法域范围。GDPR、州消费者隐私法、行业法的规则、响应时限、合法性基础差异巨大；若控制者/处理者/数据主体在配置外的法域，审查可能不适用。
- 跨境传输若**缺失传输机制**且确有国际传输 → 直接判 🔴（无合法传输机制）。SCC 版本、充分性决定、所需补充措施会因新决定/判例/监管指南而变，引一手来源并核验时效。
- 严重级别只能升不能悄悄降；任何降级都写明并解释。
- 检索稀少不要硬填——停下来问，由律师决定是否接受低置信来源。

## 互见

- fact-checking：核验一手来源引用（充分性决定、SCC 版本、判例时效）时配合使用。
- first-principles-thinking：在方向判定或条款立场存在根本分歧时，回到"我们到底在保护什么"重新推演。

---

*本条采编自 anthropics/claude-for-legal（Apache-2.0），适配重写为中文技能大典条目。*