Imported from LegalQuants/lq-skills (skills/dpa-checklist-review/SKILL.md). Install upstream with npx skills add LegalQuants/lq-skills --skill dpa-checklist-review. Copyright stays with the author.

DPA Checklist Review

Conduct a structured compliance review of a Data Processing Agreement, DPA-equivalent addendum, or Business Associate Agreement against the requirements of the applicable regulatory regime. The output is a checklist suitable for a compliance tracker — each required term has a row, an assessment, and a clause reference.

When this skill applies

Apply when the user provides a DPA, DPA addendum, or BAA and asks for compliance review against a specific regulatory regime. The skill works against four distinct regimes (see regulatory_regime input) and applies different requirements for each.

Do not apply this skill to:

• Privacy policies. Those are public-facing notices, not contracts; different review skill needed.
• Standalone privacy schedules or security exhibits inside larger agreements where the privacy/security terms have not been collected into a DPA structure. Tell the user the substantive privacy and security terms need to be pulled into a DPA-shaped structure before this skill is useful.
• Contractual privacy clauses inside MSAs that have not been broken out as a DPA addendum. Recommend the user request a separate DPA addendum from the counterparty, which is now industry standard.
• Cross-regime analysis (e.g., "is this GDPR-compliant and HIPAA-compliant?"). Run the skill twice with different regulatory_regime values and compare outputs.

Privilege and confidentiality

DPAs and BAAs frequently contain client-confidential information (data flows, security postures, vendor relationships, deal terms) and the resulting compliance review is plausibly attorney work product. Before running the skill, the user must confirm:

• Privileged work product. The checklist produced by this skill is a draft work product intended to support legal advice. Treat the output as presumptively privileged where applicable, and do not distribute it outside the attorney-client circle without considering waiver consequences.
• External-model exposure. If this skill is being executed in an environment that routes the document to a model or service outside the user's attorney-supervised workflow (e.g., a non-BAA-covered API, a non-enterprise consumer endpoint, a logged training surface), confirm with the user before proceeding. Run this skill only inside an attorney-supervised workflow where the routing and retention posture has been vetted.
• Legal-use posture. Output is a draft for review by qualified privacy counsel — it is not a legal opinion, not a regulator-facing artifact, and not a substitute for a PIA, TIA, or other formal compliance assessment (see "What this skill does not do").

If the user cannot confirm that the workflow is attorney-supervised and the model routing is acceptable for the document at hand, stop and surface the concern before running the review.

Inputs

The skill requires the document and the regulatory regime. If regime is not provided:

"Before I review, which regulatory regime should I check this DPA against?

• GDPR (EU/UK GDPR Article 28; covers any DPA processing EU/UK personal data)
• US state privacy (CCPA/CPRA, Virginia VCDPA, Colorado CPA, Connecticut CTDPA, Utah UCPA, Oregon OCPA, and similar)
• HIPAA BAA (Business Associate Agreement under US healthcare law)
• General commercial (DPA without a specific regime; checks commercially-standard DPA terms)

If multiple regimes apply, pick the most prescriptive (typically GDPR) for the primary review; we can run additional reviews for other regimes after."

Do not guess the regime from document title or governing law. A document titled "Data Processing Addendum" with Delaware governing law could be GDPR-driven (because it processes EU resident data), CCPA-driven (because it processes California resident data), or both. Only the user knows what data is in scope.

Optional inputs (party_role, data_categories, international_transfer_context, standard_positions) refine the analysis. The party_role input materially changes severity calibration:

• Controllers / data exporters / businesses / covered entities want strong, specific processor obligations — they bear regulatory liability for processor failures.
• Processors / data importers / service providers / business associates want clear, operationally feasible scope — vague obligations create open-ended liability.

When party_role is not provided, default to controller perspective (regulators almost always investigate the controller, so controller-favorable analysis is the safer default for reviews) and note the assumption in the report. Ask the user to re-run if they are on the processor side.

Workflow

Produce the review in three passes.

Pass 1: Document orientation

Before substantive review:

• Confirm the document is actually a DPA / DPA addendum / BAA. If it is a privacy policy, an MSA with privacy clauses not broken out, or a different instrument, stop and tell the user.
• Note the parties and which is controller / processor (or equivalent under the relevant regime).
• Note the governing law and any specified data-protection authority.
• Note the structure: does the document have the required terms organized into sections, or are they scattered? A DPA without clear structural sections is harder to assess.
• Identify any annexes, schedules, exhibits, or appendices and note what they cover (typically: data categories, processing purposes, security measures, sub-processors, SCCs).

