Data sovereignty in Africa and the Gulf: an architect's point of view

Ask an IT director in Casablanca, Dakar or Nairobi where their customers' data physically sits, and the answer often comes after a short pause. Somewhere in Europe, maybe the United States, "in the cloud". That is not a criticism. For years, nobody really asked. The tools were good, cheap and easy to roll out, and no one was demanding answers.

That is changing. Regulators are getting stricter, so are customers, and the arrival of artificial intelligence in companies is moving the topic from the legal department to the executive floor.

This article keeps that thread, but it is written for the people who then have to turn it into architecture. A warning first: I am an architect, not a lawyer. Nothing below is legal advice. I cite legal texts as examples, after checking that they exist, and applying them to a specific case requires a lawyer who knows the jurisdiction.

What are we really talking about?

Data sovereignty is not isolationism, nor a rejection of foreign technology. It is the ability of a company or a state to keep control over its own information. In practice, it comes down to three questions:

Where? In which country and which data center is your information stored and processed?
Who? Who can access it, including at your providers and their subcontractors?
Under which law? Which legal system applies if a foreign court, administration or government asks to see it?

If you cannot answer these three questions clearly for your most sensitive data, you are not really in control of it. Someone else is, at least in part.

Residency, control, jurisdiction: three distinct properties

The vocabulary is often mixed up, and that is the first source of design mistakes. I separate four properties, none of which follows from the others.

Residency: the physical location of the bytes, at rest and during processing. This is what a region = "..." setting measures.
Operational control: who can act on the machines and services: provider administrators, support staff, subcontractors, automation.
Cryptographic control: who holds the keys and can therefore decrypt.
Jurisdiction: which law can compel which actor to produce what.

