Dpa Checklist Review

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.