Pass 2: Regime-specific term checking

Walk through the requirements for the specified regime using the corresponding reference file:

• For gdpr: use reference/gdpr_requirements.md. The required terms are the nine items in GDPR Article 28(3) plus security obligations under Article 32 plus (when applicable) international-transfer mechanisms.
• For us_state_privacy: use reference/us_state_privacy_requirements.md. The required terms are the convergent set across CCPA/CPRA, VCDPA, CPA, CTDPA, and similar laws; differences between laws are noted where material.
• For hipaa_baa: use reference/hipaa_baa_requirements.md. The required terms are those listed in 45 CFR §164.504(e)(2) plus the additional requirements under HITECH and the HIPAA Omnibus Rule.
• For general_commercial: use reference/general_commercial_requirements.md. The expected terms are commercially-standard DPA terms in the absence of a specific regime — broadly compatible with any of GDPR, US state privacy, or HIPAA but not optimized for any.

For each required term, classify:

• Present — the document addresses this term and the addressing is compliant with the regime's requirements.
• Partial — the document addresses this term but the addressing is non-compliant, narrower than required, or has problematic carve-outs.
• Missing — the document does not address this term.
• Unclear — the document arguably addresses this term but the language is ambiguous enough that compliance cannot be confirmed without negotiation.
• N/A — this term does not apply given the document type, regime variant, or specific facts.

Pass 3: Compile the checklist and posture

Compile the findings into the structured checklist (see Output section). Add an overall posture paragraph stating whether the document is:

• Compliant — all required terms present and adequate; no negotiation needed for compliance purposes (business preferences may still warrant changes).
• Compliant with minor gaps — most terms present; minor partial/missing items can be addressed via short negotiation or in supporting agreements.
• Non-compliant — material gaps requiring negotiation before signing; the document does not currently meet the regime's requirements.
• Materially non-compliant — multiple critical terms missing or partial; the document needs substantial reworking, or the user should propose replacing it with the user's own template.

Output

Produce the review as a structured checklist in markdown:

# DPA Checklist Review: [Document name or counterparty]

**Regulatory regime:** [gdpr | us_state_privacy | hipaa_baa | general_commercial]
**Party role:** [controller | processor | etc.]
**Data categories:** [user-provided context, or "not specified"]
**International transfer context:** [for GDPR; user-provided context, or "not specified"]

## Overall posture

[One paragraph: compliant / compliant with minor gaps / non-compliant / materially non-compliant. State the headline gap or strength. State the recommended next step at a high level.]

## Compliance checklist

| # | Required term | Source | Status | Severity | Clause | Assessment |
|---|---|---|---|---|---|---|
| 1 | [Term name] | [Statute reference, e.g., "GDPR Art. 28(3)(a)"] | Present / Partial / Missing / Unclear / N/A | High / Medium / Low | [§ ref or "—"] | [One-line assessment] |
| 2 | [...] | [...] | [...] | [...] | [...] | [...] |
| ... | | | | | | |

Every finding gets a severity rating. Calibrate severity using the Critical / Material / Minor bands in the regime reference file (`reference/gdpr_requirements.md`, `reference/us_state_privacy_requirements.md`, `reference/hipaa_baa_requirements.md`, `reference/general_commercial_requirements.md`), mapped as: **High** = Critical (regulator-facing requirement, missing it would render the document non-compliant); **Medium** = Material (gap creates real legal or operational risk but is not a per-se compliance failure); **Low** = Minor (drafting hygiene, commercial preference, or belt-and-braces). Severity is required even for Present items so the reader can see what the document gets right on the high-stakes terms at a glance.

## Detailed findings

[For each Partial, Missing, or Unclear item, a subsection with:]

### [#] [Term name] — [Status]

**Required by:** [Statute reference]

**What's required:** [Brief plain-language statement of what the regime requires.]

**What the document says:** [Quoted or paraphrased clause language, with citation. If the term is missing, "Not addressed."]

