GDPR international transfers

A plain route through GDPR Chapter V: whether a flow is a transfer, which lawful mechanism fits, what a transfer assessment involves, and what an implementation partner can and cannot do.

On this page

Which lawful route do GDPR international transfers need in October 2026?

A transfer of personal data out of the EEA needs one of three routes: an adequacy decision under Article 45, an appropriate safeguard under Article 46 or 47, or a narrow derogation under Article 49, which applies only when the first two fail. Which route works depends on the destination country and on the specific flow, so the same vendor may need different answers for a support session and for a storage region. The organization that exports the data owns this decision and the transfer assessment behind it, even when a vendor proposes the mechanism. An implementation partner can document the flows and prepare the evidence, but no auditor or certificate body issues a transfer approval or certificate for it.

The EU-US Data Privacy Framework covers only US organizations that appear on the DPF List maintained under Decision (EU) 2023/1795. The Commission still lists it in October 2026, but an appeal lodged on 31 October 2025 (Case C-703/25 P, Official Journal C/2025/6610) seeks to set aside the General Court's judgment in Case T-553/23 and annul the decision. Confirm the recipient's current listing on the day of transfer, and keep a fallback. For most other flows, the Commission's 2021 standard contractual clauses under Decision (EU) 2021/914 are the default safeguard. Choose the correct module for each relationship, and document a transfer impact assessment, since Clause 14 requires the parties to have no reason to believe the destination's laws prevent the importer from complying. Contracts on the older clauses stopped providing appropriate safeguards after 27 December 2022.

The Commission's adequacy list covers 16 countries and territories plus the European Patent Organisation as of October 2026, so check the list before relying on an adequacy decision, since it can change. Binding corporate rules suit groups with many intra-group flows, but they need supervisory authority approval under Article 47(1). Transfer infringements carry fines of up to EUR 20 million or 4% of worldwide annual turnover, whichever is higher, and authorities can order a suspension of data flows under Article 58(2)(j). Ask your vendor for the route it relies on, the sub-processors and locations involved, and the assessment it has completed, and treat any answer that names no route as an open risk.

How a transfer decision moves from mapping to documented safeguard

