Data residency

What is data residency?

Data residency is the physical country, region, or geography where data is stored and processed. If your customer database runs in a datacenter in the Netherlands, its residency is the Netherlands. If you move it to a US region, the residency changes.

In the cloud, that location is usually a design choice. When you create a database, tenant, workspace, storage account, or cloud resource, you often choose a region. That choice may be driven by performance, customer contracts, sector rules, or a requirement to keep data inside Europe.

Data residency answers a map question: where is the data?

Residency, sovereignty, and localisation

These three terms are related, but they answer different questions.

Data residency
Where is the data physically stored or processed? This is the region or datacenter location.

Data sovereignty
Which laws and public authorities can affect the data? This can depend on location, the provider's jurisdiction, contracts, and the type of data.

Data localisation
Is there a legal requirement to keep certain data inside a country or region? Localisation is a rule imposed by law. Residency is a location choice.

A European region does not automatically solve every sovereignty question. Data stored in Frankfurt with a US-headquartered provider can still raise questions about foreign legal requests, even if the physical residency is Germany.

How do you control residency?

The main control is the region or geography you select when creating the cloud service.

Azure regions sit inside geographies, and Microsoft describes each geography as a data residency boundary. If you have residency requirements, the practical step is to choose regions inside the required geography and check the service-specific documentation.

AWS works in a similar way at the region level: an AWS Region is a separate geographic area with multiple isolated Availability Zones, and customers choose where customer content is stored for many services.

On top of region choices, some vendors offer stronger boundary commitments. Microsoft's EU Data Boundary is a defined boundary within which Microsoft commits to store and process customer data and personal data for in-scope enterprise online services, including Azure, Microsoft 365, Dynamics 365, and Power Platform.

An example

A Belgian accounting firm builds reporting in Power BI on top of Azure SQL and selects the West Europe region. The accounting data is stored in a datacenter in the Netherlands rather than in the United States.

That is a residency decision. It belongs in data governance: which datasets must stay in the EU, which services are allowed, and who can approve exceptions?

It does not end every compliance question. The firm still needs to understand backups, logs, support access, subprocessors, encryption, and which legal jurisdictions apply to the provider.

Metadata and support access

Residency is not always as simple as the main database location. Cloud services also generate logs, telemetry, diagnostic data, support files, metadata, and identity events. Some of that data can contain personal data or pseudonymous identifiers.

Microsoft's EU Data Boundary documentation is explicit that the boundary applies to customer data and personal data for in-scope services, with service-specific configuration and transparency documentation. That is useful, but it also means teams should read the service detail rather than rely on a slogan.

Support access is another practical point. If an engineer outside the EU helps troubleshoot, access should be controlled, approved, logged, and limited. Serious residency work looks at both where data sits and who can access it from where.

What to watch out for

Confusing residency with sovereignty
Europe-based storage does not automatically mean only European law matters.

Global services
Some cloud services are not tied neatly to one region, or need extra configuration to stay inside a boundary.

Backups and replicas
Disaster recovery, snapshots, and backups may use another region if you configure them that way.

Logs and diagnostics
The content may stay in one place while operational data has a different processing path.

Contracts and documentation
Residency promises live in service terms, trust documentation, data processing agreements, and configuration choices. Keep evidence, not just intent.