Host Your App GDPR-Compliant in the EU: a Checklist

The European Court of Justice's Schrems II ruling from July 2020 shook a basic assumption behind many infrastructure decisions: that it's enough to keep your data somewhere in Europe. Since then the legal situation has become more complicated, and anyone who doesn't look closely at their cloud provider can quickly end up in a compliance grey zone.

This article explains what the ruling actually means, why the topic still isn't settled in 2025, and gives a practical checklist for developers and DevOps teams who need legally sound cloud hosting in the EU.

What Schrems II means and why it's still relevant

At its core, the ECJ found that the Privacy Shield agreement between the EU and the US at the time did not guarantee adequate data protection. US intelligence agencies have far-reaching access rights to data held by US companies, and those access rights override European data protection standards.

Privacy Shield was history. Since then, data transfers to the US have only been possible on the basis of Standard Contractual Clauses (SCCs), and even then only when a case-by-case assessment confirms that the recipient country offers an equivalent level of protection. For the US, that's hard to affirm.

The Data Privacy Framework and its weaknesses

In July 2023, the EU-US Data Privacy Framework (DPF) came into force, intended as the successor to Privacy Shield. It contains stronger restrictions on US intelligence access and a complaints mechanism for EU citizens.

The problem: privacy activists, above all Max Schrems, consider the DPF structurally inadequate. A new lawsuit has been announced. Anyone making an infrastructure decision today based on the DPF should factor in that this agreement could be struck down again in a few years, just as happened with Safe Harbor (2015) and Privacy Shield (2020).

The CLOUD Act as a structural problem

Even if a US company runs its data center in Frankfurt, that changes nothing about one central fact: the CLOUD Act of 2018 allows US authorities to require US companies to hand over data, regardless of where that data is stored.

This means: anyone using AWS, Azure or Google Cloud doesn't have full control over who can access their data and under what circumstances — the conflict between the CLOUD Act and GDPR puts them between two legal systems. For many use cases that's not a problem. For others, in healthcare, in public administration, in the financial sector, or anywhere sensitive personal data is processed, it is.

Why an "EU data center" alone isn't enough

A common misconception: "Sure, we use AWS, but the region is eu-central-1, so Frankfurt. That's GDPR-compliant."

That's not quite right. The location of the data center is just one factor of several — data residency is not data sovereignty. What matters:

• The provider's company headquarters: if the provider is a US company, the CLOUD Act applies, no matter where the servers stand.
• Ownership structure: if the European provider has a US parent company, that parent can be used as a lever.
• Access by subprocessors: is data passed to US companies through tools, monitoring services or support processes?

When a provider is genuinely European

For data protection purposes, a provider can be classified as "European" when:

1. It is based in the EU.
2. No US parent company or material US subsidiary exists through which CLOUD Act access would be possible.
3. All subprocessors also meet these criteria, or at least operate under a valid transfer mechanism.
4. The provider signs a Data Processing Agreement (DPA) under Art. 28 GDPR.

This is not a theoretical exercise. During a GDPR review or an audit, these exact points get checked.

The checklist – legally sound cloud hosting in the EU

Here's a structured checklist you can use for your hosting decision. For the wider picture beyond GDPR, see our sovereign cloud checklist and our comparison of sovereign cloud providers in Germany.

Choosing a provider

• Provider has its headquarters in the EU
• No US parent company or US majority stake
• All subprocessors in use are documented and GDPR-compliant
• Provider signs a DPA under Art. 28 GDPR
• Certifications in place (e.g. ISO 27001, BSI C5, SOC 2 – the latter only as a supplement)
• Data centers are physically located in the EU

Contracts

• The DPA is current, complete and signed by both parties
• If SCCs are used: a Transfer Impact Assessment (TIA) is documented
• The subprocessor list is available in the DPA or as an annex and is updated when changes occur
• The contract contains clear rules on deleting data after the contract ends

Technical measures (TOMs)

• Encryption of data in transit (TLS) and at rest (e.g. AES-256)
• Access control: only authorized people and services can access production data
• Logging and monitoring: access to sensitive data is logged
• Backup strategy: backups stay within the EU and are subject to the same access controls
• Incident response process: data breaches are reported within 72 hours (Art. 33 GDPR)

Documentation

• The Records of Processing Activities (RoPA) is current and includes all cloud services
• A Data Protection Impact Assessment (DPIA) has been carried out where required (Art. 35 GDPR)
• The checklist is reviewed regularly – at least annually or when switching providers

Kubernetes and DaaS: what to watch for when choosing a platform

For teams running container-based applications, the choice of Kubernetes operator is especially relevant. Managed Kubernetes services from US hyperscalers, EKS, AKS, GKE, offer a lot of convenience, but they also carry the legal risks described above.

European Kubernetes-DevOps-as-a-Service providers close this gap: they offer similar abstraction layers and operational convenience, but run the infrastructure exclusively in the EU and are fully subject to European law (more on when Kubernetes is truly sovereign).

When choosing such a provider, it's worth checking the following points:

• Which Kubernetes version is being run, and how quickly are updates rolled out?
• How is the access model for support staff regulated?
• Is there a self-service portal for configuration, monitoring and DPA management?
• Are network policies, RBAC and pod security standards supported?

What happens if you don't

In engineering teams, compliance topics are often seen as bureaucracy to be dealt with "at some point too." That's understandable, but risky.

The GDPR provides for fines of up to 20 million euros or 4% of global annual turnover. For serious violations, such as personal data being transferred to the US without a legal basis, those aren't theoretical numbers. Supervisory authorities like the BayLDA or the Berlin Data Protection Commissioner have repeatedly imposed steep fines in recent years.

On top of that come operational risks: a hosting provider that's problematic under data protection law can force a switch, with everything that means for systems already in production. Get this right from the start and you spare yourself these problems.

Conclusion: data protection is an infrastructure decision

Schrems II isn't an abstract topic for lawyers. It directly affects the question of where, and with whom, you run your applications. The good news: the technical and contractual prerequisites for legally sound cloud hosting are well understood and achievable, it just takes a deliberate decision and a bit of documentation effort.

The bad news for everyone who keeps putting it off: the supervisory authorities are getting more active, not less.