The Multi-Cloud Illusion for the State: Duplication Is Not Sovereignty

Every procurement conversation about a government cloud strategy in West Africa eventually reaches the same recommendation: do not put all your workloads with a single provider, spread them across several. The pitch comes from hyperscaler sales teams who want to sell you a second contract, from consulting firms who bill by the strategy document, and from development finance institutions whose "cloud-smart" playbooks treat vendor diversification as a proxy for digital modernization. The promise is twofold: resilience against a single provider's outage, and sovereignty against a single provider's power over your data. For a state operating under Togo's law 2019-014 on the protection of personal data and the cybersecurity regime of the 2022-040 order issued by the ANCY, that second promise is false. Multi-cloud does not divide legal exposure across providers, it unions it. Each additional foreign-headquartered vendor is one more jurisdiction that can compel disclosure, one more subcontracting chain to bind under the law, one more set of logs to reconcile for an audit that already struggles with one.

This is not an argument against cloud computing, and it is not an argument against competition among vendors. It is an argument against a specific and common conflation: treating vendor-diversity multi-cloud, several unrelated hyperscalers each holding a slice of the same regulated data, as a sovereignty strategy. Multi-region redundancy inside one accountable provider is a different thing, and a legitimate one, discussed later. So is choosing several vendors for unrelated, non-sensitive workloads. What follows targets the version of multi-cloud that gets pitched in government IT strategy decks as the anti-lock-in, anti-sovereignty-risk answer, because that is the version an ANCY-regulated administration is most likely to be sold.

What the multi-cloud pitch actually promises

The steelman deserves to be stated honestly before it is challenged. A single provider is a single point of failure: a regional outage, a contract dispute, a change in pricing or terms of service can take down or hold hostage an entire government's digital services at once. Splitting workloads across two or three providers removes that concentration risk and gives procurement real negotiating leverage, since no single vendor can assume the relationship is permanent. Several hyperscalers now market a "local region" on the continent or promise data residency commitments that look, on a slide, indistinguishable from sovereignty. Consulting firms package this into "multi-cloud by design" architectures, and development-finance-funded digital transformation projects often list vendor diversification as a risk-mitigation line item, because it is measurable and easy to write into a project appraisal document.

None of this is dishonest on its face. The outage risk is real, the negotiating leverage is real, and a "local region" genuinely does put bytes on disks physically inside the country or the sub-region. The problem is not that these claims are false, it is that they answer a narrower question than the one a state actually needs answered. An outage-resilience argument and a negotiating-leverage argument are operational and commercial. A sovereignty argument is legal: it is a claim about who can be compelled, by which court, under which law, to hand over or stop processing your citizens' data. Multi-cloud answers the first two questions reasonably well. It does not answer the third, and treating it as if it does is where the illusion sets in.

Residence is not solved by duplication

Article 28 of law 2019-014 conditions the transfer of personal data "to a third country" on that country offering "a sufficient level of protection", and requires prior notice to the Instance, the data protection authority, which issues a reasoned opinion. The question the law asks is not "where does the disk sit", it is "which legal system can reach this data, and did you declare that exposure". A hyperscaler's "local region" answers the first question and leaves the second exactly where it was.

The clearest illustration is the United States' CLOUD Act, the Clarifying Lawful Overseas Use of Data Act of 2018. It amends the Stored Communications Act so that a provider subject to US jurisdiction, typically because it is incorporated or headquartered there, must produce data in its "possession, custody, or control" in response to valid US legal process, regardless of whether that data is stored inside or outside the United States. A local African region operated by a US-headquartered hyperscaler does not remove this exposure. The parent entity remains a US legal person, and the data remains within its "control" in the sense the statute uses, no matter which country hosts the physical disk. Geography changed. Jurisdiction did not.

This is not a uniquely American problem, and not a hypothetical one. The European Union, with a data protection regime far more mature and better resourced than Togo's, ran into exactly this wall. In its 2020 Schrems II judgment (Case C-311/18), the Court of Justice of the European Union invalidated the EU-US Privacy Shield framework because US surveillance law could reach data held by US-linked providers regardless of the standard contractual clauses or the physical location of storage in the EU. If an economic and legal bloc the size of the EU could not contract its way around extraterritorial reach, a "local region" clause in a single hyperscaler's terms of service is not going to do it for a West African state either.

