The agency in this story is a composite, drawn from several engagements, though every detail in it is one we’ve seen. It signed a sovereign cloud contract after a careful procurement. The platform was certified, the data would stay in-country, and the provider’s operating entity met the ownership conditions the policy asked for. Well into the second year, a team mapping dependencies for an unrelated migration counted thirty-two services in the agency’s stack that still reached outside the sovereign boundary. The identity directory synchronised to a global tenant. Logs and traces went to a monitoring service hosted overseas, and that vendor’s support staff, in another jurisdiction, could see them. A CI/CD service and a handful of developer tools each had their own route out. Separately, the platform’s key management service was still running on the provider’s defaults, with the settings that would have given the agency its own key custody left for a later phase.
The contract covered the platform well and said very little about everything around it. Procurement had bought what the policy described, a sovereign platform, and the engineering team inherited it the way engineering teams usually inherit contracts: after signature, with a delivery date attached. In our experience that’s where sovereignty tends to leak, in the systems that surround the platform: who holds the keys, where people authenticate, what the data layer will accept, where telemetry goes, and what the contract lets engineers actually check. Our earlier series, The Engineering Underneath, made the cross-industry case that sovereignty gets settled in the architecture as much as at the procurement desk (see Sovereignty Versus Efficiency). Government cloud architecture is where that argument has the most at stake, and where the frameworks are explicit enough to show the gap clearly.
The thirty-two services
None of the thirty-two arrived as a sovereignty decision. The identity directory had been set up years earlier for email and collaboration, and the new platform simply federated to it. The monitoring service was already the agency’s standard, so new workloads were pointed at it on day one. Endpoint agents, the CI/CD service, and the developer tools were each approved separately, by different teams, for good reasons. The platform’s certification didn’t catch them either, and it wasn’t asked to. The agency’s own system authorisations had each looked at one workload at a time, so nobody had assessed the estate as a whole.
Each government cloud framework points at the wider picture, although they differ a lot in how much sovereignty they demand. France’s SecNumCloud qualification is aimed at protecting sensitive data from both cyber threats and extraterritorial law, and ANSSI notes that the qualification says nothing about the security of the customer services built on a qualified offer (ANSSI, n.d.). A qualified platform, in other words, doesn’t make what runs on it sovereign. Australia’s Hosting Certification Framework separates Assured certification from Strategic certification, the highest level, which is only available to providers that let government specify ownership and control conditions. It covers sensitive government data, whole-of-government systems, and systems rated PROTECTED (Department of Home Affairs, n.d.a), and it’s currently being reformed, with new certification registrations paused since November 2025 (Department of Home Affairs, n.d.b). The UK takes a risk-based line. The National Cyber Security Centre’s cloud guidance asks organisations to know where their data is and who can access it, including derivatives such as verbose logs, and it points out that data held in a local region may still be reached through an authentication service replicated worldwide (National Cyber Security Centre, 2018).
These regimes ask for very different amounts of sovereignty, and this post isn’t arguing for more of it across all public sector cloud use. Most OFFICIAL workloads don’t need a hard sovereign boundary, and building one for them is expensive. The argument is about where a commitment leaks once an agency has decided it needs one, whatever its jurisdiction and whichever provider it uses. For those workloads, a government cloud strategy built around the platform alone leaves most of the outcome to chance. Five decisions do most of the work, and in many agencies they sit with different owners, so nobody holds the whole picture.
The five decisions
Where the keys live
The first decision is who can decrypt the data. Encryption at rest is standard on every major platform. What varies is custody. If the provider generates and holds the keys, protection rests on the provider’s controls and on the laws the provider answers to. If the agency holds the keys in its own hardware security modules, outside the provider’s reach, a demand made of the provider largely yields ciphertext for data at rest, provided the provider’s services can’t be compelled to request key unwraps on the agency’s behalf. Data in use is a separate problem, because anything the provider’s services process in plaintext is still exposed, and that’s where confidential computing and service design come in. Most arrangements sit in between, with customer-managed keys stored in the provider’s key service, and the details of that middle ground matter.
For a lot of workloads, the provider’s key service is the right answer, and the NCSC accepts a provider’s cloud-hosted key management service as a way to protect keys through their lifecycle (National Cyber Security Centre, 2018). The higher the classification, the more the custody question matters, because sovereign data residency and actual control can part ways: data can sit in the right country on a certified platform and still be readable by whoever can reach the keys. Holding keys independently has real costs, including an operational burden, availability planning for the key service itself, and some platform features that stop working when the provider can’t see plaintext. Those costs belong in the decision, made on purpose, rather than deferred to a phase that doesn’t get funded.
Where the identity provider lives
Next comes where people and workloads authenticate. Whoever controls authentication controls access to everything the keys protect, and an agency can keep every byte in-country while routing every login, token, and administrative session through a service that lives elsewhere. That’s the case the NCSC describes, and in the composite agency the directory synchronised to a global tenant was the largest single reason the boundary didn’t hold.
A sovereign identity layer means the directory, the token service, and the privileged access paths for administrators sit inside the boundary, or are federated so the authoritative decision is made inside it. It also means support access gets engineered: who can open a privileged session, from where, with whose approval, and with what record left behind. Provider support access is sometimes necessary, and it should be rare, time-bound, approved by the agency, and logged somewhere the agency controls. Public sector security teams already hold their own administrators to that standard, and it has to reach the provider’s people too. This is also the most expensive of the five to change. When the directory in question is the one that runs email and collaboration for the whole agency, moving it inside the boundary can be a multi-year programme, and for many workloads a well-controlled federation is the realistic answer.
What the data layer actually accepts
The third decision is whether the data layer enforces the rules on government data sovereignty or only documents them. In our experience most agencies classify their data carefully, and far fewer have a data layer that refuses to put a record where its classification says it can’t go. Without enforcement, a backup policy replicates to a second region for resilience, an analytics team spins up a workspace in a default location, or a managed service creates a cache somewhere convenient. Each is a reasonable default, set by someone doing their job.
Enforcement means classification travels with the data as metadata, and placement rules are written as policy that the platform evaluates when resources are created and when data moves. A storage account in a region that isn’t permitted fails to deploy, and a replication rule that crosses the boundary is rejected with a clear reason. Derived data counts too: backups, snapshots, replicas, extracts, and the features built from them for analytics. In a public sector multi-cloud estate this gets harder, because each provider expresses these controls differently, and the agency needs one policy that means the same thing everywhere it runs.
Where the telemetry goes
Telemetry catches a lot of teams. Logs, traces, metrics, and crash reports are data about the system, and they very often carry data from it: identifiers, request payloads, query parameters, and error messages that quote the record they failed on. The NCSC lists credentials, configuration data, derived metadata, and logs among the data types most often overlooked (National Cyber Security Centre, 2018). In the composite agency, the overseas monitoring service was receiving a steady stream of exactly that, and the vendor’s support staff could read it.
Keep telemetry inside the boundary, or scrub it before it leaves, so observability doesn’t become the easiest way out. Then watch what leaves at all. An agency can only show where its data goes for the traffic it can see, and egress monitoring that records every connection leaving the boundary, by service and destination, would have surfaced most of the thirty-two on day one rather than well into the second year. It won’t show key custody or how federation is configured, which is why it sits alongside the other decisions, and it’s also what catches the next developer tool that ships with an undeclared path home.
The contract the engineering team can hold
The fifth decision is to write the sovereign commitment in terms engineers can test. Procurement teams do careful work on ownership, jurisdiction, liability, and exit. What often goes unwritten are the technical conditions that make those terms real, and they fall into two groups. Some belong in the contract, because the provider has to support and evidence them: where keys can be held, which regions data may occupy, how provider support access is approved and recorded, and what an exit looks like in practice. Others are the agency’s own architecture decisions, such as where identity is resolved and where telemetry may go, and they belong in a design record kept alongside the contract, so the engineering team is held to them as firmly as the provider is held to its side. Exit deserves a sentence of its own, because an agency that can’t move a workload off a provider in a stated time, or keep it running if the provider’s global control plane is cut off, has less control than its contract suggests.
The broader shift in government assurance points the same way. FedRAMP 20x, the US programme’s overhaul of cloud security assessment and certification, rests on principles that treat a provider’s security as something to be enforced and reported continuously, and that give ongoing evidence more weight than written policy (FedRAMP, 2026). Those principles are aimed at providers, and they work just as well for the conditions an agency writes down for itself. Singapore’s Government on Commercial Cloud is a platform rather than a certification regime, and its emphasis is assurance and speed more than sovereignty: it gives agencies a standardised way onto commercial cloud and builds continuous compliance, observability, and auditability into the platform. GovTech reports that more than seventy percent of eligible government systems now run on it (GovTech Singapore, 2025).
Sakura saw a small version of the same idea with SkillsFuture Singapore, where controls were engineered into the platform and every API was tested for conformance before release (SkillsFuture Singapore case study). Building the enforced, provider-neutral foundation that makes conditions like these testable is a large part of what Sakura’s Cloud practice does for public sector clients.
The practical step is for procurement and engineering to sit down together before the tender or call-off goes out, so that sovereign cloud procurement specifies the architecture around the platform as well as the platform itself, and the engineering team inherits a commitment it can check.
Turning those conditions into controls an agency can evidence on demand, and keeping them true as the estate changes, is work Sakura’s GRC service does alongside agency engineering and procurement teams.
References
ANSSI, n.d. Cloud: posture générale et actions de l’ANSSI sur le cloud (SecNumCloud). Agence nationale de la sécurité des systèmes d’information. Available at: https://cyber.gouv.fr/enjeux-technologiques/cloud/ [Accessed 29 September 2026].
Department of Home Affairs, n.d.a. Hosting Certification Framework: framework overview. Australian Government. Available at: https://www.hostingcertification.gov.au/framework [Accessed 29 September 2026].
Department of Home Affairs, n.d.b. Hosting Certification Framework: home. Australian Government. Available at: https://www.hostingcertification.gov.au/ [Accessed 29 September 2026].
FedRAMP, 2026. FedRAMP 20x. US General Services Administration. Available at: https://www.fedramp.gov/20x [Accessed 29 September 2026].
GovTech Singapore, 2025. Government on Commercial Cloud (GCC). Government Technology Agency of Singapore, last updated 26 September 2025. Available at: https://www.tech.gov.sg/products-and-services/for-government-agencies/software-development/government-on-commercial-cloud/ [Accessed 29 September 2026].
National Cyber Security Centre, 2018. Cloud security guidance, Principle 2: asset protection and resilience. Version 2.1, reviewed 7 June 2023. Available at: https://www.ncsc.gov.uk/collection/cloud/the-cloud-security-principles/principle-2-asset-protection-and-resilience [Accessed 29 September 2026].