GDPR, data residency and cloud costs for EU SMBs on Hetzner

Compliance and cost conversations rarely happen together. They should.

EU SMBs often choose cloud infrastructure under GDPR pressure, making costly decisions. Legal demands: "EU-only, sovereign provider if possible." DevOps spins up servers. Finance opens the bill later and wonders: Why is this higher? Why do we have three same environments when one would do? This post closes that gap.

The short version. The actual GDPR floor for a typical B2B SaaS on Hetzner Cloud is narrow: a signed Data Processing Agreement, encryption appropriate to the data's risk, a record of processing activities, and a 72-hour breach process. Most "compliance costs" on your invoice are actually architecture decisions driven by compliance anxiety: a redundant region, an idle standby, a snapshot retention policy with no audit basis. Know the difference. It separates a defensible architecture from an expensive one with gaps.

The legal framework is narrower than most compliance anxiety suggests. Under Article 28 of the General Data Protection Regulation, your cloud provider is a "processor", meaning it processes personal data on your instructions. That triggers one core obligation: a written, binding contract known as a Data Processing Agreement (DPA).

In cross-border cloud contracts, the English term DPA is standard (Auftragsverarbeitungsvertrag in Germany, umowa powierzenia in Poland, contrat de sous-traitance in France). Hetzner provides a standard GDPR-compliant DPA with an all-electronic signing process. Sign it directly in your Hetzner account at accounts.hetzner.com/account/dpa: fill in the data categories and subjects in the appendix, check a box, done. No PDF needed. This meets Article 28(9), which explicitly allows electronic form.

Article 32 requires "appropriate technical and organisational measures" (TOMs) proportionate to the risk. The article lists pseudonymisation and encryption as examples, not hard requirements. The Court of Justice of the EU reinforced this: appropriateness depends on the nature, scope, and context of your processing, and the practical effect of your measures, not a checklist.

For example, a SaaS storing business contact data needs less security than a clinical trial platform handling genetic records. The compliance question isn't "Did you encrypt?" but whether you can show:

risk assessed → control chosen → why enough → tested → documented

Hetzner's contribution to that chain is real but bounded. The company publishes its TOMs document as a DPA appendix. It also holds ISO/IEC 27001:2022 certification (covering its Nuremberg, Falkenstein, and Helsinki data centers) and BSI C5 Type 2 attestation. These cover physical access, operational security, identity management, and cryptographic controls for Hetzner's own employee access. You can cite them under Article 32(3) as evidence of the provider's security posture. But they do not encrypt your data at rest for you.

GDPR doesn't require a server in your home country. Storage anywhere within the EU/EEA is enough. Transfers within the bloc aren't "transfers" under Article 44; they need no separate legal basis.

The CLOUD Act: jurisdiction follows the company, not the server

The harder compliance risk isn't a missing DPA. It's jurisdiction.

The US CLOUD Act (2018) and FISA Section 702 allow US authorities to compel any US-controlled company to produce customer data, regardless of where that data physically sits. A server in Frankfurt, Dublin, or Stockholm on AWS, Azure, or Google Cloud remains reachable via a warrant served on the US parent. Microsoft has stated this directly in EU forums; AWS's own legal team confirms the same in its compliance documentation.

Jurisdiction follows the company, not the data center. This is the central asymmetry every EU SMB needs to understand before optimising further.

The EU-US Data Privacy Framework (DPF), adopted in July 2023, restored a lawful transfer mechanism for certified US recipients. On 3 September 2025, the EU General Court upheld its validity against a French challenge. The DPF makes transatlantic transfers easier to document. But it doesn't change the CLOUD Act or exempt controllers from running a Transfer Impact Assessment for non-EU providers. A further Schrems-style challenge before the Court of Justice has been signalled but, as of mid-2026, not lodged.

Hetzner Online GmbH is German-headquartered, privately held, and has no US parent. As a German entity, it falls under EU and German law, not the CLOUD Act or National Security Letters. That cuts the jurisdictional question off at the source for any data stored in Nuremberg, Falkenstein, or Helsinki.

Hetzner is transparent about its limits. Like any provider, it must comply with lawful requests from local authorities and cannot guarantee immunity from government access. Be sceptical of providers that claim otherwise.

One nuance for the non-EU regions: Hetzner now operates customer-facing infrastructure in Ashburn (Virginia), Hillsboro (Oregon), and Singapore. According to Hetzner's data protection notes, only data stored on a cloud server in those locations is transferred there. Hetzner continues to process its own customer master data inside the EU.

If your GDPR posture requires EU-only personal data storage, the answer is simple: do not provision instances in US or Singapore regions for personal-data workloads.

The same structural split shows up across the broader provider landscape:

