Data Sovereignty: Where Your Website Data Actually Lives and Why It Now Matters
The question of where your website’s data physically sits was, a few years ago, a technical footnote. It has become a legal one: a growing number of countries require certain categories of data to be stored within their jurisdiction, or transferred abroad only under defined conditions.
A caveat first: the specific requirements depend on country, industry and data type. This does not replace legal advice. What follows is the technical part, useful to know before that conversation.
What data sovereignty means
The principle is simple: data is subject to the laws of the country where it is physically stored. Not where your company is registered, and not where you manage it from.
The practical consequence is less obvious: you can operate in one country, serve clients from a second, and store data in a third, and the laws of the third will apply. Alongside the laws of the client’s country.
Where your website’s data actually lives
The answer “on the hosting” is almost always incomplete. The real picture for a typical site looks like this:
| What | Where it usually is | Which data |
|---|---|---|
| Primary server | The host’s data centre | Database, files, enquiries |
| Content delivery network | Dozens of countries at once | Page copies, sometimes cookies |
| Analytics | The provider’s servers | Behaviour, identifiers, IP addresses |
| Forms and newsletters | The form or email service | Names, phone numbers, correspondence |
| CRM | The vendor’s cloud | The entire client base |
| Backups | Often a different country from the server | Everything listed above |
| The mail provider | Client correspondence |
The last two rows are usually the surprise. Backups get placed wherever it is cheapest, with nobody asking about jurisdiction. And email carrying client correspondence is rarely treated as a personal data store, although it is one in full.
Why this became a question now
Three causes overlap:
- Localisation requirements are tightening. More countries are introducing rules about which data may not leave their territory.
- The number of external services has grown. A typical site passes data to five or ten destinations, each its own jurisdiction.
- A new class of recipient appeared. AI-based tools process data on their own servers, and that flow is most often recorded nowhere.
The last point is the newest. When an employee pastes client data into an external service, a cross-border transfer takes place. Formally the same as exporting a database, only without a contract and without a record.
How to find out where your data is
This is a couple of hours of work, and nobody does it until somebody asks.
- List the services receiving anything from the site: hosting, analytics, forms, chat, email, CRM, advertising, maps, fonts.
- Find the processing region for each. Usually in the contract or the privacy section. Many services let you choose a region during setup, but the default is not the one you need.
- Check backups separately. Where they sit, how long they are kept, who has access.
- Check fonts and external libraries. Loading a font from a third-party domain sends the visitor’s address there. A detail that regularly turns out to be a violation.
- Record the result as a table. Service, region, which data, on what basis.
That table is precisely what people ask to see. Not having it costs more than any individual mistake within it.
What to do about it
Do not panic and do not migrate everything urgently. A more pragmatic order:
- Separate data by sensitivity. Anonymous visit statistics and a client database with phone numbers are different categories with different requirements.
- Start where the most personal data sits. That is usually the CRM and email, not the website.
- Check whether a region can be selected. In many services this is simply a setting nobody knew about.
- Bring backups into the same jurisdiction as the primary data. That rarely costs more.
- Minimise. The cheapest way to resolve a data storage question is not to collect data you do not need.
A trade-off worth knowing about
Local storage is not free. A server closer to your audience gives better speed, but choosing a region on legal grounds sometimes means worse response times. A content delivery network solves that partly, but becomes its own question, since page copies get distributed across many countries.
The decision here is managerial rather than technical: how sensitive your industry is to these requirements and how much speed you are willing to pay. For most companies the compromise looks like this: the primary database in the required jurisdiction, static assets served through a delivery network from anywhere.
Data sovereignty looks like a topic for large corporations, right up until you discover your website backups sit on another continent and your client correspondence in a third country. That does not make you non-compliant automatically, but it is something worth knowing about your own business before somebody asks.
