Choose where your data lives — and prove it

More and more countries require data to stay within their borders. A promise in a contract is not enough — the system itself has to refuse to break the rule.

What a policy says

  • Allowed jurisdictions: a country by its ISO 3166-1 code, plus a region
  • Residency classes
  • The class of the data
  • The minimum protection level for the keys

Placement needs a proof

A node accepts data only together with a proof that the placement was checked against the policy. That proof is produced by the check itself and cannot be assembled by hand, so there is no way to place data «just this once» around the rules.

Nodes in several regions: data stays where the policy saysPolicy: data stays in the GulfGulfHome nodelive dataReplicaencrypted onlyEuropeNode of anotherorganisationPlacement refused:jurisdiction
Nodes in different regions form one network, yet each organisation's data stays where its policy allows.

A refusal names its reason

When a placement is refused, the reason is specific:

  • The key or node was revoked
  • It is not valid yet, or it has expired
  • The jurisdiction is not allowed
  • The residency class does not match
  • The data class does not match
  • The key storage is below the required level
  • Replicas would end up outside the policy

An example

Tell the platform that this organisation's data lives only in the UAE, with keys at or above a set protection level — and any placement that breaks the rule is refused with the reason.

Residency works the same in our cloud and on your own nodes: the policy travels with the organisation, not with the data centre.

Next step

See it on your own business

Book a demo: we show the platform on your processes and agree where your data will live — in our cloud or on your own nodes.