The sequence starts with finding every flow that leaves the EEA and ends with a written safeguard and a transfer assessment that can be reviewed when conditions change. Each step produces a record that the next step depends on, so gaps found early do not surface later in a supervisory inquiry.

  1. Map every flow leaving the EEA

    The organization, with its engineering, support and procurement teams, lists each system, export, API call and vendor path that makes personal data available to a separate controller or processor in a third country. Include remote access for support or administration, storage in a non-EEA cloud region offered by a provider, and the sub-processors behind each vendor. Under the EDPB Guidelines 05/2021, viewing data from abroad counts, while an employee accessing the employer's systems during travel does not. The output is a transfer register with the data categories, recipient, country, purpose, role of each party and the contract that covers it. The step is done when engineering confirms the register matches the actual data paths, not only the vendor list.

  2. Check for an adequacy decision

    For each destination in the register, the team checks the Commission's adequacy list to see whether a decision under Article 45 covers that country or territory, and for the United States whether the recipient is on the Data Privacy Framework List. Confirm the status on the day of the assessment, because the DPF remains listed while an appeal in Case C-703/25 P is pending. Where a decision covers the flow, record its name, date and scope, and confirm that the recipient falls within it. The output is a per-flow decision: adequacy relied on, or no adequacy and a safeguard needed. Flows that rely on an adequacy decision still need a record, because decisions can be amended or annulled.

  3. Select the safeguard for each remaining flow

    Where no adequacy decision applies, the controller or processor chooses an Article 46 safeguard. For most vendor relationships this is the Commission's 2021 standard contractual clauses under Decision (EU) 2021/914, with the module that matches the roles (controller to controller, controller to processor, processor to processor or processor to controller). Contracts on the older clauses stopped providing appropriate safeguards after 27 December 2022, so check the version in every existing agreement. For intra-group flows, binding corporate rules are an option only if the competent supervisory authority has approved them through the consistency mechanism under Article 47(1). The output is a signed instrument for each flow, with the correct module and parties named in the annexes.

  4. Run and document the transfer assessment

    Clause 14 of the 2021 clauses requires the parties to warrant that they have no reason to believe the destination's laws and practices prevent the importer from meeting its obligations. The exporter assesses those laws and practices for each destination and transfer, considers the data categories and the likelihood of foreign authority access, and records whether supplementary measures such as encryption with keys held in the EEA, or restricted access, are needed. Legal input is usually required for the destination analysis, which the organization pays for through counsel or a specialist firm. The output is a written assessment per flow, dated, signed by the responsible owner and linked to the register entry. Ask any outside party to state which sources and destination laws the assessment covers.

  5. Record derogations only as narrow exceptions

    Article 49 derogations for specific situations apply only when no adequacy decision and no Article 46 or 47 safeguard is available, and they are interpreted narrowly. Where a team proposes one, it records why each safeguard failed, which specific situation the derogation covers and why the flow is occasional rather than systematic. The output is a documented justification that legal reviewers accept or reject before the flow starts. Most recurring business flows will not qualify, so the register should show that the team considered and rejected derogations rather than defaulting to them.

  6. Connect the safeguard to technical controls and contracts

    Engineering and procurement confirm that the technical facts in the assessment are true in production: the region, the encryption key location, the access paths for support staff, and the sub-processor list. They also confirm that the processor contract and the transfer instrument reference the same flows and parties. The output is a reconciliation record showing that each assessed flow matches a configured system, and that any change requiring a new assessment has a trigger in the change process. Access controls and logging that limit remote viewing from third countries are part of the evidence supervisors expect to see.

  7. Review when laws, vendors or flows change

    The transfer register and assessments are reviewed when a new vendor or region is added, when a sub-processor changes, when an adequacy decision is amended or invalidated, when the Data Privacy Framework appeal or other court outcomes change the basis of a flow, and when destination laws shift. Monitor the Commission's adequacy page and the EDPB outputs for changes. The output is a dated review log that shows who reviewed each flow, what changed, and whether the safeguard still holds. A flow that loses its basis is suspended until a new route is in place, because supervisory authorities can order suspension of data flows under Article 58(2)(j).

Which mechanism fits which transfer: adequacy, SCCs, BCRs or derogations

Chapter V offers a fixed order of routes: an adequacy decision first, then appropriate safeguards such as standard contractual clauses or binding corporate rules, and derogations only when those fail. Each card below covers one route and the question that decides whether it fits a given data flow.

Adequacy under Article 45

An adequacy decision means the Commission has found that a third country or territory protects personal data to an essentially equivalent level, so the transfer needs no further safeguard. The Commission's list covers 16 countries and territories plus the European Patent Organisation as of October 2026, and recent entries include Brazil (decision dated 26 January 2026) and the renewed UK decisions (19 December 2025). Check the recipient's country and the scope of the decision, since some decisions cover only certain sectors or organizations.

EU-US Data Privacy Framework

The DPF under Decision (EU) 2023/1795 applies only when the US recipient is an organization on the DPF List, not to US companies in general. It remains listed by the Commission in October 2026, but an appeal lodged on 31 October 2025 (Case C-703/25 P) asks the Court of Justice to set aside the General Court's 3 September 2025 judgment and annul the decision. Confirm the importer's listing status on the day of transfer and keep a fallback safeguard, such as SCCs with a transfer assessment, in case the framework is invalidated.

2021 standard contractual clauses

The Commission's 2021 clauses under Decision (EU) 2021/914 come in four modules, covering controller to controller, controller to processor, processor to processor and processor to controller transfers. Contracts on the older clauses stopped providing appropriate safeguards after 27 December 2022, so any legacy agreement must be replaced. Under Clause 14, the parties must have no reason to believe the destination's laws prevent the importer from complying, which means a documented transfer assessment for each destination.

Binding corporate rules for intragroup flows

Binding corporate rules under Article 47 cover transfers between entities of the same corporate group, and they must be approved by the competent supervisory authority through the consistency mechanism. Approval takes time and is usually worth it only for groups with frequent intragroup flows across several third countries. Ask whether your lead authority has already approved a template and whether the rules cover all the entities that will import data.

