Per-country residency vs EU residency.

The phrase used to mean one thing

Until about 2022, "EU residency" in a procurement document meant: the data is held in a datacenter located inside the European Union. Frankfurt, Dublin, Paris, or Amsterdam — any of them satisfied the box. Most procurement teams nodded and moved on.

The phrase covered two distinct concerns at once: physical location of the bytes, and the jurisdictional perimeter that protected them. As long as the underlying vendor was EU-headquartered or contractually committed to keeping the data in EU regions, the two concerns were treated as one.

What changed

The Cloud Act, Schrems II, and a round of national-supervisor guidance pulled the two concerns apart. A US-headquartered vendor with EU hosting is not the same as an EU-domiciled vendor. The parent company can be subpoenaed under US law; the subpoena reaches the data even when the bytes never crossed an ocean. Most enterprise customers could live with that risk. Regulated ones increasingly cannot.

The second shift is national-supervisor preference. The Banque Nationale de Belgique prefers to see customer data in Belgium. The CSSF in Luxembourg prefers Luxembourg. The BaFin in Germany prefers Germany. None of these are hard requirements in primary legislation, but each shows up in supervisory guidance and in the questions a senior examiner will ask during a periodic review. "EU region" is no longer a satisfying answer when the question is "which country."

What per-country residency actually requires

A vendor that promises Belgium residency has to do four things. Run a Postgres instance in Brussels with no read replicas in other regions. Run an object store in Brussels with no cross-region replication. Run the worker queue in Brussels. Sign daily attestations from a Brussels KMS key proving where the data lived during that UTC day.

None of that is technically novel. What is novel is the contractual commitment that none of the four will quietly drift. A vendor that ships per-country residency as an architectural property — as opposed to a deployment preference — has the answer to the supervisor's question already on the page. A vendor that ships it as "we deploy to your preferred region by default" has the answer until the next platform-team decision pulls it apart.

What we ask buyers to verify

Three questions cut through the marketing language quickly. First, where is the customer's data physically located today, and can the vendor produce a signed attestation of that fact? Second, can the vendor name every region into which the data could move under any operational scenario including failover, backup, and search indexing? Third, what is the contractual remedy if the vendor moves the data to a different country without the customer's consent?

A vendor whose answer to question one is "EU" and whose answer to question two is "multiple EU regions for resilience" is offering EU residency, not per-country residency. That is fine for many buyers. It is not the right answer for a buyer whose supervisor is going to ask about Brussels specifically.

How we shape it

Estøkad sells per-country residency as a separate module per region — Belgium, Germany, France, Netherlands, Luxembourg, Switzerland — and provisions the underlying infrastructure only when a paying customer signs up for the region. Brussels is not running today; it spins up the day a Belgian customer pays for it. The cost discipline matches the architectural discipline: regions exist when they have a customer, not as marketing options.

Pricing per region at /pricing; the comparison of how incumbents handle this at /vs.