Review this claim. A public-sector tenant is served from an in-country region of a global cloud, staffed locally, with customer-managed keys in the provider's key service and a contract forbidding foreign access. The CI pipeline, the identity provider, the observability backend and the provider's operator tooling all run outside the jurisdiction. The team calls this sovereign. What would you remove, what would you change, and what would you leave alone?

What was actually bought

Three different things get called sovereignty, and this architecture satisfies the weakest one. Residency: the bytes sit in-country, and they do. Operational sovereignty: only people in the jurisdiction can act on the system, and here they cannot, because four control paths run outside it. Jurisdictional immunity: no foreign authority can compel access, and a contract does not deliver that.

The useful review question is not "is this sovereign" but "what could a foreign order produce today?" The answer is the keys, through the provider; the code, through the pipeline; and the tokens, through the identity provider.

What I would leave alone

The in-country region of a global provider. Building a datacentre is not the correction, and the argument that a hyperscaler's hardware is disqualifying leads to an estate nobody can run. Keep the contract clause too. Stop counting it as a control.

The changes that matter and in what order

1. Key custody. Customer-managed keys inside the provider's own key service still means the provider's software performs the decrypt. The change that moves the needle is an external key store operated in-jurisdiction, so every unwrap is a call to a system the provider does not run. Price it honestly: data keys are cached with a time to live, so the key store's availability becomes yours within one TTL, and the TTL is the dial. A 5-minute TTL gives 5 minutes of grace during a key-store outage and 5 minutes of residual access after you revoke; an 8-hour TTL inverts both.
2. The control plane is the boundary, not the data plane. A deployment pipeline outside the jurisdiction can ship code that reads everything inside it. Move the artifact registry and release approval in-country, or require an in-country signature that the in-country admission controller verifies.
3. Identity. A foreign identity provider can mint a token for any principal. Bring the provider in-country, or at minimum hold the break-glass path and its credentials in-country.
4. Observability. Logs and traces carry payload fragments, and exception payloads carry whole records. Put the backend in-country or enforce a field allow-list at the collector rather than a redaction rule at the backend.

What I would remove

The contract clause treated as a technical control, and any diagram that shows a jurisdiction boundary drawn around the data store alone. A contract is a remedy after disclosure, not a mechanism that prevents it, and drawing the boundary around storage is how four control paths went unexamined for a year.

When this is the wrong programme

If the obligation in writing is residency only, everything above is over-built and expensive. An external key store, an in-country pipeline and a second identity provider add operational surface, on-call load and failure modes that the customer never asked to pay for. Get the obligation in writing and classify it as residency, operational sovereignty or immunity before any of this is designed. Teams routinely spend a year and seven figures answering the strongest reading of a requirement whose author meant the weakest one.