审查数据处理协议(DPA)时：按处理者/控制者方向套用…

客户发来 DPA、供应商 DPA 或要求检查 data processing addendum 时，用于确定方向、逐条审查、识别行业监管 overlay 并输出可发送的红线与审查备忘录。

适用场景

解决思路

1. 加载 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` 中的 DPA playbook；如果其中还是占位符，停止并提示先完成设置。
2. 获取 DPA（文件、Drive 链接或粘贴文本），判断方向：我们是 processor（客户发来的 DPA）还是 controller（供应商的 DPA）；不明确就询问。
3. 按本技能工作流逐条对照相应 playbook 行运行；运行隐私政策一致性检查；输出带 redlines 的审查备忘录；按 house style 保存。
4. 检查 practice-level CLAUDE.md 的 `## Matter workspaces`：若 `Enabled` 为 `✗`（in-house 默认），跳过其余 matter 段落，技能使用 practice-level 上下文，matter 机制不可见；若启用且没有 active matter，询问：“Which matter is this for? Run `/privacy-legal:matter-workspace switch <slug>` or say `practice-level`.” 加载 active matter 的 `matter.md` 获取 matter-specific 上下文和 overrides；把输出写入 matter 文件夹 `~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/`；除非 `Cross-matter context` 为 `on`，绝不读取另一个 matter 的文件。
5. 先确定方向：我们是 processor → 客户发来 DPA → 读取 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` 的 “When we are the processor” 表；我们是 controller → 我们向 vendor 发送 DPA（或审查其 DPA）→ 读取 “When we are the controller” 表；不清楚就问。方向错会反转每一条建议。
6. 采用配置中指定的管辖范围假设；若 controller、processor 或 data subjects 位于与配置不同的 jurisdiction，本审查可能不按原样适用。
7. 加载同一 counterparty/processing activity 的先前上下文：读取 `~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md` 的 `## Outputs` 获取输出文件夹路径，扫描 prior `use-case-triage` 结果（风险评级和条件应遵守或明确偏离）、prior `pia-generation` 输出（PIA 标记的风险缓解需在 DPA 实现）、prior `dpa-review` 输出（保持一致性，避免无说明矛盾）。若找到，在审查中引用：prior triage ([date]) rated this [risk level] and conditioned approval on [X]. This DPA review is consistent with that finding. 或 prior triage ([date]) rated this [risk level]. This DPA review departs from that finding because [reason — new facts, different scope, contract term that changed the picture]. 按 shared guardrails 的 cross-skill severity floor，上游 🔴 不能在 DPA review 中悄悄降为 🟢；任何降级需说明并解释。若未找到，明确写 “No prior triage or PIA on this counterparty in outputs folder”。
8. 加载 playbook：读取 `CLAUDE.md` 的 `## DPA playbook`；同时读取 `## Privacy policy commitments`，确保 DPA 不能与隐私政策承诺矛盾。
9. 先问 federal sectoral overlay，再进行逐条审查：数据是否涉及联邦监管类别？逐项询问是否涉及 GLBA/Reg P 金融账户数据或 NPI（要求 NPI-sharing restriction consistent with 15 U.S.C. § 6802(a)-(c) and Reg P、safeguards aligned with 16 C.F.R. Part 314、incident notification reaching FTC/OCC timing、clean carve-out 避免 CCPA § 1798.145(e) 豁免意外 waived GLBA-level obligations）；HIPAA PHI held by covered entity/business associate（要求 BAA layered with or integrated into DPA per 45 C.F.R. § 164.504(e)、HITECH breach timing 60 days to CE; CE 60 days to HHS; 500+ threshold for media、permitted-uses clause、subcontractor BAA flow-down；商业 DPA 无 BAA flow-down for PHI 是 defect）；FERPA 教育记录（school official/directory-information framing consistent with 34 C.F.R. § 99.31、parental-consent flow-through、state student-privacy analog handling NY Ed Law 2-d, CA SOPIPA, IL SOPPA）；COPPA 13岁以下儿童（verifiable-parental-consent flow-through、retention limits、deletion-on-request machinery、禁止 behavioral advertising absent VPC）；其他 sectoral federal regime（VPPA, CPNI, DPPA, TCPA/Shaken-Stir, GLBA Reg S-P, §5 FTC Act）。若任一为是，联邦 overlay 通常提供 controlling substantive restriction，不只是 state consumer privacy law 的 exemption；研究当前生效条款并引用。若 DPA 因 GLBA-covered 而 “exempt” from CCPA under § 1798.145(e)，仍受 GLBA 限制；在 deal-breakers list 中与 GDPR/state-privacy gaps 一起标记 sectoral gaps。若没有 sectoral overlay，明确写 “no federally-regulated data categories identified; sectoral overlay n/a”。
10. 进行核心条款逐条审查：对每个 DPA 逐 clause 走以下 terms；具体数值和实质立场从 `CLAUDE.md` 的 `## DPA playbook` 获取；任何 DPA 必须满足的监管底线来自 primary law——研究每个适用 regime 当前生效的规则，并在陈述底线前引用 primary sources。
11. 遵守 no silent supplement：如果对 configured legal research tool 的 research query 对某 regime 的 breach window、transfer-mechanism requirement、subprocessor-change rule 或其他 floor 返回很少或无结果，报告发现并停止；不要未经询问从 web search 或 model knowledge 填补。说：“The search returned [N] results from [tool]. Coverage appears thin for [regime / topic]. Options: (1) broaden the search query, (2) try a different research tool, (3) search the web — results will be tagged `[web search — verify]` and should be checked against a primary source before relying, or (4) flag as unverified and stop. Which would you like?” 由律师决定是否接受低置信来源。
12. 按来源归因分层给每条引用打 tag：regulatory floors、SCC versions、adequacy decisions、regulator guidance、case law。model-knowledge citations 使用三个 tier：`[settled]` stable, well-known statutory and regulatory references unlikely to have changed (e.g., GDPR Art. 28, Art. 33 72-hour breach notice, SCC Decision 2021/914 by number) still verify before filing but lower priority；`[verify]` model-knowledge citations that are real but should be verified: specific implementing regulations, regulator guidance, case holdings, adequacy decisions, SCC modules and versions, UK Addendum/IDTA status, thresholds, effective dates；`[verify-pinpoint]` pinpoint citations (specific subsection letters, clause numbers within SCCs, paragraph numbers, volume/page references) highest fabrication risk and ALWAYS verify against a primary source。Tool-retrieved citations keep source tag (`[Westlaw]`, `[Commission / regulator site]`, or MCP tool name)；web-search citations remain `[web search — verify]`；user-supplied citations remain `[user provided]`。Never strip or collapse the tags。
13. 逐项检查 core terms（每项看对方文本、playbook 字段、常见争议）：Roles：清晰 controller/processor designation；matches reality；常见争议 counterparty 把关系标为 “joint controller” 等与事实不符。Processing scope：limited to documented instructions；defined purposes；常见争议 open-ended scope expanders（“and related purposes”）。Subprocessors：current list disclosed，change mechanism defined；playbook 字段 Subprocessor changes；常见争议 blanket approval vs. veto vs. notice-only。Security measures：Annex references specific controls or standards；playbook 字段 Security standards；常见争议 “appropriate technical and organizational measures” with no annex = empty promise。Breach notification：defined trigger（“discovery” vs “confirmation”），defined timeline；playbook 字段 Breach notification；常见争议 timeline tightness、clock trigger、“without undue delay” is vague。Audit rights：method（report vs. on-site）、frequency、notice、cost allocation；playbook 字段 Audit rights；常见争议 on-site audits on tight notice。International transfers：transfer mechanism identified、supplementary measures、transfer impact assessment reference；playbook 字段 Transfers；常见争议 outdated or missing transfer mechanisms。Deletion/return：timeline post-termination、certification、backup carveout；playbook 字段 Deletion on termination；常见争议 “commercially reasonable” deletion = ???。Liability：within MSA cap or separate；carveouts；playbook 字段 Liability for data；常见争议 uncapped data breach liability = existential。
14. 当我们是 processor：做 defensive review。Customer DPAs 试图把 operational burden 推给我们；逐 clause 比较 customer ask 与 playbook。若 customer ask 超出 playbook，push back 到 config CLAUDE.md 的 team standard position，并准备 fallback 到 acceptable position。逐项：Subprocessor approval right (veto) → 不能逐客户批准才能加基础设施 → 应用 playbook position on subprocessor changes。On-site audit on short notice → 规模化不可行 → 应用 playbook position on audit rights。Aggressive breach notification window → 常要求在我方知道发生了什么之前通知 → 研究每个适用 regime 的 regulatory floor（引用 primary sources），对比 playbook position。Hard data residency (single country/DC) → 可能不符合架构 → 应用 playbook position on data location，确认实际能承诺什么。Processor liability uncapped → bet-the-company → 应用 playbook position on liability for data。Customer may issue binding “instructions” → open-ended operational control → 将 instructions 定义为 “documented in the Agreement or agreed in writing”。Deletion on very short timeline → backup and log retention 使其不可能 → 应用 playbook position on deletion on termination，并 document backup rotation carveout。
15. 当我们是 controller：做 protective review。Vendor DPAs 试图什么都不给；逐 clause 比较 controller-side playbook。逐项：No subprocessor list → 不知道谁接触我们的数据 → 要求 published current list + advance notice per playbook。“Industry standard security” → 毫无意义 → 要求 annex with specific controls，或 reference to a named standard (e.g., SOC 2, ISO 27001)。No breach notification timeline → 他们随时告诉我们 → 研究 applicable regulatory floor，要求 playbook position。No audit rights at all → 无法验证任何事 → 要求至少 independent audit report per playbook。Vendor can use data for “service improvement” → 可能训练我们的数据 → strike；processing limited to providing the service to us。No international transfer mechanism → 没有合法 transfer mechanism → 研究 corridor 当前生效的 transfer mechanism（origin/destination jurisdictions、applicable regime、any adequacy decision、any supplementary measures），引用 primary sources 并 verify currency。No deletion commitment → 数据永久存在 → 要求 playbook position on deletion + certification on request。
16. 运行隐私政策一致性检查：签的 DPA 不能承诺 privacy policy 不覆盖的内容，反之亦然。检查：如果 DPA 承诺 processing only for purposes X, Y, Z，privacy policy 是否列出这些 purposes？如果 privacy policy 说 “we never sell data”，是否有任何 DPA clause 在 CCPA 下看起来像 sale？如果 privacy policy 点名特定 subprocessor categories，DPA subprocessor list 是否匹配？标记 mismatch；通常是 privacy policy stale，不是 DPA 错，但需有人修复一个。
17. Redline 以最小可能粒度编辑：redline 是 negotiation artifact，不是 rewrite。整体替换 clause 会显得 aggressive、迫使对方重读全条、丢弃他们好的起草；surgical redlines（删一个词、插入短语、重构子条款）表示具体请求，更快阅读理解和接受。默认最小编辑达到 playbook position：先换 word 再换 phrase（“twelve (12)” → “twenty-four (24)”）；先换 phrase 再换 sentence（“paid by the Buyer” → “paid and payable by the Buyer”）；先重构 subclause 再替换 sentence（加 “(a)” 和 “(b)” 拆分 compound condition）；先换 sentence 再换 clause；只有 counterparty version 离我方立场太远、surgical edits 更难读时才替换 whole clause——并且要在 transmittal 说明：“We've replaced §8.2 rather than marking it up because the changes were extensive. Happy to walk you through the delta.” 当不确定时，更小。
18. 输出：prepend work-product header（来自 `CLAUDE.md` 的 `## Outputs`，按 user role 不同）。生成 markdown：header；`# DPA Review: [Counterparty]`；`Direction:` [We are processor / We are controller]；`Reviewed:` [date]；`Attached to:` [MSA / standalone]；`Bottom line` 两句话：能否签？必须改什么？；`Issues:` [N]🟢 [N]🟡 [N]🟠 [N]🔴；`Term-by-term`：每个核心 term 用 standard deviation-memo format——对方 DPA 说什么、playbook 说什么、gap、risk、proposed redline language，每 term 短小自包含便于 skim；`Privacy policy consistency`：🟢 Consistent | 🟡 Flags: list；`Recommended redlines`：合并，ready to send back；`If they won't move`：每个 issue 给 config CLAUDE.md fallback，或 no fallback 时给 escalation routing。
19. International transfers note：如果 DPA 涉及跨境数据传输，研究适用 corridor(s) 当前生效的 transfer mechanism requirements。对每个 origin/destination pair，识别：applicable regime；是否有 adequacy decision 生效；要求或可用的 transfer mechanism（例如 Standard Contractual Clauses 及其 applicable version/module、UK Addendum or IDTA、BCRs、derogations）；是否需要 transfer impact assessment 或同等文件；可能需要哪些 supplementary measures。引用 primary sources（regulation、Commission decision、regulator guidance、controlling case law）带 pinpoint cites 并 verify currency——adequacy decisions、SCC versions、required supplementary measures 会通过新 Commission decisions、court rulings、regulator guidance 变化。标记不确定供 attorney verification。若存在国际传输但缺少 transfer mechanism，这是 🔴——没有合法传输机制。
20. Gate: signing a DPA。审查 DPA 是研究；签署或指示代签（包括返回已签署版本、在对方平台同意自动执行、指示签署人执行）才是 consequential act。签署或 countersign DPA 前：读取 `CLAUDE.md` 的 `## Who's using this`。若 Role 为 Non-lawyer：问“Signing a DPA is a legal act — it binds the company to specific data-protection obligations that flow to regulators and data subjects. Have you reviewed this with an attorney? If yes, proceed. If no, here's a brief to bring to them:” 并生成 1-page summary：counterparty、direction（we are processor / controller）、terms that deviate from the playbook and how they were resolved、any open fallback decisions、three things to ask the attorney before executing。如果需要找 licensed attorney/solicitor/barrister/other authorised legal professional：建议联系职业监管机构的 referral service（US state bar、England & Wales SRA/Bar Standards Board、Scotland/NI/Ireland/Canada/Australia Law Society 或当地 equivalent）。未获 explicit yes 不得越过此 gate。
21. 结尾用 next-steps decision tree，按 `CLAUDE.md` 的 `## Outputs`。定制选项到本技能产出：五个默认分支（draft the X, escalate, get more facts, watch and wait, something else）是起点不是锁定；decision tree 是 output，律师选择。
22. 明确本技能不做什么：不从零起草 DPA；若答案是 “use our template”，从 config CLAUDE.md 的 seed docs path 拉模板；不自己做 Transfer Impact Assessment——只在需要时标记；不决定是否接受 fallbacks 之外的条款——按 escalation table 路由。

适用边界 · 注意事项

• 当 `CLAUDE.md` 中的 DPA playbook 仍是占位符、设置未完成时；技能会停止并提示 setup。
• 当用户要求从零起草 DPA、执行 Transfer Impact Assessment，或直接签署 DPA 时；这些不在本技能范围内，签署还受 attorney gate 限制。
• 当处理活动涉及配置管辖范围之外的司法辖区且未另行调整时；本审查可能不按原样适用。