Skip to Content

Hosting Data Outside the EU and the GDPR: What the Text Actually Says

Learn how to host data outside the EU while staying GDPR compliant: permitted mechanisms, transfer impact assessments and mandatory documentation.

Hosting Data Outside the EU and the GDPR: What the Text Actually Says

Assessing a data transfer outside the EU

Yes, hosting your data outside the European Economic Area is still possible under the GDPR, but only if you put a proper legal framework around every single flow, in line with Chapter V of the regulation. That means picking a recognised mechanism (adequacy decision, standard contractual clauses, BCRs), assessing how effective those safeguards really are through a transfer impact assessment, and then documenting all of it in your record of processing activities. Without that discipline, the transfer is unlawful, even if a contract exists on paper.

In short:

  • Compliance for a transfer outside the EU rests on choosing a recognised mechanism and running an impact assessment to confirm the safeguards actually work.
  • When hosting or processing happens outside the EEA, you have to look at local law — its government access powers and available remedies — not just where the provider is legally registered.
  • Since the Schrems II ruling, signing standard contractual clauses is no longer enough on its own without a thorough technical and legal review of the destination country's context.
  • A transfer impact assessment must include a precise map of the flow, an evaluation of the risk of access by a foreign authority, and mitigation measures suited to that risk.
  • Hosting your data in France or elsewhere in the EEA through a sovereign hosting provider can simplify compliance by avoiding the transfer altogether and making data subject rights easier to handle.
Yundera
Keep your data under control
Yundera offers managed private servers hosted in France, with no data collection or resale, and export available at any time.
Discover Yundera

Table of contents

What counts as a data transfer outside the EU under the GDPR?

A transfer exists as soon as three conditions come together: an exporter located in the EEA, a communication of data to an importer, and that importer being established outside the European Economic Area. The European Data Protection Board treats these criteria as cumulative, which rules out certain internal flows but captures far more use cases than most people assume at first glance.

The criterion that catches out the most controllers is the registered office. A company can be incorporated in France, carry a perfectly French name, and still be carrying out a transfer outside the EU if its servers run in the United States or its technical support sits in India. The actual place of processing and storage always takes precedence over the provider's legal nationality.

In practice, here are the situations that most often trigger this classification without anyone noticing:

  • A CRM or sales management tool hosted on US servers, even if the interface is in French.
  • An outsourced customer support service that accesses the data from a third country.
  • Analytics tools or advertising pixels that send browsing data to servers outside the EEA.
  • A CDN that replicates content across nodes spread around the world.

Each of these cases needs to be identified individually, because each one creates its own distinct obligation under Chapter V.

The GDPR sets out a fairly clear hierarchy of tools for framing a transfer to a third country, and each one comes with its own conditions of use, costs and limits.

An adequacy decision is still the simplest option where one exists. The European Commission recognises that a third country offers a level of protection deemed equivalent to the EU's, which removes the need for any additional safeguards. The problem is that the list of these countries is short and keeps shifting: the United Kingdom, Japan and South Korea benefit from one, but most of the major global cloud providers operate from jurisdictions that don't appear on it.

Standard contractual clauses (SCCs), adopted under the 2021 implementing decision, are the mechanism most widely used in practice. They contractually bind the importer to meet certain protection standards. But since the Court of Justice of the European Union's Schrems II ruling (case C 311/18), signing SCCs is no longer enough: the EDPB now requires you to verify that those clauses have a real effect against local legislation, failing which the transfer remains unlawful despite the contract.

Binding corporate rules (BCRs) offer broad coverage for intra-group flows, but putting them in place demands a heavy investment. They mainly suit multinational groups able to absorb approval timelines that are often measured in months, sometimes years.

Finally, the Article 49 derogations (explicit consent, performance of a contract, public interest) are reserved for one-off situations and can never serve as the basis for systematic or repeated transfers, as the CNIL regularly points out.

How do you run a transfer impact assessment (TIA)?

Confirming that a legal mechanism exists is never enough. Since Schrems II, you have to demonstrate that the mechanism actually works given the legal context of the destination country, particularly in the face of surveillance laws such as the US Cloud Act. That is the purpose of the Transfer Impact Assessment.

Here is the method most specialist firms follow:

  1. Map the flow precisely: what data, to which country, through which provider, and for what purpose.
  2. Analyse the destination country's legislation, especially its government data access laws and whether data subjects have any remedies available.
  3. Assess the concrete risk of access by a public authority, taking into account your sector and the volume of data processed.
  4. Identify the mitigation measures available if the risk looks significant.
  5. Document the final decision, whether that means approving the transfer, adding safeguards, or abandoning it.

