Data sovereignty in plain language

If you run a product, data sovereignty is three practical questions. Where does the data sit. Who can force access to it. Can you leave the vendor without losing the business.

You do not need a national programme to start. You need clear answers before customer records, source, or learning traces live on someone else's stack.

This post is for product and infra leads who have to defend those choices in a vendor call or an internal review.

The three questions that matter

Before you commit to a tool that will hold important data, ask these out loud. If the vendor cannot answer in plain language, treat that as a signal.

1. Where is it stored

Ask for the country or region of the primary store. Then ask the same question for backups, logs, analytics copies, support exports, and AI training opt-outs.

A common failure mode is a dashboard that says "Africa region" while nightly backups or crash dumps leave that boundary. Sovereignty is about the whole path, not the marketing region label.

Write the answer in one sentence your team can reuse: "Primary in X. Backups in Y. Analytics in Z."

2. Who can compel access

Ask which law can force the vendor to hand over data, and which partners sit in the path. That includes the cloud provider, subprocessors, and any admin tooling your support team uses.

You are looking for control and notice, not a fantasy of perfect isolation. If a partner can read production data and you only find out after the fact, you do not control the risk.

3. Can you leave

Ask for export formats, deletion timelines, and what breaks if the vendor vanishes or locks the account. Try to picture the worst week: invoice dispute, region outage, sudden terms change.

If leaving means weeks of rebuild with no usable export, you are renting a trap. Exit has to be boring and documented while the relationship is still good.

If the only answer you get is a polished sales page with no concrete locations, partners, or export path, you do not have sovereignty yet. You have a dependency you have not measured.

Why African product teams feel this early

Most of our tools, clouds, and SaaS defaults were designed for other markets. Using them can still be the right call. It does not stop them from being dependencies.

Dependencies fail in boring ways first: billing holds, broken renewals, support that cannot reach you, policy changes you did not vote on. By the time politics shows up, the architecture is already set.

So the work is not "ban every foreign cloud." The work is know which data can travel, which data must stay controllable, and how you leave.

What to do with the answers

Once the three questions are answered, sort the data into classes: public, internal, regulated, and irreversible. Each class needs a different hosting bar. If those words are still fuzzy, read more on how to classify product data.

Then act in this order:

• Put irreversible data on hosting you can describe in one short paragraph.
• Prefer open formats and documented APIs so exit is real.
• Keep your own subprocessor list so you are not discovering partners during an incident.
• Own one critical system before you try to own everything.

For that first ops step, read more: self-hosting in Nigeria.