GDPR-Compliant Hosting Doesn't Exist. Here's What to Buy Instead.

“GDPR-compliant hosting” is a category error. Compliance is a property of your processing, not of a server you rent.

You can run flagrantly non-compliant processing on the most impeccably certified infrastructure in Europe, and nothing about the host will save you. What a host can do is give you four specific things you’d otherwise have to build or forgo. So we went and read their actual data processing agreements to find out who gives them.

The four things a host can actually provide

1. A data processing agreement you can sign — the Article 28 contract between you as controller and them as processor
2. A subprocessor list — who else touches the data
3. EU data location — a region you selected deliberately
4. Breach notification terms — what they tell you, and when

That’s the complete list. Everything else marketed as GDPR compliance is one of those four, or it’s yours.

What their DPAs actually say

We looked for each provider’s data processing agreement at its published URLs and read what we found.

Read that “not found publicly” column carefully. DPAs are frequently behind a login or supplied on request — Hetzner’s is concluded inside the customer account, which is arguably better than a public PDF. So the column measures public availability, not existence. It is not a score, and a provider missing from it may well hand you a perfectly good DPA the moment you ask.

The 72-hour SLA you’re looking for doesn’t exist

This was the surprise. If you’re shopping for a breach notification SLA in hours, you will not find one, and that isn’t evasion.

GDPR’s 72-hour clock is the controller’s obligation — yours, to your supervisory authority, under Article 33(1). A processor’s obligation is to notify the controller “without undue delay”, and that’s the language both DPAs we read use, because it’s the language the Regulation uses.

So speed isn’t the differentiator. Content is — and here the two differ markedly.

Hostinger’s section 7.1 commits that on becoming aware of a Security Incident it will, without undue delay, notify the customer and take reasonable steps to mitigate, with section 7.2 adding an assistance obligation for the notifications you then have to make.

Kinsta’s clause goes further and lists what the notice must include — the dates and times of the breach, the basic facts underlying the discovery or the decision to investigate, and a description of the personal data involved, specifically or by data category.

That enumeration is worth more than an hour count. A notification that arrives in two hours saying “we had an incident” doesn’t let you assess risk or draft an Article 33 filing. One that arrives in a day with dates, facts and affected data categories does. Ask for the notice content, not the deadline.

The one genuinely differentiating extra

Hetzner publishes its technical and organisational measures as a separate document, and states that those TOMs are audited annually by TÜV Rheinland (i-sec GmbH), with the current audit report released to customers who have concluded a DPA.

That’s an independent, named, recurring third-party audit whose output you can actually obtain — which is a materially stronger assurance than a self-declared security page, and the most concrete thing we found across all six.

The parts nobody can sell you

Here’s where the compliance work actually lives, and all of it is yours.

Your logs contain IP addresses, and IP addresses are personal data. Every web server writes them by default, usually with no retention policy and no documented lawful basis. This is the most common and most overlooked processing on a self-managed server. Decide how long you keep access logs, write it down, and configure logrotate to enforce it. No host does this for you.

Your backups are a transfer. If your data sits in Frankfurt and your backups land in a bucket in Virginia, you have a third-country transfer regardless of where the primary lives. Check the backup destination separately from the server region — they’re configured separately and people assume they follow.

Support access is real access. When you open a ticket and grant access to debug something, a human reads your data. That’s legitimate and it’s also processing that your records should reflect. Ask where support staff sit and what their access controls are.

Cookies and analytics are entirely on you, and they’re where enforcement actually happens. Consent before non-essential cookies, and an analytics configuration that doesn’t ship identifiers to a third country without a basis. Far more GDPR enforcement has concerned tracking scripts than server locations — and no hosting purchase touches this. If you do one thing after reading this article, audit your tag manager rather than your data centre.

For the jurisdictional layer underneath all this — why an EU data centre run by a US company isn’t the same as an EU provider — see residency versus sovereignty, and what EU-only actually requires for the subprocessor axis in detail.

Questions to send a sales team

Copy this. The answers, or the absence of them, will tell you more than any certification badge.

1. Can you provide a data processing agreement under Article 28, and can I see it before purchasing?
2. Where is your subprocessor list published, and how will I be notified when it changes?
3. Which specific data centre will my data be in, and can I select it at signup?
4. Where are your backups stored, and is that the same jurisdiction as the primary?
5. On a personal data breach, what will you tell me, and what does your DPA commit you to include in that notice?
6. Where are your support staff located, and what access do they have to customer data?
7. Do you publish technical and organisational measures, and are they independently audited? Can I have the report?
8. Which entity will be named on my contract? — worth asking, because one provider in our testing contracts through a German entity on one domain and a US entity on another.

Question 5 and question 7 are the ones that separate serious answers from marketing.

The providers

Hetzner — the strongest position of the six on this specific axis. A German GmbH, a published DPA you can conclude yourself inside your account rather than negotiating, a separate published TOM document, and TOMs audited annually by TÜV Rheinland with the report available once you have a DPA in place. €19.99 for 4GB on the CPX line plus €0.50/month for IPv4. It sells US regions too, so choose your location deliberately.

