Residency is where your data sits. Sovereignty is who can be compelled to hand it over. Many vendor questionnaires test the first and assume the second, and the gap between them is where a
compliant-looking deployment quietly fails.
The mechanism at issue here is the US CLOUD Act. A provider subject to US jurisdiction can be compelled to produce data in its possession, custody, or control in response to a US legal request, even when that data is stored outside the United States. The obligation attaches to the provider, not the server location. We have made the full sovereignty argument for the public sector elsewhere, and it applies equally to a bank, an insurer, a hospital, or a law firm.
Seeing the distinction is the easy part. Establishing whether a specific shortlisted vendor actually passes is harder, because the vendor, its parent, its cloud provider, its hosting partner, and its support provider may each be governed by a different jurisdiction. Below are the five questions that do that work. Put them in the RFP in writing, and treat a vague or partial answer as a finding rather than a formality.
The five questions
1. Which legal entities are actually in the chain?
A headquarters location is not a jurisdiction answer. Ask for the contracting entity, its ultimate parent, and any affiliates that hold, process, or can access customer data, along with the country each is organized in. A vendor headquartered outside the US can still be reachable if a US parent or US affiliate has possession or control of the data. Ask every shortlisted vendor to state its own jurisdictional position at the entity level, not just at the brand level. Inuvika contracts from Canada or the UK and is not subject to US jurisdiction. That is the level of entity-specific clarity the answer should provide.
What a bad answer looks like: a marketing address, a country name with no entity behind it, or silence on the parent company.
2 Who else in the delivery chain can be compelled?
This is the question that catches a risk that the first question misses. The software vendor is one link. The cloud provider, hosting partner, managed-service provider, and any support subcontractor are each governed by their own jurisdiction, and each may have possession, custody, or control of something disclosable. A deployment on a US hyperscaler, or support delivered through a US-based provider, can reintroduce the exposure that the vendor’s own location removed. If that party has possession, custody, or control of relevant data, it is at risk. A vendor can be entirely outside US jurisdiction and still deliver your service through parties that are not.
Map every party in the chain and the jurisdiction governing each. Because Inuvika OVD Enterprise is hypervisor and cloud agnostic, you can keep that chain on infrastructure and partners you choose, rather than inheriting a single global cloud’s legal footprint.
What a bad answer looks like: an answer that covers only the vendor’s own entity, or a named cloud region offered as though the region were the jurisdiction.
3. What can each party reach, and who holds the keys?
“Customer data” is not just documents. For each party in the chain, ask what they can access across content, logs, backups, telemetry, and support files, and ask who holds the encryption keys. Key custody is a jurisdiction question, not just a security one. That is because a party holding the keys may be able to produce readable data. For on-premises deployments, OVD Enterprise collects no customer data (other than voluntary subscription expiry and total use numbers), which materially reduces what we could ever be asked to produce. OVD Enterprise can also be used in a fully “air-gapped” environment. Where a managed service is preferred, we deliver it through independent local hosting partners, in your country, rather than a single global operator.
What a bad answer looks like: “the data is encrypted,” offered without saying who holds the keys, or a scope limited to documents with no mention of logs, backups, or telemetry.
4. What does remote support quietly send out?
Even an on-premises install is not automatically sealed. Ask what leaves the environment for updates, diagnostics, and support, and whether remote support sessions create temporary access to customer information. These are the channels that can reintroduce exposure a residency review may have treated as closed. Confirm what is transmitted, including whether it is operational metadata or customer content, who receives it, and which jurisdiction governs the recipient.
What a bad answer looks like: “nothing leaves the environment,” asserted without a list of what the licensing, update, and diagnostic channels actually transmit.
5. How does the vendor handle a government demand?
Jurisdiction is ultimately about what happens when a demand actually arrives. Ask each vendor for its documented process. Does it challenge or narrow overbroad requests? Does it notify the customer where legally permitted? Does it report the volume of demands it receives? A vendor without a documented process risks having to improvise with your data if a demand arrives. Here is an example of a demand on Google.
What a bad answer looks like: a reassurance that no demand has ever been received, offered in place of a process for any future demand.
Questions two through five are where many “sovereign” claims quietly fail, and they are the ones a vendor cannot satisfy with a single line about its head office.
Where this belongs on your matrix
For organizations whose sovereignty obligations prohibit foreign compelled-access exposure, jurisdiction is a pass/fail criterion: a solution that fails should not get to compete on features or price. For everyone else bound by regulation, it belongs on the matrix as a material legal-risk factor, weighed against how sensitive your data is, what your regulator demands, how you deploy, and what your contracts already cover, rather than left in the footnotes. Either way, it is a line you score deliberately, using questions you wrote down in advance.
We built OVD Enterprise for buyers who ask these questions. See how OVD Enterprise is built for sovereign, secure delivery, or start a free trial.
Frequently asked questions
Can a local hosting partner reintroduce foreign exposure?
Yes, and it is a common way a sovereignty review goes wrong. If the hosting partner, its parent, or the underlying cloud provider is subject to a foreign jurisdiction and has possession, custody, or control of relevant data, the exposure can return regardless of where the vendor is incorporated or where the data physically sits. The jurisdiction test has to run against every party in the chain, not just the name on the contract.
What should a vendor’s government-demand process actually contain?
At minimum: a documented process for reviewing the legal validity of a demand, a commitment to challenge or narrow requests that are overbroad, customer notification wherever the law permits it, and some form of transparency reporting on volume. Ask for it in writing. A vendor without an existing process is unlikely to produce a credible one under procurement pressure.
Does an on-premises deployment close the question by itself?
Not automatically. On-premises removes a major category of exposure, but it does not by itself account for licensing checks, update and diagnostic channels, and remote support sessions, each of which can move information out of the environment. Ask any vendor to document exactly what those channels transmit, to whom, and which jurisdiction governs the recipient. Those channels survive the on-premises decision, which is exactly why they need their own line in the evaluation.