A Reference Architecture for a Sovereign Government Cloud

Two articles set this one up. The first mapped the mismatch between Decree 2018-062 and the Kubernetes mental model: a body of law that reasons in stable, locatable entities, a platform that dissolves those anchors, and four real gaps that follow. The second argued that multi-cloud does not answer a jurisdictional question and that it multiplies exposure rather than dividing it. Both are critical by construction: they say what breaks and what does not fix it. They leave open the only question a public administration actually cares about, which is what to build instead.

This article answers that in the form of a reference architecture. Not a deployment tutorial, not a named case study, not a product list. An architecture document in the strict sense: a set of requirements derived from the applicable legal texts, a series of design choices justified against those requirements, an operating model that states what team and what budget it takes to hold the whole thing together, and above all a statement of limits, because a reference architecture that never says when it is the wrong choice is not a reference architecture, it is a brochure.

The thesis fits in one sentence. Sovereignty is not a contractual clause you obtain from a vendor, it is an architectural property you build and must be able to prove. The rest of this article is about making that sentence operational.

One methodological note before the substance. This article is written in pure reference-architecture mode. The choices below are informed by hands-on practice operating regulated platforms, but no organisation is named, no attributable measurement is cited, and no identifiable topology is described. Field lessons are stated at the level of the sector, never at the level of a particular deployment.

Requirements derived from the legal texts

The classic mistake is to design the platform first and then look for ways to make it compliant afterwards. This section does the opposite: it turns legal obligations into numbered non-functional requirements, each with a verification criterion. It is this requirement set, and not a tooling preference, that justifies every choice in the sections that follow.

Three of these deserve to be flagged immediately, because they are the ones that swing the architectural decision. EX-2, EX-4 and EX-12 are precisely the three that article 1 identified as structural Kubernetes gaps, and they are also the ones a managed cluster at a foreign provider makes hardest to satisfy: storage geography there is a property of the service rather than a documentable choice, identity stops at the ServiceAccount, and the scope of action of the provider's own controllers is neither inventoriable nor negotiable. A sovereign architecture should be judged on those three lines first. The others, a competent operator satisfies more or less anywhere.

Scope and assumptions

A reference architecture with no declared scope cannot be criticised, and is therefore useless. Here is what this one targets and what it excludes.

The target workloads are those of a public administration: citizen service portals, administrative registries (civil status, land, tax, vehicle registration), agency back offices, interoperability APIs between administrations, document management, internal line-of-business applications. The order of magnitude assumed is tens to a few hundred application services, with traffic that is mostly daytime, national, and with peaks that are largely predictable: tax deadlines, school enrolment campaigns, election periods, benefit disbursements. That predictability is an important property, and the final comparison comes back to it, because it changes the value of elasticity entirely.

Out of scope: high performance computing, large-scale model training, a telecom operator's network core, and real-time critical systems in healthcare or defence. Those domains have their own constraints and their own frameworks, and pretending a single architecture covers them would be dishonest.

Three assumptions condition everything else, and if one of them fails the architecture must be revisited. First, at least two distinct machine rooms with a link between them; a single room rules out any serious continuity story, and saying so early avoids selling a promise the topology cannot keep. Second, the possibility of an upfront hardware investment, which is not a given in an annualised budget framework where operating expenditure is easier to obtain than capital expenditure. Third, a permanent team, as opposed to a project staffed with a contractor for eighteen months and then left to itself.

One regional factor weighs on the choices: international transit is expensive and sometimes unstable, while latency to a distant region degrades the experience of services that are entirely domestic. Local hosting therefore has a technical justification independent of the legal one, and that is worth noting, because a sovereignty argument that also rests on performance is much harder to wave away than a purely regulatory one.

The foundational choice: bare metal, virtualisation, or both

This is the decision that constrains all the others, and it is settled on compliance grounds as much as on performance.

