"EU hosted" describes one server. Your data lives in more places than that.

---

QUICK ANSWER

"EU hosted" usually answers one question: where the web server sits. It says nothing about backups, logs, email delivery, or who logs in from where. Under the GDPR, support staff in a third country reading data stored in Europe is a transfer. Three questions get you the real answer, and they are below.

---

A prospective client asks the agency a fair question: is our website hosted in the EU? The answer comes back in one line. Yes, our servers are in Frankfurt.

The answer is true. It is also about one machine. Meanwhile the nightly backups go to a different provider, the error logs are collected by a monitoring tool, the contact form sends mail through a delivery service, and one developer who supports the site logs in from outside Europe. Each of those is personal data moving somewhere. None of them was covered by the answer.

"EU hosted" is a fact about a server, not about a system

A website is not one place. It is a chain of services, and the data your visitors give you passes along it.

Ask most agencies where the site is hosted and you get the name of a data centre. That is the easiest link in the chain to answer for, and often the only one anybody has checked. The rest of the chain is assembled from whatever was convenient at build time, usually without a map.

None of this means anyone is careless. It means the question "is it EU hosted" is too small to produce a useful answer.

Question one: where does the data actually sit, including copies?

The web server is the start. The real list is longer:

• Backups. Often a different provider, in a different country, and holding a full copy of everything the site holds.
• Logs and monitoring. Error trackers and performance tools frequently receive page addresses, browser data and sometimes form contents.
• Email delivery. A contact form's messages usually leave through a mail service, not from the server itself.
• A content delivery network. Files and sometimes visitor addresses are handled by edge servers around the world.
• Analytics and marketing tools. Their own storage, wherever it is.
• The place the agency keeps your content while it works: a drive, a design tool, a ticket system.

A copy is not a lesser thing than the original. A backup of your members' data in a third country is your members' data in a third country.

The length of that list is a design decision, not a fact of nature. Elevates builds sites that relay form messages to an inbox instead of keeping a database of enquiries on the server, which removes several lines from the list before anyone has to audit them.

Question two: who else touches it?

Every one of those services is a company. Under the GDPR they are sub-processors: other firms your agency brings in to process data on your behalf.

Article 28(2) of the Regulation says a processor "shall not engage another processor without prior specific or general written authorisation of the controller", and that with general authorisation the processor must inform you of any intended changes so you can object. In practice that means two things you can insist on: a list, and a notice when it changes.

The list is the useful artefact. One line per service, what it does, which company runs it, and in which country the data sits. Any agency that cannot produce it has not mapped its own chain.

Question three: who logs in, and from where?

This is the question almost nobody asks, and it is the one with the clearest answer in law.

The GDPR does not define "transfer". The European Data Protection Board filled the gap in its Guidelines 05/2021, version 2.0, adopted on 14 February 2023. It sets three cumulative criteria: the exporter is subject to the GDPR; it makes the data available to another controller or processor; and that importer "is in a third country".

Then it gives the case that matters here. A processor outside the EU that is "remotely accessing, e.g. for support purposes, the data which is stored in the EU" produces a transfer, because the person reading the data is in a third country. Where the disk sits does not settle it. Where the people sit matters too.

So the third question is simply: who has login access to the server, the database and the content system, and from which countries do they work?

A transfer is not forbidden. It is conditional

None of this means data may never leave Europe. Article 44 allows transfers when the conditions in Chapter V are met, and there are two ordinary routes.

The first is an adequacy decision: the Commission has decided the destination protects data adequately, and no extra paperwork is needed. The Commission's list covers Andorra, Argentina, Brazil, Canada, the Faroe Islands, Guernsey, Israel, the Isle of Man, Japan, Jersey, New Zealand, the Republic of Korea, Switzerland, the United Kingdom, the United States and Uruguay, plus the European Patent Organisation.

Two of those come with a condition attached. Canada's decision covers commercial organisations only. The United States is covered only for companies that have joined the EU to US Data Privacy Framework, under the decision adopted on 10 July 2023. So "our backup provider is American" is not an answer by itself: the question is whether that specific company is on the Framework list.

The second route, where there is no adequacy decision, is the standard contractual clauses under Article 46. They are ordinary paperwork, not an obstacle, and an agency that works internationally should already have them.

An EU company owned abroad is a different question

There is a case in between that gets argued about a lot, and the EDPB has answered it.

If your processor is established in the EU, processes your data only in the EU, and nobody outside the EU has access, then handing data to it is not a transfer, even when its parent company sits in a third country and foreign law could reach it. The EDPB's own example says the disclosure "does not amount to a transfer and Chapter V" does not apply.

That is not the end of the matter, because the risk of a foreign access request still exists and still has to be weighed under the Regulation's security duties. But it is not a transfer question, and treating it as one confuses the conversation.

Four answers that sound reassuring and are not

Some answers arrive with confidence and settle nothing.

"We use a European provider." The provider's headquarters is not the same fact as where your data sits, nor the same fact as who can reach it. A European company can store data outside Europe, and a company outside Europe can store data inside it. Ask about the data, not the letterhead.

"It is all encrypted." Encryption is a security measure, required in its own right under Article 32, and it is worth having. It does not answer the location question. Data that is encrypted at rest is still processed somewhere, by someone with the key.

"We do not store any personal data." This is often meant sincerely and is often wrong. The contact form leaves a copy in an inbox. The error log caught the visitor's address. The backup holds the database from before the last clean up. What a site was designed to store and what it actually holds are two different lists.

"Our host is GDPR compliant." No authority certifies a company as GDPR compliant in general terms. A provider can offer standard contract terms, security certifications and EU regions, and those are useful, but compliance attaches to what you do with the data, not to a badge on a supplier's website.

None of these answers are lies. They are answers to easier questions than the one you asked.

What to ask for, in writing

Six lines, and they work on any agency:

• The list of sub-processors: name, what each one does, and the country where the data sits.
• Where the backups are, with whom, and for how long they are kept.
• What the error logs and analytics collect, and where they go.
• Which countries your support staff log in from, including freelancers.
• How you will be told when a sub-processor changes, and how you can object.
• The data processing agreement itself, since Article 28(3) requires one in writing.

An agency that answers all six in a day is telling you it has a map. An agency that answers only the first is telling you the truth about its server and nothing else.

Where the checklist stops

A list is a statement, not a guarantee. It reflects what the agency knows about its own chain on the day it was written.

Two things make it more than paper. The first is minimising what exists to protect: a site that never stores enquiries on its own server has a much shorter list than one that keeps every message in a database for years. The second is keeping the list current, because a new plugin or a new monitoring tool adds a link to the chain without anyone announcing it.

What a vague answer costs you, and what Elevates does

For the business asking, the cost of "yes, Frankfurt" is that the question stays open. It surfaces again when a client demands a processor list, when a funder's compliance officer asks, or after an incident, which is the worst moment to start drawing the map.

Often the honest answer is that a small brochure site with a contact form has a short chain and a simple map, and an afternoon with the six questions settles it for years. Where Elevates builds, the design starts from storing less: forms relay to an inbox rather than building a database of enquiries on the server, and what the contract calls for is deletion on delivery rather than indefinite retention. A shorter chain is easier to keep honest than a long one that has to be audited.

The question to ask this week

Ask whoever runs your website: which countries do the people who can log in work from?

If the answer arrives with a list of services and countries next to it, EU hosting means something in your case. If the answer is the name of a city where a server sits, you have learned one fact about one machine.

This is a description of the Regulation and the EDPB's guidance. It is not legal advice, and whether your own arrangements comply is a question for a lawyer in your country.