Data Residency and GDPR for Cloud Infrastructure

Data residency is the question of which country your data physically sits in.
It gets conflated with GDPR compliance, which is a broader obligation about how
personal data is handled. The two are related but not the same, and the
confusion produces both unnecessary restrictions and false confidence.

This is a practical guide to the infrastructure side. It is not legal
advice.

The distinction

Residency is location. Your data is in Frankfurt, or
Virginia, or Singapore.

Compliance is a set of obligations: having a lawful basis,
minimising what you collect, securing it appropriately, honouring individual
rights, and having a valid mechanism for any international transfer.

European residency makes one of those obligations simpler, because data that
does not leave the jurisdiction does not need a transfer mechanism. It does not
address the others. A server in Frankfurt holding personal data you had no basis
to collect, retained indefinitely, is not compliant for being in Frankfurt.

Where data actually goes

This is the part that catches people. You choose a European region for your
production instances and assume the question is settled. Several other paths
exist:

• Backups and snapshots. Check which region they are stored
  in. Cross-region replication is a feature people enable for durability without
  considering jurisdiction.
• Logs and monitoring. Observability platforms frequently
  process in a region you did not choose, and application logs routinely contain
  personal data such as addresses, identifiers and sometimes request bodies.
• Content delivery networks. A CDN caches at edge locations
  worldwide by design. For public static assets this is unremarkable. For anything
  personalised it deserves a look.
• Email and notifications. Transactional email providers
  process recipient addresses and message contents wherever their infrastructure
  is.
• Support access. When you open a ticket and grant access to
  investigate, an engineer somewhere may be looking at your systems.
• Managed service control planes. The data stays regional;
  the metadata and management layer may not.

None of these is necessarily a problem. All of them are worth knowing about
before someone asks.

What to put in place

A data processing agreement with each provider handling
personal data on your behalf. Every serious provider offers one. Accept it and
record that you have, because this is a documentation requirement that is
trivial to satisfy and awkward to be missing.

A transfer mechanism where data does leave the UK or EEA.
Adequacy decisions and standard contractual clauses are the usual routes, and
the major providers have built them into their standard terms.

A record of processing activities, which for a small
organisation is a document rather than a system: what you collect, why, where it
sits, how long you keep it, and who else touches it. Assembling it usually
surfaces at least one thing nobody had thought about.

Choosing regions and providers

If residency is a hard requirement, it becomes the first filter on provider
choice. European providers make this straightforward:
OVHcloud and
Hetzner both operate
European infrastructure, and the shorter answer they allow on a security
questionnaire has commercial value independent of the legal position.

The large providers all operate EU and UK regions with processing agreements
and transfer mechanisms, and are used by organisations with serious obligations.
The analysis is longer, particularly around access by authorities in another
jurisdiction, and that is a question for advice rather than for a decision made
quickly. The provider-selection angle is covered in
which cloud provider for GDPR
obligations.

The obligations that infrastructure cannot solve

Most GDPR failures are not about location. They are about collecting more
than necessary, keeping it longer than justified, being unable to find all
copies of one person’s data when they ask, and not being able to demonstrate any
of the above.

Retention is the one to address first, because it is both the most commonly
ignored and the easiest to fix. Decide how long each category of data is kept,
automate the deletion, and you have removed a recurring risk with a single piece
of configuration. Storage lifecycle rules do this for object storage, and the
same thinking applies to logs and backups.

A short checklist

1. Know which regions hold production, backups, logs and caches.
2. Have a processing agreement with each provider, recorded.
3. Have a transfer mechanism for anything leaving the UK or EEA.
4. Keep a record of what you process and why.
5. Set and automate retention periods.
6. Be able to locate and delete one individual’s data across every system.
7. Write down the reasoning, because demonstrating the decision is part of the
   obligation.