"Yes, we host in the EU" is too short an answer to the question "is my data in Europe". It's true, and it's not the whole story.

This post answers it for ourselves, with names included. We are not lawyers and this is not legal advice. It's how we've set it up, and why.

01 / the question behind the questionWhy do you actually want to know this?

The geography itself isn't the point. Behind the question is one of these three reasons:

• Your clients ask about it. Healthcare, education, financial services: it's in the procurement terms and you simply need to be able to answer it.
• You need a data processing agreement, and it must state which parties process your client data. Then you need a list, not reassurance.
• You want to know who can access your data. That's the real question, and the answer to it isn't "Germany".

The third is the most important. Where the disk is located is a technical fact. Who is allowed access is a legal fact. They don't automatically align.

You can see where that data originates by walking through your client journey. At each moment something is created, and it lands somewhere:

1. First contact. Name, company, what someone is looking for. Originates on your website or in your mailbox.
2. Conversation. What someone actually wants and what they tried before. This is the most valuable data of the whole journey, and it usually lands nowhere.
3. Proposal. What you offer and on what terms. Lands in a document tool, sometimes with a signing service attached.
4. Delivery. Files, reports, hours, correspondence. Spread across project environment, mailbox and disk.
5. Aftercare. Invoices, evaluations, everything you keep so you can look back later. Lands in the accounts, and the rest nowhere.

At every step there's also a shadow copy: an export in someone's downloads folder, a shared folder with old quotes, a mailbox going back twelve years. Those copies fall under the same rules as the original, and in a data breach they're usually the source.

02 / where it isWhich server, which country?

Our servers are in Germany and Finland, with a single supplier. The current state of our servers and costs is at datadriftdigital.nl/stack/.

The supplier is Hetzner: a German company, with German and Finnish data centres. That's why we can say "in Europe" without an asterisk after it: it's not just the servers that are there, the company itself falls under it too.

That distinction is the entire point of this post, and it comes back in block 4.

03 / what does cross the borderWhere isn't it true?

With seven suppliers, one of which is American. Here they are.

On our own site we once wanted to write "one sub-processor". That wasn't true and it was removed before it went live. There are eight, and a list of names is more useful than a number a lawyer can knock down with a single question.

A supplier who tells you they have one sub-processor hasn't counted them.

What you can take from this: ask for the list, not for reassurance. Anyone processing client data should have that list ready.

04 / the difference with "EU region"What are you actually buying when a supplier promises that?

A location. Not necessarily a jurisdiction.

Large providers give you the option to put your data in a European data centre. That's real, and it helps: it makes a difference to speed, and it's often exactly what a procurement term asks for.

But it doesn't answer the third question from block 1. Where the disk is says nothing about which law applies to the company that manages the disk. An American parent company remains an American company, even if the server is in Frankfurt.

We are not lawyers and won't make any claim here about how that plays out in a specific case. What we can say: they're two different questions. Keep them separate, even if a salesperson lumps them together.

To be clear: we ourselves use two American services for things that matter. So we're not saying it's not allowed. We're saying you need to know what you have.

Open source solves part of this, and part of it it doesn't. Where your software runs determines the privacy, not the licence: open software on an American server is still data on an American server.

• Solves: being locked into a single supplier, and not being able to check what happens under the bonnet.
• Doesn't solve: where the servers are, who has access, and whether your setup is sound.

05 / what you can askSix questions for any supplier, including us

These six separate a real answer from reassurance.

1. Give me the list of sub-processors, with name and country. If you get a number instead of a list, it hasn't been counted.
2. Under which law does the company itself fall, regardless of where the server is? This is the question "EU region" doesn't answer.
3. In whose name are the accounts you build in registered? If the answer is "ours", you know enough: you don't own the data, you just have access to it.
4. What can I export tomorrow, and in what format? An answer without a format isn't an answer.
5. Who can access my data, and how is that recorded? Ask about the logging, not the promise.
6. How long is what kept? Keeping things indefinitely isn't a luxury, it's at odds with the principle that you shouldn't keep data longer than necessary.

For us, the answer to the third is: the accounts are in your name. We build in them, not alongside them. There's no environment of ours that your client data moves into and where we hold the key. If you stop working with us, the maintenance stops, not your access.

This text was produced with AI assistance and checked and approved by a human before publication.