IONOS — genuinely European and the best value per core here at four vCores and 4GB for around $11. We could not locate a public DPA, so add question 1 to your list. And check which entity your invoice names — the German site’s imprint says IONOS SE, the .com’s says IONOS INC.

Hostinger — publishes its DPA openly at /legal/dpa, with a defined Security Incident, a “without undue delay” notification and assistance obligation, an explicit subprocessor section, and a Sensitive Data definition. The most transparent documentation of the cheap providers, at $11.99 renewal for 4GB. Its privacy policy is candid that some servers sit outside the EEA, so select an EU region.

Liquid Web — the fully-managed end, where you’re buying an operations team. We could not find a public DPA, which for a managed provider is worth pressing on, because managed support implies broader routine access to your data than unmanaged hosting does. Ask questions 1, 5 and 6 before signing.

Kinsta — publishes the most specific breach notification clause we read, enumerating the dates and times, the underlying facts and a description of the affected data categories. Managed WordPress at a premium, with a $0.50 per 1,000 visits overage that’s the gentlest in that category. If your GDPR concern is what happens on a bad day rather than what a badge says, this is a genuinely good signal.

Nexcess — managed hosting in the same family as Liquid Web. Its site blocked our automated requests entirely, so we could not assess its DPA position at all — that’s a gap in our research rather than a finding about the company, and we’d send it the full question list.

How we checked this

What we read, on 18 August 2026. Hetzner’s DPA is published as a PDF at hetzner.com/AV/DPA_en.pdf; that document references a separate technical and organisational measures document at /AV/TOM_en.pdf, a self-service DPA conclusion route at accounts.hetzner.com/account/dpa, a data-protection@hetzner.com contact, and states that its TOMs are audited annually by TÜV Rheinland (i-sec GmbH) with the current audit report made available after a DPA is concluded. We extracted that PDF’s text programmatically and the extraction was partial — the document’s embedded font encoding defeated a clean read — so we have not quoted Hetzner’s breach notification clause and have marked it unread rather than guessing at it.

Hostinger’s DPA at /legal/dpa and Kinsta’s at /legal/data-processing-agreement/ we read as rendered pages. The Hostinger material — the Security Incident and Sensitive Data definitions, sections 6.1 and 6.2 on authorised subprocessors, and section 7.1’s “without undue delay” notification and mitigation commitment with 7.2’s assistance obligation — and the Kinsta material, including its enumerated breach notice contents, are quoted or paraphrased from those pages.

The “not found publicly” entries are statements about our search, not about the providers. We probed conventional DPA URL patterns and the providers’ legal and policy index pages. A DPA behind a login or supplied on request is normal and not a deficiency — Hetzner’s own is in the customer account. We did not contact any provider’s sales team to request one, which is the obvious next step and precisely what the question list above is for. Nexcess returned HTTP 403 to every request we made, so it is unassessed rather than assessed poorly.

On the 72-hour point: that Article 33(1) places the 72-hour notification duty on the controller toward its supervisory authority, while a processor’s duty under Article 33(2) is to notify the controller without undue delay, is the structure of the Regulation. We are not lawyers and this is not legal advice — the reader-owned obligations section in particular describes common failure points rather than telling you what your basis or retention period should be.

What we did not do: hold accounts with any of these providers, sign or negotiate a DPA, obtain any audit report, verify that any audit took place, confirm where any support engineer sits, or review anyone’s subprocessor list beyond what we covered in the EU-only comparison. The claim that TOMs are audited annually by TÜV Rheinland is Hetzner’s own statement in its DPA, which we have not independently corroborated.

The host links above are affiliate links. The article’s central claim is that the product category in its title doesn’t exist, and its strongest practical advice — audit your analytics rather than your data centre, and set a log retention policy — costs nothing and earns us nothing.

FAQ

Is any web host GDPR compliant?

No host is compliant as a product, because compliance is a property of how you process personal data. A host can provide a data processing agreement, a subprocessor list, an EU data location and breach notification terms. The rest is yours.

What is a DPA and do I need one?

A data processing agreement is the Article 28 contract between you as controller and your host as processor. If your host processes personal data on your behalf — which it does the moment your site has visitors — you need one in place.

Do hosts guarantee breach notification within 72 hours?

Generally not, and the question is slightly misdirected. The 72-hour deadline is your obligation to your supervisory authority; a processor’s obligation is to notify you “without undue delay.” Ask what the notice will contain instead — one provider we read enumerates dates, times, underlying facts and affected data categories.

Do server logs breach GDPR?

Not inherently, but they contain IP addresses, which are personal data. What causes problems is keeping them indefinitely with no documented retention period or lawful basis. Set a retention policy and enforce it with logrotate.

Are my backups covered by my server’s location?

No — backup destination is configured separately and is a separate transfer question. Data in Frankfurt with backups in Virginia is a third-country transfer. Check it explicitly.

Which host has the best GDPR documentation?

Of those we could read, Hetzner: a published DPA you can conclude in your own account, a separate technical and organisational measures document, and TOMs it states are audited annually by TÜV Rheinland with the report available to customers.

What matters more than my choice of host?

Your cookie consent and analytics configuration. Far more enforcement activity has concerned tracking scripts than data centre locations, and no hosting purchase affects it.