dpa-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/dpa-review

/dpa-review

  1. Load
    ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
    → DPA playbook. If placeholders, stop and prompt setup.
  2. Get the DPA. Determine direction: are we processor (customer's DPA) or controller (vendor's)? Ask if ambiguous.
  3. Run the workflow below — term-by-term against the appropriate playbook row.
  4. Run privacy policy consistency check.
  5. Output: review memo with redlines. Save per house style.
/privacy-legal:dpa-review customer-dpa.pdf

  1. 加载
    ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
    → DPA操作手册。如果存在占位符,请停止操作并提示完成设置。
  2. 获取DPA文件,确定关系方向:我们是处理者(客户提供DPA)还是控制者(供应商提供DPA)?若存在歧义,请询问用户。
  3. 执行以下工作流——逐条对照操作手册中对应部分的条款。
  4. 执行隐私政策一致性检查。
  5. 输出:包含修订标记的审查备忘录,并按照内部格式保存。
/privacy-legal:dpa-review customer-dpa.pdf

DPA Review

DPA审查

Matter context

事项背景

Matter context. Check
## Matter workspaces
in the practice-level CLAUDE.md. If
Enabled
is
(the default for in-house users), skip the rest of this paragraph — skills use practice-level context and the matter machinery is invisible. If enabled and there is no active matter, ask: "Which matter is this for? Run
/privacy-legal:matter-workspace switch <slug>
or say
practice-level
." Load the active matter's
matter.md
for matter-specific context and overrides. Write outputs to the matter folder at
~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/
. Never read another matter's files unless
Cross-matter context
is
on
.

事项背景。查看实践级CLAUDE.md中的
## Matter workspaces
部分。如果
Enabled
(内部用户默认设置),则跳过本段剩余内容——技能将使用实践级上下文,事项机制不可见。如果已启用且无活跃事项,请询问:“这是针对哪个事项的?请运行
/privacy-legal:matter-workspace switch <slug>
或说明
practice-level
。”加载活跃事项的
matter.md
文件以获取特定事项的上下文和覆盖规则。将输出写入事项文件夹:
~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/
。除非
Cross-matter context
设置为
on
,否则不得读取其他事项的文件。

Purpose

目的

