Drafting a GDPR-compliant data processing agreement for a cross-border health data analytics engagement fails when the agent does not reconcile conflicts among the controller’s data governance materials, the processor’s standard template, and the transfer-impact analysis before drafting, and does not apply the more protective standard where instructed.
Scanned 9/11/2026
Install to Claude Code
npx -y skills add sunyifeisb-art/legalwork --skill draft-data-processing-agreement --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Draft Data Processing Agreement?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/sunyifeisb-art-draft-data-processing-agreement)More formats (shields.io, HTML) on the badges page.
---
name: draft-data-processing-agreement
task_id: data-privacy-cybersecurity/draft-data-processing-agreement
description: Drafting a GDPR-compliant data processing agreement for a cross-border health data analytics engagement fails when the agent does not reconcile conflicts among the controller’s data governance materials, the processor’s standard template, and the transfer-impact analysis before drafting, and does not apply the more protective standard where instructed.
activates_for: [planner, solver, checker]
---
# Skill: Draft GDPR-Compliant Data Processing Agreement for Cross-Border Health Data Analytics Engagement
## 1. Subject-matter triage
- Determine whether the engagement involves controller/processor processing, joint controllership, or a service relationship that is not truly Article 28 processing; the agreement must match the actual role allocation in the source materials.
- Identify whether special-category health data, cross-border transfers, subprocessors, security commitments, and deletion/return obligations are in scope before drafting operative provisions.
- If more than one document set governs the deal, map which source is controlling for each topic before writing; do not merge inconsistent standards into generic drafting.
## 2. Failure modes the skill is correcting
- Drafting from the processor’s template alone and missing conflicts with the controller’s governance materials, impact findings, or transfer analysis.
- Failing to apply the more protective standard when source documents diverge on security, subprocessing, retention, audit, breach notice, or transfer safeguards.
- Leaving out health-data specificity and producing boilerplate Article 28 language that does not reflect the actual processing, access model, or operational controls.
- Omitting the cross-border transfer mechanism or supplementary safeguards where transfer analysis requires them.
- Treating assessment mitigation items as informal notes instead of binding contractual obligations.
- Producing the agreement without a separate client cover memo that explains key drafting choices and unresolved items.
- Drafting a memo that describes the work but does not identify conflict resolutions, open points, and the legal basis for the choices made.
## 3. Legal frameworks / domain conventions that apply
- GDPR Article 28 sets the mandatory controller-processor contract terms; the agreement must include the required subject-matter, duration, nature and purpose, categories of data, data subject types, controller obligations, processor obligations, and assistance commitments.
- GDPR Article 9 requires careful treatment of special-category health data and should inform restrictions, safeguards, and access controls.
- GDPR Chapter V governs international transfers; if the engagement includes a third-country transfer, the agreement should incorporate the applicable transfer mechanism and any contractually required supplementary measures.
- Standard contractual transfer clauses, where used, must be aligned with the transfer-impact analysis and the actual data flows described in the deal materials.
- Security and privacy-by-design obligations should be drafted as operational commitments, not aspirational language, and should reflect the actual technical and organizational measures described in the source documents.
- Data processing agreement conventions for health analytics usually require annexed details for processing scope, parties, data subjects, data categories, security measures, and approved subprocessors.
- Where the source set contains competing standards, the more protective standard controls unless the instructions or governing agreement clearly require otherwise.
## 4. Analytical scaffolds
- Start with a source hierarchy: identify the documents that define scope, role allocation, security baseline, transfer position, and commercial override terms.
- Read the controller-facing governance materials first to anchor the protective baseline; then test the processor template against that baseline and flag every inconsistency.
- Translate assessment findings into contractual language: any mitigation measure identified in the risk materials should become an express obligation, control, or condition in the draft.
- For transfer issues, confirm the destination, mechanism, and supplemental protections before finalizing operative clauses; if the transfer analysis leaves a condition unresolved, surface it as an open item.
- Populate the agreement with engagement-specific details in the body and annexes; avoid generic placeholders where the source materials provide facts.
- Resolve conflicts clause-by-clause, favoring the more protective standard, and preserve a short drafting rationale for each material choice in the cover memo.
- Check consistency between the agreement and the commercial master document so the DPA supplements, rather than contradicts, the broader service arrangement.
- Keep the memo decision-focused: what was chosen, why it was chosen, what remains open, and who must decide.
## 5. Vertical / structural / temporal relationships
- Role allocation in the service materials drives the Article 28 structure; if roles shift, the contract architecture must shift with them.
- Risk assessment findings generate mitigation commitments; those commitments should appear as binding clauses, annex entries, or conditions precedent.
- Transfer conclusions constrain drafting options; any clause on onward transfer, subprocessing, or audit must be consistent with the transfer mechanism and supplementary measures.
- Commercial terms in the master agreement set the outer frame; the DPA should be supplemental and consistent, not duplicative or contradictory.
## 6. Output structure conventions
- Produce the execution-ready DPA first, then the client cover memo.
- The DPA should use conventional legal architecture: parties, recitals, defined terms, processing terms, confidentiality and security, assistance, subprocessors, breach notification, audits, return/deletion, cross-border transfer terms if applicable, and annexes with factual schedules.
- Annexes should carry the engagement-specific facts: controller/processor identities, processing description, categories of data subjects and data, jurisdictions, security measures, and approved subprocessors or approval mechanics.
- Use the more protective drafting where source documents conflict, and reflect the resolution in the memo.
- The cover memo should briefly explain key drafting decisions, identify open items needing client instruction, and note any assumptions made because the source set was incomplete.
- The memo should also identify any transfer or security conditions that must be confirmed before signature.
- Deliver the documents in the filenames exactly requested, with the agreement as the primary deliverable and the memo as the secondary deliverable.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!