stakwork/stakgraph/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

DPA Review

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.

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.

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.

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.

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.

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.

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.

The term-by-term review

Core terms (check every 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.

When we're the processor: defensive review