dpa-review

/dpa-review

Load ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → DPA playbook. If placeholder, stop and prompt to set up.
Obtain the DPA. Determine direction: are we the processor (a client sent us their DPA) or the controller (reviewing a vendor's DPA)? Ask if unclear.
Run the following workflow—clause by clause against the corresponding playbook row.
Perform a personal information processing rules consistency check.
Output: a review memo with redlines. Save in the internal format.

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

DPA Review (Data Processing Agreement Review)

Matter context

Matter context. Check the practice-level CLAUDE.md for ## 事项工作区. If 已启用 is ✗(the default for legal users), skip this section—the skill uses practice-level context and the matter mechanism is invisible. If enabled and there is no active matter, ask: "Which matter is this? Run /privacy-legal:matter-workspace switch <slug> or say 实践级." Load the active matter's matter.md to get matter-specific context and overrides. Write output to the matter folder ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/matters/<matter-slug>/. Never read another matter's files unless 跨事项上下文 is 开启.

Purpose

DPAs come in two shapes, and the review direction is almost entirely opposite. When a client sends us their DPA, we are defending our operational flexibility. When we send a DPA to a vendor, we are protecting our data (and our clients' data). Both reviews read the same ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md playbook, but read from opposite rows.

First: which direction?

Before doing anything, determine:

We are the processor → the client sends us their DPA → read ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → the "When we are the processor" table (corresponding to PIPL Article 21 entrusted processing [法条原文]）
We are the controller → we are sending a DPA to a vendor (or reviewing theirs) → read the "When we are the controller" table

If unclear, ask. Getting the direction wrong will reverse every recommendation.

Jurisdiction assumptions

This review assumes the jurisdictional scope specified in your configuration. Privacy rules, response deadlines, and legal bases vary by jurisdiction (PIPL vs. GDPR vs. other jurisdictions). If the controller, processor, or data subject is located in a jurisdiction different from the configured one, this review may not directly apply.

Load prior context about this counterparty/matter

Before reviewing, check the output folder for prior work on this counterparty or processing activity. Read ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → ## 输出 to get the output folder path. Scan:

Prior use-case-triage results covering the same counterparty/processing activity—the triage produced a risk rating and conditions, and this DPA review should comply with or explicitly deviate from them.
Prior pia-generation output covering this counterparty/processing activity—the PIA may have flagged risk mitigations that require DPA implementation.
Prior dpa-review output Covering the same counterparty—a prior DPA review set expectations about what is acceptable, what is flagged, and what has been resolved. A new draft that silently contradicts the prior review erodes trust in the work product.

If a prior output is found, cite it in the review:

"The prior triage ([date]) rated this activity as [risk level] and made approval conditional on [X]. This DPA review is consistent with that finding."—or— "The prior triage ([date]) rated this activity as [risk level]. This DPA review departs from that finding because [reason—new facts, different scope, changed contract terms that alter the picture]."

Inherit severity from upstream as a floor, following the ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → ## 共享护栏 cross-skill severity floor rule. A processing activity triaged as 🔴 cannot be silently downgraded to 🟢 in the DPA review; any downgrade should be stated and explained.

If no prior output is found (new counterparty/new activity), state it explicitly in the review—"No prior triage or PIA concerning this counterparty in the output folder"—so the reviewing attorney knows the check has been performed.

Load the playbook

Read ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → ## DPA 操作手册. Also read ## 个人信息处理规则承诺—the DPA cannot contradict the processing-rule commitments.

Industry regulation overlay (ask before clause-by-clause review)

Before the clause-by-clause review, answer:Does the data passing through this DPA include any categories subject to special industry regulation? PIPL and general data protection law provide a baseline; industry regulation often provides another baseline that does not appear in the general DPA playbook. A DPA that is complete under PIPL may still have blind spots in finance, healthcare, protection of minors, and other areas.

Industry regulation overlay—ask first:

Does this processing activity involve:

Consumers' personal financial information(JR/T 0171-2020 Personal Financial Information Protection Technical Specification + Regulations on the Administration of the Credit Reporting Industry)? If yes, the DPA needs: (a) sharing restrictions consistent with the financial information protection technical specification, (b) security protection measures aligned with industry standards, (c) an incident notification mechanism covering financial regulator time limits, (d) explicit provision for the data recipient's security protection obligations.

Health and medical data, held by medical institutions or health and medical data processors(Measures for the Administration of Population Health Information + PIPL)? If yes, the DPA needs: the data recipient must have the corresponding security protection capabilities and qualifications, clear use restrictions and confidentiality obligations, incident notification time limits, and downstream processor authorization clauses.

Personal information of minors under the age of fourteen(Provisions on the Cyber Protection of Children's Personal Information + Article 31 of PIPL)[法条原文]? If yes, the DPA needs: clauses for the flow-down of guardian informed consent, strict retention limits and deletion mechanisms, and a prohibition on use for behavioral advertising (unless there is explicit guardian consent).

Other industry-specific regulatory regimes(such as the Several Provisions on the Administration of Automobile Data Security, the Regulations on the Administration of the Credit Reporting Industry, the Regulations on the Security Protection of Critical Information Infrastructure, etc.)?

If any item is yes: industry regulation usually provides the dominant substantive restrictions. Search currently effective provisions and cite them. A DPA that "exempts" a certain requirement of the Personal Information Protection Law but is subject to industry regulation still needs to satisfy the restrictions of industry regulation—the exemption only switches the applicable framework; it does not extinguish compliance obligations. In the red-line issue checklist, mark industry-specific gaps alongside general data protection gaps.

If no industry regulation applies cumulatively, state clearly—"No data categories subject to special industry regulation were identified; cumulative industry regulation does not apply"—so that the reviewing lawyer can see that the check was performed rather than guess whether it was skipped.

Clause-by-clause review

Core clauses (check in every DPA)

Review the following clauses of the DPA one by one.Specificnumerical values and substantive positions (notice periods, breach time limits, acceptable/unacceptable baselines) come from ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md → ## DPA 操作手册. The regulatory baseline that any DPA must satisfy comes from primary-source law—search the currently effective rules of each applicable regimeand cite the primary source before stating the baseline.

No silent supplementation. If a search query returns few or zero results, report what was found and stop. Do not fill gaps from web search or model knowledge without asking. Say: "Search returned [N] results. Coverage appears thin. Options: (1) broaden the search query, (2) try a different retrieval tool, (3) search the web—results will be marked as [联网检索 — 需复核], (4) mark as unverified and stop. Which do you want to choose?" It is for the lawyer to decide whether to accept lower-credibility sources.

Layered source provenance labels. Mark the source for every citation in the review. For model knowledge citations, use three tiers rather than a single "verified" label:

[已确定] — Stable, well-known statutory and administrative regulation citations that are unlikely to have changed (e.g., Article 21 of the Personal Information Protection Law on entrusted processing, Article 57 on breach notification). They should still be verified before submission, but with lower priority.

[需验证] — The model knowledge citation is genuine but should be verified: specific implementing rules, regulatory authority guidance, case positions, thresholds, effective dates.

[需验证——精准引用] — Precise citations (specific paragraph numbers, article numbers, paragraph numbering) carry the highest risk of fabrication and should always be verified against the primary source.

Citations obtained through retrieval tools retain their source labels; web search citations retain [联网检索 — 需复核]; user-provided citations retain [用户提供]. Layering reveals the real verification work—whoever verifies everything verifies nothing. Never strip or collapse labels.

Clause	Concern	Playbook field	Common disputes
Role	Clear processor/entrusted processor designation; matches actual	—	The counterparty labels the relationship (e.g., "joint controller") inconsistently with reality
Processing scope	Limited to written instructions; define purpose	—	Open-ended scope expansion ("and related purposes")
Downstream processors	Current list disclosed, change mechanism defined	Downstream processor changes	Blanket approval vs. veto right vs. notice only
Security measures	Annex references specific controls or standards	Security standards	"Appropriate technical and organizational measures" with no annex = empty promise
Breach notification	Trigger defined ("discovery" vs. "confirmation"), time limit defined	Breach notification	Urgency of the time limit; when the clock starts; ambiguity of "timely"; Article 57 of the Personal Information Protection Law requires immediate notification to the Cyberspace Administration and the individual `[法条原文]`
Audit rights	Method (report vs. on-site), frequency, notice period, cost allocation	Audit rights	On-site audit with short notice period
Data cross-border transfer	Cross-border mechanism identified, supplementary measures, cross-border security assessment reference	Data cross-border transfer	Missing or outdated cross-border mechanism; whether a security assessment has been passed / a standard contract has been signed / certification has been obtained (Article 38 of the Personal Information Protection Law) `[法条原文]`
Deletion/return	Time limit after contract termination, certification, backup exceptions	Deletion after termination	"Commercially reasonable" deletion = ???
Liability	Within the main contract's liability cap or accounted for separately; exceptions	Data liability	Uncapped liability for data breaches = existential risk to the company

When we are the entrusted processor: defensive review

The customer's DPA tries to push operational burdens onto us. For each of the following, compare the customer's requirements against the playbook. When the customer's requirements exceed the playbook, push back to the team's standard position (from the configured CLAUDE.md), and be prepared to fall back to an acceptable position.

Clause	Risk	Search / playbook lookup
Downstream processor approval right (veto right)	Each new infrastructure addition requires per-customer approval	Apply the playbook's position on downstream processor changes
On-site audit with short notice period	Impractical at scale	Apply the playbook's position on audit rights
Aggressive data breach notification window	Often requires notification before we know what happened	Search the regulatory floor under each applicable regime (cite primary sources — Article 57 of the Personal Information Protection Law requires "immediate" notification); compare against the playbook position
Hard data localization (single city/data center)	May not match the architecture	Apply the playbook's position on data location; confirm what we can actually commit to
Uncapped liability as entrusted processor	Betting the company	Apply the playbook's position on data liability
Customer may issue binding "instructions"	Open-ended operational control	Define instructions as "contractually agreed or in writing"
Deletion within an extremely short period	Backup and log retention make this impossible	Apply the playbook's position on post-termination deletion; document backup cycle exceptions

When we are the processor: protective review

The vendor's DPA tries to give us everything. But for us: no. For each of the following, compare against the processor-side playbook.

Clause	Gap	Search / playbook lookup
No downstream processor list	Don't know who touches our data	Require disclosure of the current list + advance notice as required by the playbook
"Industry-standard security"	meaningless	Require an annex with specific controls, or reference to specified standards (e.g., Multi-Level Protection Scheme Level 3, ISO 27001)
No breach notification deadline	They tell us whenever they feel like it	Search applicable regulatory floor (PIPL Article 57 as a reference `[法条原文]`); require the playbook position
No audit right at all	Cannot verify anything	At minimum require an independent audit report per the playbook
Vendor may use data for "service improvement"	May train models on our data	Delete; processing limited to providing services to us
No cross-border data transfer mechanism	No lawful transfer mechanism	Search for currently effective transfer mechanismsapplicable to the relevant path (data origin/destination, applicable regime, any adequacy determination, any supplementary measures). Cite primary sources and verify currency.
No deletion commitment	Data persists forever	Require the playbook position on deletion + certification upon request

Consistency check: personal information processing rules

The DPA you sign cannot promise something the processing rules do not cover, and vice versa.

If the DPA promises processing only for purposes X, Y, Z — do the processing rules list those purposes?
If the processing rules say "we never provide data to third parties" — is there any clause in the DPA that looks like providing to or sharing with third parties?
If the processing rules specify particular categories of downstream processors — does the DPA's downstream processor list match?

Flag mismatches. Usually the processing rules are stale, not the DPA wrong, but someone must fix one of them.

Redline granularity

Edit at the smallest granularity possible. Redlining is a negotiation artifact, not a rewrite. Wholesale replacement signals "we threw out your drafting" — it is aggressive, it forces the other side to re-read the entire clause, and it discards the parts of their drafting that were fine. Surgical redlines — delete a word, insert a phrase, restructure a sub-clause — signal "we have a specific ask," and are easier to read, understand, and accept.

By default use the smallest edit to achieve the playbook position:

Replace a singlewordfirst, rather than a phrase. ("twelve (12)" → "twenty-four (24)")
Replace a singlephrasefirst, rather than a sentence. ("paid by Buyer" → "paid by Buyer and payable")
Restructure a singlesub-clausefirst, rather than replacing a sentence. (Add "(a)" and "(b)" to split compound conditions.)
Replace a singlesentencefirst, rather than replacing the entire clause.
Replace theentire clauseonly when the other side's version is so far from your position that a surgical edit would be harder to read than a redraft — and in that case explain in the cover letter: "We replaced Clause 8.2 rather than redlining it piecemeal because the changes were extensive. Happy to walk you through the changes item by item."

When in doubt, use the smaller one. A client who receives surgical redline marks trusts that you read carefully. A client who receives wholesale replacement suspects you did not read at all.

Output

Under the heading of the work product in ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md ## 输出 (varies by user role — see ## 谁在使用）。

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

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

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

---

## 结论

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

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

---

## 逐条审查

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

---

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

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

---

## 建议修订

[汇总——可直接发回]

---

## 如对方不让步

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

Data Cross-Border Transfer Statement

If the DPA involves cross-border data transfer,Retrieve the currently effective cross-border transfer mechanism requirementsapplicable to the relevant channel. For each source/destination pair, identify: the applicable regime, whether a security assessment is required (Measures for Security Assessment of Data Cross-Border Transfer), signing of a standard contract (Measures for Standard Contract for Cross-Border Transfer of Personal Information), or obtaining certification (Article 38 of the Personal Information Protection Law), whether a cross-border transfer security assessment report is needed, and what supplementary measures may be required. Cite primary sources (laws, administrative regulations, Cyberspace Administration guidelines) with precise citations and verify currency — security assessment thresholds, standard contract versions, and required supplementary measures change as new regulations are issued. Flag uncertainties for lawyer verification.

If a cross-border transfer mechanism is missing and there is indeed cross-border data transfer, this is 🔴 — no lawful cross-border transfer mechanism.

Gate: Signing the DPA

Reviewing a DPA is research.Signingit — or instructing someone to sign and seal on our behalf — is an act with legal consequences.

Before signing a DPA (including returning a signed version, agreeing to automatic execution on the counterparty's platform, or instructing a signatory to sign): Read ~/.claude/plugins/config/claude-for-legal-zh/privacy-legal/CLAUDE.md in ## 谁在使用. 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 had a lawyer review it? If so, proceed. If not, here is the brief you bring to the lawyer:

[Generate a 1-page summary: counterparty, direction (we are processor/controller), clauses deviating from the playbook and how they were resolved, any pending concession decisions, and three things to ask the lawyer before signing.]

If you need to find a practicing lawyer or other authorized legal professional: the lawyer lookup system of your local bar association or judicial bureau is the fastest starting point.

Do not cross this gate without explicit consent.

End with a next-step decision tree

End with a next-step decision tree consistent with CLAUDE.md ## 输出 . Customize the options based on what this skill just produced — the five default branches (draft X, escalate, get more facts, watch and wait, other) are a starting point, not a lock-in. The decision tree is the output; the lawyer chooses.

What this skill does not do

Does not draft a DPA from scratch. If the answer is "use our template," extract the template from the seed document path in the configured CLAUDE.md.
Does not perform the cross-border security assessment itself — it flags when one is needed.
Does not decide whether to accept terms beyond the concession position. It routes those decisions according to the escalation table.