Ask a sales engineer at almost any modern cloud platform where your data is hosted, and you will get an answer. Ask the same question of their incident-response team at three in the morning during a multi-region failover, and the answer changes. Ask their data-protection officer six months later when a regulator subpoenas the audit log, and it changes again.

The gap between these three answers is the data-residency problem. It is the gap between what a platform promises in a sales deck and what its architecture actually does at runtime. Regulators across geographies have noticed, and they are no longer accepting the sales-deck answer.

This article walks through what residency now means to four very different regulators, why the standard vendor claim does not satisfy any of them, and what shifts when teams treat residency as a deployment-time architectural decision instead of a contract clause.

What "residency" actually means to regulators

The four regimes worth tracking demand four different things, but they all ask the same underlying question: do you actually know where this data is, who can reach it, and what would happen to its location under stress.

The European Union. GDPR Chapter V allows personal data to leave the EU, but only under specific mechanisms: an adequacy decision from the European Commission, Standard Contractual Clauses (SCCs) in the modernised 2021 templates, or Binding Corporate Rules for intra-group transfers. Since the Court of Justice's Schrems II ruling in 2020, SCCs alone are not enough. Data exporters must also conduct a Transfer Impact Assessment that documents whether the destination country offers protection "essentially equivalent" to the GDPR. The Data Privacy Framework that currently covers EU-to-US transfers is under live legal challenge, with a CJEU ruling expected within the next two years. The prudent default in 2026 is to keep SCCs and TIAs current even for DPF-certified recipients.

The United Arab Emirates. ADHICS V2, the Abu Dhabi healthcare standard now operative through its 2026 remediation window, enforces UAE data residency for protected health information. Cloud-based hospital systems must store data within UAE borders; cross-border transfers require explicit approval from the Department of Health. UAE-region cloud capacity (Azure UAE, AWS UAE, G42 Cloud) is the expected substrate for PHI workloads. For healthcare technology providers in scope, this is non-negotiable.

Switzerland. FINMA's outsourcing and operational-resilience circulars (2018/3 and 2023/1) allow Swiss financial institutions to outsource across borders, but with a structural caveat: information required for Swiss restructuring or resolution must be accessible in Switzerland at all times, not only from Switzerland. The Swiss supervisor wants to be sure that if a regulated institution fails, the documents needed to resolve it are inside the country it is regulated in. The 2023 circular also introduced a new concept of "critical data" that must be identified, classified, and protected with enhanced technical and organisational measures.

The Kingdom of Saudi Arabia. SAMA's Cloud Computing Regulatory Framework requires banks to store customer data, transaction records, and business continuity backups on infrastructure within Saudi Arabia. Core banking systems, customer relationship management platforms, and payment processing environments must reside in-country. SAMA permits public-cloud use only where the provider operates certified KSA regions and signs enforceable agreements granting SAMA inspection rights and prohibiting unilateral data movement.

Four regimes, four shapes of demand. Read together, the trend is clear: residency is no longer a label. It is a position the regulator will verify, sometimes against the will of the vendor.

Why vendor claims do not satisfy the question

The standard vendor answer is "we are hosted in your region". The honest answer is more complicated. Most modern cloud platforms rely on multi-region deployment patterns where parts of the system move when load, latency, or failure demand it. The customer-facing application runs in the region the customer was sold. The audit log might ship to a centralised log aggregator hosted elsewhere. Telemetry and observability data often flow to a vendor-owned SIEM in a different jurisdiction. Backups land in a separate region for disaster recovery. Support engineers connect from offices on three continents. Multi-region failover, the thing customers pay for in the SLA, by definition moves data across borders during a stress event.

Each of these is defensible from an engineering standpoint. Each is potentially a finding from any of the four regulators above.

Concretely, here is where the sales-deck answer typically breaks under scrutiny:

  • Backups and disaster recovery. "Hosted in UAE" rarely extends to the DR copy. A backup landing in Frankfurt or Virginia is a cross-border transfer in the eyes of GDPR Chapter V, a residency violation under ADHICS V2 PHI rules, and a likely finding under SAMA's BCP-backup-localisation expectation.
  • Telemetry and audit log shipping. If the platform forwards security telemetry to a vendor-managed observability stack outside the customer's jurisdiction, that flow contains regulated data and almost no vendor maps it explicitly in their data-residency commitment.
  • Support access. A support engineer in a non-approved jurisdiction logging into a production environment to fix a customer's issue is a data transfer. FINMA's "access in Switzerland, not only from Switzerland" language is specifically aimed at this case.
  • Failover behaviour. During an availability incident, the customer's data may legitimately move to a recovery region. Whether that region was permitted to receive it is rarely answered in advance.