Provider	Parent jurisdiction	EU regions	CLOUD Act exposure	Notable sovereignty certifications
Hetzner Cloud	DE, privately held	Nuremberg, Falkenstein, Helsinki	No	ISO/IEC 27001:2022, BSI C5 Type 2
OVHcloud	FR, listed	Multiple EU sites plus global footprint	No	SecNumCloud 3.2 (Hosted Private Cloud line), ISO 27001
Scaleway	FR, Iliad group	FR, NL, PL, IT (DE and SE planned)	No	SecNumCloud qualification in progress (started Jan 2025), ISO 27001, HDS
AWS / Azure / Google Cloud	US	Yes (Frankfurt, Dublin, etc.)	Yes, even when data sits in EU regions	ISO 27001 and similar; not SecNumCloud-eligible
AWS European Sovereign Cloud	DE legal entity, US parent	Germany (launched Jan 2026)	Yes, at parent level	ISO 27001; not SecNumCloud-eligible by design

Two EU-native peers stand alongside Hetzner. OVHcloud is the largest EU-native provider: French-listed, with a SecNumCloud-qualified offering for workloads requiring extraterritorial-law immunity. Scaleway is Iliad-owned, with an EU-only regional footprint and SecNumCloud qualification in progress since January 2025.

The line that matters is parent jurisdiction, not server location.

Where compliance anxiety produces bad architecture and cost

Compliance-driven decisions made without cost awareness create four recurring patterns.

Over-replication "just in case"

Teams provision parallel environments in two EU locations, say a primary in Falkenstein and a hot standby in Helsinki, and frame it as a GDPR requirement. It's not. A single EU location satisfies data residency.

Multi-location is an availability decision. The Article 32 risk assessment rarely produces a hard requirement for synchronous geo-redundancy in an SMB context.

The cost isn't from egress. Falkenstein, Nuremberg, and Helsinki all sit in Hetzner's eu-central network zone, and traffic between them is free. The cost comes from:

Doubled compute
Doubled block storage
Doubled IPs
Doubled snapshot footprint
The operational overhead of keeping two environments in sync

Refusing to use non-EU regions for legitimate non-personal workloads

Not every workload processes personal data. Static asset distribution, build pipelines, integration test fixtures, and ephemeral CI runners often touch nothing in Article 4(1) scope.

If lower latency to APAC users or cheaper capacity in Singapore makes sense for those workloads, GDPR does not block you; your data classification does.

A blanket "EU-only everywhere" rule wastes money. Without per-workload classification, engineers treat compliance as folklore, not analysis.

The encryption-at-rest gap, in both directions

Hetzner doesn't encrypt customer data at rest by default on Cloud servers, Volumes, Storage Box, or Object Storage.

The provider's TOMs document explicitly covers cryptographic protection for administrative access to infrastructure. But at-rest encryption of customer data is your responsibility:

LUKS / dm-crypt for Cloud server disks and Volumes
SSE-C for Object Storage
Application-side for sensitive columns

Two failure modes follow.

Some teams assume Hetzner encrypts what AWS encrypts by default. They ship without LUKS, then discover the gap during an audit and pay for an emergency rebuild and snapshot rotation.

Others over-correct and apply envelope encryption to every column in every table. That makes sense for a payment ledger. But on a Hetzner CCX fleet, it pushes you up a pricing tier to cover the crypto overhead, with no real compliance benefit.

The cure for both is the same: classify the data, decide the layer (block, filesystem, application), document the choice, implement once.

The "clean room" reflex: bare metal where a CX would do

Some interpret GDPR Article 32 as requiring physical isolation from other tenants, which would rule out shared virtualization. It's not actually required.

Multi-tenant virtualization with proper isolation underpins every compliant EU cloud deployment. An SMB SaaS storing customer contact data doesn't need dedicated hardware.

Hetzner's April 2026 price increase makes this trade-off concrete:

Instance	vCPU	RAM	Storage	Price (net/mo)
CX22	2 shared	4 GB	40 GB SSD	€3.99
CCX13	2 dedicated	8 GB	80 GB NVMe	€15.99
CCX23	4 dedicated	16 GB	160 GB NVMe	€31.49
AX41	8 dedicated	64 GB	2× 512 GB NVMe	~€48

If your workload is just two API services and a Postgres instance, paying €48/month for 8 dedicated cores and 64 GB RAM, when €3.99 or €15.99 would suffice, is a 3× to 12× tax. You're overpaying for "physical isolation" the risk assessment never required. And you lose hourly billing and rapid teardown.

Reserve dedicated hardware for cases that genuinely require it: regulated workloads with explicit physical-isolation findings in a DPIA, or performance profiles that need bare-metal NVMe throughput. Not as a default GDPR posture.

The common thread: confusing GDPR requirements with cautious-sounding architecture. The regulation is risk-proportionate by design. Treating it as absolute creates over-built systems that cost more but don't improve compliance.

Hetzner doesn't charge extra for compliance. Pricing is the same across Nuremberg, Falkenstein, and Helsinki for equal SKUs. Storing data in the EU eliminates the Standard Contractual Clauses and Transfer Impact Assessment overhead you'd face with US-based providers, even ones with EU regions.

What shows up on the bill in a compliance-conscious architecture reflects choices, not requirements:

