Data residency is not data sovereignty, and the difference is the point

A region selector is a feature. It can be built, demonstrated in a console and priced. Reworking corporate structure so that a European entity operates independently of a foreign parent is not a feature; it is a company decision with tax, staffing and liability consequences.

So the market solved the part it could solve and named it after the part it could not. That is not fraud, and residency is genuinely useful: it addresses latency, it satisfies contractual requirements that are actually about geography, and it reduces the number of jurisdictions involved.

It just does not answer the question a regulated buyer is asking, which is what happens when a foreign authority serves an order on the entity that holds the keys.

The first is support. A platform hosted entirely in the EU is routinely operated by engineers who are not, and a support engineer with production access is an access path regardless of where the disk is. Ask which countries support staff are located in and what they can see.

The second is telemetry about the platform itself. Product analytics, crash reporting and licence checks often leave the region by default, and while the payload is usually metadata rather than customer content, metadata about a security platform is not nothing.

The third, and the one that has grown fastest, is model inference. Alert context sent to an inference endpoint is customer content leaving the region, and it is frequently not covered by the residency statement because the residency statement predates the feature.

If sovereignty cannot be promised, the useful question becomes what reduces the surface. Three things do, in descending order of effect.

Which entity operates the service and who ultimately owns it. This is the largest lever and the one least often discussed, because it is a fact about the vendor rather than about the product.

Which subprocessors are in the chain, and whether the vendor can change them without telling you. A short, named, change-controlled subprocessor list is worth more than a longer residency statement. And third, whether encryption keys are held by a party that is not subject to the same legal orders, which shifts the question from access to usability of what is accessed.

The FTC has accumulated vast rulemaking, enforcement and adjudicatory powers, and it unquestionably exercises executive power, and must therefore be controlled by the Chief Executive, in whom such power is vested.

Sovereignty requirements almost always push in one direction: fewer jurisdictions, fewer parties, a shorter chain. That is the right instinct for compelled access and it quietly creates a different exposure.

A single European provider running your detection, your storage and your analysis is one dependency rather than four. If it has an outage you have no coverage, if it is acquired the ownership answer changes overnight, and if it fails commercially you migrate under time pressure rather than at renewal.

The point is not that concentration is worse than jurisdictional exposure. It is that a requirement written only against the second creates the first without anyone deciding to, and the two should at least be weighed in the same document. Under DORA that weighing is explicit, since concentration risk among ICT third parties is part of what the framework is built to surface.

Encryption is the most frequently offered response to the sovereignty question and the most frequently misdescribed. Encryption at rest protects against a stolen disk. It does not protect against a compelled disclosure served on the entity that holds the key, because that entity can simply produce the plaintext.

What changes the answer is key custody. If keys are held by a party in a different jurisdiction from the operator, an order served on the operator produces ciphertext. That shifts the problem from access to usability, which is a genuine improvement and also an operational burden: someone has to run the key management, and a lost key is an outage.

The honest framing is that customer-managed keys move the exposure rather than removing it, because a key management service operated by the same group is not in a different jurisdiction in any meaningful sense. Ask who operates the key store and under whose control it sits, and treat the answer as part of the ownership question rather than as a separate technical feature.

Procurement documents that ask for a sovereign solution get marketing answers, because the word has no agreed definition to test against.

Ask for the five facts instead: the operating entity and its ultimate parent, the regions for storage, processing and backup, the countries support staff operate from, the current subprocessor list with a change-notification term, and where model inference executes.

Each has a documented answer, each can be re-asked at renewal, and together they describe the actual exposure. That is a requirement a vendor can meet or decline, which is more than a request for sovereignty ever produces.