A European retail bank set its cloud strategy around two requirements its procurement team had written into the same sentence: the cost profile of a US hyperscaler and the data residency guarantees of a sovereign cloud. Eighteen months later it was running three public clouds and a private region, maintaining four variants of every data pipeline, and had achieved neither the economics nor the assurance it set out to buy. The data engineering team was quietly burning out keeping the copies in step. By the time the architecture reached us for review, the pattern was clear: the contradiction was real, but it was not procurement’s to resolve, because it had never been a procurement question.
Sovereignty and efficiency are usually presented as a straight trade-off. Keep data in-country under a provider that answers only to European law and you pay more, move slower, and give up the newest managed services. Chase the economics of a mainstream hyperscaler architecture and you inherit a jurisdiction and transfer problem you cannot fully contract your way out of. Framed like that, every organisation is choosing a point on a line and then defending that point to an auditor. The framing is wrong, and it is wrong in the same way across every industry we work in.
This is the first of six posts on the engineering layer underneath enterprise strategy. Each one takes an issue that boardrooms treat as a matter of policy or purchasing and shows where it actually lives, which is in architecture. This post runs the sovereignty-versus-efficiency question across four settings that look unrelated, a bank, a government department, a pharmaceutical company, and a media business, and shows that the organisations winning in all four are engineering the trade-off into their data and identity layers rather than asking a cloud provider to sell them a resolution.
The audit finding that started this
The bank’s three-cloud sprawl did not begin with an architect, it began with an audit finding.
An operational resilience review flagged concentration risk: too much of the business depended on a single ICT provider, in a single provider’s regions, with no tested path to move. Under the Digital Operational Resilience Act, that finding is no longer a matter of prudence, it is a supervised obligation, complete with an EU oversight regime for the critical third-party providers the sector leans on (European Parliament and Council, 2022). The bank read the finding as an instruction to diversify providers, so it diversified providers. The concentration risk moved into a new form, operational fragmentation, and the residency question it thought it was also solving stayed unsolved.
The same finding lands differently in each of our other three settings, which is the point. A government department gets the finding as a procurement rule: regulated workloads of a given classification must run on an accredited sovereign platform, full stop. A pharmaceutical company gets it as an inspection risk: trial and manufacturing records must be attributable, complete, and available to a regulator years later, wherever the underlying compute happens to sit. A media business gets it as a cross-border data risk, both commercial and contractual: audience data gathered in one jurisdiction cannot freely power personalisation run in another, and rights windows differ by territory.
Four organisations, four framings, one underlying question. Each one first tried to answer it by choosing a provider or writing a policy, and each one discovered that the provider and the policy were the wrong instruments. The bank could not buy its way out with a fourth environment. The department could not procure its way to a system it could actually operate. The pharmaceutical company could not attest its way past an architecture that scattered records across regions it could not evidence. The tension does not resolve at the layer where these organisations reached for it first.
What sovereignty actually means in 2026
Part of the confusion is that “data sovereignty” names at least three different properties, and organisations buy one while believing they have bought all three. Data residency is the weakest: the bytes sit inside a defined geography. Jurisdictional control is stronger: the entity operating the platform is not compellable under foreign law to hand the data over. Operational sovereignty is stronger still: the platform can keep running, and you can keep your keys and your access, even if the relationship with the provider is severed.
The providers have noticed, and 2026 is the first year the market offers real answers rather than marketing. AWS opened its European Sovereign Cloud as a separate, EU-operated region with its own governance and controls, generally available from the start of the year (Amazon Web Services, 2026). Microsoft has extended its sovereign offering with in-Europe data handling and customer-held key controls (Microsoft, 2025), and Google has built a portfolio spanning a data boundary, dedicated deployments with local operators, and air-gapped options (Google Cloud, 2025). These are credible engineering, not slideware. But they sit on a spectrum, and where the sufficient point falls is not the provider’s decision to make.
Read as a ladder of rising strictness, the four settings sort themselves cleanly. For the media business, residency plus contractual assurance is often enough, and the newest managed services matter more than the strongest isolation. For the bank, and for any financial services cloud holding customer records, jurisdictional control is the live question, because the cross-border data transfer regime underneath it keeps moving. For the pharmaceutical company, the sovereignty question is really a durability question: the records have to stay evidenceable in place for years, whichever region ran the compute. For the government department, the bar is higher again: France’s SecNumCloud qualification, for instance, requires the operator to be EU-owned, EU-headquartered, and immune from extra-European law, which rules out most of the hyperscaler estate regardless of where the data physically rests (ANSSI, 2022). Four defensible answers, four different points on the same spectrum. An organisation that treats “sovereign cloud” as a single product it can select is already mispricing its own requirement.
Where efficiency disappears
The efficiency half of the trade-off is misunderstood in a mirror-image way. Executives imagine cloud efficiency is lost at the sticker price, the premium per virtual machine on a sovereign platform versus a mainstream region. That premium is real but small. The efficiency that actually disappears is engineering efficiency, and it disappears through fragmentation.
Go back to the bank. Three clouds and a private region is a multi-cloud architecture nobody designed on purpose. It is not three times the cost of one, it is considerably worse, because almost nothing crosses the boundaries cleanly. Every data pipeline exists in variants, one per environment, each drifting from the others. Security posture forks: identity, secrets, network policy, and logging are configured four times, by four subteams, with four sets of subtle differences that only surface during an incident. Data egress between environments becomes a line item nobody forecast. And the scarce engineers who understand the whole estate spend their time reconciling environments instead of building anything. This is where the burnout came from, and it is a direct, predictable output of resolving sovereignty at the procurement layer.
The pattern recurs. The government department that stands up an isolated sovereign enclave, then runs a parallel mainstream estate for everything else, has doubled its platform surface and halved the rate at which either side improves. The pharmaceutical company that keeps regulated records in one architecture and analytics in another discovers that the join between them, the thing that actually creates value, is the least governed and most fragile part of the system. Efficiency does not leave through the front door marked “sovereign premium.” It leaks out of every seam between the environments an organisation created to keep sovereignty and efficiency apart.
Engineering both at once
The organisations that win on both axes share a move: they stop treating placement as a per-project choice and start treating it as a property of the platform, expressed in code. Instead of asking, for each workload, “which environment does this go in,” they define once, as policy, the rules that decide. This class of data, at this classification, for subjects in this jurisdiction, may run in these places and no others. The rule is versioned, tested, and enforced at deploy time, so a workload cannot land somewhere its data is not allowed to be, and an auditor can read the rule rather than trust a promise.
Two engineering surfaces make that possible. The first is a data layer that carries residency and classification as first-class metadata, not as a spreadsheet maintained alongside the system. When every dataset knows what it is and where it may live, placement stops being a judgement call and becomes a lookup. The second is workload identity that is portable across providers, so the security posture does not fork every time a new environment appears. If an agent, a service, or a person is authenticated and authorised the same way regardless of which cloud a workload sits in, then adding a sovereign region is a placement decision, not a second security programme. This is the work Sakura’s Cloud practice does: attested foundations where placement is policy and identity is uniform, so sovereignty becomes a configuration rather than a fork.
None of this is theoretical, and it does not have to be slow. A regulated institution that builds a clean, attested foundation can move at a speed that surprises people who assume regulation and velocity trade off against each other; Xapo Bank is one worked example, reaching production on a tightly governed stack in weeks rather than quarters. The residency and jurisdiction requirements did not go away. They were engineered into the foundation once, so that every subsequent workload inherited them instead of relitigating them.
The next two years
The reason this cannot be left as a procurement posture is that the ground underneath it keeps shifting. The mechanism that currently lets European personal data flow to US-operated infrastructure is an adequacy decision the Court of Justice has already struck down once in a prior form, and which was restored only in 2023 under a new framework that is itself under live legal challenge (Court of Justice of the European Union, 2020; European Commission, 2023). An architecture that assumes today’s transfer regime holds forever is one court ruling away from an emergency migration. An architecture where residency is a runtime property, enforced by policy over a data layer that knows where each dataset may live, absorbs that ruling as a configuration change.
The pharmaceutical case makes the durability requirement concrete. Records governed by the FDA’s electronic-records rules must stay attributable, contemporaneous, and available for years, with intact audit trails, regardless of which region the compute ran in (U.S. Food and Drug Administration, n.d.). You cannot retrofit that property onto a scattered estate after an inspector asks. It has to be a characteristic of the platform from the start, which is the same conclusion the bank, the department, and the media business each reach from their own direction. Sovereignty and efficiency stop being opposing choices at the moment they become properties an organisation designs into the layer beneath the strategy, rather than terms it negotiates at the desk. The organisations spending the next two years engineering that layer will have both. The ones still choosing a point on a line will keep paying for both and keep getting neither.
The organisations that treat residency and identity as engineering surfaces rather than contract clauses are the ones getting the economics and the assurance at the same time, and building that layer underneath the strategy is the work Sakura’s Data & AI practice does.
References
Amazon Web Services, 2026. Opening the AWS European Sovereign Cloud. AWS News Blog. Available at: https://aws.amazon.com/blogs/aws/opening-the-aws-european-sovereign-cloud/ [Accessed 1 July 2026].
ANSSI, 2022. SecNumCloud: référentiel d’exigences pour les prestataires de services d’informatique en nuage, version 3.2. Agence nationale de la sécurité des systèmes d’information, Paris. Available at: https://cyber.gouv.fr/secnumcloud-pour-les-fournisseurs-de-services-cloud [Accessed 1 July 2026].
Court of Justice of the European Union, 2020. Data Protection Commissioner v Facebook Ireland Ltd and Maximillian Schrems (Schrems II), Case C-311/18, ECLI:EU:C:2020:559. Available at: https://curia.europa.eu/juris/liste.jsf?num=C-311/18 [Accessed 1 July 2026].
European Commission, 2023. Commission Implementing Decision (EU) 2023/1795 of 10 July 2023 pursuant to Regulation (EU) 2016/679 on the adequate level of protection of personal data under the EU-US Data Privacy Framework. Official Journal of the European Union, L 231, 20 September, pp. 118-228. Available at: https://eur-lex.europa.eu/eli/dec_impl/2023/1795/oj [Accessed 1 July 2026].
European Parliament and Council, 2022. Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (Digital Operational Resilience Act). Official Journal of the European Union, L 333, 27 December, pp. 1-79. Available at: https://eur-lex.europa.eu/eli/reg/2022/2554/oj [Accessed 1 July 2026].
Google Cloud, 2025. Sovereign Cloud from Google. Available at: https://cloud.google.com/sovereign-cloud [Accessed 1 July 2026].
Microsoft, 2025. Announcing comprehensive sovereign solutions empowering European organizations. Official Microsoft Blog. Available at: https://blogs.microsoft.com/blog/2025/06/16/announcing-comprehensive-sovereign-solutions-empowering-european-organizations/ [Accessed 1 July 2026].
U.S. Food and Drug Administration, n.d. 21 CFR Part 11: Electronic Records; Electronic Signatures. Code of Federal Regulations, Title 21, Chapter I, Subchapter A, Part 11. Available at: https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11 [Accessed 1 July 2026].