Cross-zone egress is the only traffic line worth watching. Replication or backup that leaves eu-central for us-east, us-west, or ap-southeast is billed as standard outgoing traffic. Anything inside eu-central, or over a Cloud Network, is free.
Audit-log shipping to an external SIEM. "Trace-level logging for GDPR" is a common overcorrection. The cost typically comes from egress and SIEM ingestion, not Hetzner itself. Datadog, Splunk, and Elastic Cloud all have EU-hosted regions (typically in Frankfurt, Germany), so it's possible to ensure data residency. However, two costs remain:
- Egress and ingestion fees increase with the level of detail in the logs, regardless of where the SIEM stores the data.
- Choosing a US-based SIEM provider brings back the CLOUD Act issue you avoided by picking Hetzner.
Article 30 requires a record of processing activities, not full-fidelity query logs. Retention periods and log verbosity should match your actual incident response needs.
Snapshots and backups are billed as a percentage of the cost of the server. Teams often keep months of snapshots because "the DPO said audit trails." But an application audit log serves that purpose, not stacks of point-in-time disk images.

On the other hand, Article 17 states that erasure requests must eventually propagate into backups. For most SMBs, the practical solution is simple: set a documented backup retention window (for example, 30 days), then permanently delete records after that period. This is cheaper and more defensible than enterprise backup products promising selective purging of immutable snapshots.

For more on where Hetzner costs leak after removing compliance anxiety from architecture decisions, see Hetzner cloud costs you're probably missing.

Documentation is the actual compliance artefact

The most overlooked part of SMB GDPR posture isn't the infrastructure. It's the paper trail connecting your infrastructure to the regulation.

When a supervisory authority asks about your Hetzner deployment, they won't ask "Is it encrypted?" They'll ask: which GDPR Article did you assess? What risk did you identify? What control did you choose? Why did you consider it enough? And how do you know it still works?

That chain requires four documents and all are your responsibility as controller, not Hetzner's:

A Record of Processing Activities under Article 30, listing each processing purpose, the data categories and subjects, the retention period, the processors used (Hetzner, with the EU location specified), and any third-country transfers, along with their legal basis. In practice, the Article 30(5) exemption for organisations with fewer than 250 employees almost never applies; most SMB SaaS workloads are "not occasional," which invalidates the exemption.
A risk assessment for each processing activity, written down. For higher-risk processing, this becomes a full Data Protection Impact Assessment under Article 35. Both are where you justify your encryption layer choice, your backup retention, your access model, and your region selection, in writing, with reasoning.
An incident response procedure that names the people, the escalation path to Hetzner's abuse and security contacts, and the decision criteria for the 72-hour notification clock under Article 33. A controller that has to invent the procedure during the incident is already late.
A review cadence: who looks at all of the above on what schedule, and what triggers an out-of-cycle review (new processing activity, new sub-processor, breach, regulatory change).

You don't need expensive tooling for any of this. A versioned set of Markdown files in a private repository, reviewed quarterly, is enough. What matters is that your documents match what's actually deployed. RoPAs listing decommissioned servers, or DPIAs from three architectures ago, are worse than none. They prove you're not maintaining the process.

The compliance floor for a typical EU SMB on Hetzner Cloud

If you're running on Hetzner Cloud in Nuremberg, Falkenstein, or Helsinki and processing personal data, your baseline obligations are:

DPA concluded in the customer account at accounts.hetzner.com/account/dpa, once per legal entity, with the personal-data categories and data subjects specified in the appendix.
Encryption in transit on every endpoint that handles personal data, with TLS 1.3 where the stack supports it. This is one of the few near-universal expectations under Article 32 in 2026.
Encryption at rest where the risk assessment calls for it, implemented by you (Hetzner does not provide it by default; see the encryption pattern above). Low-risk data with strong access controls may legitimately go without; for cloud disks, backups, and any sensitive or large-scale processing, encryption is hard to justify omitting. Document the reasoning either way.
Record of processing activities under Article 30, kept current. List Hetzner as a processor, the specific EU location used, the data categories, the retention periods, and any sub-processors you have engaged on top.
A risk assessment per processing activity (and a full DPIA where Article 35 thresholds apply), written down, that ties each technical control back to the risk it addresses.
Documented breach response that meets the 72-hour Article 33 notification window, names the escalation path to Hetzner's abuse and security contacts, and is rehearsed at least once a year.

That is the floor. Anything beyond it is a risk-proportionate business decision, not a hard GDPR requirement: more certifications, multi-region replication, application-layer encryption, sovereign-cloud premiums. None of it is required for a typical B2B SaaS workload.

The implication

Hetzner's EU-only company structure removes the hardest GDPR problem, extraterritorial jurisdiction. By design. There is no US parent to receive a CLOUD Act warrant. No Standard Contractual Clauses to maintain for intra-EU storage. No asymmetry between where your data sits and which legal system governs it.

For a typical EU SMB, the genuine compliance overhead on Hetzner is low.

The costs that surprise teams aren't compliance costs, but architecture decisions made under compliance anxiety, without anyone tracking what each line item is actually buying.

The fastest way to find them: look at the bill the same way you look at the data-flow diagram and the RoPA together. Per resource, per environment, per tag. Ask, for each, which processing activity it serves and which Article of the GDPR justifies its existence.

The line items that cannot be matched to either are the cheapest savings you will ever find. The line items that can be matched are now also documented, which is what an auditor was going to ask about anyway.