Glossary
Data Sovereignty
The principle that data answers to the laws of the place where it lives. Residency says where the bytes are; sovereignty asks which government can compel access to them and which rules apply.
General definition
Data Sovereignty is the idea that information is governed by the legal system of the jurisdiction where it is collected, stored or processed. A record held in a data centre in Frankfurt is subject to German and EU law, including the powers of German courts and regulators to demand it. The term is often used alongside two related ones:
- Data residency: where data is physically stored and processed, usually a policy or contractual choice
- Data localisation: a legal requirement that certain data be stored, and sometimes processed, only inside a country’s borders
- Data sovereignty: which laws and authorities govern the data, which also depends on who operates the infrastructure and where that operator is incorporated
The practical tension is that residency does not guarantee sovereignty. Under the US CLOUD Act of 2018, a provider subject to US jurisdiction can be compelled to produce data in its possession or control even when that data is stored abroad. On the EU side, GDPR Chapter V (Articles 44 to 49) allows personal data to leave the European Economic Area only under an adequacy decision, appropriate safeguards such as Standard Contractual Clauses, or a narrow derogation. The Court of Justice’s Schrems II judgment in 2020 struck down the EU-US Privacy Shield over exactly this conflict between US surveillance powers and EU rights; the EU-US Data Privacy Framework adopted in 2023 is the current successor and has faced its own legal challenges.
Responses to this tension include sovereign cloud offerings (regions operated by a locally incorporated entity with locally resident staff and locally held keys), customer-managed encryption keys, and simply running the workload on infrastructure the organisation controls. For a messaging system the questions are concrete: where are messages and attachments stored, where are backups and logs replicated, which company can access the database, and which law governs a subpoena. An on-premise deployment or a virtual private cloud in a chosen region answers most of them, provided no component quietly routes data elsewhere.
In the Ethora ecosystem
Ethora addresses sovereignty through deployment choice rather than a promise about its shared cloud. On a dedicated deployment, Ethora TechOps run the chat server, database, file storage and any AI components inside your own cloud account, in the region you select; an EU-only deployment is possible, and the same applies to a private cloud or on-premise install. Because the account and the infrastructure are yours, your organisation is the operator of record for sovereignty purposes, and Ethora’s access is the scoped operational access you grant under the Data Processing Agreement.
Two details matter for chat specifically. First, push notifications and cloud LLM APIs are the components most likely to leave a region; Ethora agents can use self-hosted models through an OpenAI-compatible endpoint, and push credentials are your own. Second, the multi-tenant managed cloud is convenient for building but is not the answer to a sovereignty requirement; prototype there and move to a dedicated deployment when the requirement is real.
