---

name: prompt-pack-cross-border-data-transfer-assessment
description: Use when a privacy lawyer or compliance officer needs to assess the lawfulness of transferring personal data from one jurisdiction to another. Analyses adequacy decisions, appropriate safeguards (SCCs, BCRs, binding corporate rules), supplementary measures, and jurisdiction-specific risks. Covers GDPR (EU/UK), UAE PDPL, KSA PDPL, DIFC DP Law, ADGM DP Regs, and GCC data localisation requirements; includes Schrems II and post-Schrems transfer impact assessment methodology.
license: MIT
metadata:
id: prompt-pack.cross-border-data-transfer-assessment
category: prompt-pack
practice_area: privacy-data-protection
priority: P2
intent: [compliance, cross-border-data-transfer-assessment, data-transfer, adequacy, sccs, privacy]
related: [prompt-pack-data-processing-agreement, prompt-pack-data-retention-policy, prompt-pack-cookie-policy, prompt-pack-privacy-policy]
source: Louis — HAQQ Legal AI (github.com/sboghossian/mini-claude-for-legal)
version: "1.0"

Cross-Border Data Transfer Assessment

Cross-border data transfers are one of the highest-risk areas of data protection compliance: a transfer that violates the applicable restriction can result in enforcement action, fines, contractual disputes, and reputational damage. The assessment framework is complex because it depends on both the origin jurisdiction's rules and the destination jurisdiction's legal protections.

When to use this

• A company is implementing a new SaaS tool, cloud service, or data processor headquartered outside the origin jurisdiction.
• A group of companies is centralising data processing (e.g., HR data) in a shared services centre in a different country.
• A company is moving its data infrastructure to a new cloud region.
• An M&A transaction involves combining data from entities in different jurisdictions.
• A regulator or DPA has raised concerns about the company's data transfer practices.
• The company is building a new product that processes data of users from multiple jurisdictions and the developer needs to understand transfer restrictions from the outset.

Required inputs

Input	Why it matters	Sensible default
Origin jurisdiction (where the data originates)	Determines the restriction framework (GDPR, UAE PDPL, KSA PDPL, DIFC DP Law, etc.)	Ask the user
Destination jurisdiction (where the data will be sent/processed)	Determines whether an adequacy decision or safeguard is needed	Ask the user
Categories of personal data to be transferred	Risk level varies by data type (health, financial, biometric data carry higher obligations)	Ask the user
Volume and frequency of transfers	Distinguishes occasional from systematic transfers (different risk profile)	Ask the user
Existing legal relationship (controller-processor or controller-controller)	Determines which safeguard mechanism is appropriate	Ask the user
Purpose of the transfer	Must be consistent with the original processing purpose	Ask the user

Optional inputs

• Names of specific service providers or data processors receiving the data.
• Whether the destination country has surveillance laws that could override contractual protections (Schrems II factor).
• Whether any data localisation requirement applies in the origin jurisdiction.
• Whether the company has existing Binding Corporate Rules (BCRs) in place.

Assessment methodology

Step 1 — Identify the origin jurisdiction's transfer restriction framework

Origin jurisdiction	Transfer restriction framework
EU	GDPR Chapter V (Articles 44–49); transfer only to: (a) adequate countries, (b) countries with appropriate safeguards (SCCs, BCRs, approved codes of conduct), or (c) specific derogations (Art. 49)
UK	UK GDPR / Data Protection Act 2018; UK adequacy regulations; IDTA (International Data Transfer Agreement, the UK equivalent of EU SCCs)
UAE (onshore)	UAE PDPL Art. 22–27; transfer requires: (a) adequate country, or (b) recipient provides adequate protection, or (c) consent, or (d) specific exceptions
UAE (DIFC)	DIFC DP Law 2020 Art. 27; transfer only to countries with adequate DP framework or with appropriate safeguards (DIFC SCCs or equivalent); DIFC Adequacy Decisions issued by Commissioner
UAE (ADGM)	ADGM DP Regs 2021 Art. 22; equivalent to DIFC framework
KSA	Saudi PDPL Art. 29; transfer permitted if: (a) no threat to national security or vital interests, (b) recipient provides adequate protection; NDMO regulations specify mechanisms
Lebanon	No comprehensive data protection law in force as of 2026; draft law under consideration; GDPR alignment recommended for EU-connected businesses
Egypt	Egyptian Data Protection Law (Law No. 151 of 2020); transfer requires adequate destination or contractual safeguards; MCIT regulations govern specifics
Qatar (QFC)	QFC Data Protection Regulations (2021); similar to GDPR framework

Step 2 — Assess the destination jurisdiction

