EU SaaS Compliance on Hetzner: What the Law Actually Requires

You’re an EU founder. Your SaaS runs on Hetzner. You store user email addresses, process user data as part of the product, and send transactional and product emails. What does EU law actually require of you?

This post gives concrete answers: which articles apply, what they oblige you to do, and what to put in place. It skips edge cases that don’t apply to you, and it won’t tell you to “consider engaging a DPO” unless you actually need one.

Not legal advice. I am not a lawyer. Nothing in this post constitutes legal advice, and you should not rely on it as such. This is my personal reading and interpretation of publicly available law and official guidance, informed by what regulators, legal commentators, and practitioners have published, but filtered through a non-lawyer’s understanding. EU data protection law is complex, national implementations vary, and your specific situation may have details that change the analysis entirely. If you are making compliance decisions with real legal or financial consequences, consult a qualified data protection lawyer or DPO in your jurisdiction.

What you are under GDPR

You are a data controller under GDPR Article 4(7). You determine the purposes and means of processing your users’ personal data. This is not optional: the classification follows from the facts, not from what you put in a privacy policy.

Your users’ email addresses are personal data under Article 4(1). Everything you do with them – collecting, storing, using them to send emails, sharing them with a third-party email provider – is “processing” under Article 4(2). GDPR applies to all of it.

Hetzner and your email service provider are data processors under Article 4(8). They process personal data on your behalf, under your instructions. This has a specific legal consequence covered below.

The obligations point at you, and stay there. A processor can carry out the work, but it cannot carry the duty.

The lawful basis for each processing activity

GDPR Article 6 requires a lawful basis for every processing activity. You need to identify one for each distinct thing you do with user data. Guessing at a single catch-all basis is a common mistake. At a glance:

What you’re doing	Lawful basis	Separate consent?
Running the account, authenticating, delivering the service	Art 6(1)(b) - contract	No
Transactional email (password reset, receipt, alerts)	Art 6(1)(b) - contract	No
Product email about a feature they already use	Art 6(1)(f) - legitimate interests	No (document a brief LIA)
Marketing / promotional email	Art 6(1)(a) - consent + ePrivacy	Yes - prior opt-in

The detail behind each row:

Account creation and service delivery. Your users give you their email address to create an account and use the product. Processing this data to operate the account, authenticate the user, and deliver the service they signed up for is covered by Article 6(1)(b): processing is necessary for the performance of a contract to which the data subject is party. No consent needed. No separate opt-in. They accepted terms and signed up; that’s the contract.

This basis covers: storing the email address, using it for login/authentication, storing whatever data they create or upload as part of using the SaaS, and using their data to provide the features they’re paying for.

Transactional emails. Emails sent because the user took an action or something happened to their account – password reset, email verification, subscription renewal confirmation, payment receipt, alert that their data export is ready – are covered by Article 6(1)(b) for the same reason. These emails are part of delivering the service. No separate consent, no opt-in checkbox.

Product emails. This is the muddy one. Emails about your product – release notes, feature announcements, tips for using the service – sit at the boundary between Article 6(1)(f) (legitimate interests) and regulated marketing communications.

Article 6(1)(f) allows processing where it is necessary for the purposes of legitimate interests pursued by the controller, provided those interests are not overridden by the interests or fundamental rights of the data subject. For an existing customer relationship, sending relevant product communications about the service they’re actively using is generally supportable under legitimate interests. You should document a brief legitimate interests assessment (LIA): not an elaborate document, but a record that you considered the three-part test: purpose test (is the interest legitimate?), necessity test (is processing necessary?), balancing test (do the user’s interests override yours?). The EDPB’s Guidelines 1/2024 on legitimate interests walk through this test in detail and are the authoritative reference. The ICO’s legitimate interests guidance is more concise and practical as a first read, despite being UK-focused; the three-part test is identical.

This does not extend to promotional emails about other products, upsell campaigns, or anything that crosses into commercial marketing.

Marketing emails. If you send promotional emails – discount offers, cross-sell campaigns, affiliate promotions – you need explicit prior consent under both GDPR Article 6(1)(a) and the ePrivacy Directive (Directive 2002/58/EC), Article 13. This means an opt-in at the point of collection, separate from terms of service acceptance, and a genuine choice. Pre-ticked boxes are not valid consent under GDPR Recital 32.

The practical line: “here’s what’s new in the product you use” = legitimate interests. “Here’s a special offer on our premium plan” = consent required. Most product emails from a SaaS to an active user are defensible as legitimate interests. Treat anything that could be read as a sales pitch with the consent standard.