Now add a second and a third provider, each headquartered in a different jurisdiction, each governed by its own extraterritorial disclosure regime, and the arithmetic gets worse, not better. Multi-cloud does not average out this exposure across vendors: it adds a new jurisdiction of potential compulsion for every vendor added, and a new article 28 adequacy determination and a new article 20 processor contract to maintain for each one. Redundancy at the infrastructure layer becomes redundancy of legal risk at the compliance layer.

The control plane never left home

"Local region" is almost always a claim about the data plane, the place where bytes are stored and computed. It is rarely a claim about the control plane: the identity and access management system, the billing and account-suspension mechanism, the encryption key management service, the support and incident-escalation path, the global orchestration layer that pushes configuration changes across regions. Those usually remain operated from, and governed by, the provider's home jurisdiction, wherever the disks sit.

This connects directly to the establishment question the decree already raises. Decree 2018-062 anchors accountability in a provider "established on the national territory" (art. 58), because the text assumes there is a legally accountable local entity the regulator can reach and sanction. A "local region" run by a foreign hyperscaler puts data in-country without necessarily putting that accountable establishment in-country: the entity that can suspend the account, rotate the keys, or push a global control-plane change in response to a legal order from its home government is still, in most cases, the foreign parent. The state has localized the bytes and left the lever somewhere else.

Multi-cloud does not fix this, it multiplies it. Instead of trusting one foreign control plane, the state now depends on two or three, each with its own key management defaults, its own incident response practice, its own support-access model, none of which the state can unify into a single auditable chain of control. More vendors means more control planes to trust simultaneously, not fewer points of foreign leverage.

Multi-cloud and the ANCY audit burden

An ANCY audit under the 2022-040 order works through control domains: event logging (D1.1.1), business continuity and resilience (R1), cryptographic controls (G3.1.5), and others already mapped in detail elsewhere. Each of these controls expects a coherent evidence trail: one retention policy to check, one incident-notification clock to verify against the decree's twenty-four hour rule, one set of audit logs to sample.

A multi-cloud estate breaks that coherence by construction. Each provider exposes audit logs in its own schema, retains them under its own default policy, and reports incidents on its own internal timeline before the twenty-four hour clock the decree imposes can even start. Answering a single ANCY control, "show me the access logs for this workload over the last twelve months," now means building and maintaining separate ingestion and correlation pipelines per provider, normalizing formats that were never designed to align, and hoping the weakest provider's logging defaults do not become the ceiling for what the whole estate can prove. This is not a hypothetical inconvenience, it is a direct multiplication of audit cost and audit risk: an auditor only has to find the gap in the least-instrumented provider to fail the entire estate on a control that a single-provider deployment could answer with one dashboard.

The hidden cost: portability's lowest common denominator

Real multi-cloud portability, the kind that lets a workload move between providers without a rewrite, requires standardizing on the intersection of what all chosen providers support. In practice this means running vanilla Kubernetes primitives instead of a managed database, a managed queue, or a managed secrets service, because those managed services are exactly the parts that differ between vendors and create lock-in. The team then has to operate, patch, and secure in-house what a managed offering would have handled, which is a direct transfer of operational burden onto a state IT organization that is, almost by definition, more resource-constrained than any of the hyperscalers it is trying to stay portable between.

The Kubernetes compliance analysis already showed that a single well-run cluster has real, non-trivial gaps against law 2019-014 and the 2022-040 order: data residence versus ephemeral storage, traceability of access to personal data, the ambiguity of an autonomous Operator's accountability, encryption at rest that is not on by default. None of those gaps disappear by adding a second cloud. They multiply by the number of providers, while the in-house engineering capacity available to close them stays the same size. A state that could barely close four gaps on one platform is being asked to close four gaps on two or three platforms simultaneously, with the same headcount.

When multi-cloud is legitimate

The argument above targets a specific pattern, not every use of more than one provider. The following cases are legitimate, for different reasons than the sovereignty narrative usually given.

The pattern across the legitimate rows is simple: either the data has no meaningful legal exposure to begin with, or the redundancy stays inside a single jurisdiction of accountability. The illegitimate row is the one where redundancy is purchased at the price of adding jurisdictions, and marketed as if it removed risk instead of relocating and multiplying it.

The sovereign bare-metal alternative