Article 49 derogations as exceptions

Derogations for specific situations under Article 49 apply only when no adequacy decision and no appropriate safeguard is available. They cover narrow cases such as explicit consent after being informed of the risks, or transfers necessary for a contract with the data subject, and they are read restrictively. Do not use a derogation to cover systematic, repeated or large-scale flows, such as routine remote support from outside the EEA. Document why the exception applies for each flow.

What the transfer assessment must examine under Clause 14

Clause 14 of the 2021 standard contractual clauses (Decision (EU) 2021/914) requires the parties to warrant that they have no reason to believe the laws and practices of the destination country prevent the importer from complying with the clauses. That warranty cannot be given on assumption. The exporter must examine the destination's laws and practices for each transfer, especially laws that let public authorities compel access to data, and record what it found. The assessment is tied to the specific flow, so a generic statement about a country does not cover every contract that sends data there.

The written assessment should record four things. First, the flow itself: the categories of personal data, the data subjects, the importer, every location where data is stored or viewed, and whether remote support staff outside the EEA can reach it. Second, the laws and practices of the destination that bear on government access, with the sources relied on and their date. Third, the supplementary measures that reduce the risk, such as encryption with keys held in the EEA, pseudonymisation, strict access controls and logging of administrative access. Fourth, the conclusion, including what was done where the measures do not fully close the gap. Confirm with counsel whether the destination's laws require additional steps before the transfer proceeds.

The record matters because it is what the organization can show when a foreign authority requests data, when a customer or regulator asks why a flow is lawful, or when a supervisory authority considers suspending a flow under its powers in Article 58(2)(j). The organization or its counsel owns the conclusion and signs it. An implementation partner can prepare the technical inputs, including architecture diagrams, data location maps, access control and encryption configurations, and logs that show who administered the system and from where. Ask any partner to state in writing which parts of the assessment it prepares and which parts remain the controller's decision.

Who owns the transfer decision and who prepares the evidence

The controller or processor that exports the data holds the legal responsibility for the transfer decision. It must map which flows leave the EEA, choose the lawful route under Chapter V, and sign the contract and transfer assessment. Nobody else can accept that accountability on its behalf, and regulators will look to the exporter first when a flow is found to be unlawful.

  • Flow mapping: Maintain a current inventory of every system, vendor, sub-processor and remote support path that gives a party outside the EEA access to personal data.
  • Mechanism choice: Decide between an adequacy decision, standard contractual clauses or binding corporate rules, and record why the chosen route fits each flow.
  • Transfer assessment: Assess the destination's laws and practices for each transfer, as Clause 14 of the 2021 clauses requires, and sign the conclusion.
  • Contracts: Execute the clauses with the importer and keep the module selection and annexes accurate.
  • Independent advice: Engage qualified counsel on foreign law where the assessment depends on it.

Before relying on the file, confirm that the signed assessment names each flow and the person who approved it.

What a transfer failure can cost and which measures reduce exposure

This table maps each source of exposure from a non-compliant transfer to the legal basis for it and the measures that reduce it. Read each row as a separate risk, since fines, suspension orders and contract claims can arrive independently of one another. The main takeaway is that a documented transfer route and a completed transfer assessment reduce more than one of these exposures at once.

ExposureSourceWhat reduces it
Administrative fines up to EUR 20 million or 4% of worldwide turnoverArticle 83(5)(c), whichever is higher, for transfer rule infringementsA documented transfer route under Articles 45 to 49 and a completed transfer assessment for each flow
Supervisory suspension of data flowsArticle 58(2)(j) allows the authority to order data flows suspendedMapping every transfer, including remote support access, so flows can be paused or rerouted quickly
Customer contract claimsCustomer contracts and processing agreements that allocate liability for unlawful transfers by the processorClear contract terms on transfer locations, sub-processors and notice, plus evidence the controls operate
Operational disruption from a forced change of hosting or support locationConsequence of a suspension order or a lost safeguard, such as an invalidated routeContingency plans for alternative EEA hosting and support paths, tested in advance
Loss of a safeguard after a legal changeAdequacy or DPF status can change; the 2021 clauses replaced older clauses after 27 December 2022Monitoring the Commission's adequacy list and the status of the EU-US Data Privacy Framework, with a documented fallback route

