Transfer Impact Assessment Tia Oliver Schmidt Prietz

GDPR Transfer Impact Assessment (TIA) Skill

Disclaimer (show at session start, do not block)

Important: This skill provides structured GDPR Chapter V transfer assessment guidance based on EDPB Recommendations, CNIL guidance, CJEU case law, and emerging national case law (OLG München 21 U 3882/25 e). It is not legal advice. Involve your DPO and qualified counsel for final decisions, especially where the skill flags a transfer for suspension or restructuring.

Routing

Determine what the user needs and lazy-load only the references required:

docx skill: /mnt/skills/public/docx/SKILL.md in Claude.ai Projects, or docx-processing-anthropic in Claude Code. If unavailable, generate Markdown as fallback.

Session Setup

Three quick questions. Adapt if the user provides rich context upfront — extract answers and confirm rather than asking sequentially.

1. Scope: "Are you assessing a specific transfer you already know about, or do you need to map your organisation's international transfers first?"
2. Existing data: "Do you have an existing RoPA or transfer inventory I can work from?" (Skip if Scope = specific transfer)
3. Timing: "Is this for a new transfer before it goes live, or a retrospective assessment of transfers already in place?"

The remaining details — exporter, importer, country, mechanism, data categories — are captured as the natural first step of the assessment pipeline, not as a sterile upfront questionnaire.

Workspace Pattern (Batch Assessments)

For organisations with multiple transfers needing assessment, the skill uses a workspace pattern:

skills/tia-workspace/<org-slug>/
├── transfer-registry.json        # All identified transfers, each with a UUID
├── assessments/
│   ├── TIA-US-2026-001.json     # Per-transfer assessment state
│   ├── TIA-US-2026-001.md       # Per-transfer Markdown report
│   ├── TIA-US-2026-001.docx     # Per-transfer formal document (generated last)
│   └── TIA-IN-2026-002.*
├── outbound/                     # Delta files queued for RoPA
│   └── tia-<uuid>-<timestamp>.delta.json
└── state.json                    # Session checkpoint (current transfer, step, partial findings)

Checkpoint after every step. Resume by reading state.json.

Pre-Assessment Gate: Transfer Qualification

Before running the 6-step pipeline, the skill determines whether a "transfer" under Chapter V exists. Apply EDPB Guidelines 05/2021 — three cumulative criteria:

1. Exporter subject to GDPR for the processing in question (Art. 3(1) or 3(2)).
2. Disclosure to a separate controller or processor (not same entity; not direct collection by data subject).
3. Importer in a third country (regardless of whether GDPR applies to the importer under Art. 3).

All three met → Chapter V applies → continue to the TIA requirement check.

Any criterion fails → output a Transfer Qualification Finding documenting:

• Which criterion failed and why.
• That Chapter V does not apply to this processing.
• That Art. 5/24/32 safeguards remain mandatory (per Section 4 of the guidelines).
• For EU-subsidiary-of-third-country-parent scenarios (EDPB Example 12): require Art. 28 due diligence on the processor's exposure to extraterritorial law.

This finding is a valuable deliverable on its own — it documents that the question was assessed.

TIA Requirement Check (when all three criteria met)

• Art. 45 adequacy? → Lightweight assessment only (document the decision, conditions, review dates, fragility risks for DPF). Use the relevant country profile.
• Art. 49 derogation? → Art. 49 assessment path (load art49-derogations.md). Balanced framing; document justification.
• Art. 46 tool (SCCs, BCRs, ad hoc, codes, certifications) → Full TIA required → proceed to Step 1.

Assessment Pipeline (Steps 1–6)

Reference: references/edpb-six-steps.md. Full detail there; SKILL.md captures the key flow.

Step 1: Know Your Transfer

Capture (from discovery, RoPA import, or direct user input): exporter, importer, country, data categories, subjects, purpose, volume, frequency, data format, onward transfers. Confirm completeness. Flag onward transfers for separate assessment.

Step 2: Identify the Transfer Tool

Document the Chapter V mechanism: adequacy / SCCs (module) / BCRs / ad hoc / code / certification. Note execution dates and SA authorisations as relevant.

After identifying the primary mechanism: Ask "Could any Art. 49 derogation apply as a primary or alternative basis for this transfer?" If yes → also run Art. 49 assessment as parallel/backup path.

Step 3: Assess Third-Country Law and Practices

Load the relevant country profile. Three blocks:

Block A — Data protection framework. General law, SA, rights, remedies.

Block B — Surveillance / access laws. For each relevant law: apply the four essential guarantees (clear rules / necessary & proportionate / independent oversight / effective remedies). Rate each as adequate / concerns / insufficient.

Block C — Practical risk assessment (Rosenthal-inspired). Importer's request history, realistic targeting basis, plaintext access necessity, realistic authority interest in this data.

Step 3 Conclusion — three-way fork (CNIL methodology):

1. Transfer tool effective → proceed to Step 6.
2. Transfer tool not effective, supplementary measures needed → proceed to Step 4.
3. Transfer tool not effective on paper, BUT no realistic basis to believe the problematic law will apply to this transfer in practice → proceed to Step 6 with thorough, substantive justification.

Option (3) is legitimate (CNIL guide accepts it explicitly) but requires real reasoning — sector, data type, importer profile, request history — not boilerplate.

Step 4: Supplementary Measures

Triggered when Step 3 returns conclusion (2). Load references/supplementary-measures.md. Auto-suggest measures matched to identified gaps. User reviews / accepts / customises. Then assess: do selected measures effectively close the gaps?

If yes → proceed. If no → the transfer cannot proceed as structured. Options: restructure (different importer, different country, different architecture) or suspend.

Step 5: Implementation Action Plan

Document: measures to implement, owners, due dates, contractual amendments (SCC Annex II edits, side letters), technical changes (encryption, pseudonymisation pipelines), timeline.

Step 6: Re-assessment Triggers

Document: standing triggers (adequacy review dates, DPF fragility), event-driven (new law, SA action, importer government request, certification change), periodic (12-month default, shorter for high-risk). Set the next review date.

Outputs

Four deliverables (the user picks what they need):

1. Markdown TIA Report — in-session preview. Sections mirror Steps 1–6.
2. .docx Formal TIA Document — for the compliance file. Uses references/tia-template.md structure with CNIL-style tables, cover page, sign-off block (assessor + DPO), annex with country profile summary.
3. JSON Interchange Sidecar — delta file conforming to interchange-inbound-schema.json v1.0. Patches tia_ref, tia_status, supplementary_measures[], tia_completed_date, tia_review_date. Lands in skills/ropa-workspace/<org-slug>/inbound/. See references/interchange-delta.md.
4. Transfer Risk Summary — one-page executive overview for batch assessments. Per-transfer row: destination, mechanism, verdict, key risk, measures. No numerical scores.

Cross-Skill Integration

Inbound from RoPA: Read sidecar (<org-slug>-ropa-sidecar.json) → filter entries with third-country transfers → pre-populate Step 1 → track activity_id UUIDs.

Outbound to RoPA: Emit delta file per assessed transfer (see Output #3). The delta is owned by RoPA after writing.

DPIA trigger: If Step 3 reveals high-risk processing (Art. 9 special categories + systematic monitoring + third-country risk), flag for the user: "Consider whether a DPIA is required under Art. 35. This transfer's risk profile may meet DPIA threshold criteria." Do NOT auto-trigger DPIA Sentinel — just flag.