Is Hosting Data Outside the EU a GDPR Risk? What It Really Means and How to Limit It

If your business keeps client files, project folders, or team notes in the cloud, there is a good chance some of that data already lives outside the European Union, often without anyone deciding it on purpose. A default server region, a US-owned provider, a backup bucket in another country: the data crosses a border quietly, and the responsibility stays with you. For a freelancer, a small firm, or a company with no dedicated legal team, the honest question is not "is this forbidden" but "how much risk am I taking, and what can I actually do about it."

This article answers that. It is not legal advice, and no single tool makes you GDPR compliant on its own. But you can understand the rules well enough to make sound decisions, and you can put concrete controls in place today.

Quick Answer

Hosting personal data outside the EU is not automatically illegal under the GDPR, but it is a regulated "transfer" that you must be able to justify. The transfer needs a legal basis from Chapter V of the GDPR: an adequacy decision for the destination country, or appropriate safeguards such as Standard Contractual Clauses, usually backed by a transfer impact assessment. The sharpest practical risk is foreign government access, for example under the US CLOUD Act, which can reach data held by US-controlled providers even when the servers sit in Europe. The most effective way to limit that risk is to reduce what a provider can actually read: strong client-side encryption where only you hold the keys, plus choosing EU-based or EU-controlled hosting where you can.

Why this worries smaller businesses specifically

Large organizations have a data protection officer, a legal department, and vendor contracts negotiated line by line. A freelancer, a two-person studio, or a small practice has none of that, yet carries the same obligations as a data controller. When you store a client's documents, invoices, contracts, health details, or identity papers, you are processing personal data on someone else's behalf, and you answer for where it ends up.

Three things make this uncomfortable:

Transfers happen by default. Many popular tools store data in the US or spread it across global regions unless you explicitly pick otherwise. You can be "transferring" without ever clicking an export button.
"EU region" is not the same as "out of foreign reach." A provider can store your files in Frankfurt and still be legally compellable by a non-EU government because of who owns and controls the company.
The accountability sits with you. Under the GDPR, being able to demonstrate why your setup is lawful is itself an obligation. "I didn't know where the servers were" is not a defense.

The good news: you do not need to become a privacy lawyer. You need a clear mental model and a short checklist.

The rules on sending personal data outside the EU (more precisely, the European Economic Area) live in Chapter V of the GDPR, Articles 44 to 50. The core principle is simple: you can transfer data outside the EEA only if the protection travelling with it stays essentially equivalent to EU protection. There are a few recognized ways to achieve that.

Adequacy decisions

The European Commission can decide that a country offers an adequate level of protection. Transfers to those countries are then treated much like transfers inside the EU, with no extra mechanism required. Several countries have adequacy status, and for the United States there is the EU-US Data Privacy Framework, which covers US companies that self-certify under it. Adequacy decisions can be challenged and can change, so they are a basis to document, not a box to tick once and forget.

Appropriate safeguards (Standard Contractual Clauses)

When there is no adequacy decision, the most common route is appropriate safeguards under Article 46, most often the Commission's Standard Contractual Clauses (SCCs). These are contract terms your provider signs that commit them to EU-grade protection. Reputable cloud vendors publish SCCs in their data processing agreements.

The Schrems II reality check

Here is the part people miss. In its 2020 Schrems II ruling, the Court of Justice of the EU struck down the previous US transfer framework and made clear that signing SCCs is not enough on its own. You also have to assess whether the law in the destination country could undermine those contractual protections, for instance through government surveillance powers. That assessment is commonly called a transfer impact assessment. Where the legal environment is risky, you are expected to add "supplementary measures," and strong encryption that the provider cannot decrypt is the textbook example European regulators point to.

The risk that contracts cannot fully fix: foreign government access

The reason encryption keeps coming up is a specific gap that paperwork struggles to close. Laws such as the US CLOUD Act can require US-based or US-controlled companies to hand over data they hold, regardless of which country the servers are in. So a European data center operated by a US provider does not, by itself, put the data beyond that reach.

This matters because it reframes the whole question. The issue is less "which city are the disks in" and more "who can be legally compelled to read my data, and can they actually read it if compelled." If the provider holds the keys, a lawful order can turn into readable client files. If the provider never holds the keys, the same order produces unreadable noise.

That is exactly the difference explained in what actually changes when encrypted versus plaintext data leaks, and it is why the labels matter: being clear on the concrete difference between encrypted at rest, end-to-end, and zero-knowledge is the single most useful thing you can learn before choosing a vendor.

Comparing your realistic options

Most smaller organizations end up choosing between four setups. None is perfect. Here is an honest comparison on the dimensions that affect GDPR transfer risk.

