What Is Data Residency?

Data residency is the geographic location where your data is physically stored — the country or region you or your provider have chosen to keep it in. It is a technical and contractual choice: you select a region, and the provider commits to storing your data there.

The distinction that matters most is this: residency describes where data sits, not whose law governs it or whether it may legally leave. Treating a local storage footprint as if it delivered compliance — sometimes called the "residency illusion" — is the mistake this page exists to unpick.

Data residency vs. sovereignty vs. localization

These three terms are used interchangeably, but they answer different questions, and conflating them is the most common way organizations end up exposed.

• Data residency is where data physically sits — a region you choose.
• Data localization is a legal requirement that certain data must stay within a country's borders. It is imposed by regulation, not chosen.
• Data sovereignty is whose law applies and who can ultimately compel access — a function of the operator's jurisdiction and who holds the keys, not merely of location.

Residency is therefore a component of the other two, not a substitute. You can satisfy a residency commitment in full and still breach a localization law — if a backup crosses a border — or lack sovereignty, if the operator answers to a foreign court. For the full treatment of the legal side, see data sovereignty.

What data residency actually controls — and what it does not

Residency is a real and useful control, but a narrow one, and it is worth being precise about its edges.

What it controls:

• The physical location of your data at rest — the region or data centre where the primary copy lives.
• A contractual commitment you can point to in an audit or procurement review.
• Latency, and sometimes which regional support and operations teams touch the environment.

What it does not control:

• Which jurisdiction governs the data, or which government can compel the operator to produce it.
• Where backups, replicas, cached copies, logs and telemetry go — these often leave the residency region unless explicitly constrained.
• Who can reach the data operationally, including remote support staff located elsewhere.

In short, residency answers "where is the primary copy?" — a question worth answering, but not the same as "is this data compliant and beyond foreign reach?"

Where residency quietly leaks

A residency commitment on the primary store is easy to obtain and easy to over-trust. In practice, data crosses the boundary through paths that rarely appear on the region selector:

• Backups and disaster-recovery copies replicated to a second region for durability — often a different country.
• Asynchronous replicas and caches, including CDN edge nodes that materialize copies close to users worldwide.
• Logs, metrics and telemetry shipped to a central observability platform in the provider's home region.
• Support and administrative access from engineers in other jurisdictions who can read or export data during troubleshooting.
• Metadata and key material managed by a control plane that may live outside the chosen region entirely.

Each is a legitimate feature; each is also a way the data's effective residency differs from the one on the contract. Verifying residency means tracing every copy, not just the primary bucket.

Why residency alone is not compliance

The regulatory frameworks that drive these requirements care about more than location.

GDPR does not require data to stay in the EU; it regulates the conditions under which data may leave. A dataset resident in an EU region can still be transferred lawfully — or unlawfully — depending on the mechanism relied on. The EU–US Data Privacy Framework, the main basis for transatlantic transfers, was upheld by the EU General Court in September 2025 but faces a further appeal before the Court of Justice, so the ground is not settled.

The US CLOUD Act is the sharper illustration: it can compel a provider subject to US jurisdiction to produce data it controls, regardless of the region that data resides in. Residency in Frankfurt does not remove a US parent company from that reach. Closing that gap is a question of data sovereignty — the operator's jurisdiction and who holds the encryption keys — not of residency.

Data residency and ARTESCA

Scality ARTESCA is object storage you deploy on your own standard servers, which makes residency a direct consequence of where you run it rather than a commitment you take on trust.

• You choose the location. The data resides in your own data centre, in the country and facility you select, because you operate the infrastructure.
• No implicit second region. Copies go where you configure them — multi-site replication is yours to place, so backups and replicas do not silently leave the jurisdiction.
• You hold the keys. Data at rest is encrypted with AES-256, with keys managed in an external KMIP-compatible key management system rather than on the storage itself.
• Standard S3 interface. Applications and backup software written for public-cloud object storage run unchanged, so keeping a workload in-region does not mean rewriting it.

Because you control the infrastructure, residency, sovereignty and localization stop being separate promises from a third party and become properties of your own deployment — and the same data can be made immutable through S3 Object Lock, so it is both in-region and protected against ransomware.

Data residency FAQs

Is data residency the same as data sovereignty?

No. Residency is where data is physically stored; sovereignty is which laws govern it and who can compel access. You can meet a residency requirement and still lack sovereignty if the operator is subject to a foreign jurisdiction.

Does choosing a cloud region guarantee my data stays there?

Only for the primary copy, and only as far as the contract specifies. Backups, replicas, CDN caches, logs and support access can all move data outside the region unless each is explicitly constrained. Verify every copy, not just the region selector.

Does data residency satisfy GDPR?

Not on its own. GDPR regulates how data may be transferred rather than mandating a location. Keeping data in an EU region helps, but lawful processing still depends on the transfer mechanisms and safeguards in place.

What is the difference between data residency and data localization?

Residency is a choice you make about where to store data; localization is a legal requirement that certain data must not leave a country. Localization removes the choice — residency is how you comply with it — but the two are not the same thing.

How do I guarantee data residency?

The most direct route is to control the infrastructure: self-hosted or on-premises storage in your chosen location, with backups and keys kept in the same jurisdiction. Where you use a provider, require contractual residency for every copy and confirm where backups, support and telemetry actually go.