Three serious options exist. Pure bare metal puts Kubernetes directly on physical servers: maximum density, maximum performance, a single management plane to operate, but isolation between workloads rests entirely on Kubernetes mechanisms. Full virtualisation installs a hypervisor and then Kubernetes clusters inside virtual machines: two management planes, a density loss of a few percent on compute and more on memory, but a hardware isolation boundary and the ability to host alongside it the legacy systems that will never be containerised. The third option, managed Kubernetes at a national operator, is covered in the final comparison; it changes the responsibility model more than the technical architecture.

The deciding criterion is not performance, it is EX-6 read through an auditor's eyes. In a shared cluster, isolation between agencies rests on namespaces, RBAC and NetworkPolicies. Those are logical boundaries, enforced by a shared kernel and a shared control plane. As long as the hosted agencies have comparable requirements, that boundary is acceptable and defensible. As soon as two agencies carry different classifications, or one processes data whose compromise creates liability for the other, the audit question becomes: what physically prevents a workload belonging to agency A from reaching agency B's data in the event of a container escape. Answering "RBAC" is not an answer to that question.

The reference recommendation is therefore mixed, and owned as a compromise. A light virtualisation layer based on KVM, operated for instance with Proxmox VE or an equivalent distribution, provides the substrate. On top of it, a shared Kubernetes cluster hosts the large majority of workloads, effectively bare metal from the application's point of view since the nodes are dedicated virtual machines and not shared with anything else. Workloads whose classification demands it get their own cluster on physically separate hosts. Legacy systems that will never be containerised live as virtual machines on the same substrate, which avoids maintaining two parallel infrastructures.

That choice costs three things worth naming. Lost density, and therefore additional hardware. A second management plane to operate, back up and patch, with the skills that implies. And harder diagnosis, because a performance problem can now originate in two layers instead of one.

A note on hypervisor selection, which goes straight to the subject of this article. A platform's sovereignty is also judged on its licensing dependencies. VMware moving under Broadcom's control, and the licensing overhaul that followed, was a reminder that a proprietary infrastructure layer is a lever held by a foreign third party regardless of where the servers sit. A state that builds a sovereign platform on a hypervisor whose pricing and terms can be redefined unilaterally from another jurisdiction reproduces at the bottom layer exactly the dependency it was trying to avoid at the top. That is an argument for KVM and its open ecosystem, not a comparative technical quality judgement.

Two intermediate mechanisms are worth knowing without being the default recommendation. Container sandboxes such as gVisor or Kata Containers offer stronger isolation without the full cost of a virtual machine per workload. They carry a real performance cost and a non-zero operational burden, and they complicate diagnosis. They fit a subset of higher-risk workloads inside a shared cluster, not a general substrate.

The orchestration layer

The components below form the reference stack. Each is justified by a requirement, and each is presented with the serious alternative that was rejected and the reason for rejecting it. A stack that does not show its alternatives is not justified, it is merely described.

Several of these need commentary, because they are trade-offs rather than obvious calls.

On the installer. Kubespray is heavy, slow, and its Ansible inventory quickly becomes an artifact you have to maintain yourself. Its two decisive qualities in this context are offline installation, which matters when international transit is expensive or cut, and the complete absence of any third-party service dependency across the cluster lifecycle. The newer distributions, RKE2 and especially Talos Linux, cut the attack surface significantly: Talos removes the host shell and package manager entirely and drives everything through an API, which serves EX-5 and EX-6 directly. A team with no existing Ansible culture will probably get further with RKE2 or Talos than with Kubespray. The deciding criterion is available skill, not intrinsic superiority.

On the CNI. Calico is the sober choice here. Cilium, built on eBPF, offers richer policy, application-layer visibility and, with Hubble, flow observability that would genuinely contribute to EX-3. It is objectively the better tool for network auditing. It also demands recent kernels, an understanding of eBPF to debug the awkward cases, and it moves part of the network behaviour into a layer few teams can inspect. Recommending Calico here is an owned operability choice, not a value judgement: in a team fluent in eBPF, Cilium is the better call.

On load balancing. MetalLB in BGP mode is clearly superior to layer 2 mode, which funnels all of a service's traffic through a single node. But BGP mode assumes cooperation with the network team, a peering session on the routers, and a shared understanding of the addressing plan. In a public administration this is almost always where the project stalls, and the blocker is organisational rather than technical. Anticipating that conversation at design time saves months.