Where transfer projects stall and how to avoid it

Most stalled transfer projects trace back to a few recurring mistakes: an assumption that a vendor's paperwork settles the question, access paths nobody mapped, and contracts or frameworks that quietly stopped applying. Each card below names one pitfall and the check that prevents it.

Treating a DPA as a transfer assessment

A vendor's data processing agreement sets out processing terms, but it does not show that a transfer is lawful. Chapter V requires the exporter to know where data flows, which safeguard applies and whether the destination's laws prevent the importer from complying. Ask the vendor for its sub-processor list with countries, then record a transfer assessment for each flow that leaves the EEA.

Missing remote support access

The EDPB Guidelines 05/2021 treat remote access from a third country as a transfer, even when a support engineer only views data. Vendor staff in another country, follow-the-sun support and administrator logins from abroad often fall outside the transfer register. Map who can reach production systems, from which countries, and bring those access paths into the same assessment.

Relying on DPF for an unlisted importer

The EU-US Data Privacy Framework covers only US organizations on the DPF List, so a US-headquartered vendor is not automatically covered. Subsidiaries, resellers and cloud sub-processors may each need separate checks. Confirm the importer's entry on the list for the specific entity receiving data, and keep a standard contractual clauses fallback in case that entry changes.

Keeping pre-2021 clauses in contracts

Contracts still built on the older standard clauses stopped providing appropriate safeguards after 27 December 2022. Such agreements often sit unnoticed in vendor onboarding files or in legacy contracts for internal systems. Inventory every transfer contract, identify those signed on the older clauses and replace them with the 2021 clauses, mapped to the correct module for each role.

Not rechecking the position

The DPF remains listed in October 2026, yet appeal Case C-703/25 P seeks to annul the decision, and the Omnibus IV and Digital Omnibus proposals are still moving through the EU institutions. A transfer route that works today can change. Assign a named owner to track the appeal outcome and the legislative procedures, and set a recurring review date for every transfer assessment.

Questions buyers ask about GDPR transfers

Does a US cloud provider always require standard contractual clauses?

No. The first question is whether a transfer occurs at all, and then which route applies. Under the EDPB's Guidelines 05/2021, a transfer happens when a GDPR-bound exporter discloses data to a separate controller or processor in a third country, and remote access from outside the EEA, even just to view data for support, counts as one. If the provider is on the EU-US Data Privacy Framework List, adequacy may cover the flow, and the list was still in place in October 2026. That position is under appeal (Case C-703/25 P), so check its status before relying on it. Where the framework does not cover the flow, standard contractual clauses with a transfer assessment are the usual route. Ask the provider to state in writing where data is stored, where support staff access it and which sub-processors sit outside the EEA.

How long does a GDPR transfer assessment take?

No reliable duration can be stated without knowing the scope. The effort depends on how many data flows exist, how many third countries are involved, whether the destination's laws must be analyzed for each transfer, and how much evidence the importer can provide. Clause 14 of the 2021 standard contractual clauses requires the parties to have no reason to believe local laws prevent the importer from complying, so each destination needs a documented review. Ask for a written scope that lists the transfers, the deliverables (transfer register, assessment records, supplementary measures) and the dependencies on the client's and the vendor's teams. A fixed-scope agreement sets the timeline in writing before work starts.

Does self-hosting remove GDPR transfers?

It removes the transfer to a vendor's third-country processor only if no third-country access occurs. Running open-source platforms in your own cloud account or data center means you no longer disclose data to an outside processor, but any staff, support engineer or sub-processor in a non-EEA country who can view or administer the data still creates a transfer. Check where backups, logs and monitoring tools are stored, which managed services sit in the path and whether vendor support requires remote access. Remote access from outside the EEA for troubleshooting is a common gap, so define it in your access policy and transfer register.

