GDPR-Compliant Hosting: What It Actually Means (And What Hosts Won't Tell You)

Nobody can sell you “GDPR-certified hosting.” That’s not a thing.

There is no GDPR certificate. No regulator issues one. No standards body audits hosts for it. When you see “GDPR-compliant hosting” on a marketing page, you’re looking at the host’s opinion of their own posture, which sometimes matches reality and sometimes doesn’t.

That’s the part of the conversation most hosting comparison pages skip. They want a tidy checkbox so they can rank by it. The honest version is messier: GDPR compliance for a hosted website is the sum of about a dozen small choices, and the host can quietly fail any of them while still putting the word “GDPR” on the homepage.

This is what those choices actually look like, what they cost you when a host gets them wrong, and how to test for them in five minutes with nothing more than your browser’s developer tools.

The five questions that decide whether your host is honest

1. Where does the data physically live?

GDPR doesn’t ban data leaving the EU. It bans data leaving the EU to a destination that doesn’t have adequate protections, which since the Schrems II ruling means the United States is treated with extra friction (Standard Contractual Clauses, transfer impact assessments, the works).

The honest answer for most hosts who claim “EU data residency” is more nuanced than the marketing copy:

• Your primary database might live in Frankfurt
• Your backups might replicate to a US bucket
• Your email goes through a SendGrid account in Denver
• Your support tickets sit in a Zendesk instance in San Francisco
• Your error logs ship to a Datadog tenant in Virginia

If any one of those is true, “data never leaves the EU” is a marketing claim, not a technical fact.

How to verify: ask for the sub-processor list in writing. A host who can’t produce one in under a day either doesn’t have it documented (a GDPR problem on its own) or has reasons not to.

Our answer: we operate in 10 datacenter regions across three continents. EU/EEA: Amsterdam and Frankfurt. UK (UK GDPR, not EU): London. North America: four cities. Asia-Pacific: three cities. EU residency on our platform is a choice you make at signup, not a default we can promise universally. If you need it, you tell us during onboarding (or pick the EU datacenter explicitly when deploying), and we keep the primary, backups, and snapshots inside the same continental region. We don’t claim “your data never leaves the EU” because that would only be true for customers who actively chose EU plans, and we’re not going to lie about it for the ones who didn’t.

2. Who else touches the data on the way?

Every web request involves more services than the host. CDN. CAPTCHA. Email delivery. Backup. Monitoring. Analytics. Each one is a sub-processor under GDPR, which means it has to be named, documented, and bound by a Data Processing Agreement that flows from the host down to the customer.

The dirty secret of the hosting industry: most hosts have between five and fifteen sub-processors they never disclose. They show up in the page source as third-party script tags or as DNS lookups to companies you’ve never heard of.

How to verify: open your host’s privacy policy and search for “sub-processor.” If the list has fewer than three names, they’re either tiny or hiding something. Then open the network tab on their homepage and count the third-party domains. The two numbers should match.

Our answer: our privacy policy names every sub-processor we use, including the US-based ones (Cloudflare Turnstile for CAPTCHA, ipapi.co for the “nearest datacenter” geolocation suggestion, Google Analytics if you opt into analytics cookies, Tawk.to if you opt into marketing cookies). Three of those are US companies, and we don’t pretend they’re European. Standard Contractual Clauses are in place for each, which is the GDPR-prescribed remedy for transferring data outside the EEA. The full list with countries and data types is in our privacy policy under section 6.

3. Does the cookie banner do what it claims?

The 2019 EDPB guidelines were clear: non-essential cookies require active opt-in. Pre-checked toggles are not consent. Inferred consent (“by using this site you agree…”) is not consent. Cookie walls that block the site until you accept are not consent.

A surprising number of hosting providers, including some of the biggest names in the EU market, still ship cookie banners where the “Analytics” toggle is pre-checked when you open the customize panel. That single line of HTML is a documented GDPR violation, and we know because we shipped it ourselves until earlier today.

That’s worth saying out loud. We caught it during this article’s prep, fixed the default in the cookie banner code so the analytics toggle is now unchecked by default, and shipped the change to production. Anyone who customizes their consent now has to actively turn analytics on, not off. We’re flagging it here because “we just fixed something” is more credible than “we always did it right,” and because anyone reading this can verify the fix in their browser dev tools right now.

How to verify: open any host’s cookie preferences panel and look at the toggles before clicking anything. If “Analytics” or “Marketing” is already on, the host is in violation regardless of what their privacy policy says.

4. What loads in the visitor’s browser before consent?

This is the one that catches almost everybody. The cookie banner is just the visible UI. The real question is what scripts have already executed and what network requests have already fired by the time the banner appears.

The classic example: a site claims “Google Analytics only loads after you accept analytics cookies.” Then you open the network tab and googletagmanager.com/gtag/js is already in the waterfall before the banner finished rendering. That’s because GA’s official Consent Mode v2 documentation tells hosts to load gtag.js immediately with consent defaulted to “denied,” then update consent later. The script is loaded. Your IP has reached Google. Whether or not Google “measures” you is a separate question. The data flow already happened.

The 2022 LG München I ruling made a similar point about Google Fonts: even just loading a font from Google’s CDN transmits the visitor’s IP to a US company, and that transmission requires consent in the German interpretation of GDPR.

Most hosts handwave this away. “We use Consent Mode v2 so we’re compliant.” That’s the marketing answer. The strict-compliance answer is to not load the script at all until consent is granted, and to self-host everything that would otherwise leak IPs to third-party CDNs.

How to verify: open a fresh incognito window, navigate to the host’s marketing site, and check the network tab. Filter for third-party domains (fonts.googleapis.com, fonts.gstatic.com, embed.tawk.to, connect.facebook.net, googletagmanager.com). If any of those fired before you saw the consent banner, the host is doing the “transmit then deny” pattern.

Our answer: as of this week, none of those domains fire on our site before consent. Fonts (Bricolage Grotesque, Figtree, JetBrains Mono) are self-hosted from our origin. Google Analytics doesn’t load its gtag.js script until you opt into the analytics cookie category. Tawk.to doesn’t load until you opt into marketing. Cloudflare Turnstile is the one exception, because it gates the contact and abuse forms against bots and the legitimate interest basis is clear there. That last one is named in our privacy policy with its purpose.

5. Can your visitors actually exercise their data rights?

Article 15 says people have the right to access their data. Article 17 says they have the right to be forgotten. Article 20 says they have the right to take their data with them.

In practice, “they have the right” and “you can do it” are different things. A lot of privacy policies describe these rights in detail and then provide no working mechanism for actually exercising them. The “contact us” email goes to a black hole. The “data export” button doesn’t exist. The 30-day deletion window starts the clock from a request that nobody at the host is actually monitoring.

How to verify: send a test data-subject request to the host’s listed privacy address. A real GDPR-aware host responds within five business days with either the data or a clarifying question. A theatrical host responds with a templated form letter or doesn’t respond at all.

Our answer: our contact page routes data-subject requests to the same address as legal correspondence, with a 30-day deletion enforcement window documented in the privacy policy. Honest caveat: we’re a small team. If you’re testing the response time on a Sunday, expect the reply Monday. But the address is real, the process is documented, and we keep an audit log of every request we receive.

The honest bottom line

A truly GDPR-compliant hosting setup is not a marketing tier you buy. It’s the result of:

• Choosing a host that physically operates EU/EEA datacenters and lets you stay inside one
• Verifying their sub-processor list in writing, with countries and data types
• Inspecting their cookie banner defaults (not just reading their privacy policy)
• Opening dev tools and confirming nothing third-party fires before consent
• Sending a test data-subject request before you commit

Any host that survives that five-step test is doing the work. Most don’t. We’re the first to admit we caught one of our own gaps this week and patched it before publishing. That’s the posture. Not “perfectly GDPR compliant from day one,” but “willing to be audited in public, willing to fix what we find.”

Where we go from here

A few things we know we still want to improve, in case the auditing is mutual:

• The Cloudflare Turnstile dependency for forms is a US-based sub-processor. We’ve evaluated EU-based alternatives (hCaptcha has EU servers, Friendly Captcha is German-built) and will report back on whichever we move to.
• The ipapi.co geolocation call on product pages is US-based and disclosed in the privacy policy, but we’d rather use an EU provider. On the list.
• We’re in active evaluation on self-hosting our analytics on our own EU infrastructure (Matomo on a Cloud Server in Falkenstein or Amsterdam) to remove the Google Analytics dependency entirely, even for visitors who opt in.

None of these are deal-breakers under the current setup. They’re the next round of small improvements that compound into a stronger posture over time.

If you’ve read this far

You probably have a real GDPR question that needs answering. Email us. We’ll send you our current sub-processor list, the executed DPA, and answer specific compliance questions with named tools and named jurisdictions. No marketing brochure, no “trust us,” no theatrical certifications. Just the actual paperwork.

If you’ve already decided you want EU residency: pick a Frankfurt or Amsterdam datacenter when you deploy, and we’ll keep your primary, backups, and snapshots inside the same region. Free migration from your current host is included; the migration team will handle the DNS and email cutover.

We’re a hosting company. We can’t certify ourselves GDPR-compliant, and neither can anyone else. What we can do is show our work, fix what we miss, and write articles like this one when something deserves to be said out loud.