On the PKI, which is the most underrated point here. Two trust planes must be separated, and they are routinely conflated. Publicly exposed services need certificates trusted by browsers the state does not control: ACME and a public authority remain the rational choice, the constraint being endured rather than chosen. Internal traffic is a different matter. Service-to-service mTLS, cluster component certificates, node and agent authentication all rest on a trust root. If that root is a foreign authority, then the internal authentication of a sovereign platform depends on a third party outside the jurisdiction, with its revocation policy, its terms of service and its availability. An internal root held by the state, kept offline, with intermediate authorities issuing through cert-manager, solves this cleanly. It is cheap to set up and rarely done, and it is one of the few places where sovereignty is actually earned rather than declared.

On GitOps as an evidence mechanism. Argo CD is chosen here not for deployment convenience but for its evidentiary value. When the Git repository is the source of truth, every platform change becomes a signed, reviewed, timestamped commit attributed to a named person. Answering an auditor who asks who changed a given service's network policy and when no longer means digging through raw logs, it means showing a history designed to be read. That serves EX-3 and contributes to EX-12.

Two conditions make that evidentiary value real, and without them the argument collapses. First, direct write access to the cluster must be locked down: if teams can still apply manifests by hand, the Git history describes an imaginary cluster. Second, the Git repository itself becomes a regulated asset, subject to the same retention, integrity and access control requirements as the logs, which means hosting it on the sovereign platform and not at a foreign code host. A sovereign platform whose source of truth lives in a repository under foreign jurisdiction has moved the problem rather than solved it.

Storage

Storage is where EX-2 is won or lost, and it is also where teams most often overestimate themselves.

The guiding principle is simple: pick the simplest solution that meets the continuity objectives, not the most capable one. The recommendation is tiered, because there is no single right answer.

For a modest usable volume, one primary room and a small team, a storage array exposed over NFS or iSCSI, complemented by local storage for workloads that do not need replication, is a defensible choice. Everyone understands it, everyone can restore from it, and its failure mode is diagnosable at three in the morning on a Sunday.

For an intermediate volume, Longhorn brings block-level replication across nodes, snapshots, and backup to an object target, at an operational cost far below that of a full distributed system. Its limit is real on I/O-intensive workloads, particularly active databases.

For a large volume, multiple rooms, or a need for object storage alongside block, Ceph is the technically correct answer: block through RBD, object through RGW, filesystem through CephFS, all in one replicated system. But it is worth being blunt about what that implies. Ceph demands dedicated, permanent expertise, not a one-off ramp-up. A poorly sized or poorly operated Ceph is a major failure mode, capable of taking the whole platform down, and recovering it requires expertise you cannot acquire under pressure. The practical rule is that a Longhorn you understand beats a Ceph you endure.

On the compliance side, what this choice buys is decisive. In a managed cluster, a StorageClass is a name that hides a regional service whose replication geography is neither visible nor negotiable. Here, each StorageClass maps to a set of disks whose chassis, room and address are known. EX-2 stops being a good-faith declaration and becomes a verifiable inventory, which is exactly the first gap from article 1 closing.

Encryption at rest (EX-7) is handled at two levels that do not substitute for each other. Encrypting the underlying disks, through LUKS on the devices or the storage system's native mechanism, protects against hardware theft and mishandled decommissioning. It does not protect against legitimate logical access to a running system. For the most sensitive data, application-level encryption, with keys never held by the infrastructure layer, is the only measure that withstands a platform administrator. Which data categories deserve that second level should be an explicit decision, rather than encrypting the disks and considering the matter closed.

Backup combines three distinct things that are often conflated: volume snapshots, which protect against application error and live in the same storage system; backup of Kubernetes objects and volumes, with Velero for instance, to a local object target; and the off-site copy in the second room, which is the only one that protects against losing the primary site. Object lock on the backup target satisfies EX-5 by making backups immutable for their retention period, which is also the most effective control against ransomware that would try to destroy backups before encrypting production.

