EssenceالعربيةالعربيةRequest information
Knowledge

Where your data lives: sovereign instances and what crosses a border

GovernmentRegulated enterprisesInvestors

Each country's Essence instance is a separate deployment with its own databases and keys. What stays, what may cross a border and what our central service holds is set out class by class.

Data residency is often a setting: a region chosen from a list on a shared cloud. For a government or a regulated organisation, that leaves the important questions open: which data stays, which data moves, and on whose decision. On Essence, residency starts with which deployment you are in, and the answer for each class of data is written down.

A separate deployment for each country

A sovereign instance is a complete, separate deployment of the platform for one jurisdiction. It has its own databases, its own keys and its own certificate chain. It is not a tenant on a shared cluster.

The separation is physical rather than a filter on a shared table. Each instance has its own host and its own entry point for network traffic, so there is no shared table with a country column that a faulty query could cross. The jurisdiction is enforced when the instance is created, and traffic from people in that country ends in that country rather than passing through our central service.

An organisation or authority that prefers not to join the wider network can run a standalone instance instead. A standalone instance exports nothing.

What stays in the country

For an instance that is part of the network, each class of data has a fixed place:

  • Vault content is stored as ciphertext in the country's instance.
  • Personal metadata stays in that instance's database.
  • Consent records stay in the country, and move only with a cross-border grant they represent.
  • The record of activity is kept in the country, by the instance itself.
  • Encryption keys are held on people's own devices, so they leave a country only when the person does.

What may cross a border

Movement falls into three kinds.

What never goes to our central service. Vault content, personal metadata and consent records.

What may go to our central service. None of it identifies a person:

  • aggregated metrics, such as counts and response times, with no identifiers;
  • the registry of instances, and the details the network needs to know who belongs to it;
  • the commercial catalogue and its product definitions.

Software updates travel the other way, from the central service out to each country.

What moves because a person asked. Personal data moves between two countries' instances only when a person starts a cross-border action, under their consent, and only as much as that action needs.

The rule that a country's instance sends no personal data to our central service is checked at three points. A change to the platform that adds personal data to anything sent between instances fails before it can be built. Free-form values are refused when activity records are received. And the addresses instances use to reach each other come from the registry of instances, never from anything a client supplies.

How instances come to trust each other

Being on the same network does not make two instances trust each other. Trust is an explicit decision that can be withdrawn, and a withdrawal takes effect at the next refresh. An instance that has not been admitted, or has been removed, cannot draw data from the others.

What our central service holds, and where backups go

Our central service runs sign-in. That means it holds each person's account record: email address, optional name and phone number, credential hashes, multi-factor settings and sign-in history. It holds no vault content. An authority assessing residency should count those account records in its picture.

Backups are a choice for each country. To recover from a disaster that takes out a whole region, encrypted backups can be copied outside the country. No keys travel with them, so the copy is unreadable ciphertext. Each country's instance can turn that copying on or off, trading some protection against a national-scale outage for strict in-country storage. Views differ on whether an encrypted copy counts as an international transfer, so the platform leaves that decision to each authority, to make before deployment.

We have mapped the platform against UK GDPR, EU GDPR and the UAE's personal data protection law, which gives an authority a starting point for its own assessment.

For a government or regulated organisation, residency is rarely one promise. It is knowing what each class of data does at a border, and on Essence that is set out class by class. If you are weighing a sovereign instance against your own rules, we would be glad to walk through it with you.

Want to see it working? Request information

Last reviewed 8 October 2026

Related

When an AI agent asks for your data: delegation with limitsAn AI agent acting for a person should hold a narrow, expiring, countable slice of their consent, never their credentials. Delegated capabilities on Essence are built that way.
One set of sharing terms, many councilsCouncils on the same service write similar data-sharing agreements again and again. On Essence, the terms such an agreement sets are configuration, so one set written once can be applied by many organisations.