Data Residency and Hosting: Stating the Facts Precisely

"Where is my data?" sounds like a simple question and rarely gets a simple answer. A vendor may say "in the EU" and mean that the primary database sits in a Frankfurt data centre while backups go to another country, support staff in a third region can view records, and an analytics service processes event data somewhere else. Each of those is a separate fact, and each matters to someone.

This guide separates the facts hidden inside the phrase "where is my data", shows how to state each precisely, and explains why vague answers cost vendors deals. It is addressed to people who write hosting statements and to people who read them.

Three questions, not one

Treat residency as three questions.

1. Where is the data stored at rest? The region of the primary database, file storage and any search index.
2. Where is the data processed? The regions in which application servers, background jobs and sub-processors run.
3. Who can access it, and from where? Support, engineering and subcontractors, and the locations from which they work.

A statement that answers only the first can be completely true and still mislead. A buyer concerned about a particular legal regime cares about all three, because a transfer happens whenever personal data becomes accessible from another jurisdiction, even if it is never copied there.

Residency, sovereignty and transfers

These terms are used loosely, so it helps to define them.

Data residency is the location where data physically sits. Data sovereignty is the idea that data is subject to the laws of the country where it is stored or where the controlling organisation is based. Data transfer, in data protection language, is the movement of personal data to a recipient in another country or international organisation. Under UK and EU data protection law, transfers outside the territory are allowed only with an appropriate safeguard or exception.

The UK Information Commissioner's Office publishes guidance on the UK GDPR, including the rules on international transfers. If you are writing a hosting statement you do not need to reproduce the law, but you do need to give enough facts for a customer to complete their own assessment: the regions, the entities that process the data and the safeguards you rely on.

Facts to publish

A strong hosting section has these rows.

• Infrastructure provider: the company whose platform runs your servers.
• Primary region: the named region or country for production data.
• Region choice: whether customers can choose a region and at which plan, and whether the choice can be changed later.
• Backup region: where backups are written and how long they are kept.
• Disaster recovery region: if a second region can take over, name it.
• Processing locations: regions where application servers and jobs run, where different from storage.
• Sub-processors: a link to the list, with purpose, location and date of last update.
• Support access: whether staff can view customer data, from which locations, and what approval is needed.
• Retention after cancellation: the number of days data persists and how deletion is carried out.

Each row stands alone, and each can be true or false. That is the point.

Wording that works and wording that does not

Vague: "Your data is stored securely in the cloud."

Precise: "Production data is stored in the London region of our infrastructure provider. Encrypted backups are written to a second facility in the same country and retained for a stated period. Our support team accesses data only on request and only from the UK and Ireland."

Vague: "We are GDPR compliant."

Precise: "We act as a processor of customer personal data. Our data processing agreement is linked here. Sub-processors are listed at this address and we notify customers of changes in advance."

Vague: "We keep your data in the EU."

Precise: "Primary storage and processing are in Ireland. Our email provider processes message metadata in the United States under standard contractual clauses; the sub-processor list shows the details."

Notice that the precise versions are longer and slightly less flattering. That is normal. A page that admits one non-EU processor is more believable on every other line.

Region choice as a product feature

Some vendors let customers pick a region at sign-up. If you offer this, document it as a feature with limits.

• Which regions are available now?
• Is the choice available on every plan?
• Can an existing account be migrated, and at what cost in time?
• Do all features work in every region, or are some limited to the default?
• Does choosing a region keep backups, logs and search indexes there too?

The last item catches many vendors out. A region choice that covers the main database but not the log pipeline is a partial answer and should be described as such.

The supply chain question

Modern products rely on layers of other services. The UK's National Cyber Security Centre makes the point in its supply chain guidance that you remain responsible for understanding the risks your suppliers bring. For hosting statements, this means that a complete answer includes the main third parties that touch customer data: the infrastructure provider, the email delivery service, the error-monitoring service, the analytics tool, the payment processor and the customer-support platform.

A useful test: if a customer asked "which companies can see my users' email addresses", could you answer in a minute? If not, the list is incomplete.

Backups and deletion

Customers also ask what happens to data when they leave. The honest answer is usually two-stage: live systems are cleared within a stated number of days, and backups age out on their own cycle. State both. For example: "Live data is deleted within a stated period after cancellation. Backups containing the data are overwritten on their normal rotation, which completes within a stated number of days after that."

Do not say "immediately" unless it is true for backups too. Do not say "permanently" unless you can explain how you verify it.

Keeping the statement current

Hosting statements fail when infrastructure changes and the page does not. Common triggers:

• A move to a new region or a new provider.
• A new sub-processor added to the stack.
• A new feature that sends data to a third-party service, such as an AI model provider.
• Acquisition of the vendor, which can change the controlling entity.

Add a step to your change process: any change that alters where data is stored, processed or accessed requires an update to the hosting page and the sub-processor list before release. Add a "last reviewed" date and a changelog entry.

What buyers should do with the answer

If you are on the buying side, record the answer in your own supplier file with the date. Compare the vendor's statement to the questionnaire you send and note any difference. When a vendor's hosting page and its data processing agreement disagree, trust the signed agreement and ask them to fix the page.

Checks that take minutes:

1. Does the page name a provider and region?
2. Is there a sub-processor list with a date?
3. Is the data processing agreement downloadable?
4. Does the page describe support access?
5. Are retention and deletion terms stated?

A worked hosting statement, line by line

To make the structure concrete, imagine a small scheduling product built by a team of six. Its first hosting page said: "We use trusted cloud infrastructure with industry-standard security." After a customer questionnaire exposed how little that answered, the team rewrote it as a table. Each line is annotated here with the reasoning behind it.

Infrastructure provider and primary region. One line, two facts, both nameable. The team put the provider's name and the region name rather than a country, because a country can hold several regions with different properties.

Region choice. The team had none, and said so: "Customers cannot currently select a region. Production runs in a single region." That line took thirty seconds to write and ended a whole category of follow-up questions.

Backups. The team discovered while writing this line that their nightly backups were being copied to a second region they had never documented. They documented it, then asked whether that was acceptable to their customers. Writing the page found a fact the team had forgotten, which is a common and useful side effect.

Sub-processors. They listed seven, with purpose, location and the date each was added. Two were in a different region from production. Those two lines generated the most questions and the fewest objections, because the answers were already on the page.

Support access. Staff could technically read customer records. The team wrote: "Support staff can view account data when a customer opens a request, using an audited internal tool. Access events are logged." If this had not been true they would have fixed the practice before publishing, not softened the sentence.

When the answer is "it depends"

Some facts depend on configuration. Say what they depend on. "Backups are retained for a period that depends on the plan; the table below shows each" is better than a single number that is wrong for half your customers. If a fact depends on a customer's own settings, say that too, and link to the instructions for changing them.

Summary

Residency is three facts: where data is stored, where it is processed and who can reach it. State each one with a named provider, a named region and a date; list sub-processors; describe backup and deletion behaviour; and review the page whenever infrastructure changes. Precision costs a few awkward admissions and earns a great deal of trust, from procurement teams and from the assistants that summarise your page for them.