DPAs come in two flavors and the review is nearly opposite for each. When a customer sends their DPA, we're defending our operational flexibility. When we send one to a vendor, we're protecting our (and our customers') data. Both reviews read from the same
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
playbook but from opposite rows.
DPA分为两种类型,针对不同类型的审查流程几乎完全相反。当客户发送他们的DPA时,我们需要维护自身的运营灵活性;当我们向供应商发送DPA时,我们需要保护自身(以及客户)的数据。两种审查都基于同一个
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
操作手册,但使用相反的章节内容。

First: which direction?

第一步:确定关系方向

Before anything else, establish:
  • We are the processor → customer is sending us their DPA → read
    ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
    → "When we are the processor" table
  • We are the controller → we're sending a DPA to a vendor (or reviewing theirs) → read "When we are the controller" table
If unclear, ask. Getting this wrong inverts every recommendation.
在开始任何工作之前,先明确:
  • 我们是处理者 → 客户向我们发送DPA → 读取
    ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
    → “当我们作为处理者”表格
  • 我们是控制者 → 我们向供应商发送DPA(或审查供应商提供的DPA)→ 读取“当我们作为控制者”表格
若方向不明确,请询问用户。方向判断错误会导致所有建议完全颠倒。

Jurisdiction assumption

司法管辖假设

This review assumes the jurisdictional scope specified in your configuration. Privacy rules, response deadlines, and lawful bases vary materially by jurisdiction (GDPR vs. state consumer privacy laws vs. sectoral). If the controller, processor, or data subjects are in a different jurisdiction than configured, this review may not apply as written.
本次审查基于您配置中指定的司法管辖范围。隐私规则、响应期限和合法依据因司法管辖区不同而存在重大差异(GDPR vs. 美国州级消费者隐私法 vs. 行业特定法规)。如果控制者、处理者或数据主体所在的司法管辖区与配置不符,本审查内容可能无法直接适用。

Load prior context on this counterparty / activity

加载该交易对手/活动的历史上下文

Before reviewing, check the outputs folder for prior work on this counterparty or processing activity. Read
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
## Outputs
for the outputs folder path. Scan for:
  • Prior
    use-case-triage
    results
    for the same counterparty / processing activity — the triage produces a risk rating and conditions that this DPA review should honor or explicitly depart from.
  • Prior
    pia-generation
    outputs
    covering this counterparty / processing activity — the PIA may have flagged risk mitigations the DPA needs to implement.
  • Prior
    dpa-review
    outputs
    for the same counterparty — earlier DPA reviews set expectations about what was acceptable, what was flagged, and what was settled. A fresh review that silently contradicts the earlier one erodes trust in the work product.
If a prior output is found, cite it in the review:
"Prior triage ([date]) rated this [risk level] and conditioned approval on [X]. This DPA review is consistent with that finding." — or — "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]."
Carry severity from the upstream output as a floor per the cross-skill severity floor rule in
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
## Shared guardrails
. A processing activity the triage rated 🔴 cannot be quietly downgraded to 🟢 in the DPA review; any demotion is stated and explained.
If no prior output is found (new counterparty / new activity), say so explicitly in the review — "No prior triage or PIA on this counterparty in outputs folder" — so the reviewing attorney knows the check ran.
审查前,请检查输出文件夹中关于该交易对手或处理活动的历史工作成果。读取
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
## Outputs
部分获取输出文件夹路径。检查以下内容:
  • 同一交易对手/处理活动的历史
    use-case-triage
    结果
    ——分类评估会生成风险评级和条件,本次DPA审查应遵循或明确说明偏离原因。
  • 涵盖该交易对手/处理活动的历史
    pia-generation
    输出
    ——隐私影响评估(PIA)可能已标记DPA需要落实的风险缓解措施。
  • 同一交易对手的历史
    dpa-review
    输出
    ——早期的DPA审查设定了可接受标准、标记问题和已解决事项。新审查若与早期结果无声矛盾,会削弱对工作成果的信任。
若找到历史输出,请在审查中引用:
“历史分类评估([日期])将此评为[风险等级],并要求满足[X]条件后方可批准。本次DPA审查与该结论一致。”——或—— “历史分类评估([日期])将此评为[风险等级]。本次DPA审查偏离该结论,原因是[理由——新事实、范围变更、合同条款变化]。”
根据跨技能最低严重程度规则,继承上游输出的严重程度,规则见
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
## Shared guardrails
。分类评估评为🔴的处理活动,在DPA审查中不得悄悄降级为🟢;任何降级都必须明确说明并解释原因。
若未找到历史输出(新交易对手/新活动),请在审查中明确说明——“输出文件夹中无该交易对手的历史分类评估或PIA记录”——以便审查律师确认已执行该检查。

Load the playbook

加载操作手册

Read
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
## DPA playbook
. Also read
## Privacy policy commitments
— the DPA can't contradict what the privacy policy promises.
读取
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
## DPA playbook
部分。同时读取
## Privacy policy commitments
部分——DPA不得与隐私政策的承诺相矛盾。

Federal sectoral overlay (ask first, before the term-by-term walk)

联邦行业特定规则覆盖(逐条审查前先确认)

Before walking the term-by-term review, answer: does the data flowing through this DPA include any federally-regulated category? GDPR and state consumer-privacy law supply one floor; federal sectoral law often supplies another that does not appear in the generic DPA playbook. A DPA that is GDPR-complete can still be GLBA-blind, HIPAA-blind, or COPPA-blind, and a fintech / healthtech / edtech / kidtech counterparty will notice.
Activity-based federal overlays — ask first:
Does this processing touch:
  • Financial account data or "nonpublic personal information" about consumers (GLBA / Reg P)? If yes, the DPA needs: (a) an NPI-sharing restriction consistent with 15 U.S.C. § 6802(a)-(c) and Reg P (no sharing for marketing to non-affiliated third parties without opt-out / opt-in), (b) safeguards language aligned with the Safeguards Rule (16 C.F.R. Part 314), (c) incident notification that reaches FTC/OCC timing where applicable, (d) a clean carve-out so a CCPA § 1798.145(e) exemption doesn't accidentally waive GLBA-level obligations.
  • Protected health information held by a covered entity or business associate (HIPAA Privacy / Security Rules)? If yes, the DPA needs: a Business Associate Agreement (BAA) layered with or integrated into the DPA per 45 C.F.R. § 164.504(e), breach notification timing aligned with HITECH (60 days to CE; CE 60 days to HHS; 500+ threshold for media), permitted-uses clause, subcontractor BAA flow-down. A commercial DPA without BAA flow-down for PHI is a defect.
  • Education records held by a school or a service provider acting for a school (FERPA)? If yes, the DPA needs: a "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).
  • Data from children under 13 collected by an operator of an online service directed to children or with actual knowledge (COPPA)? If yes, the DPA needs: verifiable-parental-consent flow-through, retention limits, deletion-on-request machinery, prohibition on behavioral advertising absent VPC.
  • Another sectoral federal regime (VPPA for video-viewing records, CPNI for carrier data, DPPA for DMV records, TCPA / Shaken-Stir for call/SMS, GLBA Reg S-P for broker-dealers, §5 FTC Act for unfair/deceptive practices around sensitive data)?
If yes to any: the federal overlay usually supplies the controlling substantive restriction, not just an exemption from a state consumer privacy law. Research the currently-operative provision and cite it. A DPA that is "exempt" from CCPA under § 1798.145(e) because it is GLBA-covered is still subject to the GLBA restrictions — the CCPA exemption moves the governing framework, it doesn't eliminate it. Flag sectoral gaps in the deal-breakers list alongside GDPR / state-privacy gaps.
If no sectoral overlay applies, note that explicitly — "no federally-regulated data categories identified; sectoral overlay n/a" — so the reviewing attorney sees that the check happened, rather than wondering whether it was skipped.
在开始逐条审查之前,请回答:本DPA涉及的数据是否包含任何受联邦监管的类别? GDPR和州级消费者隐私法设定了基础要求;联邦行业特定规则通常会设定额外要求,这些要求可能未包含在通用DPA操作手册中。一份符合GDPR要求的DPA仍可能未考虑GLBA、HIPAA或COPPA规则,而金融科技/医疗科技/教育科技/儿童科技领域的交易对手会注意到这一点。
基于活动的联邦规则覆盖——先确认:
本次处理是否涉及:
  • 消费者的金融账户数据或“非公开个人信息”(GLBA / Reg P)?若是,DPA需要:(a) 符合15 U.S.C. § 6802(a)-(c)和Reg P的NPI共享限制(未经选择退出/选择同意,不得与非关联第三方共享用于营销),(b) 符合《安全保障规则》(16 C.F.R. Part 314)的安全保障条款,(c) 符合FTC/OCC要求的事件通知时限(如适用),(d) 明确的例外条款,避免CCPA § 1798.145(e)豁免意外放弃GLBA级别的义务。
  • 受保实体或业务关联方持有的受保护健康信息(HIPAA隐私/安全规则)?若是,DPA需要:根据45 C.F.R. § 164.504(e),将业务关联方协议(BAA)嵌入或附加到DPA中,符合HITECH要求的 breach通知时限(60天内通知受保实体;受保实体60天内通知HHS;涉及500人以上时需通知媒体),允许使用条款,分包商BAA向下传导要求。未包含PHI分包商BAA传导要求的商业DPA存在缺陷。
  • 学校或代表学校的服务提供商持有的教育记录(FERPA)?若是,DPA需要:符合34 C.F.R. § 99.31的“学校官员”/目录信息框架,家长同意传导机制,州级学生隐私类似规则处理(NY Ed Law 2-d, CA SOPIPA, IL SOPPA)。
  • 面向儿童的在线服务运营商或明知收集的13岁以下儿童数据(COPPA)?若是,DPA需要:可验证的家长同意传导机制,保留期限限制,按需删除机制,禁止未经VPC的行为广告。
  • 其他联邦行业特定制度(视频观看记录的VPPA,运营商数据的CPNI,车管所记录的DPPA,通话/短信的TCPA / Shaken-Stir,经纪交易商的GLBA Reg S-P,敏感数据相关不公平/欺诈行为的§5 FTC Act)?
若以上任何一项为是:联邦规则覆盖通常提供控制性实质限制,而非仅作为州级消费者隐私法的豁免。研究当前生效的条款并引用。例如,因受GLBA管辖而符合CCPA § 1798.145(e)豁免的DPA,仍需遵守GLBA限制——CCPA豁免只是改变了管辖框架,并未消除义务。在重大问题清单中标记行业特定缺口,与GDPR/州级隐私缺口一并列出。
若不适用联邦规则覆盖,请明确说明——“未识别到受联邦监管的数据类别;行业特定规则覆盖不适用”——以便审查律师确认已执行该检查,而非怀疑是否被跳过。

The term-by-term review

逐条审查

Core terms (check every DPA)

核心条款(所有DPA均需检查)

Walk every DPA through these terms, clause by clause. The specific numeric and substantive positions (notice periods, breach timelines, acceptable/unacceptable floors) come from
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
## DPA playbook
. The regulatory floors that any DPA has to clear come from primary law — research the currently operative rule for each applicable regime and cite primary sources before stating a floor.
No silent supplement. If a research query to the configured legal research tool returns few or no results for a regime's breach window, transfer-mechanism requirement, subprocessor-change rule, or any other floor, report what was found and stop. Do NOT fill the gap from web search or model knowledge without asking. Say: "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?" A lawyer decides whether to accept lower-confidence sources.
Source attribution tiering. Tag every citation in the review — regulatory floors, SCC versions, adequacy decisions, regulator guidance, case law — with its source. For model-knowledge citations, use one of three tiers rather than a single blanket "verify" tag:
  • [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) carry the highest fabrication risk and should ALWAYS be verified against a primary source.
Tool-retrieved citations keep their source tag (
[Westlaw]
,
[Commission / regulator site]
, or the MCP tool name); web-search citations remain
[web search — verify]
; user-supplied citations remain
[user provided]
. The tiering surfaces the real verification work — a reader who verifies everything verifies nothing. Never strip or collapse the tags.
TermLooking forPlaybook fieldCommon fights
RolesClear controller/processor designation; matches realityCounterparty labels the relationship (e.g., "joint controller") in a way that doesn't match reality
Processing scopeLimited to documented instructions; defined purposesOpen-ended scope expanders ("and related purposes")
SubprocessorsCurrent list disclosed, change mechanism definedSubprocessor changesBlanket approval vs. veto vs. notice-only
Security measuresAnnex references specific controls or standardsSecurity standards"appropriate technical and organizational measures" with no annex = empty promise
Breach notificationDefined trigger ("discovery" vs "confirmation"), defined timelineBreach notificationTimeline tightness; clock trigger; "without undue delay" is vague
Audit rightsMethod (report vs. on-site), frequency, notice, cost allocationAudit rightsOn-site audits on tight notice
International transfersTransfer mechanism identified, supplementary measures, transfer impact assessment referenceTransfersOutdated or missing transfer mechanisms
Deletion/returnTimeline post-termination, certification, backup carveoutDeletion on termination"Commercially reasonable" deletion = ???
LiabilityWithin MSA cap or separate; carveoutsLiability for dataUncapped data breach liability = existential
逐条对照以下条款审查每一份DPA。具体的数值和实质要求(通知期限、 breach时限、可接受/不可接受标准)来自
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
## DPA playbook
。任何DPA必须满足的监管底线来自基础法律——针对每个适用制度研究当前生效规则,并在说明底线前引用原始来源。
不得无声补充。若向配置的法律研究工具发出的查询对某一制度的 breach窗口、传输机制要求、分包商变更规则或其他底线返回结果极少或无结果,请报告发现内容并停止操作。不得未经询问就通过网络搜索或模型知识填补空白。请说明:“搜索从[工具]返回[N]条结果。[制度/主题]的覆盖范围较窄。选项:(1) 扩大搜索查询范围,(2) 尝试其他研究工具,(3) 进行网络搜索——结果将标记为
[web search — verify]
,依赖前需对照原始来源验证,或(4) 标记为未验证并停止操作。您希望选择哪一项?”由律师决定是否接受低可信度来源。
来源归因分层。为审查中的每一处引用标记来源——监管底线、SCC版本、充分性决定、监管指南、判例法。对于模型知识引用,使用以下三个层级而非单一的“验证”标记:
  • [settled]
    ——稳定、知名的法规和监管引用,不太可能变更(如GDPR第28条、第33条72小时 breach通知、SCC第2021/914号决定)。归档前仍需验证,但优先级较低。
  • [verify]
    ——真实存在但需验证的模型知识引用:具体实施条例、监管指南、判例结论、充分性决定、SCC模块和版本、UK Addendum / IDTA状态、阈值、生效日期。
  • [verify-pinpoint]
    ——精确引用(具体子条款字母、SCC内条款编号、段落编号、卷/页引用)存在最高的伪造风险,必须对照原始来源验证。
工具检索的引用保留其来源标记(
[Westlaw]
[Commission / regulator site]
或MCP工具名称);网络搜索引用保留
[web search — verify]
;用户提供的引用保留
[user provided]
。分层可明确实际验证工作——若要求验证所有内容,等于无需验证。不得移除或合并标记。
条款检查要点操作手册字段常见争议
角色明确的控制者/处理者 designation;与实际情况一致交易对手对关系的标签(如“联合控制者”)与实际情况不符
处理范围限于书面指令;明确的目的开放式范围扩展(“及相关目的”)
分包商披露当前列表,变更机制明确Subprocessor changes全面批准 vs. 否决 vs. 仅通知
安全措施附件引用具体控制措施或标准Security standards“适当的技术和组织措施”但无附件 = 空洞承诺
Breach通知明确触发条件(“发现” vs “确认”),明确时限Breach notification时限严格程度;计时起点;“无不当延迟”表述模糊
审计权利方式(报告 vs. 现场)、频率、通知、成本分配Audit rights短通知期限的现场审计
国际传输明确传输机制,补充措施,传输影响评估引用Transfers过时或缺失的传输机制
删除/返还终止后的时限,证明,备份例外Deletion on termination“商业合理”删除 = 不明确
责任在MSA限额内或单独设定;例外条款Liability for data无上限的data breach责任 = 重大风险

When we're the processor: defensive review

当我们作为处理者:防御性审查

Customer DPAs try to push operational burden onto us. For each clause below, compare the customer's ask to the playbook. Where the customer's ask is outside the playbook, push back to the team's standard position (from the config CLAUDE.md) and be ready to fall back to the acceptable position.
ClauseRiskResearch / playbook lookup
Subprocessor approval right (veto)Can't add infrastructure without customer-by-customer approvalApply playbook position on subprocessor changes
On-site audit on short noticeUnworkable at scaleApply playbook position on audit rights
Aggressive breach notification windowOften demands notice before we know what happenedResearch the regulatory floor for each applicable regime (cite primary sources); compare to playbook position
Hard data residency (single country/DC)May not match architectureApply playbook position on data location; confirm what we can actually commit to
Processor liability uncappedBet-the-companyApply playbook position on liability for data
Customer may issue binding "instructions"Open-ended operational controlDefine instructions as "documented in the Agreement or agreed in writing"
Deletion on very short timelineBackup and log retention makes this impossibleApply playbook position on deletion on termination; document backup rotation carveout
客户的DPA试图将运营负担转移给我们。对于以下每一条款,将客户的要求与操作手册对比。若客户的要求超出操作手册范围,需坚持团队的标准立场(来自配置CLAUDE.md),并准备好退回到可接受立场。
条款风险研究/操作手册查询
分包商批准权(否决)无法在未获得客户逐个批准的情况下添加基础设施应用操作手册中关于分包商变更的立场
短通知期限的现场审计大规模操作不可行应用操作手册中关于审计权利的立场
严格的breach通知窗口常要求在我们了解事件详情前就发出通知研究每个适用制度的监管底线(引用原始来源);与操作手册立场对比
严格的数据驻留要求(单一国家/数据中心)可能与我们的架构不符应用操作手册中关于数据位置的立场;确认我们实际能承诺的内容
处理者责任无上限关乎公司存亡应用操作手册中关于数据责任的立场
客户可发出具有约束力的“指令”开放式运营控制将指令定义为“协议中书面规定或书面同意的内容”
极短时限内删除数据备份和日志保留使其无法实现应用操作手册中关于终止后删除的立场;记录备份轮换例外

When we're the controller: protective review

当我们作为控制者:保护性审查

Vendor DPAs try to give us nothing. For each clause below, compare to the controller-side playbook.
ClauseGapResearch / playbook lookup
No subprocessor listDon't know who touches our dataRequire published current list + advance notice per playbook
"Industry standard security"Means nothingRequire annex with specific controls, or reference to a named standard (e.g., SOC 2, ISO 27001)
No breach notification timelineThey tell us wheneverResearch applicable regulatory floor; require playbook position
No audit rights at allCan't verify anythingRequire at minimum an independent audit report per playbook
Vendor can use data for "service improvement"Potential training on our dataStrike; processing limited to providing the service to us
No international transfer mechanismNo lawful transfer mechanismResearch the currently operative transfer mechanism for the corridor in question (origin/destination jurisdictions, applicable regime, any adequacy decision, any supplementary measures). Cite primary sources and verify currency.
No deletion commitmentData lives foreverRequire playbook position on deletion + certification on request
供应商的DPA试图尽可能少地做出承诺。对于以下每一条款,与控制者侧操作手册对比。
条款缺口研究/操作手册查询
无分包商列表不清楚谁会接触我们的数据要求提供已发布的当前列表 + 操作手册规定的提前通知
“行业标准安全”无实际意义要求附件包含具体控制措施,或引用指定标准(如SOC 2、ISO 27001)
无breach通知时限他们随时通知我们研究适用的监管底线;要求符合操作手册立场
完全无审计权利无法验证任何内容要求至少符合操作手册规定的独立审计报告
供应商可将数据用于“服务改进”可能使用我们的数据进行培训删除该条款;处理仅限于为我们提供服务
无国际传输机制无法合法传输数据研究当前生效的相关传输机制(来源/目的地司法管辖区、适用制度、任何充分性决定、任何补充措施)。引用原始来源并验证时效性。
无删除承诺数据永久留存要求符合操作手册中关于删除的立场 + 按需提供证明

Consistency check: privacy policy

一致性检查:隐私政策

The DPA you sign can't promise something the privacy policy doesn't cover, and vice versa.
  • If the DPA commits to processing only for purposes X, Y, Z — does the privacy policy list those purposes?
  • If the privacy policy says "we never sell data" — does any DPA clause look like a sale under CCPA?
  • If the privacy policy names specific subprocessor categories — does the DPA subprocessor list match?
Flag mismatches. They're usually the privacy policy being stale, not the DPA being wrong, but someone needs to fix one of them.
您签署的DPA不得承诺隐私政策未涵盖的内容,反之亦然。
  • 若DPA承诺仅为X、Y、Z目的处理数据——隐私政策是否列出这些目的?
  • 若隐私政策声明“我们绝不会出售数据”——DPA中是否存在任何符合CCPA定义的出售条款?
  • 若隐私政策列出特定分包商类别——DPA的分包商列表是否匹配?
标记不一致之处。通常是隐私政策过时,而非DPA有误,但需要有人修正其中一项。

Redline granularity

修订标记粒度

Edit at the smallest possible granularity. A redline is a negotiation artifact, not a rewrite. Wholesale clause replacement signals "we threw out your drafting" — it's aggressive, it forces the counterparty to re-read the whole clause, and it discards the parts of their drafting that were fine. Surgical redlines — strike a word, insert a phrase, restructure a subclause — signal "we have specific asks" and are faster to read, understand, and accept.
Default to the smallest edit that achieves the playbook position:
  • Replace a word before a phrase. ("twelve (12)" → "twenty-four (24)")
  • Replace a phrase before a sentence. ("paid by the Buyer" → "paid and payable by the Buyer")
  • Restructure a subclause before replacing the sentence. (Add "(a)" and "(b)" to split a compound condition.)
  • Replace a sentence before replacing the clause.
  • Only replace a whole clause when the counterparty's version is so far from your position that surgical edits would be harder to read than a fresh draft — and when you do, say so in the transmittal: "We've replaced §8.2 rather than marking it up because the changes were extensive. Happy to walk you through the delta."
When in doubt, smaller. A client who receives a surgical redline trusts that you read carefully. A client who receives a wholesale replacement wonders whether you read at all.
以最小粒度进行编辑。修订标记是谈判工具,而非重写。 wholesale替换条款意味着“我们否决了您的起草”——这种方式过于强硬,会迫使交易对手重新阅读整个条款,且丢弃了他们起草中合理的部分。精准修订标记——删除一个词、插入一个短语、重组一个子条款——意味着“我们有具体要求”,更易阅读、理解和接受。
默认采用能实现操作手册立场的最小编辑:
  • 先替换单个词,再替换短语。(“twelve (12)” → “twenty-four (24)”)
  • 先替换短语,再替换句子。(“paid by the Buyer” → “paid and payable by the Buyer”)
  • 先重组子条款,再替换句子。(添加“(a)”和“(b)”拆分复合条件)
  • 先替换句子,再替换条款。
  • 仅当交易对手的版本与您的立场相差甚远,精准编辑会比重新起草更难阅读时,才替换整个条款——此时需在传输说明中注明:“我们替换了§8.2而非标记修订,因为变更内容较多。我们很乐意与您逐一说明差异。”
若有疑问,优先选择更细粒度的编辑。收到精准修订标记的客户会相信您仔细阅读了内容;收到wholesale替换的客户会怀疑您是否阅读过内容。

Output

输出

Prepend the work-product header from
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
## Outputs
(it differs by user role — see
## Who's using this
).
markdown
[WORK-PRODUCT HEADER — per plugin config ## Outputs]
添加
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
## Outputs
中的工作成果页眉(根据用户角色不同而有所差异——见
## Who's using this
)。
markdown
[WORK-PRODUCT HEADER — 按插件配置## Outputs]

DPA Review: [Counterparty]

DPA审查:[交易对手]

Direction: [We are processor / We are controller] Reviewed: [date] Attached to: [MSA / standalone]

关系方向: [我们是处理者 / 我们是控制者] 审查日期: [日期] 关联文件: [主服务协议 / 独立文件]

Bottom line

结论

[Two sentences. Can we sign? What has to change?]
Issues: [N]🟢 [N]🟡 [N]🟠 [N]🔴

[两句话。我们能否签署?需要修改哪些内容?]
问题: [N]🟢 [N]🟡 [N]🟠 [N]🔴

Term-by-term

逐条审查

[For each core term, use a standard deviation-memo format: what the counterparty's DPA says, what our playbook says, the gap, the risk, and the proposed redline language. Keep each term to a short self-contained block so a reviewer can skim.]

[针对每个核心条款,使用标准偏差备忘录格式:交易对手DPA的内容、我们操作手册的要求、差异、风险、建议的修订标记语言。每个条款保持简短独立,便于审查者快速浏览。]

Privacy policy consistency

隐私政策一致性

[🟢 Consistent | 🟡 Flags: list]

[🟢 一致 | 🟡 标记:列表]

Recommended redlines

建议修订标记

[Consolidated — ready to send back]

[整合版——可直接反馈给对方]

If they won't move

若对方拒绝修改

[For each issue: the fallback from the config CLAUDE.md, or escalation routing if no fallback exists]
undefined
[针对每个问题:配置CLAUDE.md中的 fallback方案,或无fallback时的升级路径]
undefined

International transfers note

国际传输说明

If the DPA contemplates cross-border data transfers, research the currently operative transfer mechanism requirements for the applicable corridor(s). For each origin/destination pair, identify: the applicable regime, whether any adequacy decision is in force, which transfer mechanism is required or available (e.g., Standard Contractual Clauses and their applicable version/module, UK Addendum or IDTA, BCRs, derogations), whether a transfer impact assessment or equivalent is required, and what supplementary measures may be needed. Cite primary sources (regulation, Commission decision, regulator guidance, controlling case law) with pinpoint cites and verify currency — adequacy decisions, SCC versions, and required supplementary measures change through new Commission decisions, court rulings, and regulator guidance. Flag uncertainty for attorney verification.
If a transfer mechanism is missing and there is an international transfer, that is a 🔴 — there is no lawful transfer mechanism.
若DPA涉及跨境数据传输,研究当前生效的相关传输机制要求。针对每个来源/目的地组合,确定:适用制度、是否存在有效的充分性决定、所需或可用的传输机制(如标准合同条款及其适用版本/模块、UK Addendum或IDTA、BCR、例外情形)、是否需要传输影响评估或等效措施、可能需要哪些补充措施。引用原始来源(法规、委员会决定、监管指南、控制性判例)并精确引用,验证时效性——充分性决定、SCC版本和所需补充措施会因新的委员会决定、法院裁决和监管指南而变更。标记不确定性供律师验证。
若缺少传输机制但存在国际传输,属于🔴级问题——无合法传输机制。

Gate: signing a DPA

签署DPA的门槛

Reviewing a DPA is research. Signing it — or instructing someone to countersign on our behalf — is the consequential act.
Before proceeding to sign or countersign a DPA (including returning an executed version, consenting to automatic execution on a counterparty platform, or instructing a signatory to execute): Read
## Who's using this
in
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
. If the Role is 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:
[Generate a 1-page summary: counterparty, direction (we are processor / controller), the terms that deviate from the playbook and how they were resolved, any open fallback decisions, and the three things to ask the attorney before executing.]
If you need to find a licensed attorney, solicitor, barrister, or other authorised legal professional in your jurisdiction: your professional regulator's referral service is the fastest starting point (state bar in the US, SRA/Bar Standards Board in England & Wales, Law Society in Scotland/NI/Ireland/Canada/Australia, or your jurisdiction's equivalent).
Do not proceed past this gate without an explicit yes.
审查DPA是研究工作。签署DPA——或指示代表我方签署——是具有法律后果的行为。
在签署或副署DPA之前(包括返还已签署版本、同意在交易对手平台自动签署、或指示签署人执行): 阅读
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md
中的
## Who's using this
。若角色为非律师:
签署DPA是法律行为——它使公司承担特定的数据保护义务,这些义务会延伸至监管机构和数据主体。您是否已与律师审查过此内容?若是,请继续。若否,请向律师提供以下摘要:
[生成1页摘要:交易对手、关系方向(我们是处理者/控制者)、偏离操作手册的条款及解决方式、任何未决的fallback决定、执行前需向律师询问的三个问题。]
若您需要在所在司法管辖区寻找持牌律师、事务律师、出庭律师或其他授权法律专业人士:您所在行业的监管机构推荐服务是最快的起点(美国州律师协会、英格兰及威尔士SRA/律师标准委员会、苏格兰/北爱尔兰/爱尔兰/加拿大/澳大利亚律师协会,或您所在司法管辖区的等效机构)。
未获得明确同意不得越过此门槛。

Close with the next-steps decision tree

以下一步决策树结束

End with the next-steps decision tree per CLAUDE.md
## Outputs
. Customize the options to what this skill just produced — the five default branches (draft the X, escalate, get more facts, watch and wait, something else) are a starting point, not a lock-in. The tree is the output; the lawyer picks.
根据CLAUDE.md
## Outputs
中的下一步决策树结束。根据本技能生成的内容自定义选项——五个默认分支(起草X、升级、获取更多事实、观察等待、其他)是起点,而非固定选项。决策树是输出内容,由律师选择。

What this skill does not do

本技能不执行的工作

  • It doesn't draft a DPA from scratch. If the answer is "use our template," pull the template from the seed docs path in the config CLAUDE.md.
  • It doesn't do the Transfer Impact Assessment itself — it flags when one is needed.
  • It doesn't decide whether to accept terms outside the fallbacks. It routes those per the escalation table.
  • 不从头起草DPA。若需要“使用我们的模板”,请从配置CLAUDE.md中的种子文档路径获取模板。
  • 不自行执行传输影响评估——仅标记何时需要执行。
  • 不决定是否接受fallback之外的条款。仅根据升级表路由此类问题。