When a regulator asks "where is this data right now and where could it be tomorrow?", the answer needs to be precise and the answer needs to be true. Most cloud platform architectures cannot produce that answer without significant reservation.

The architectural shift: residency as a deployment choice

The vendors that will survive the next two years of regulatory scrutiny are the ones who treated residency as an architectural property of the deployment rather than a property of the contract.

There are three concrete shifts worth naming.

Customer-controlled storage. When the customer's data lives in a storage account the customer owns, in a region the customer selected, controlled by credentials the customer holds, residency is no longer a vendor commitment. It is a fact of the deployment. The customer can show the regulator the storage account ARN, the bucket policy, the audit log of every read and write, and the region attribute on the resource itself. The vendor's regional presence becomes irrelevant to the residency question; the customer's storage placement is what answers it.

Customer-controlled region. Where the customer cannot fully own the storage substrate (for example, in a managed cloud tier), the next-best architecture lets the customer pin the deployment to a specific region at provisioning time and forbids cross-region movement without explicit approval. Failover, telemetry shipping, support access, all bind to that pin. Novantra's Sovereign deployment takes this further: the customer chooses the data centre and the platform runs inside it.

Database-per-organisation isolation. Tenant isolation through "row-level security on a shared multi-tenant database" is increasingly read as architectural compromise by serious regulators. Database-per-organisation isolation gives the customer a fact a regulator can inspect at the storage layer (the database literally is its own database, not a logical partition trusted to query middleware). For multi-jurisdictional deployments, the per-organisation database can sit in the per-organisation region without the cross-tenant entanglement that a shared schema creates.

These are not features that bolt on. They are deployment-time choices baked into the platform's foundations. A platform that did not choose isolation, customer-owned storage, and customer-controlled region from the start cannot retrofit them without a structural rewrite.

The questions that distinguish real residency from theatre

A short, uncomfortable checklist for any team evaluating a platform's residency posture. These are the questions auditors are increasingly asking, and the questions buyers should learn to ask too.

  1. Where do backups land? Specifically, not generally. Region, account, retention. If the answer is "in your region" without an artefact you can inspect, the answer is incomplete.
  2. Where does support operate from? A vendor with a 24/7 support team distributed globally is making cross-border transfers every time a ticket touches a regulated record. FINMA and SAMA both look at this.
  3. Where do telemetry and audit logs flow? Many platforms forward observability data to a centralised stack that the customer was never asked to approve. That stack has a location.
  4. What happens to data during multi-region failover? "We use AWS multi-AZ" is not the answer to a residency question. Failover region, failover triggers, and post-failover data location need to be explicit and inspectable.
  5. Can you produce a current map of where customer data lives? If a regulator asked for a per-record location report covering the last twelve months, what would the vendor produce? If the honest answer is "we would explain that we are very compliant", the platform is failing this question.

The point of the list is not that any platform clears every question on day one. The point is that a serious vendor can answer each one with an artefact, not a paragraph.

The architectural answer

Data residency used to be a procurement clause. It became a Schrems II problem, an ADHICS V2 control, a FINMA outsourcing requirement, and a SAMA localisation mandate, more or less at the same time. The platforms responding well to that convergence are the ones that moved the residency question out of the contract and into the deployment.

This is the design principle behind Novantra. Novantra's BYO Storage means the customer's data lives in the customer's bucket from the moment the platform writes it. Novantra's customer-controlled keys mean that even if the bytes moved, the vendor could not read them. Novantra's database-per-organisation isolation means the customer's database is the customer's database, located in the customer's region, with no shared tenancy to entangle the question. Novantra's Sovereign deployment closes the loop by running the platform inside the customer's own infrastructure, removing the vendor from the data path entirely.

None of these is a label. Each is a deployment fact that a regulator can verify. That is the difference between residency that survives audit and residency that survives only the sales call. The companion article on cloud in your Region covers the technical mechanics underneath every cloud-provider Region claim, including what each Sovereign Cloud SKU actually delivers and where the four control surfaces customers most often miss.