The alternative this argument points toward is not "no cloud", it is a single, nationally or regionally established provider, potentially operated on bare-metal Kubernetes, that satisfies the establishment the decree assumes and gives ANCY one coherent estate to audit. The honest accounting has losses on both sides.

What is lost: unlimited elasticity for unpredictable demand spikes, access to the most advanced managed AI and data services that only the largest hyperscalers currently operate at scale, and reliance on a smaller, less mature regional provider ecosystem that has its own capacity and talent constraints. A sovereign provider can itself become a single point of failure if it is under-resourced, and "local" is not a synonym for "well audited": a sovereign provider still needs the same rigorous, independent audit that a foreign hyperscaler would need, not a pass because of its address.

What is gained: one legally accountable establishment that actually satisfies article 58 instead of gesturing at it, one control plane instead of several, one evidence trail for an ANCY audit instead of a reconciliation exercise across providers, and a cost structure that is predictable rather than elastic, which matters because most state workloads are not internet-hyperscale and do not need hyperscaler elasticity to begin with. Compliance stops being a retrofit exercise performed after the fact on infrastructure designed elsewhere, and becomes closer to a property of the architecture itself.

Neither side of this trade is free. Sovereignty through a single accountable provider costs elasticity and access to frontier managed services. The illusion of sovereignty through multi-cloud duplication costs more in engineering effort and audit complexity than it advertises, while delivering less actual jurisdictional insulation than the pitch implies. Between a real cost with a real benefit and an illusory benefit with a real cost, the choice is not close.

A decision framework

Before adopting multi-cloud for a given workload, three questions settle whether it helps or hurts:

What is the data? If it is personal data under law 2019-014, state-classified data, or anything an article 28 adequacy determination would touch, treat jurisdictional diversification as a liability to minimize, not a benefit to pursue. If it is public or non-regulated content, the sovereignty question does not apply and the resilience and negotiation arguments stand on their own.

Where does the control plane actually live, and who can be compelled to act on it? Name the jurisdiction honestly, for every provider under consideration. If the answer names a jurisdiction outside the one the workload is supposed to be sovereign to, adding a second foreign provider does not change that answer, it adds a second one.

What is the real motive? Cost leverage and technical resilience are legitimate engineering and procurement reasons, and should be named as such in the strategy document. If the stated justification is "sovereignty" or "reducing legal risk," it has to point to a specific exposure it removes, an article, a control, a transfer it avoids, not just a diversified vendor list that looks prudent on a slide.

Limits of the analysis and open questions

This is a strategic framework, not a substitute for a legal risk assessment of any specific vendor contract. Some hyperscalers now offer entity structures designed specifically to narrow CLOUD Act exposure, such as data-trustee arrangements run through a local or regional subsidiary with contractual barriers against the US parent's access. Whether a given structure actually achieves that narrowing is a case-by-case legal question that deserves real scrutiny, not a blanket dismissal alongside ordinary "local region" marketing, and not blind acceptance either. Equally, a purely bare-metal sovereign strategy trades one set of risks for another: capacity and talent constraints in a thin local ecosystem are real failure modes, and "sovereign" is a jurisdictional property, not a competence guarantee. A poorly run local provider is not safer than a well-run foreign one, it is differently exposed.

The heart of the argument fits in one sentence. Multi-cloud answers an availability question and, sometimes, a negotiation question, but it does not answer a jurisdiction question, and dressing it up as a sovereignty strategy multiplies the number of legal systems that can reach your data instead of reducing it. The fix for a jurisdiction problem is a jurisdiction answer: one accountable establishment, inside the perimeter the law already defines, not a longer list of foreign providers each holding a piece of the same exposure.

Sources

• Law n°2019-014 of 29 October 2019 on the protection of personal data, Official Journal
• Decree n°2018-062/PR regulating electronic transactions and services in Togo, ARCEP
• Order n°2022-040/PMRT adopting cybersecurity rules in the Togolese Republic, CERT Togo
• H.R.4943, Clarifying Lawful Overseas Use of Data Act (CLOUD Act), 115th Congress, Congress.gov
• Court of Justice of the European Union, Case C-311/18, Data Protection Commissioner v Facebook Ireland and Maximillian Schrems ("Schrems II"), 16 July 2020, InfoCuria

This is a strategic and technical analysis, not legal advice. For a jurisdiction-specific risk assessment of any vendor contract, consult a data protection and public procurement practitioner.