Cross-Border Data Transfer Impact Assessment Prompt

This prompt is designed for privacy engineering and legal compliance teams who need to evaluate whether a proposed international data transfer from an AI workflow meets regulatory requirements before execution. Use it when an AI system or agent proposes to move personal data across jurisdictional boundaries and you need a structured, reviewable gate decision before the transfer proceeds. The ideal user is a technical privacy analyst or compliance engineer who understands the data flow but needs a consistent, first-pass analysis of transfer risk, mechanism adequacy, and supplementary measures. The prompt is not a replacement for qualified legal advice, and it should never be the sole decision-maker for high-risk transfers.

The prompt requires specific, grounded inputs to function correctly. You must provide the destination country or countries, the categories of personal data involved, the purpose of the transfer, the proposed transfer mechanism (e.g., Standard Contractual Clauses, Binding Corporate Rules, an adequacy decision), and a copy of the relevant data protection impact assessment or transfer risk assessment template. Without these inputs, the model will generate a plausible but ungrounded assessment. The prompt is designed to be used inside a compliance gate workflow where the AI acts as a first-pass analyst, producing a structured report that a human legal reviewer can quickly evaluate, challenge, and approve or reject. It is not intended for real-time, autonomous blocking of data flows without human oversight.

Do not use this prompt for transfers that are purely hypothetical, for jurisdictions where no regulatory framework applies, or for transfers of non-personal data. It is also unsuitable for transfers involving complex, multi-party data controller relationships where liability is shared across several entities without clear contractual boundaries. In these cases, the prompt's structured output may create a false sense of completeness. The output should always be treated as a draft assessment that requires human verification of cited regulations, mechanism validity, and the completeness of supplementary measures. Every high-risk transfer assessment must be reviewed by a qualified human legal reviewer before the transfer is approved. The next section provides the copy-ready prompt template you can adapt for your jurisdiction and data transfer policy.

The following prompt is designed to be pasted directly into your compliance gate workflow. It instructs the model to act as a privacy compliance analyst and produce a structured transfer risk assessment. Before execution, replace every square-bracket placeholder with the actual values for the specific transfer you are evaluating. This prompt is intended to be used with a system message that establishes the model's role, its strict prohibition against providing legal advice, and the requirement for human legal review on any transfer classified as high risk.

textCopy
You are a privacy compliance analyst. Your task is to produce a Transfer Impact Assessment (TIA) for a proposed cross-border data transfer. You must ground your analysis strictly in the provided context documents. Do not rely on external knowledge or make assumptions about laws or regulations not cited in the provided text. If the provided context is insufficient to make a determination, state that clearly and recommend escalation.

## TRANSFER DETAILS
- Data Categories: [DATA_CATEGORIES]
- Data Subjects: [DATA_SUBJECTS]
- Processing Purpose: [PROCESSING_PURPOSE]
- Exporter Entity & Country: [EXPORTER_DETAILS]
- Importer Entity & Destination Country: [IMPORTER_DETAILS]
- Technical & Organizational Safeguards: [SAFEGUARDS]

## CONTEXT DOCUMENTS
### 1. Applicable Internal Data Transfer Policy

[INTERNAL_TRANSFER_POLICY_TEXT]

codeCopy

### 2. Destination Country Privacy Law Summary

[DESTINATION_COUNTRY_LAW_SUMMARY]

codeCopy

### 3. Relevant Transfer Mechanism Text (e.g., SCCs, BCRs, Adequacy Decision)

[TRANSFER_MECHANISM_TEXT]

codeCopy

## OUTPUT SCHEMA
Produce a JSON object with the following structure. Do not include any text outside the JSON object.
{
  "assessment_id": "string, a unique ID for this assessment",
  "transfer_summary": "string, a one-paragraph summary of the proposed transfer",
  "destination_country_analysis": {
    "privacy_framework_assessment": "string, analysis of the destination's legal framework based on the provided summary",
    "government_access_risk": "string, analysis of risks related to government surveillance or access",
    "rule_of_law_assessment": "string, analysis of the enforceability of data subject rights"
  },
  "transfer_mechanism_adequacy": {
    "mechanism_identified": "string, the specific transfer mechanism from the context",
    "is_adequate": "boolean, assessment of whether the mechanism is valid for this transfer",
    "gaps_identified": ["string, list of any gaps or weaknesses in the mechanism for this specific scenario"]
  },
  "supplementary_measures_required": [
    {
      "measure": "string, a specific technical, contractual, or organizational measure",
      "rationale": "string, why this measure is necessary to address a specific risk"
    }
  ],
  "overall_risk_classification": "string, one of: 'Low Risk', 'Medium Risk', 'High Risk', 'Prohibited'",
  "escalation_required": "boolean, true if the risk is High or Prohibited, or if context is insufficient",
  "reasoning": "string, a detailed explanation of the risk classification, citing the provided context documents"
}

