European CMS: what "hosted in the EU" actually buys you
GDPR, the Cloud Act, transfer impact assessments and sub-processor lists. What EU hosting genuinely changes for a client website, and what it is often sold as changing but does not.
“Hosted in Europe” appears on a lot of pricing pages, ours included, and it means less than most of them imply and more than the sceptics allow. It is worth being precise, because a client who asks the question deserves a better answer than a flag icon.
This is not legal advice. It is what a developer needs to understand to answer a client honestly and to fill in a supplier form without guessing.
What GDPR actually requires of a brochure site
Start with the boring truth: most brochure sites process very little personal data. A contact form, maybe an email address for a newsletter, and analytics if you added any.
For that, GDPR asks for a handful of concrete things:
A lawful basis for each processing purpose. For a contact form it is usually the pre-contractual steps at the data subject’s request, or legitimate interest.
Transparency: a privacy policy naming what you collect, why, for how long, and who else sees it. “Who else sees it” means a sub-processor list, and it must be a real list with names, not “our trusted partners”.
A data processing agreement between the client, who is the controller, and each processor. If you build and host the site, you are a processor for your client and they need a DPA from you. If you use a CMS, that CMS is a sub-processor and you need a DPA from them, which you can pass through.
Rights handling: access, rectification, erasure, within a month.
None of that requires EU hosting. GDPR is not a data-localisation law, and a US-hosted service can be fully compliant. What EU hosting changes is a narrower and more specific thing.
What EU hosting does change
It removes the transfer question. Sending personal data outside the EEA requires a legal mechanism: an adequacy decision, standard contractual clauses, or one of the derogations. Since Schrems II, using standard contractual clauses also requires a transfer impact assessment, a document assessing whether the destination country’s surveillance law undermines the protection. That is real work, it has to be revisited when the legal landscape moves, and it is the thing your client’s lawyer will ask about.
If the data never leaves the EEA, the entire question does not arise. That is the actual, concrete benefit: not “more secure”, but one fewer document to write and maintain.
It reduces exposure to the Cloud Act. The US CLOUD Act lets US authorities compel a US-headquartered provider to produce data it controls, including data stored in Europe. A European provider with no US parent is outside that reach. Whether this matters depends entirely on your client: for a plumber’s website, close to not at all; for a lawyer’s practice, a hospital, or anything public sector, potentially a lot.
It matters for public procurement. French and European public bodies increasingly require EU hosting, and sometimes SecNumCloud qualification. If your client is a municipality, this stops being a nuance and becomes a yes-or-no gate.
Latency, marginally. Real but small, and largely irrelevant once a CDN is in front of the site.
What it does not change
Let us be equally clear about the overselling.
It is not “more GDPR compliant”. Compliance is about your processing, your basis, your documentation. A badly documented EU-hosted service is less compliant than a well documented US one.
It is not automatically more secure. A data centre in Frankfurt has no inherent security advantage over one in Virginia. Encryption, access control and patching decide that, not geography.
It does not remove the DPA. You still need one, and your client still needs one from you.
It does not cover sub-processors you forgot. A site hosted in Europe that loads a US font service, a US analytics script and a US embedded map is transferring personal data on every page view, whatever the origin server’s location. This is the single most common gap, and it is entirely within your control.
That last point deserves emphasis because it is where most sites actually fail. The origin server is rarely the problem. The problem is the fourteen third-party scripts.
The stack question, made concrete
For a client site, the honest audit is: what does the browser connect to, and what does the build connect to?
The browser connecting to a US CDN for a font, a US tag manager, and a US video embed is three transfers you have to document, regardless of where you host. Self-hosting fonts, avoiding tag managers, and using a privacy-respecting analytics tool removes them.
Our own stack, for what it is worth as an example rather than an advertisement: application and database on a French provider, published content and media served by a European CDN, transactional email through a French provider, payments through Stripe, which is the one unavoidable US processor in the chain and is named as such in our sub-processor list rather than glossed over.
Naming the exception is the point. A sub-processor list with an inconvenient entry on it is more credible than one that claims a perfectly European chain, because almost nobody has a perfectly European chain.
Analytics, where this gets decided in practice
The most common personal-data processing on a brochure site is analytics, and it is where “European” stops being abstract.
Google Analytics has been the subject of decisions by several European supervisory authorities finding its use unlawful without additional measures, because of the transfers involved. Whatever the current state of any particular case, the practical consequence for an agency is that recommending it to a client requires a conversation you would rather not have.
The alternatives that avoid the question entirely are cookieless, EU-hosted analytics: no personal data collected, therefore no consent banner, therefore no transfer question. This is one of those rare cases where the compliant option is also the simpler and faster one.
The static site advantage nobody mentions
There is a structural point in favour of static sites here that rarely comes up, and it is worth making because it is genuinely unusual.
A statically generated site, served from a CDN, does not process personal data to render a page. There is no server-side session, no database query per visitor, no application log tying an IP to a user. The origin is a bucket of files.
Compare that with a WordPress site, where every page view hits PHP, touches a database, writes to an access log, and usually sets a handful of cookies before the visitor has interacted with anything.
The consequence is that the compliance surface of a static brochure site is unusually small: a contact form, if you have one, and analytics, if you added any. Everything else is bytes leaving a cache.
Where a CMS fits into this matters too. If your CMS serves content at request time, it is in the visitor’s path and becomes part of the processing chain. If content is baked in at build time, the CMS is only ever touched by you and your editors, never by a visitor. That is a smaller and much easier chain to document: your editors are identified people with accounts, not anonymous data subjects whose rights you have to handle at scale.
When the answer is “this does not matter for your client”
Proportionality is part of doing this well, and over-engineering compliance for a plumber is its own kind of failure.
For a local business’s brochure site with a contact form and cookieless analytics, the honest answer is that the risk is low, the documentation is short, and EU hosting is a nice-to-have that costs nothing extra. Do not sell a transfer impact assessment to someone who needs a website.
The cases where it genuinely changes the decision are narrower and recognisable: public sector, where it is often a requirement; health, legal and finance, where the data categories are sensitive and the client’s own regulator has opinions; anything with an audit, where a supplier form will ask exactly these questions and a good answer saves days.
Know which case you are in before spending the client’s money on it.
What to actually give a client who asks
When a client or their lawyer asks “is this GDPR compliant”, the useful answer is a set of documents rather than a yes:
- A sub-processor list with real names and locations, including the awkward ones.
- A DPA they can sign.
- A retention statement: how long each category is kept and what happens at deletion.
- An export path, so leaving is possible.
- A hosting statement: where the data physically sits.
If a CMS vendor cannot produce those five things quickly, that tells you something regardless of where their servers are.
We publish ours at /dpa/ and /privacy/, and the pricing page covers the commercial side including the VAT treatment for EU businesses.
The honest summary
EU hosting is a real benefit with a narrow scope: it removes the transfer assessment, reduces Cloud Act exposure, and unlocks public-sector work. It is not a compliance certificate and should not be sold as one.
The things that actually determine whether your client’s site is compliant are the documents you can produce and the third-party scripts you did not load. Both are within your control, and neither depends on the flag on the data centre.