Can DeployOpen sign standard contractual clauses for us?

The controller or the exporter signs the standard contractual clauses, and the importer signs as the party receiving data. DeployOpen plans, implements, hardens and documents self-hosted platforms inside your infrastructure, and it does not act as a certifying or legal party to your transfer arrangements. Your legal team should confirm roles in writing before work starts, including whether DeployOpen acts as a processor under an Article 28 agreement, which modules apply and who is the importer for each flow. The scope document should record which technical tasks, such as data location settings and access logging, support your transfer assessment, and which decisions remain yours.

What must the client provide to start a transfer project?

Start with an inventory of where personal data goes and who can reach it. Before scoping, gather the following:

  • A list of systems, data categories and purposes, plus any existing records of processing
  • Each vendor, sub-processor and cloud region involved, with contract copies and any existing standard contractual clauses
  • Descriptions of remote access, support arrangements and backup locations outside the EEA
  • Current legal grounds for each flow, such as an adequacy decision, the Data Privacy Framework or binding corporate rules
  • Named owners in legal, security and engineering who can confirm facts and approve decisions
  • Your intended outcome, such as moving a flow to EU hosting or documenting an existing transfer

These inputs allow a written scope with defined deliverables and timelines before any work begins.

What happens if a transfer lacks a valid route?

Transfer infringements can carry fines of up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher, under Article 83(5)(c). Supervisory authorities can also order a suspension of data flows under Article 58(2)(j), which may stop a service in its tracks. Because the risk is operational as well as financial, document each flow, its legal route and the date you last reviewed it. Ask counsel to confirm your exposure in your specific case, since fine calculations depend on the facts of each infringement.

What DeployOpen hands over for a transfer file

DeployOpen starts by writing down every flow that could be a transfer before any system is configured. The written scope lists each data flow, its origin and destination, each system and sub-processor that touches the data, and each person or support path that can view it from outside the EEA. Remote support sessions, log shipping to a vendor, backups replicated to another region and vendor telemetry are listed alongside the main data store, because the EDPB Guidelines 05/2021 treat remote viewing and non-EEA cloud storage as transfers. The client chooses the hosting region and the cloud account, data center or air-gapped network where the platform runs, and DeployOpen configures the deployment there. The client should confirm in writing which regions are permitted for storage, backup and administrative access before work starts, since that decision drives which Chapter V route is needed.

The evidence package records what was configured and how access works in practice. It covers the access paths into each system, including named administrator accounts, jump hosts, VPN endpoints and any vendor remote access, with the conditions under which each path is used. It documents encryption in transit and at rest, key custody and who holds the keys, and the logging that shows administrative access from each location. DeployOpen delivers these as technical records the client can hand to its own assessor, along with the flow inventory that supports a transfer impact assessment. The organization owns the assessment, decides whether the Clause 14 analysis of destination laws is satisfied, and signs the contracts. DeployOpen prepares systems and documents them, but it issues no certificates, attestations or legal conclusions about whether a transfer is lawful.

How DeployOpen prepares transfer evidence for your team

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so you can see where personal data is stored and who can reach it. We prepare the systems and records a transfer assessment needs, while your organization owns the transfer decisions and an independent assessor or counsel reviews them.

How we scope

  • We map which data flows leave the EEA, including remote support access and cloud storage outside the EEA.
  • We record the destination, the importer and the lawful route your team has chosen for each flow.
  • Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

  • We configure hosting, access paths and support tooling so transfer routes match the approved data map.
  • We restrict third-country administrative access and log every session that touches personal data.
  • We prepare the technical facts a transfer impact assessment depends on, such as encryption and key custody.

How we test and document

  • We test that access restrictions and logging behave as the transfer records describe, and report gaps.
  • We document data locations, sub-processors and access paths in a form your legal team can review.
  • We keep change records so a new flow or support route triggers a fresh review before it goes live.

How we support

  • Ongoing support, upgrades and continuous testing are available as retainers after handover.
  • We update transfer documentation when your platform, hosting location or support model changes.
  • Decisions on adequacy, clauses and derogations stay with your organization and its legal advisers.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.