One narrow exception is worth knowing before you conclude that every promotional email needs fresh consent. Article 13(2) of the same directive, the so-called soft opt-in, lets you send direct marketing for your own similar products or services to an existing customer whose address you obtained in the context of a sale, provided you gave them a clear, free way to refuse at the point of collection and repeat that offer in every message. Where it applies, the GDPR side is typically legitimate interests rather than consent (Recital 47 names direct marketing as a possible legitimate interest). But all of its conditions have to hold, and member states read them narrowly: a free signup is generally not a sale, Germany’s transposition applies the conditions strictly and cumulatively, and France’s CNIL interprets “similar products” tightly. If you plan to rely on it, record which national rules apply to your recipients and be certain the opt-out was genuinely offered at collection. For everyone else, opt-in remains the safe default: it is valid in every member state and requires no analysis of what counts as similar.

The DPA with Hetzner

Article 28 requires that when you engage a processor (which Hetzner is) you have a written contract covering specific requirements. This is called a Data Processing Agreement (DPA), or in German, an Auftragsverarbeitungsvertrag (AVV). You cannot legally use Hetzner to store or process personal data without one.

Hetzner provides their standard DPA through their customer portal. You conclude it once, for Cloud and Robot alike, in the central account portal at accounts.hetzner.com/account/dpa; agreeing is a checkbox, with no signature required. Accept it. This is a minutes-long administrative task, not a negotiation; they have a standard agreement that meets Article 28 requirements.

The DPA covers Hetzner’s obligations: processing only on your instructions, confidentiality, security measures, sub-processor management, assistance with data subject requests, and deletion of data at termination. Their listed sub-processors are documented in the agreement and on their website.

One thing the tier does not change: Cloud or Robot, shared-vCPU or dedicated, the Article 28 obligation is identical and so is your legal exposure. What does differ between them is how Hetzner could technically reach your data – and that turns out to be an Article 32 question, not an Article 28 one. It’s covered under security measures below.

The DPA with your email provider

Every email you send goes through a third-party SMTP provider. That provider receives email addresses and sometimes message content. They are a processor under Article 28, and you need a DPA with them too.

Use an EU-incorporated provider. If your email provider is incorporated in the US, you face an international data transfer obligation under GDPR Chapter V (Articles 44-50). This requires either an adequacy decision for the destination country, Standard Contractual Clauses, or Binding Corporate Rules. The US does not have a general adequacy decision; the EU-US Data Privacy Framework covers only US companies that have self-certified under the programme. This isn’t insurmountable, but it adds documentation overhead and carries ongoing legal risk given the track record of adequacy decisions being challenged.

EU-incorporated email providers eliminate this problem entirely. Brevo (formerly Sendinblue) is incorporated in France and processes email on EU infrastructure. Mailpace is a reasonable alternative, with the caveat that it’s incorporated in the UK – not an EU member state, though the UK GDPR adequacy decision means transfers are currently permitted (worth monitoring). Both offer standard DPAs that you can accept through their dashboard. Check the corporate chain rather than the brand – and then check it again in a year. Mailjet still reads as French. It was bought by US-based Mailgun in 2019, and Mailgun was itself bought by Sweden’s Sinch in 2021. So the correct transfer analysis for Mailjet was one thing in 2018, a different thing in 2020, and a third thing today, and nobody emailed you on either occasion. This one happens to have landed back inside the EU. The next one might not, and you will find out by looking.

The DPA acceptance process with these providers is similar to Hetzner: find it in account settings, accept, done.

Privacy notice under Article 13

Article 13 requires that you provide specific information to data subjects at the time their data is collected. This means at account signup. The information you must provide:

• Identity and contact details of the controller: your company name and address, or your personal details if you’re operating as an individual.
• Contact details of the DPO, if you have one. See below on whether you need one.
• Purposes and legal basis for each processing activity. Not a vague “to provide our services”, but the specific purposes (account management, service delivery, product communications) and the specific basis (Article 6(1)(b) for service delivery, Article 6(1)(f) for product emails, Article 6(1)(a) for marketing if applicable).
• Legitimate interests pursued, where that’s your basis. Brief description of the interest and the balancing assessment.
• Recipients or categories of recipients: Hetzner, your email provider. You don’t need to list individual employees.
• Transfers to third countries, if any. If you’re using only EU processors, state that explicitly.
• Retention period, or the criteria used to determine it. “We retain your data for the duration of your account, plus 30 days after deletion to allow for recovery, and billing records for 7 years as required by applicable tax law” is the kind of specificity required.
• Data subject rights: the right to access (Article 15), rectification (Article 16), erasure (Article 17), restriction (Article 18), data portability (Article 20), and objection (Article 21). Plus the right to withdraw consent where consent is the basis, and the right to lodge a complaint with a supervisory authority.