One point deserves to be stated without hedging: a backup never restored is not a backup, and EX-9 requires a measured RTO and RPO, not declared ones. A full restore exercise, scheduled, timed and documented, at least twice a year, is the only admissible evidence. It is also the first thing operational pressure drops.

Databases deserve an explicit decision. Running them in-cluster with a mature Operator such as CloudNativePG brings genuine automation of failover, continuous backup and point-in-time recovery. It also places an autonomous controller on the critical path of personal data, which is exactly the accountability gap described in article 1. The answer is not to give it up, it is to document it under EX-12: which Operator, which permissions, which destructive actions are possible, which team owns it, and what guardrails apply to operations that delete or move data.

Identity and authorisation

This is where the second structural requirement, EX-4, is settled, and it is the part of the architecture most often treated lightly even though it carries most of the compliance value.

The foundation is a single identity provider, Keycloak in this reference architecture, federating the agencies' existing directories rather than claiming to replace them. That nuance matters: in a public administration each agency has its directory, its habits and its governance, and a project that requires migrating every directory into a central repository fails for political reasons before it fails for technical ones. Federation centralises authentication without centralising account ownership.

Human access to the cluster goes through OIDC against that provider. The practical consequence is the end of unlimited-lifetime kubeconfig files carrying a client certificate, which circulate over email and outlive their holder's departure. Every administrative access becomes named, expiring and revocable from one place, and the API server audit log stops recording anonymous identities.

That settles accountability for access to the platform. It does not settle accountability for access to the data, which is what the law actually asks for. That is the job of the application authorisation layer.

The reference architecture uses a relationship-based model, with OpenFGA, inspired by Google's Zanzibar system. The reasoning is as follows. Rights in a public administration do not decompose into global roles, because they almost always depend on the relationship between the officer and the object: the caseworker assigned to this specific file, the line manager of the applicant, the agency the citizen belongs to, the deputy designated during leave, the department that temporarily delegated a competence to another. Modelling that with roles produces either a combinatorial explosion of roles, one per file or per perimeter, or authorisation logic scattered through each application's business code, where it becomes invisible, untestable and unauditable. A relationship model expresses those situations directly, and more importantly it centralises them in a single artifact.

The decisive argument for this article, though, is not modelling, it is evidence. An authorisation decision evaluated by a dedicated service is an event: a subject, a relation, an object, a result, a timestamp, a context. Logged, it constitutes exactly the trail that article 41 of the decree and article 69 ask for, at the level they ask for it, which is the data level rather than the infrastructure level. The API server audit log can tell you that a deployment's ServiceAccount listed Secrets; it will never tell you that a named officer viewed a named citizen's tax file on Tuesday at two in the afternoon. The authorisation decision log can, provided the architecture makes that possible.

That proviso is end-to-end identity propagation. It deserves to be stated precisely, because it is the point where most systems break the chain. The user's identity must travel from authentication down to the data access layer without being replaced along the way by a service identity. Three common practices break that chain: a connection pooler that funnels all database access through a single technical account, an intermediate API layer that re-authenticates with its own identity, and batch processing that acts on a user's behalf without retaining the reference to that user. Each of those breaks turns a named trail into a service trail, and makes EX-4 unsatisfiable regardless of the rest of the tooling. Design must therefore treat identity propagation as a first-order requirement, not an implementation detail.

The risks this layer introduces must be owned. The identity provider becomes a first-order single point of failure: if it goes down nobody signs in to anything, and it also becomes the most attractive target on the platform. It therefore requires real redundancy, tested backups of its database and its signing keys, and dedicated monitoring. The authorisation service adds one more call on the critical path of every request, with its consequences for latency and availability, which forces a caching strategy and a predefined degraded behaviour: denying or allowing when it is unavailable is a policy decision, not a default to discover during an incident. Finally, the authorisation model becomes a critical artifact to version, test and deploy with the same rigour as application code, because a modelling error there has the effect of a security flaw.

Observability and the audit trail

The most expensive confusion in this whole architecture is believing that observability covers auditing. These are two systems with two purposes, two audiences, two retention policies and two levels of integrity requirement. Merging them produces a stack that serves neither operations nor compliance well.