## CONSTRAINTS
- If the [DESTINATION_COUNTRY_LAW_SUMMARY] is missing or empty, set `overall_risk_classification` to 'High Risk' and `escalation_required` to true, noting the lack of data as the primary risk.
- If the [TRANSFER_MECHANISM_TEXT] is missing or empty, set `is_adequate` to false and `escalation_required` to true.
- Do not invent or hallucinate legal standards. If a required analysis cannot be performed due to missing information, state that clearly in the relevant field.

To adapt this prompt for your specific environment, you must first integrate your source documents. The [INTERNAL_TRANSFER_POLICY_TEXT], [DESTINATION_COUNTRY_LAW_SUMMARY], and [TRANSFER_MECHANISM_TEXT] placeholders are critical for grounding the model's analysis. In a production system, these would be populated dynamically by a retrieval-augmented generation (RAG) pipeline that fetches the relevant policy document, an up-to-date legal memo on the destination country, and the full text of your standard contractual clauses or other transfer instrument. The [DATA_CATEGORIES] and [PROCESSING_PURPOSE] fields should be pulled directly from your data catalog or the output of a prior data classification step. The output JSON schema is designed to be machine-readable so that the escalation_required boolean can automatically trigger a ticket in your legal review queue. This prompt is a gate, not a final decision-maker; its primary job is to structure the analysis and reliably flag high-risk transfers for human attention.

Before deploying this prompt, you must build a thin validation layer around it. A JSON schema validator should confirm the model's output conforms to the defined structure. An evaluation harness should test the prompt against a golden dataset of known transfers to ensure it correctly classifies risk and does not hallucinate legal standards. For example, a test case with a destination country known to lack adequate privacy laws but with no provided transfer mechanism should always result in escalation_required: true. Another test case with a fully documented, low-risk internal transfer should result in a Low Risk classification. These evals are your safety net against silent failures. Finally, ensure your operational playbook dictates that any assessment with escalation_required: true is routed to a human reviewer and that the AI's output is never used as the sole basis for authorizing a transfer.

The Cross-Border Data Transfer Impact Assessment prompt is not a standalone document generator. It is a decision-support tool that must be embedded in a compliance gate workflow. The prompt produces a structured risk assessment, but the application layer is responsible for enforcing the gate: blocking high-risk transfers, queuing medium-risk transfers for human review, and logging every decision for audit. The prompt output should be treated as a recommendation, not a final legal determination. The harness must validate the output schema, check for hallucinated regulations or transfer mechanisms, and route the assessment to the correct downstream action based on the risk classification.

Wire the prompt into a compliance gate as follows. First, assemble the input context: the source country, destination country, data categories, legal basis for transfer, and the text of any applicable transfer mechanism (Standard Contractual Clauses, Binding Corporate Rules, adequacy decision reference). Pass these as [SOURCE_COUNTRY], [DESTINATION_COUNTRY], [DATA_CATEGORIES], [LEGAL_BASIS], and [TRANSFER_MECHANISM] placeholders. Call the model with a low temperature (0.1–0.2) to reduce variance in risk classification. Parse the JSON output and validate it against a strict schema: risk_level must be one of low, medium, high, or blocked; transfer_mechanism_adequate must be boolean; supplementary_measures must be an array of strings; requires_human_review must be boolean; and reasoning must be a non-empty string. If validation fails, retry once with the validation error injected into the prompt as a correction instruction. If the retry also fails, escalate to a human reviewer with the raw output and validation errors attached.

For medium-risk and high-risk assessments, route the validated output to a human review queue. The queue item must include the original inputs, the full prompt response, and a pre-formatted approval decision payload. The human reviewer confirms, overrides, or requests more information. Every decision—whether automated or human—must be logged immutably with a timestamp, model version, prompt version, input hash, output hash, reviewer identity, and final gate decision. Do not allow the system to proceed with a transfer unless the gate returns approved. For blocked assessments, log the blocking reason and notify the data governance team. Avoid wiring this prompt directly into an automated transfer execution path; the harness should always enforce a human-in-the-loop breakpoint for any transfer where risk_level is medium or higher, or where transfer_mechanism_adequate is false.

Model choice matters here. Use a model with strong legal and regulatory reasoning capabilities and a large context window to accommodate full transfer mechanism text. If the transfer mechanism text exceeds the context window, preprocess it by extracting only the clauses relevant to international transfer safeguards. Do not summarize the mechanism text with a separate model call, as this introduces hallucination risk. For eval, maintain a golden dataset of known transfer scenarios with expected risk classifications and mechanism adequacy determinations. Run this eval suite on every prompt version change and flag any regression in false-negative rates on high-risk transfers. The most common production failure mode is the model approving a transfer based on an adequacy decision that does not actually cover the destination country. Mitigate this by cross-referencing the model's cited adequacy decision against a hardcoded allowlist of current EU adequacy decisions in the validation layer, and flagging any mismatch for human review regardless of the model's confidence.