This goes in your privacy policy, which must be linked at the point of data collection: the signup form, not buried in a footer that’s three clicks away from where the user enters their email.

Data subject rights you must handle

Users have enforceable rights that you must be able to fulfill within one month of a request (Article 12). The practical requirements:

Access (Article 15): A user can ask what data you hold about them. You must provide a copy. For a SaaS, this means being able to export everything associated with a user account: their profile data, their content, their email address, activity logs if you store them. If your schema makes this difficult to produce, that’s a technical debt that’s now a legal obligation.

Erasure (Article 17): A user can request deletion of their data. You must comply unless you have grounds for retention (legal obligation, public interest, establishment of legal claims). For a cancelled account, “we need to keep this for 30 days for recovery” is supportable. “We keep it indefinitely for analytics” is not. Build an account deletion process that actually deletes the data, and document what you retain and why.

Portability (Article 20): Where your processing is based on consent or contract and carried out by automated means, users can request their data in a structured, commonly used, machine-readable format. JSON or CSV export of their account data satisfies this. This only applies to data they provided to you, not derived data you generated about them.

Objection (Article 21): Where you’re relying on legitimate interests, users can object. You must stop processing unless you can demonstrate compelling legitimate grounds. Direct marketing is the exception to that exception: under Article 21(2) an objection to marketing is absolute. There is no balancing test and nothing to weigh – they object, you stop. For product emails, that means a working unsubscribe mechanism that actually stops the emails and is honored promptly.

Two more round out the set, and both are usually cheap in a SaaS. Rectification (Article 16) is a user telling you their name is spelled wrong – an editable profile page satisfies most of it. Restriction (Article 18) is the ability to freeze processing while something is contested, rather than deleting it: in practice, a flag that keeps the record but takes it out of use.

So: a way to receive these requests (an email address is fine), a documented process for handling them (a simple internal runbook is enough), and the technical capability to actually fulfill them.

Records of processing activities

Article 30 requires maintaining a record of processing activities. There’s an exemption for organisations with fewer than 250 employees, but it doesn’t apply if the processing “is not occasional.” For a SaaS that continuously processes user data as part of its core function, the processing is not occasional. The exemption doesn’t apply to you.

The record doesn’t have to be elaborate. The ICO’s records of processing guidance covers what a ROPA should contain. A document (a spreadsheet or an Outline page) with the following is sufficient:

• Name and contact details of the controller
• Purposes of the processing
• Categories of data subjects (your users)
• Categories of personal data (email addresses, user-generated content, usage data)
• Categories of recipients (Hetzner, email provider)
• Where applicable, transfers to third countries (and the safeguards, if any)
• Envisaged time limits for erasure
• General description of technical and organisational security measures

Two or three rows in a table (one for account/service data, one for email communications) is a complete ROPA for a simple SaaS. Its real value is as evidence that you’ve thought through your processing rather than stumbled into it.

Most of that list should look familiar, because it is mostly the same information as your Article 13 privacy notice: controller, purposes, recipients, transfers, retention. The two documents differ in who they are written for – your users, and a regulator who asks – rather than in what they are about. Gather the facts once and write them into both.

Security measures under Article 32

Article 32 requires “appropriate technical and organisational measures” to ensure a level of security appropriate to the risk. The regulation does not mandate specific measures, but specifies factors to consider: the state of the art, the costs, the nature of the data, and the risks. For a SaaS holding email addresses and user-generated content rather than special-category data like health records, that bar is not high: you are expected to take the obvious precautions competently, not to build a bank’s security programme.

Appropriate measures for your context:

• Encryption in transit: TLSTLSThe encryption behind the padlock in your browser - it scrambles data traveling between a visitor and your server so nobody in between can read it. (It’s the ‘S’ in HTTPS.) for all HTTP connections (Caddy handles this automatically with automatic certificate renewal). Also TLS for connections between your application and your database.
• Encryption at rest: no Hetzner tier encrypts your disk by default, and on every one of them Hetzner has a technical path to it. This is the measure worth your attention, and the reason is below.
• Access control: Limit who can access production systems. Two-person team with shared root credentials is not appropriate. Use SSH keysSSH keysA pair of cryptographic files that log you into a server in place of a password - far harder to guess or steal, and the standard way to secure remote server access. , not passwords. Administer the server through a non-root account with sudo and disable root SSH login (PermitRootLogin no): root is the account attackers try first, and a per-person sudo account gives you an audit trail that a shared root login can’t. Authentik or similar for SSO to internal tooling.
• Backups: Automated, and – the part everyone skips – restored at least once, so you know the restore works. Article 32(1)(c) asks for the ability to restore personal data in a timely manner; it says nothing about your ability to take a backup. Then match the copy’s distance to the failure you’re insuring against. On the same server, it survives you dropping the wrong table but not a dead disk. In the same Hetzner account, it survives the dead disk but not an account that gets compromised, or suspended over a billing dispute. Only a copy under separate credentials – ideally at a second provider – survives that. And turn on object lock, so that an attacker who does get your keys can’t delete the backups along with everything else.
• Logging: Retain application and infrastructure logs sufficient to reconstruct what happened after an incident.
• Dependency management: Track your dependencies and apply security updates promptly. Running a version with a known critical CVECVEA publicly catalogued security flaw with an ID number (like CVE-2024-1234). ‘A known CVE’ means the weakness is public - so attackers may already be probing for it. is a specific Article 32 failure you’d need to explain to a supervisory authority after a breach.

Why encryption at rest is the one to spend time on. Hetzner Cloud VMs run on shared KVM hypervisors that Hetzner operates. They can attach your volume, snapshot it, or boot it into rescue mode – and that is true on a dedicated-vCPU tier (CCX) exactly as much as on a shared one (CX/CPX/CAX). “Dedicated vCPU” only means your cores aren’t time-sliced with other tenants for performance consistency. It says nothing about isolation from the host operator, and reading it that way is the most common mistake on this page.

Bare metal doesn’t close the door either. Robot, Hetzner’s actual dedicated-hardware product, has no shared hypervisor at all – which is confusingly the opposite of what “dedicated” suggests if you’ve only met Cloud’s CCX line. But Robot ships a rescue system Hetzner can boot the machine into from their own panel, and that reaches an unencrypted disk without anyone going near the hardware.

Two traps: "dedicated vCPU" buys performance, not isolation -- and bare metal still has a rescue system you don't control.

So the tier is not the lever. What gets you a defensible Article 32 position is disk encryption whose keys you hold, kept somewhere the disk itself doesn’t reveal, plus tight database access control and an audit trail. It is also, as the next section but one explains, the single measure that can excuse you from telling your users about a breach at all.

Document these measures. A half-page description in your ROPA or a separate security policy is enough for a small team. What you’re creating is evidence that you made deliberate choices, not proof that your security is perfect.

Breach notification under Article 33

If you experience a personal data breach – unauthorized access, accidental disclosure, loss of availability – you must notify your national supervisory authority within 72 hours of becoming aware of it under Article 33, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The 72-hour clock starts when you know enough to assess that a breach has occurred, not when you know the full details.

The notification must include: the nature of the breach, the categories and approximate number of affected data subjects, the categories and approximate number of personal data records, the likely consequences, and the measures taken or proposed to address it. You can provide information in phases if the full picture isn’t available in 72 hours.

If the breach is likely to result in high risk to individuals – their data was exfiltrated and could be used for fraud or identity theft – you must also notify the affected users without undue delay under Article 34.

Article 34(3) gives three ways out of that second notification, and the first is why disk encryption keeps coming up in this post. If the data was rendered unintelligible to whoever took it – encrypted, and they didn’t take the keys along with it – you generally don’t have to tell the individuals at all. The other two: you’ve since taken measures that mean the high risk is no longer likely to materialise, or telling everyone individually would take disproportionate effort, in which case you make a public communication instead.

Read that carefully, because it’s the part people get backwards. An Article 34(3) exemption spares you the call to your users. It does not spare you the call to the authority – the 72-hour clock under Article 33 runs either way, encrypted or not. And the authority can still order you to tell the individuals anyway under Article 34(4). Encryption buys you a great deal here. It does not buy you silence.

Which is also the practical argument for holding your own keys, and for keeping them somewhere the person who walked off with the disk could not reach. An encrypted volume whose key sits unencrypted on the same host has bought you nothing at all.

Encryption can excuse you from telling your users. It never excuses you from telling the regulator.

Know which supervisory authority covers you before a breach happens: competence follows where your company is established, not where your servers sit. If you’re incorporated in one EU member state, that’s your lead supervisory authority under the one-stop-shop mechanism. A full list of national authorities is on the EDPB members page. In Germany, the competent authority for a private company is the data protection authority of the Land where it’s established (for example the BayLDA for Bavarian companies), not the federal BfDI. For France, it’s the CNIL. For Ireland, the DPC.