Operational telemetry exists to run the platform. Metrics with Prometheus, alerting with Alertmanager, visualisation with Grafana, application logs with Loki or an equivalent, distributed tracing if the application landscape warrants it. Its audience is the on-call team, its useful horizon is days or weeks, sampling is legitimate, and data loss is an inconvenience. It should be sized for diagnostic comfort, not for proof.

The regulatory audit trail exists to prove. It brings together four sources that are not interchangeable: API server auditing with an explicit policy, generally at metadata level for most resources and at request-and-response level for sensitive ones; personal data access logs emitted by the applications; authorisation decisions; and database access logs. Its audience is an auditor or a regulator, its horizon is twelve months minimum under EX-3, sampling is disqualifying, integrity is required under EX-5, and access to it must itself be restricted and logged.

The practical implication is that you need two storage destinations and two distinct policies. A Loki sized for fifteen days of retention proves nothing at day minus three hundred. Trace sampling that divides volume by ten destroys the evidentiary value of what it discards. An automatic purge policy designed to control storage costs can erase, with no intent and no alert, exactly the evidence an inspection will demand. All three mistakes are common and are discovered at the worst possible moment.

The twenty-four hour notification requirement (EX-8) needs its own attention, because it is usually treated as a documentation checkbox when it is in fact a timed process. Three questions must have a written answer before any incident. When the clock starts: at detection, which is the prudent reading, and not at legal qualification, otherwise the deadline becomes indefinitely extensible and indefensible. Who decides to notify, with a named deputy, because major incidents rarely occur during office hours. Through which channel, with what minimum content, to which recipient, and with what record of sending. An Alertmanager alert is not a regulatory notification, and the gap between the two is measured in hours lost looking for who has whose phone number.

One last point of method: compliance dashboards and operational dashboards should be separate. The former answers questions such as encryption coverage, the age of the last restore test, the number of workloads without a NetworkPolicy, the proportion of named administrative accesses. Those indicators are of no interest to the on-call engineer and are read once a month, but they turn compliance from a painful annual exercise into a continuously observed property.

The operating model

An architecture is only worth what an organisation can sustain. This is the part architecture documents most often omit, and it is the part that determines whether the project still exists in three years.

Four roles are necessary, and these are roles rather than headcount. Platform operations covers the cluster, network, storage and upgrades. Security and compliance covers policy, the audit trail, access reviews and incident response. The data role covers databases, backups and restore exercises. A design role maintains the coherence of the whole and arbitrates the hosted agencies' requests, without which the platform drifts into a collection of special cases.

Those roles require redundancy. A role held by one person is not held, it is borrowed from an individual until they leave or take leave. This is an experience-based judgement and I give it as such: below roughly five or six people covering those four roles with effective doubling, a platform of this kind is carried by individuals rather than by an organisation, and one departure becomes a major incident. That threshold is not a standard, it is an order of magnitude meant to be argued about during sizing rather than discovered afterwards.

The genuinely scarce skills in the sub-region are identifiable and should guide the technical choices. Operating a distributed storage system, BGP networking, running a PKI, structured incident response, and operating Kubernetes in the proper sense, which is a different thing from using it. Those skills are hard to hire and harder to retain, because the international market pays for them at levels a public administration cannot match. The architectural consequence has already been stated for storage and holds everywhere: systematically prefer the component the team can operate over the one that is technically superior. An architecture that assumes skills the organisation does not have is an architecture that will fail, however good it looks on paper.

On costs, I give a method rather than figures, and that decision deserves justifying. Publishing amounts that have not been measured in the target context would create a false anchor, and a figure imported from a European or North American comparison does not transfer: energy cost, salary cost, import duties and taxes on hardware, and international transit cost differ by enough to invert a conclusion. A serious costed analysis is a piece of work in its own right, with local sources, and it deserves its own article.

