Which Cloud Provider for GDPR Obligations

Two misconceptions dominate this topic. The first is that GDPR prohibits
using American cloud providers. The second is that choosing a European data
centre makes a service compliant. Both are wrong, and they are wrong in ways
that lead to bad infrastructure decisions.

This article is about how the regulation shapes a provider choice. It is not
legal advice, and anything with real exposure deserves a professional opinion.

What the regulation actually asks of infrastructure

Three things are relevant when choosing a provider.

A processing agreement. A cloud provider handling personal
data on your behalf is a processor, and you need a data processing agreement
with them. Every serious provider offers one. Check that it exists and that you
have accepted it, because this is a documentation requirement that is easy to
overlook and awkward to explain later.

A lawful basis for international transfers. Personal data
moving outside the UK or EEA needs a transfer mechanism. Adequacy decisions and
standard contractual clauses are the usual routes, and major providers have
built them into their terms. This is the part that makes “American providers are
banned” false: the transfer is lawful when the mechanism is in place.

Appropriate security. Encryption in transit and at rest,
access control, and the ability to demonstrate both. This is less about which
provider you choose and more about how you configure whichever one you do.

Why region choice still matters

Keeping data in an EU or UK region does not by itself achieve compliance, but
it does simplify the transfer question considerably. If the data never leaves
the jurisdiction, the hardest part of the analysis does not arise.

It also tends to be what customers and procurement departments ask about.
Whether or not it is the legally decisive factor, “where is our data stored” is
the question that appears on security questionnaires, and being able to answer
it cleanly has commercial value.

Be careful about the parts that are not obvious: backups, logs, monitoring
and support access can all cross borders even when your primary region does not.
Check where each of those actually sits.

Providers with a European focus

OVHcloud is a European
provider whose entire proposition includes data residency, which makes it a
straightforward answer when keeping data inside the EU is the binding
constraint. The trade-offs are a less polished catalogue and a strict
verification process.

Hetzner is German, with
European data centres and strong price-to-performance. Its catalogue is narrow,
so it suits infrastructure-level workloads rather than those needing many
managed services.

Both are covered in the
developer VPS
comparison and the
main comparison table.

Why the large providers are still viable

AWS, Azure and Google Cloud all operate EU and UK regions, offer processing
agreements, and have transfer mechanisms in their standard terms. Many European
organisations with serious compliance obligations use them, which is reasonable
evidence that it can be done properly.

The analysis is more involved, particularly where a parent company is subject
to another jurisdiction’s legal process, and that concern is genuine rather than
imagined. Whether it is material depends on your sector, your data and your risk
appetite, which is exactly the kind of judgement that benefits from advice
rather than a blog post.

A workable decision sequence

1. Establish whether a contract, regulator or customer actually requires
   data to stay in a specific jurisdiction. Often nobody has checked.
2. If yes, treat that as a hard filter and choose among qualifying
   providers.
3. If no, keep EU or UK regions as a strong default anyway, because it
   simplifies the paperwork and answers the question customers ask.
4. Confirm the processing agreement is in place and recorded.
5. Check where backups, logs and support access sit, not just the primary
   region.
6. Document the decision and the reasoning, because demonstrating that you
   thought about it is itself part of the obligation.

The part people get wrong

Compliance is mostly about what you do with the data rather than where the
server is. Collecting less, retaining it for a defined period, controlling who
can reach it, and being able to find and delete an individual’s records on
request are the obligations that fail audits. A perfectly located server full of
data nobody can account for is not a compliant system. See
data residency and GDPR for the
infrastructure side in more detail.