Tier A — Adequate jurisdictions (no additional safeguards needed from an EU perspective):
EU adequacy decisions cover: Andorra, Argentina, Canada (commercial), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Republic of Korea, Switzerland, UK (for EU), and Uruguay (as of 2026). Verify current list — adequacy decisions can be revoked (Safe Harbor was revoked; Privacy Shield was revoked; EU-US Data Privacy Framework is current but subject to legal challenge).

Tier B — Jurisdictions requiring appropriate safeguards:
Most MENA countries (UAE, KSA, LB, EG) are not on EU adequacy lists. Transfers to these jurisdictions from the EU require appropriate safeguards.

Tier C — Restricted jurisdictions (data localisation or outbound transfer ban):
Some jurisdictions prohibit or severely restrict outbound transfer: Russia (Federal Law on Personal Data requires localisation of Russian citizens' data), China (PIPL requires security assessment for large-scale transfers), and certain sector-specific rules in KSA (health, financial, and government data localisation).

Step 3 — Select the appropriate safeguard mechanism

Mechanism	Suitable for	Key requirements
EU Standard Contractual Clauses (SCCs) — 2021 version	Controller-to-processor; controller-to-controller; processor-to-processor transfers from EU	Must use the correct module; execute with all relevant parties; conduct Transfer Impact Assessment (TIA) if destination has surveillance laws
UK IDTA	Transfers from UK following Brexit	Separate from EU SCCs; must comply with UK ICO template
Binding Corporate Rules (BCRs)	Intra-group transfers where the group is established in EU	Require approval by lead supervisory authority; extensive process; suitable only for large multinationals
DIFC SCCs / ADGM SCCs	Transfers from DIFC/ADGM to non-adequate countries	Separate from EU SCCs; issued by DIFC Commissioner / ADGM Commissioner
Consent of the data subject	Ad hoc, one-off transfers where a derogation applies	Must be explicit, informed, specific; not suitable for systematic transfers; cannot be used as the primary mechanism for ongoing transfers
Contractual necessity	Transfer necessary for contract with or in the interests of the data subject	Narrow; not suitable for B2B data transfers
Approved code of conduct / certification	Where the destination party adheres to an approved code	Limited availability currently; growing in use

Step 4 — Conduct a Transfer Impact Assessment (TIA)

Required under GDPR post-Schrems II (Data Protection Schrems II ruling, CJEU July 2020) when transferring to a country with surveillance or law enforcement access laws that could undermine the safeguards:

1. Identify the laws and practices of the destination country that may affect the safeguard: mass surveillance laws, government access to data, national security exemptions.
2. Assess the practical impact: Has there been documented government access to data of the type being transferred? Are there oversight mechanisms and remedies for data subjects?
3. Determine whether supplementary measures are needed: Encryption (so government access yields only ciphertext), pseudonymisation, contractual prohibitions on disclosing data to authorities (with notification obligation), or technical measures.
4. Document the assessment: The TIA is a legal document that may be required by the supervisory authority. Keep it on file.

Step 5 — Implement and document

• Execute the appropriate SCCs or other safeguard documents.
• Update the company's data processing register to record the transfer.
• Include the transfer description and safeguard in the Privacy Policy.
• Implement any supplementary technical measures identified in the TIA.
• Establish monitoring: if the destination jurisdiction changes its surveillance laws or an adequacy decision is revoked, the safeguard must be reassessed.

Jurisdiction-specific traps

Scenario	Trap
UAE company sending employee data to EU parent	UAE PDPL transfer restrictions apply outbound even though GDPR applies inbound; need to assess both regimes
KSA health data leaving KSA	Saudi NDMO health data regulations may require localisation or Ministry of Health approval
Dubai (non-DIFC) company receiving EU data	UAE PDPL (not DIFC DP Law) applies; DIFC SCCs are not the correct instrument
DIFC company sending data to non-DIFC UAE entity	Cross-DIFC-boundary transfer; DIFC DP Law Art. 27 applies
Group using US-based SaaS tool (e.g., Salesforce, Workday)	EU SCCs (Module 2) required; TIA required; EU-US DPF may cover if provider is certified

Output format

Deliver a Transfer Assessment Report:

1. Summary: Origin, destination, data categories, proposed safeguard, conclusion (transfer lawful / conditional / not recommended).
2. Transfer Impact Assessment (TIA) (if destination has surveillance risk).
3. Safeguard documentation checklist: SCCs to execute, parties, modules, annexes required.
4. Open issues / escalation points.

Related skills

• [[prompt-pack-data-processing-agreement]]
• [[prompt-pack-data-retention-policy]]
• [[prompt-pack-cookie-policy]]
• [[prompt-pack-privacy-policy]]
• [[prompt-pack-data-subject-access-request-procedure]]