Data residency vs data sovereignty vs operational sovereignty

Data residency is where your data physically sits and is processed. Data sovereignty is which country’s laws govern that data and the company holding it. Operational sovereignty is who can run, administer and reach the system that processes it. They are three separate questions, and a vendor can give a strong answer to one while failing another. Most of the confusion in regulated AI procurement comes from treating them as a single question.

Data residency: a question of place

Residency is the easiest to verify and the easiest to over-read. It asks one thing: in which region is the data stored and processed. A region selector, or a contractual commitment to a location, answers it. In this database that is the regions field on each profile and, where a vendor commits to it in writing, the data residency guarantee column. Residency matters for latency, for some contractual terms, and for the narrow legal rules that turn on location. What it does not tell you is who can compel the data once it is there.

Data sovereignty: a question of law

Sovereignty asks whose law governs the data and the entity that holds it. It turns on the parent jurisdiction of the controlling company, not on where the servers are. A US-parented provider is subject to US law, including 18 U.S.C. § 2713, wherever its data centres sit, so a European region does not change the answer. The database records this separately as parent jurisdiction, and the jurisdiction analysis works through why an EU region is not EU sovereignty. The EU Cloud Sovereignty Framework formalises the same split, scoring legal and jurisdictional sovereignty as its own objective (SOV-2) on a separate axis.

Operational sovereignty: a question of control

Operational sovereignty asks who can actually run and reach the system: which people administer it, whose staff hold the keys and the root access, and whether the service can be operated without a non-domestic dependency. It is the layer most sovereign-cloud marketing sells: local engineers, an in-country subsidiary, an independent trustee holding the encryption keys. Those are genuine operational-sovereignty measures. The EU framework treats operational sovereignty as a distinct objective (SOV-4), alongside the legal one, precisely because the two do not substitute for each other. Strong operational controls raise the practical difficulty of foreign access; they do not change which law the controlling company answers to. That gap is what the sovereignty washing analysis is about.

Reading the three together

The three stack rather than compete:

• Residency without sovereignty: a US-parented vendor with a guaranteed EU or UK region. The bytes stay put; the controlling law is still foreign.
• Sovereignty without operational depth: a domestically owned vendor that still leans on foreign-run infrastructure or support. Ownership is local; day-to-day control may not be.
• All three aligned: a domestically parented vendor that keeps data in-country and operates it with domestic staff and control plane. In this database, Civo is the one vendor whose parent jurisdiction and residency guarantee point at the same place, a different position for a UK buyer than any EU- or US-parented option. The UK buyer’s position sets out what that does and does not settle.

For a procurement decision, name which of the three you actually need. Latency and some data-handling rules need residency. Exposure to foreign legal process needs sovereignty. Assurance that no foreign party can operate or reach the system needs operational sovereignty. The matrix keeps residency and parent jurisdiction in separate columns so you can read them apart; operational sovereignty is the question you carry into due diligence once the first two are settled.

This piece is analysis, not legal advice. A specific procurement should be checked against the current rules and with counsel.