The method itself is stable. A five-year total cost of ownership is built on seven items. Hardware, servers, network and storage, amortised over five years, with an annual replacement rate for failures. Physical hosting, room, energy, cooling and electrical redundancy, an item that is regularly underestimated and particularly sensitive in a context where public grid supply is irregular and where the UPS and the generator are not optional. Connectivity, including the link between the two rooms. Support and subscriptions, including whichever distributions and commercial tools are retained. Human cost, which is the dominant item over five years by a wide margin. Training and certification, which are not an adjustment variable but the condition of the previous item. And audit and compliance, including internal time consumed by inspections.

Two items fall outside those seven and must be added explicitly. The ramp-up cost, meaning the period during which the team is paid to learn and produces less. And the exit cost, meaning what it would take to migrate off this architecture if the decision were reversed, a question nobody asks at investment time and everybody regrets not asking.

The structuring economic property of this architecture is that its cost is mostly fixed. Unit cost per hosted service therefore falls as the platform fills up, which is the exact inverse of an elastic bill. That shifts the right question. It is not which of the two options is cheaper in absolute terms, but at what usage level the two curves cross, and to note that a platform shared across several agencies reaches that crossing point far sooner than one dedicated to a single agency.

Field lessons

What follows are failure patterns observed across the sector, stated at sector level. They target no organisation and describe none. Their value is that they repeat: the same ones keep coming back, and they are almost always failures of discipline rather than of design.

Configuration drift leads the list. Without effective lockdown of direct cluster access, actual state gradually diverges from declared state, often for good reasons during the pressure of an incident. The symptom only appears much later: nobody dares rebuild a component any more, because nobody knows what was adjusted by hand and recorded nowhere.

The backup never restored is the most expensive classic. The backup job runs and reports success for two years, and the first restore attempt happens on the day it is vital. That is also the day you find out the backup did not contain everything it needed to, or that the real RTO is an order of magnitude above the announced one.

The etcd store is regularly forgotten. Many teams carefully back up application volumes without separately backing up cluster state, even though losing it is losing the cluster, and backing it up is both trivial and fast.

The identity provider installed temporarily as a single instance stays a single instance. It gets deployed early, to unblock other work, with a sincere intention to make it redundant later. It then becomes the component everything else depends on, and making it redundant requires a maintenance window nobody wants to own.

Certificates cause more incidents than attacks. The first major incident on an internal PKI is almost never a compromise, it is an expiry, often on an intermediate component nobody had put on a calendar. Automating issuance is not enough: it is the certificates outside cert-manager's scope, those on appliances and legacy systems, that expire.

The deferred upgrade turns routine into a project. Kubernetes moves at a sustained pace, and being two or three versions behind changes the nature of the exercise: it is no longer an upgrade, it is a migration, with API removals to handle and a risk profile that justifies deferring it again.

Finally, compliance discovered late. An architecture designed with the requirements from the start, as the first section of this article does, costs a fraction of what the same compliance costs when retrofitted three weeks before an inspection. That is not a moral argument, it is a cost observation.

Limits of this architecture

A reference architecture that does not say where it fails is not usable. Here are the cases where this one is the wrong choice, and the limits of the sovereignty it delivers.

It serves unpredictable peak workloads poorly. Sizing is done for the peak, so a workload whose peak is rare and far above its average is paid for in idle capacity all year. That is precisely why the scope declared above insists on the predictability of administrative peaks: if that assumption fails, the economic trade-off changes.

It does not provide access to advanced managed services. Large-scale analytical warehouses, managed artificial intelligence services and globally distributed databases have no self-hosted equivalent at comparable cost. Reproducing those services in house costs more than the dependency you were trying to avoid, and that should be admitted rather than papered over with the claim that the open ecosystem covers everything.

A single machine room provides no real continuity, and two rooms close together do not protect against a regional disaster, an extended power outage or a flood. The distance between sites is a design parameter, not a logistical detail.

The sovereignty obtained is jurisdictional and operational, not industrial, and that is the most important limit in this entire article. The servers, their firmware, their out-of-band management controllers and their network components are not sovereign: they are designed and manufactured elsewhere, and their supply chain is entirely beyond the reach of the state buying them. The out-of-band management controller deserves a special mention, because it constitutes a complete administrative surface, often left in a poorly segmented network, with default credentials and rarely updated firmware. A platform that is rigorous at the Kubernetes level and negligent at the hardware management level is not secure, it is badly audited.