**Why this is a gap:** [Specific deficiency from the regime's perspective.]

**Recommended language:** [Specific suggested clause language to add or modify. Reference any applicable model clauses (e.g., EU SCCs) where appropriate.]

## Items requiring human judgment

[Items the skill cannot resolve and that need the user's regulatory-counsel expertise or business judgment. Examples: jurisdictional applicability questions, novel data flows the skill is unfamiliar with, regulator-specific guidance the skill cannot verify is current.]

## Recommended next steps

[Short bulleted list. Common options: sign as-is (if compliant), negotiate the redlines proposed above, propose user's own DPA template, escalate specific issues to outside privacy counsel, run an additional review under another regime.]

The checklist table is the centerpiece. Detailed findings only cover non-Present items — do not pad with "Present and standard, no further notes" rows; the table already shows that.

Edge cases and refusals

• Document is not a DPA/BAA. Stop and tell the user. Common adjacent documents that get confused for DPAs: privacy policies, security questionnaires, data sharing agreements (different instrument under GDPR), data licensing agreements, MSAs with privacy clauses but no DPA addendum.
• Regime is gdpr but the document does not contain SCCs or another transfer mechanism, and international_transfer_context indicates transfers occur. Critical gap; flag in posture and detailed findings even if the controller-processor terms are otherwise compliant.
• Regime is hipaa_baa but the document does not invoke HIPAA at all (no reference to PHI, BAA, 164.504, etc.). The document may not actually be a BAA. Flag and ask the user to confirm.
• Document is a DPA from before significant regime changes (e.g., a GDPR DPA dated 2018 without Schrems II / 2021 SCC updates; a CCPA DPA dated 2020 without CPRA amendments). Flag in posture and note the regulatory drift.
• Document includes terms for multiple regimes. Some DPAs are written to satisfy GDPR + CCPA + others simultaneously. Review against the requested regime and note where multi-regime drafting creates ambiguity (e.g., conflicting deletion timelines).
• Document references model clauses or templates that are not attached. If the document says "the parties have entered into the EU SCCs" but no SCCs are attached or referenced specifically, flag — the SCCs are a required artifact, not a reference.

What this skill does not do

• Give a definitive compliance opinion. Outputs are drafts for human review; ultimate compliance determinations belong to qualified privacy counsel.
• Predict regulator behavior. Flags gaps; does not opine on enforcement risk.
• Negotiate. Suggests language; does not draft side letters.
• Replace a privacy impact assessment, transfer impact assessment, or other formal compliance artifact. Those are separate processes.
• Cover non-US/non-EU regimes (Canada PIPEDA, Brazil LGPD, China PIPL, etc.) in v1.0.0. The structure supports adding regime-specific reference files; community contributions welcomed.

Reference materials

• reference/gdpr_requirements.md — Article 28(3) required terms, Article 32 security, transfer-mechanism requirements.
• reference/us_state_privacy_requirements.md — Convergent CCPA/CPRA/VCDPA/CPA/CTDPA/UCPA/OCPA processor-contract requirements.
• reference/hipaa_baa_requirements.md — 45 CFR §164.504(e)(2) BAA requirements plus HITECH/Omnibus updates.
• reference/general_commercial_requirements.md — Commercially-standard DPA terms when no specific regime is stated.
• examples/example_gdpr.md — Worked example: GDPR DPA review from a controller perspective.
• examples/example_us_state.md — Worked example: US state privacy DPA review from a service-provider/processor perspective.

QA Remediation (LegalQuants, 2026-05)

LegalQuants QA evaluated this skill as SOME CONCERN against the Legal Skill Design Framework on 2026-05-11. Targeted remediation applied 2026-05:

• Privilege treatment strengthened. Added an explicit "Privilege and confidentiality" section in Scope, requiring the user to confirm attorney-supervised workflow and acceptable model-routing posture before running the skill. Treats output as presumptively privileged work product and warns against external-model exposure of confidential client documents. Reinforced the "draft for review by qualified privacy counsel" framing already present in "What this skill does not do".
• Severity surfaced in headline checklist. Added a Severity column (High / Medium / Low) to the mandated checklist table so the Critical / Material / Minor calibration from the regime reference files propagates into the headline artifact rather than being buried in prose. Severity is required for every row, including Present items, so a reader scanning the table can see the document's posture on high-stakes terms at a glance.
• Provenance reconciled. author field set to Kevin Keller (matching the registry README). last_reviewed and last_reviewed_by fields added to surface the QA cadence on the artifact itself.

Technical content (workflow passes, regime reference files, output structure, edge cases, refusal triggers) preserved unchanged. Substantive privacy-counsel judgment required to use this skill is unchanged.