dpa-checklist-review

name	dpa-checklist-review
description	Use when the user provides a Data Processing Agreement, Data Processing Addendum, or HIPAA Business Associate Agreement and asks whether it contains the terms required under the applicable data-protection regime. Produces a structured checklist scoring each required term as present, partial, missing, or unclear, with clause references and recommended language for any gaps. Supports GDPR Article 28, US state privacy laws (CCPA/CPRA, VCDPA, CPA, CTDPA, and similar), HIPAA BAAs, and general commercial DPAs without a specified regime.
lq_ai	{"title":"DPA Checklist Review","version":"1.0.0","author":"LegalQuants","tags":["contracts","dpa","privacy","gdpr","ccpa","hipaa","compliance","review"],"jurisdiction":"regime-dependent","trigger_examples":["review this DPA","is this DPA GDPR compliant","check this BAA","what's missing from this data processing agreement","compare this DPA against Article 28"],"inputs":{"required":[{"name":"document","type":"document","description":"The DPA, DPA-equivalent addendum, or BAA to review (PDF, DOCX, or pasted text)."},{"name":"regulatory_regime","type":"text","description":"Which regulatory regime governs this review. One of \"gdpr\" (EU/UK GDPR Article 28; covers any DPA processing EU/UK personal data), \"us_state_privacy\" (CCPA/CPRA, VCDPA, CPA, CTDPA, UCPA, OCPA, and similar US state privacy laws), \"hipaa_baa\" (HIPAA Business Associate Agreement; protected health information under US healthcare law), or \"general_commercial\" (DPA without a specific regime stated; checks for commercially-standard DPA terms). If not provided, ask which regime applies before proceeding — do not guess."}],"optional":[{"name":"party_role","type":"text","description":"The user's role in the agreement. One of \"controller\" / \"data_exporter\" (under GDPR; or \"business\" under CCPA, \"covered_entity\" under HIPAA), or \"processor\" / \"data_importer\" (under GDPR; or \"service_provider\"/\"contractor\" under CCPA, \"business_associate\" under HIPAA). Affects which provisions get the most scrutiny — controllers want strong processor obligations, processors want clear scope and operational feasibility."},{"name":"data_categories","type":"text","description":"The categories of data being processed under this DPA, if known (e.g., \"employee HR data,\" \"customer transactional data,\" \"sensitive personal data including health information,\" \"EU resident contact data only\"). Affects severity calibration on data-category-specific obligations."},{"name":"international_transfer_context","type":"text","description":"For GDPR reviews, whether the agreement contemplates international data transfers, and to where. Examples - \"transfers to US-based processor,\" \"EU-only processing,\" \"transfers to multiple non-adequacy countries.\" Triggers SCCs and TIA analysis."},{"name":"standard_positions","type":"text","description":"User's organization's standard fallback positions on common DPA issues, if applicable."}]},"output_format":"structured_checklist","self_improvement":false}

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.

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 | Clause | Assessment |
|---|---|---|---|---|---|
| 1 | [Term name] | [Statute reference, e.g., "GDPR Art. 28(3)(a)"] | Present / Partial / Missing / Unclear / N/A | [§ ref or "—"] | [One-line assessment] |
| 2 | [...] | [...] | [...] | [...] | [...] |
| ... | | | | | |

## 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.