The upstream open source dependency is real. The chosen components are developed by communities and companies outside the jurisdiction, with their own end-of-support decisions, their own licence changes, and their own pace of vulnerability fixes. Without organised monitoring and internal patching capacity, "open source" means "free", not "under control". The software supply chain extends that point: container images, Helm charts and operators pulled from public repositories enter the platform with a level of verification that is often nil. A local registry with vulnerability scanning and signature verification is necessary, failing which independence stops at the hardware layer.

Finally, the limit already set out in the previous article stands, and it bears repeating here to avoid any misunderstanding: a poorly operated sovereign platform is less safe than a well operated foreign one. This architecture does not remove the need for independent audit, it makes that audit possible. Being local is not a security qualification, it is a jurisdictional property.

An honest comparison with the alternatives

The table below compares four realistic options for a West African administration, on criteria derived from the requirement set rather than from vendor positioning.

None of these columns wins everywhere, and that is the point. Colocation with state operation is often the most realistic compromise to start with: it removes the building, the power and the electrical redundancy from the equation, all of which are trades in their own right, while keeping the control plane and accountability inside the perimeter. Managed Kubernetes at a national operator is attractive if and only if that operator accepts a level of audit comparable to what the state would impose on itself, and if the contract explicitly prohibits any subcontracting outside the jurisdiction, including for third-line support, which is the usual blind spot in those contracts.

The hyperscaler with a local region retains a perfectly legitimate use, already described in the previous article: unregulated public content, workloads with no personal data, and one-off compute capacity needs on non-sensitive data. Rejecting it wholesale would be as unserious as adopting it wholesale.

Limits of the analysis and open questions

This article is a reference architecture, not a measured case study. The choices are justified by requirements derived from legal texts and by operating practice, not by published, reproducible measurements on an identified deployment. A reader looking for comparative performance or cost figures will not find them here, and that is deliberate: publishing them without having measured them in the target context would have produced false precision.

The requirement derivation rests on the same interpretive extension owned in article 1. Decree 2018-062 primarily targets trust service providers, and treating its obligations as a baseline for a general-purpose compute platform is a reasonable but contestable reading. These requirements are written by an engineer and deserve review by a Togolese legal practitioner before being used in a contract or a public tender specification.

Several questions remain open and I would rather name them than dress them up. Whether a shared government platform qualifies as an essential services operator under Order 2022-040 is not obvious and changes part of the obligations. The evidentiary weight of a signed Git history before a regulator is, as far as I know, not established: the argument looks solid technically, but it has not been tested in an inspection. The status of an authorisation decision log as proof of access to personal data carries the same uncertainty. Finally, regional pooling, a platform shared between several WAEMU states, would raise a question of applicable law that neither the national texts nor the current community instruments settle clearly, even though that is probably the only path that makes the economics of this model genuinely favourable.

The core of the matter fits in one sentence. Digital sovereignty is not bought in a contract, it is designed into an architecture and proven in an audit. The work described here is not about reproducing a hyperscaler in miniature, it is about building a platform where every layer answers a named requirement, every choice owns what it costs, and the limits are written down before somebody else discovers them.

Sources

• Decree No. 2018-062/PR regulating electronic transactions and services in Togo, ARCEP
• Law No. 2019-014 of 29 October 2019 on the protection of personal data, Official Journal
• Law No. 2017-007 on electronic transactions, numerique.gouv.tg
• Order No. 2022-040/PMRT adopting cybersecurity rules in the Togolese Republic, CERT Togo
• Kubernetes, Encrypting Confidential Data at Rest, kubernetes.io
• Kubernetes, Auditing, kubernetes.io
• Kubespray, kubernetes-sigs/kubespray
• R. Pang et al., Zanzibar: Google's Consistent, Global Authorization System, USENIX ATC 2019, USENIX
• OpenFGA, authorization model documentation, openfga.dev

This is an engineering and architecture analysis, not legal advice. For any compliance decision or use in a contractual document, consult a Togolese practitioner in data protection and public procurement law.