dpa-checklist-review

Files (14)

• SKILL.md
• gdpr-baseline.md · acceptance/fixtures/
• gdpr-gaps.md · acceptance/fixtures/
• hipaa-baa.md · acceptance/fixtures/
• gdpr-baseline.golden.json · acceptance/snapshots/
• gdpr-gaps.golden.json · acceptance/snapshots/
• hipaa-baa.golden.json · acceptance/snapshots/
• example_gdpr.md · examples/
• example_us_state.md · examples/
• gdpr_requirements.md · reference/
• general_commercial_requirements.md · reference/
• hipaa_baa_requirements.md · reference/
• us_state_privacy_requirements.md · reference/
• test-plan.md

SKILL.md (first lines)

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

```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

From LegalQuants/lq-ai, Apache-2.0.

More from LegalQuants/lq-ai