architecture

Sovereign Cloud for Regulated Industries: Four Requirements, Not One

Data residency, operational, jurisdictional and technical sovereignty are separate questions. Most estates satisfy two and assume they have satisfied all four.

Sovereignty has become one of those words that means whatever the person using it needs it to mean. For a regulator it is a legal question. For a vendor it is a product category. For an architect it is a set of design constraints that have to be met and evidenced, and the gap between those three definitions is where projects get into trouble.

This is the architect's version. What sovereignty actually requires, how to decompose it into design decisions, and where the requirements tend to be stricter than people expect.

Sovereignty is four separate questions

Treating it as one requirement is the first mistake. It decomposes into four, and an estate can satisfy some and fail others.

Data residency

Where the data physically sits. The easiest to satisfy and the one most people stop at. Backups, replicas, logs and telemetry all count, and telemetry is where estates usually fail an audit.

Operational sovereignty

Who can access the data and from where. A platform hosted in-country but supported from an offshore operations centre may fail this even though residency is satisfied.

Jurisdictional sovereignty

Which legal system can compel disclosure. This is about the operator's corporate nationality, not the data centre's postcode, and it is the question that has driven most sovereign cloud programmes.

Technical sovereignty

Whether you can operate, exit or reconstitute the platform without the vendor. The hardest to achieve and the one almost never specified until it is needed.

Ask which of the four your obligation actually requires. Some regulations only demand residency. Others demand all four without saying so explicitly, and you find out at audit.

Where the requirement comes from

Sovereignty requirements rarely arrive as a single rule. They accumulate from several directions at once, and the architect's job is often to reconcile them.

Financial services regulation drives most of it. Operational resilience frameworks, outsourcing rules and material-service-provider obligations all impose constraints on where processing happens and who can reach it. In Australia that is APRA CPS 234 and CPS 230. In Europe it is DORA. The UK has its own operational resilience regime, and the Gulf states have been building theirs rapidly, with several jurisdictions now running their own cloud and data classification frameworks.

Then there is sector-specific regulation, government procurement policy, and increasingly national AI strategy, which is bringing a new set of requirements about where models are trained and where inference runs.

Do not design from a generic framework

Sovereignty rules are jurisdiction-specific and they change. Get the current text of the obligations that actually apply to your customer, in their jurisdiction, and design against that rather than against a summary. A control narrative built on last year's interpretation is worse than none, because it creates confidence that is not warranted.

Decomposing it into design decisions

Once you know which of the four dimensions apply, the design work is concrete.

Placement policy. Which workloads can run where, enforced by the platform rather than by convention. If placement is a policy a human applies, it will drift.
Data flows, mapped end to end. Including backups, replicas, log shipping, telemetry and support bundles. The support bundle is the classic failure, because it leaves the jurisdiction by design and nobody thinks of it as data.
Key management. Who holds the keys, where the key management system runs, and whether the platform operator can technically decrypt. This is often the single most load-bearing control in a sovereignty argument.
Access model. Which support personnel can reach the environment, from which locations, under what approval, and whether that is enforced or merely documented.
Evidence generation. Not whether the control exists, but whether you can produce evidence that it operated continuously. Point-in-time compliance is not the same as continuous compliance, and regulators have noticed.
Exit and reconstitution. If the operator relationship ends, can you rebuild elsewhere, and how long would it take. Write down the actual answer.

The controls that carry the weight

Three platform capabilities do most of the work in a modern sovereignty design, and they are worth understanding properly rather than citing.

Encryption with customer-held keys. Data at rest and in transit is table stakes. The question that decides sovereignty arguments is who can decrypt, and whether the operator is structurally excluded rather than contractually excluded.

Confidential computing. Hardware-enforced memory encryption during processing, on both major CPU vendors now, closes the data-in-use gap that previously had to be handled with compensating controls and careful wording. For a jurisdictional sovereignty argument, a structural guarantee enforced in silicon is a materially different claim from a policy enforced in software.

Continuous compliance evidence. Automated, timestamped, machine-readable proof that controls operated. This is what converts a design into something defensible at audit, and it is the difference between a compliance state and a compliance event.

The commercial reality worth naming

Sovereign designs cost more. Smaller regional footprints mean less consolidation. In-country support is more expensive than follow-the-sun. Evidence generation is operational overhead. Exit capability requires deliberate portability that you would not otherwise build.

That is fine, provided it is stated. What damages a programme is discovering the premium halfway through, because the business case assumed hyperscale economics for a design that cannot use them. Model sovereignty as a cost line from the start, and make sure the people approving the requirement understand what they are approving.

What to do first

Establish which of the four sovereignty dimensions actually apply. Get it in writing from whoever owns the obligation, not from an assumption.
Map every data flow including telemetry, support bundles and backups. This is the exercise that finds the problems.
Answer the key management question early. It shapes everything downstream and it is expensive to revisit.
Decide what evidence you must produce and how it gets generated, before designing the controls that produce it.
Price the sovereignty premium explicitly and put it in front of the sponsor at the start.

Where this is heading

Two things are pushing sovereignty from a specialist concern to a mainstream design constraint.

The first is AI. Inference on sensitive data raises the data-in-use question in a form that cannot be answered with a contractual assurance, which is why confidential computing has moved from research to product so quickly.

The second is that several jurisdictions are building national AI and cloud strategies with sovereignty designed in from the start rather than retrofitted. That is generating a genuinely new class of requirement, and architects who have thought it through properly are going to be in demand for a while.

This is a framework rather than legal advice. Jurisdictional requirements differ and change; verify the current obligations that apply to your organisation.

Views expressed here are my own.