Do you need a Data Protection Officer?

Article 37 requires a DPO in three situations: you’re a public authority, your core activities require large-scale, regular, and systematic monitoring of individuals, or your core activities consist of large-scale processing of special categories of data (health, biometrics, political opinions, etc.).

A SaaS that stores email addresses and user-generated content and sends product emails does not trigger any of these. Many small EU SaaS companies appoint one voluntarily or because a consultant suggested it; it’s not required and not worth the overhead at an early stage.

Does NIS2 apply?

The NIS2 Directive (Directive 2022/2555), transposed into national law by October 2024, applies to “essential entities” and “important entities” in specified sectors. The size threshold for most “important entity” categories is medium enterprises: at least 50 employees, or over €10 million in both annual turnover and balance-sheet total.

If you’re below both thresholds, NIS2 almost certainly does not apply to you as a direct regulatory obligation. The notable exception is companies in certain sectors regardless of size (DNS providers, TLD registries, trust service providers, specific critical infrastructure), which are probably not you.

The indirect implication of NIS2 is more likely to be relevant: if your customers are NIS2 entities, they will flow down supply chain security requirements to their ICT providers. Your enterprise customers may ask for evidence of security measures even if you’re not directly in scope. The security documentation from Article 32 compliance covers most of what they’ll ask for.

What you don’t need

To be explicit about what this situation does not require:

• Cookie consent banners for cookies that are strictly necessary for the service to function (session cookies, authentication tokens). The ePrivacy Directive requires consent for non-essential cookies: analytics, advertising, tracking. If you’re not running analytics or ad tracking, you don’t need a cookie banner, whatever a consent plugin’s default settings suggest.
• An EU representative under Article 27. That requirement applies to controllers established outside the EU.
• ISO 27001 certification to be compliant. Article 32 requires appropriate measures, not certification. Certification is a way of demonstrating those measures to enterprise customers, not a legal prerequisite.

The actual checklist

Everything above condenses to this:

1. Sign Hetzner’s DPA through your account portal.
2. Choose an EU-incorporated email provider (e.g. Brevo) and accept their DPA.
3. Document your lawful basis for each processing activity (Article 6): account management = Art 6(1)(b); product emails = Art 6(1)(f) with a brief LIA; marketing = Art 6(1)(a) with opt-in.
4. Write a privacy notice containing all Article 13 information; link it at signup.
5. Create a ROPA (Article 30): a simple document listing your processing activities, data categories, recipients, and retention periods.
6. Document your security measures (Article 32): encryption in transit, encryption at rest with a key you hold and Hetzner doesn’t, access controls, a backup you have actually restored at least once, update policy.
7. Set up a way to receive and fulfill data subject requests: access (Art 15), erasure (Art 17), portability (Art 20), and objection (Art 21) – which for most SaaS means an unsubscribe link that genuinely stops the emails.
8. Know your supervisory authority (EDPB members list) and their breach notification portal before you need it (Art 33).

The paperwork really is small. Two DPAs, a lawful-basis note, a privacy notice, and a ROPA that fits in a spreadsheet – a week or two of admin, and anyone quoting you a six-month programme for it should be asked what the other five months are for.

The capability underneath the paperwork is not paperwork. Article 12 gives you one month to answer a request, which only helps if something can actually gather one user’s data out of your app tables, your logs, your billing provider and your support inbox, delete it when they ask, and leave a record that it did. Article 33 gives you 72 hours, which only helps if you find out at all. Those are engineering problems, and writing a document about them does not solve them. They also get harder every time you add a processor, an analytics tool, or a feature that touches personal data – which is to say, they get harder as the company succeeds.

And this is the floor for one specific situation: an EU-established SaaS holding email addresses and user content on EU infrastructure. Add health data, children’s data, employee records, automated decision-making, or a processor outside the EU, and the analysis changes. Nothing above is the whole of the GDPR. It is the part that applies to you today.

The documents take a fortnight. Keeping them true is the job.

Edited 2026-07-24. Two small corrections after a fact-check: GDPR Chapter V spans Articles 44 to 50, not 44 to 49, and Hetzner’s DPA is now concluded once in the central account portal at accounts.hetzner.com rather than separately in the Cloud and Robot interfaces. The marketing email section also gained a paragraph on the ePrivacy Article 13(2) soft opt-in for existing customers, which the original text passed over in favor of the blanket opt-in rule.

Edited 2026-07-27. Corrected the NIS2 size threshold: qualifying as a medium enterprise means at least 50 employees, or exceeding €10 million in both annual turnover and balance-sheet total – not €10 million in turnover alone.