Setup	Where data lives	Who can read it	Main GDPR concern	Transfer risk level
US cloud (keys held by provider)	Often US or global	Provider, and whoever can legally compel the provider	Transfer basis plus provider readability	High
EU region of a US-controlled provider	EU data center	Provider, still reachable under foreign law	Ownership and control, not just location	Medium to high
EU-based provider, keys held by provider	EU	Provider	Provider readability on breach or order	Medium
Any provider, client-side encryption, you hold the keys	Anywhere	Only you	Mostly solved for content; metadata and legal basis still matter	Low for content

Two honest caveats. First, client-side encryption protects the content of your files, but it does not magically erase every obligation: you still need a lawful basis for the processing itself, you still handle metadata, and you still owe your clients transparency about who your sub-processors are. Second, keeping data purely local on your own machines removes the transfer question entirely for that copy, but it shifts risk onto your own backups, device theft, and loss. There is no option with zero trade-offs, only options where you understand the trade-off.

What this means in practice: a short checklist

You do not need a compliance department to act on this. You need a handful of deliberate decisions.

Map where your data goes. List the tools that hold client or personal data and find out, for each, the storage region and the company's country of control. If you cannot find out, treat that as a red flag.
Prefer EU hosting where you can. It reduces, though does not eliminate, foreign-access exposure, and it simplifies your paperwork.
Encrypt before upload whenever the data is sensitive. If the provider cannot read your files, a transfer or a subpoena leaks ciphertext, not client documents. This is the supplementary measure regulators explicitly favor.
Keep the keys yourself. "The vendor encrypts your data" means little if the vendor also holds the key. Look for zero-knowledge designs where the key never leaves your side.
Document your reasoning. Note the transfer basis (adequacy or SCCs), and keep a short written assessment of the risk and the measures you took. Being able to show this is itself a GDPR requirement.
Plan recovery. Encryption that only you can undo means that if you lose your key or recovery phrase, nobody can help you. Store your recovery material safely offline.

For sector-specific angles, two of our guides go deeper on exactly this tension: how accounting firms handle client document storage under the GDPR, and how freelancers and consultants protect client data without an IT department.

Where Filarr can help, and where it cannot

Filarr is a local-first encrypted workspace: notes, files, and a graph that links them, stored encrypted on your own disk. It is relevant to this discussion for one specific reason, so let us be precise about what it does and does not solve.

What it helps with. Every file is encrypted on your device with AES-256-GCM, each file with its own key, before anything leaves your machine. The optional cloud sync uploads only already-encrypted, opaque blobs: in the code the server stores ciphertext it cannot read, file names are replaced by opaque identifiers, and your encryption key never reaches the server in cleartext. That means even though the default sync backend runs on Cloudflare R2 (a US-controlled provider), the provider holds unreadable data, which is precisely the kind of supplementary measure the post-Schrems II guidance points to. You can read how that works in the look inside Filarr's zero-knowledge sync. If you want full control over location, Filarr also supports bring-your-own-storage, so you can point sync at an EU S3-compatible bucket you choose; the bring-your-own-storage S3 setup guide walks through it.

What it does not solve. Filarr is an encryption and storage tool, not a GDPR certification and not legal advice. It does not choose your legal basis for processing, write your data processing agreements, manage your clients' consent, or handle data subject requests for you. Encryption is one control among several. If your overall processing is non-compliant, encrypting the files does not fix it. And because only you hold the keys, recovery is your responsibility: lose the recovery phrase and the data is gone.

In short, Filarr can shrink the single hardest-to-fix part of the outside-the-EU problem, which is provider readability, and it can let you pick where the encrypted blobs live. The rest of compliance stays your job.

FAQ

Is it illegal to store client data outside the EU? No. It is a regulated transfer, not a ban. It is lawful if you have a valid basis under Chapter V of the GDPR, typically an adequacy decision or Standard Contractual Clauses, and, since Schrems II, a reasoned assessment of the destination country's risks with supplementary measures where needed.

My provider stores data in an EU region. Am I safe from foreign access? Not necessarily. If the provider is owned or controlled by a non-EU company, laws like the US CLOUD Act can still reach the data even in an EU data center. Location helps, but ownership and whether the provider can read your data matter just as much.

Does encryption make me GDPR compliant? No, but it is one of the strongest single controls you can add. Encryption where only you hold the keys is the supplementary measure European regulators explicitly favor for risky transfers, because a compelled disclosure or a breach then exposes unreadable ciphertext. Compliance still depends on your whole processing, not one tool.

What is the simplest high-impact change I can make? Stop letting the provider hold your keys for sensitive data. Use client-side, zero-knowledge encryption so files are unreadable server-side, and prefer EU-based or self-chosen storage. That combination addresses both the breach risk and the foreign-access risk at once.

Is keeping everything local instead of in the cloud a valid option? Yes, and it removes the transfer question for that copy, which is why many privacy-conscious users prefer it. The trade-off moves to your own backups and device security, so pair local storage with encrypted backups and a safely stored recovery key.

This article is general information, not legal advice. For decisions about your specific obligations, consult a qualified data protection professional.