When the assessment reveals a genuine risk, two categories of measures come on top of the contractual safeguards. Technical measures first: end-to-end encryption, pseudonymisation before sending, or keeping the decryption keys in Europe. The EDPB explicitly recommends this kind of supplementary measure where local law threatens the effectiveness of SCCs. Then organisational measures: strictly limiting internal access, running regular audits of the processor, or including notification clauses covering access requests from a foreign authority.

Pro tip: Keep control of your encryption keys within the EEA. A provider outside the EEA that has no technical means of decrypting your data considerably lowers the risk assessed in your TIA, even if it continues to host the encrypted content.

Encryption key held separately from the hosted data

Which technical and organisational measures reduce the risk?

Beyond the TIA itself, certain structural practices reduce your exposure over the long run, without depending on a one-off assessment for every new flow.

On the technical side, several levers combine effectively:

  • Systematic encryption of data at rest and in transit, with key management located in the EEA.
  • Pseudonymisation of personal data before anything is sent to a system hosted outside Europe.
  • Access logging, so you can trace who consulted what, from where, and when.

On the organisational side, contractual solidity counts just as much as the technology. A precise data processing agreement (DPA) must list any sub-processors, set out notification requirements in the event of a breach, and provide for a right of audit. A clear SLA on incident response times rounds this out, as does a reversibility clause guaranteeing you can retrieve your data if the contract ends.

These checks are not a one-time exercise. A periodic audit of your processors, at least annually, lets you spot a change in server location or the appearance of a new sub-processor outside the EEA that the original provider added without telling you.

What are the most common pitfalls in transfers outside the EU?

The most widespread mistake is focusing solely on signing a contract, an SCC or a DPA, without ever examining the actual legislation of the destination country. A contract that looks solid on paper protects nothing if local law permits government access that nobody can challenge.

The US SaaS case illustrates this trap well. Before signing, always ask the vendor for the full list of its sub-processors, the exact location of its data centres, and whether it is certified under the Data Privacy Framework. That certification, where it exists, amounts to a form of partial adequacy, but it remains open to challenge in court, as the turbulent history of Safe Harbor and then Privacy Shield showed.

Cascading subcontracting poses a similar problem. A French provider may perfectly well hand its technical support or hosting to a third party outside the EEA without the end customer being clearly informed. Mapping the whole chain, including the tools your teams use internally without any formal IT sign-off, is usually the most neglected and the most time-consuming task in the entire compliance process.

What are the most common pitfalls in transfers outside the EU? — overview diagram

An operational checklist for data controllers

Faced with this volume of obligations, here is the order in which the most effective DPOs generally tackle the subject:

  1. Map every flow and every provider, including tools your teams adopted without official sign-off.
  2. Check whether an adequacy decision or SCCs exist for each flow you identify, and launch a TIA as soon as there is any doubt.
  3. Update your record of processing activities to cover each transfer, its safeguards, and the date it was last reviewed.
  4. Negotiate a solid DPA, add the technical measures you need, and plan an exit route in case the contract ends or the legal framework you rely on is invalidated.
  5. Test the real portability of your data regularly, to confirm the export works on the day you actually need it.

This work has to be redone for every new supplier, never once and for all.

Why sovereign hosting simplifies compliance

The most underrated argument in this debate is the administrative burden you avoid. Hosting that stays entirely within the EEA simply isn't a transfer under the GDPR: no TIA, no SCCs to negotiate, no legal monitoring of a third country. Handling data subject rights (access, erasure, portability) also becomes more direct, with no overseas intermediary to contact. That simplicity has a cost, often a narrower service catalogue than a US giant offers, but for many small and mid-sized businesses the maths comes out clearly in favour of legal peace of mind.

Yundera, one way to sidestep the transfer question

This managed private server solution, hosted in France, keeps data from leaving the European Economic Area, which removes some of the assessment work tied to transfers.

Yundera

In practical terms, the solution bundles several open source applications (file sharing, websites, photo gallery, collaboration tools) reachable from a custom domain, with simplified administration. Data can be exported at any time, and the infrastructure is designed to respect data confidentiality.

For a small business or a startup that wants to cut short the endless discussions about whether a third country is adequate, this approach strips out a good part of the complexity set out in the GDPR cloud compliance checklist. Teams also juggling budget constraints will find a concrete overview of the potential savings on the page dedicated to startups and SMEs. To work out whether your current infrastructure is worth moving, the Yundera private server overview covers the offer in detail and lets you start an assessment straight away.

— Yundera

Sources

Before making any decision, consult the CNIL framework on transfers outside the EU, the EDPB recommendations, and the official standard contractual clauses template. For documenting your flows, the Notyfile guide to the GDPR offers useful additional reference points.

This article is general information and does not replace the advice of a qualified lawyer. Consult a qualified legal professional about your own situation before acting on this content.

Recommendations

Sign in to leave a comment