Search for "GDPR-compliant hosting" and every provider on the planet claims it. The phrase has become a badge on pricing pages rather than a verifiable property — which is a problem, because when your customer's DPO sends the vendor questionnaire, or a supervisory authority asks for your Article 30 records, "the website said GDPR compliant" is not an answer.
Here is the uncomfortable truth the badges skip: there is no official GDPR certification for hosting. Compliance is a set of concrete, checkable properties — where data lives, what the contract says, who can be compelled to hand it over, how it is protected, and what happens when you leave. This guide turns those properties into a ten-point checklist you can run against any provider in an afternoon, including us.
(Obligatory honesty: we are a hosting provider and this is our blog. Also, this is an engineering guide, not legal advice — your lawyer outranks our checklist.)
What GDPR actually asks of your hosting
When you store personal data with a hosting provider, you are the controller and the provider is a processor. Three clusters of obligations follow:
- Article 28 — you may only use processors that give "sufficient guarantees", and you must have a written contract (the Data Processing Agreement) covering instructions, confidentiality, sub-processors, deletion and audits.
- Article 32 — "appropriate technical and organisational measures": encryption, resilience, access control, tested backups.
- Chapter V (Articles 44-49) — transfers outside the EU/EEA need a legal mechanism: an adequacy decision, Standard Contractual Clauses plus a transfer impact assessment, or narrow derogations.
Every line of the checklist below traces back to one of those three.
The ten-point checklist
1. Data residency is named in writing
Not "EU-based infrastructure" in a marketing paragraph — a named country or region in the contract or DPA. "Germany" is checkable; "European data centers" can mean a London edge node. Verify: the DPA's processing-locations annex.
2. A DPA you can read before you sign up
A processor that makes you email sales to see the DPA is telling you something. It should be public, current, and self-service. Verify: find it on the website in under two minutes; check it covers Art. 28(3)'s required clauses.
3. A public sub-processor list with change notice
Your provider's providers are your problem — that is how GDPR works. You need the current list and advance notification of changes, with the right to object. Verify: the list exists, has dates, and names jurisdictions, not just company names.
4. Provider jurisdiction, not just server location
This is the one most checklists miss. The US CLOUD Act reaches any provider "subject to US jurisdiction" — including a US company's Frankfurt region. An EU data center owned by a US parent gives you EU latency, not EU jurisdiction. If jurisdictional isolation matters to your risk assessment, the provider's corporate ownership chain has to be European. We wrote a full analysis in our CLOUD Act guide. Verify: the commercial register, not the marketing site.
5. A transfer mechanism for whatever still crosses
If any component (support tooling, analytics, a CDN) processes data outside the EU/EEA, there must be a mechanism: adequacy, or SCCs plus an assessment. The EU-US Data Privacy Framework currently covers certified US companies, but its two predecessors (Safe Harbor, Privacy Shield) were both struck down in court — build your architecture so that a third strike is a news item, not an incident. Verify: the DPA's transfer section; ask which sub-processors rely on DPF.
6. Encryption in transit and at rest, by default
TLS on every endpoint (including database and object-storage endpoints, not just the dashboard) and encryption at rest on disks and backups. "Available on request" is not "by default". Verify: connect and inspect; ask where at-rest encryption applies.
7. Backups and replicas live where the data lives
Residency includes every copy: backups, snapshots, read replicas, log archives. A German primary with backups replicated to a US region fails the checklist retroactively. Verify: ask specifically "where are backups and logs stored?" — it is the question that exposes the most badge-compliance.
8. Deletion that actually deletes
Article 28(3)(g): at the end of the service, data is deleted or returned. Practically: you can export your data in standard formats, destroy instances yourself, and the DPA commits to post-termination deletion of remnants including backups within a stated window. Verify: delete a test resource; read the retention clause.
9. Breach notification that respects your 72 hours
Your Article 33 clock starts when you become aware. The processor must commit to notifying you "without undue delay" — and a named channel beats a promise. Verify: the DPA's incident section; is there a security contact and a status page?
10. Access control worthy of the data
Two-factor authentication (ideally passkeys), scoped API tokens, team roles, and an audit trail of who did what. Your provider dashboard is the master key to everything above. Verify: can you enforce 2FA for your whole team? Can an API token be limited to one project?
Three misconceptions that survive every year
- "We picked the Frankfurt region of a US hyperscaler, so we are covered." Region selection addresses latency and residency, not jurisdiction (point 4). It can be a perfectly reasonable, defensible choice — but it is a documented risk-acceptance, not a non-issue.
- "Our host is GDPR-compliant, so our app is." Hosting is one processor relationship. Your cookie banner, your analytics, your marketing pixels, your log retention and your consent flows remain entirely yours. Compliant infrastructure is the floor, not the finish line.
- "GDPR-certified hosting" does not exist as an official scheme. Art. 42 certifications are slowly emerging for specific services; ISO 27001 and SOC 2 speak to security process, which helps Art. 32 — but no logo replaces the checklist.
Where DanubeData stands, point by point
We built DanubeData to make this checklist boring to complete: a Romanian company — EU jurisdiction end to end, no US parent — running services from data centers in Falkenstein, Germany, with a self-service DPA you can read before creating an account. Backups and snapshots stay in the EU alongside the services they protect. TLS is on by every default; accounts support two-factor authentication and passkeys; API tokens are scoped. Our sub-processor list is short by design and published with the DPA.
If you are evaluating by product, we keep per-service deep dives: databases, static sites, serverless containers, message queues and file sharing. For the wider landscape, see European cloud providers compared and European alternatives to AWS, GCP and Azure.
Run the ten questions against your current provider this week. If any answer is a marketing page instead of a document, you have found your risk register's newest entry — and if you would rather the answers just be yes, DanubeData takes about two minutes to try.