Hosting in the country settles the first one. It settles neither the second (a foreign operator can administer a local data center remotely), nor the third (the keys may be in its hands), nor the last (the law that applies to the company running the service does not depend on the building's address).

The four layers of sovereignty. Residency is only the bottom layer: without operational, cryptographic and legal control, it guarantees little.

A legal framework taking shape

A growing number of African countries have adopted a personal data protection law. Morocco with law 09-08 and the CNDP, Senegal, Tunisia, Kenya with its 2019 Data Protection Act, Nigeria with the Nigeria Data Protection Act signed in June 2023 (which creates the Nigeria Data Protection Commission), South Africa with POPIA. At continental level, the African Union Convention on Cyber Security and Personal Data Protection, known as the Malabo Convention, adopted in 2014, entered into force on 8 June 2023, thirty days after the fifteenth ratification was deposited. It has been ratified by only a minority of member states, which limits its practical reach for now.

The Gulf follows the same trend with recent texts: Federal Decree-Law No. 45 of 2021 in the United Arab Emirates (in force since 2 January 2022), and Saudi Arabia's Personal Data Protection Law (PDPL), whose entry into force was set at 14 September 2023 after an amendment, followed by a one-year compliance period. Sources differ on some exact publication dates: for a real case, go to the official source.

These texts are not identical, but they point the same way: framing transfers of data across borders, requiring safeguards, giving rights to individuals. I do not go into their obligations: they differ by text, by sector (banking, health, telecoms) and sometimes by sector authority, and I prefer not to summarize them from memory. What the architect should take away is more modest and more useful: the framework moves, it varies by country, so the architecture must be able to change where it processes data without being rewritten. That is an engineering requirement before it is a legal one.

The risk you don't see: depending on others

Beyond compliance, there is a simpler question. What happens the day your provider changes the rules?

A US provider remains subject to US law, even when its servers are elsewhere. The CLOUD Act, signed on 23 March 2018, amends the Stored Communications Act: a provider of electronic communication or remote computing services subject to US law can be required to produce data in its "possession, custody, or control", whether it is located in the United States or abroad. It arose from the case between the United States and Microsoft about servers in Dublin. The text also opens limited ways to challenge a request, notably when it conflicts with the law of a "qualifying" foreign government. Other countries have comparable rules. This is not a conspiracy theory, it is written in the law.

The notion of "control" is the technical point that matters here. US courts read it broadly, and the statute does not define it precisely. For an architect, this translates as follows: the question is not "where is the disk?" but "among those who can read these bytes, who is subject to a legal system that can compel them to produce them?". A local provider that is a subsidiary of a foreign group, or a local operator built on a large provider's platform, may fall within that scope depending on its structure: that is a legal analysis to be done case by case.

There are also more mundane risks: a sudden price increase, a service shutting down, a suspended account, an international sanction cutting access to a platform overnight. If all your data and applications live with a single foreign provider, your room to negotiate, or to leave, stays very thin.

Classify the data and map the flows

Before any technology choice, two inventories. The first is classification: what sensitivity level each dataset belongs to. The second, more neglected, is flow mapping: who reads what, where, by which path.

A useful classification has four or five levels, not twenty. Each level must translate into machine-checkable rules, otherwise it stays a document nobody applies. One possible shape, illustrative:

classes:
  public:
    examples: [brochures, FAQ]
    location: any
    keys: provider_managed
  internal:
    examples: [wiki, non-customer tickets]
    location: region_or_country
    keys: customer_managed
  confidential:
    examples: [customer files, contracts]
    location: country
    keys: customer_managed_dedicated_hsm
    logging: full_access
  restricted:
    examples: [health data, banking secrecy, government files]
    location: country_controlled_infrastructure
    keys: outside_provider
    leaves_country: forbidden_without_written_waiver

Flow mapping is the exercise that produces the most surprises. An architecture diagram shows the application and its database. It forgets what leaves: logs sent to a SaaS observability tool (with customer identifiers in them), error reports carrying payloads, backups replicated to another region by default, transactional emails, exports to an analytics tool, prompts sent to an AI API. For each flow, I record the source, the destination, the class of the data, the network path, who can decrypt at the end of the path, and which legal system that recipient sits under.

The path of a sensitive piece of data, with a control point at each step. The first thing to check is the exit: that is where silent leaks happen.

A practical rule: treat outbound flows as an allowlist. Every flow leaving toward a third party must be declared and tied to a class. An application firewall or egress gateway that denies by default turns the mapping into a control, not just a document.

Encryption: what it solves, what it does not

Encryption at rest and in transit is a baseline, not a sovereignty strategy. At rest, it protects against the theft of a disk or a backup. In transit, TLS protects the network path. Neither protects against someone who legitimately holds the keys or the access rights: the provider's administrator, a compromised application account, a request addressed to the operator.

The common pattern is envelope encryption: each object is encrypted by a data key (DEK), itself encrypted ("wrapped") by a key-encryption key (KEK) held in a KMS or HSM.

write : random DEK -> encrypts the object -> KEK wraps the DEK
        stored: encrypted object + wrapped DEK
read  : KMS call (unwrap DEK, logged) -> decrypts the object

The benefit: the KEK never leaves the KMS or HSM, and every read goes through a logged, revocable call. The sovereignty question becomes: who controls the KMS, and who can ask it to decrypt?

Key management: four models

People talk about BYOK, HYOK, customer-managed keys, and the vocabulary varies from one provider to another. I describe the models by what matters, the location of the key material and of the cryptographic operation.

Provider-managed keys: the provider generates, stores and uses the keys. Simple, nothing to operate, and cryptographic control belongs to it.
Customer-managed keys in the provider's KMS (CMK): you control the access policy, rotation and revocation, but the key material and the operation live in the provider's infrastructure.
BYOK (bring your own key): you generate the key elsewhere and import it. That gives you a reference copy and the ability to withdraw it, but once imported, it is used inside the provider's infrastructure.
HYOK or external key store: the key stays in an HSM or key manager that you run, and every encryption or decryption operation is delegated to your system. The AWS KMS documentation describes this model as an "external key store" (XKS): KMS only talks to a proxy that you provide, and the provider itself calls this option a major departure from the shared responsibility model, with additional operational burden, to be limited to workloads that require it.

Comparison of three key management models by where the key is used. As control increases, so do the operational load and the risk of outage.

The real limits

A few realities usually left out of presentations.

Availability becomes your problem. With HYOK, if your HSM or the network link to it is down, the encrypted data is unreadable. Latency is added to every call, high availability has to be designed, recovery procedures have to be tested.
Processing often needs plaintext. If the provider's service must read the data to index, analyze or serve it, it decrypts it in memory, however the key was supplied. External keys mainly protect data at rest in services that do not need the plaintext.
Uneven compatibility. Not all of a provider's services support every key model; check service by service, at the date of the decision.
A withdrawn key is not a legal guarantee. It makes the data unreadable to the provider, but does not stop an authority from demanding the key or the plaintext data from you, if you are subject to that law.
Who holds the key matters. The European guidelines on supplementary transfer measures (EDPB recommendations 01/2020) treat encryption as effective only if the keys stay under the exclusive control of the exporter or of an entity located in a territory deemed adequate. The text is European, but the reasoning is useful: cryptographic protection is worth what the jurisdiction of the key holder is worth. I have only read commentary on this text, not its full content: check it directly before relying on it.

Confidential computing: useful, but not magic

Confidential computing targets data "in use": processing runs inside a hardware-based, attested trusted execution environment (TEE). The Confidential Computing Consortium defines three target properties: data confidentiality, data integrity and code integrity. Attestation lets a third party remotely verify which code is running in the enclave before handing it a key.

The useful sovereignty pattern is this: your KMS releases the key only to a workload whose attestation matches an expected measurement. The infrastructure provider then cannot read the virtual machine's memory.

The limits, honestly:

The root of trust remains the hardware maker. You replace trust in the cloud operator with trust in the processor maker and its firmware.
Side-channel attacks exist. Research has demonstrated attacks against several TEE implementations; fixes come through microcode and software. It is not an absolute guarantee.
It says nothing about jurisdiction. Confidential processing at an operator still sits in a legal perimeter: the operator can be compelled to other measures, such as suspending the service.
Integration cost. Attestation, deployment and observability take real work, and GPU support in these environments, for AI, depends on the hardware and platform: check at the time of choice.

I recommend it as a layer for cases where the infrastructure provider is part of the threat model, not as a replacement for key control and location.

AI changes the scale of the problem

With artificial intelligence, the topic takes on another dimension. When an employee pastes a contract, a medical file or a customer list into a consumer AI assistant, that information leaves the company. Depending on the terms of use, it may be retained, analyzed, sometimes used to improve the models. Most of the time, nobody decided this. It just happened.

Architecturally, a call to an external AI API is simply one more outbound flow in the map: it belongs on the same allowlist as the others. An internal gateway that logs, filters by data class and routes sensitive requests to a model hosted on your side is more effective than a written ban. I detail the architecture in Sovereign AI architecture and local deployment in Running AI locally.

There is a second, less visible stake. The big models are mostly trained on data from North America, Europe and Asia. They know Darija, Wolof or Swahili poorly, and local administrative and tax realities even less. If African data is used to train systems designed elsewhere, the value created goes elsewhere too. Keeping control of your data also means keeping the ability to build tools that really understand your market.

Sovereignty does not mean doing everything yourself

Let's be honest: no company needs to build its own data center to be sovereign. And not all data is equal. A sales brochure can live on any online service. Health data, banking information or a ministry's files cannot.

The reasonable approach is to sort. Sensitive data stays on infrastructure you control, on premises or in a private cloud hosted in the country or region. On the AI side, there are now high-performing open models you can install yourself, without sending a single line outside. For the rest, you can keep using market services, knowing the rules of the game.

Simplified decision tree for placement, from least to most sensitive. Real thresholds depend on the law, the sector and the contract: this table is a starting point, not a rule.

Logging and auditability

A sovereignty promise without evidence is worth only as much as the trust behind it. Three elements make evidence possible.

Access logs for data and keys. Every KMS call (decrypt, wrap, policy change) must be logged outside the perimeter it monitors, with the caller's identity and the resource concerned. A burst of decrypt calls outside usual hours is an actionable signal.
Immutability and separation. Logs are written to append-only or immutable storage, with rights distinct from those of the administrators they oversee.
Egress logs. Outbound flows to third parties (including AI APIs) are logged with the data class, never with the data itself.

A classic trap: logs themselves become sensitive data, often in a different region or at a different provider. They must be classified like everything else.

Reversibility and portability

The most neglected sovereignty criterion is the ability to leave. Asking how to get your data back and switch provider must happen before signing, because afterwards the exit cost is a dependency in itself.

A few concrete checks:

Format. Is the data exportable in open formats (standard SQL, Parquet, documented object formats), or only in a proprietary one?
Volume and exit cost. How long does a full export take, and what egress fees apply? The calculation is simple: volume divided by real bandwidth, plus validation time. Measure it on a sample, do not estimate it.
Specific managed services. The more proprietary services you use (databases, queues, functions), the more an exit is a rewrite. Hexagonal architecture, with adapters between business logic and services, limits the damage.
The keys. If your data is encrypted with provider keys, exporting it in plaintext costs you a mass decryption operation. With keys you hold, the exit is one coherent block.
The real exercise. An exit that has never been tested does not exist. I recommend an annual exercise: restore a representative dataset in another environment, and time it.

A realistic threat model

To decide what to put in place, you have to name the adversary. Expensive measures (HYOK, dedicated HSM, enclaves) only make sense against certain adversaries. I distinguish three families, without claiming to be exhaustive.

Three families of adversaries and what answers them. The legal route is the least visible in technical diagrams and the hardest to fix with technology alone.

Most real incidents come from the second column instead: an over-privileged account, an open bucket, an API key in a repository. A sovereignty budget that ignores this, funding only the legal route, gets its priorities backwards. I cite no statistic here: I have no verified one, and my point rests on field experience rather than a figure.

Decision checklist for an architect

For each dataset or service, in order:

What is its class, and who decided it?
Which outbound flows exist, and are they all in the register?
Who can read the bytes in plaintext, and which legal system is that actor under?
Where is the key, who can use it, and what happens if it is revoked?
Are access to data and to keys logged outside the monitored perimeter?
Does the threat model justify the extra cost (HYOK, enclave, dedicated hosting), or is a CMK enough?
How long does it take to get everything back and restart elsewhere, and has it been tested?
What do local and sector laws say, confirmed by someone qualified to say it?

Where to start

You do not need a big transformation program to move forward. A few steps are enough to see clearly:

Take inventory. List the data you process and spot what is really sensitive.
Know where it goes. For each tool and provider, check where data is hosted and which law applies.
Frame AI use. Define what teams may or may not share with external tools, and offer an internal alternative for sensitive uses.
Plan the exit. Before signing, ask how you would get your data back and switch provider if needed.
Train the teams. The best architecture is useless if nobody knows why it exists.

What to take away

Data sovereignty is a stack of properties, not a hosting label. Residency is the easiest to obtain and the least decisive. Key control and mastery of jurisdiction weigh more, but cost in operations and availability, and no technique replaces a serious legal analysis. My practical advice is to start with classification and flow mapping: they cost almost nothing in infrastructure, and they usually reveal what really deserves investment. The open question is AI: as open models progress, the share of workloads you can keep in-house grows, and that is probably where the trade-offs of the coming years will be decided.