Can you host customer data on AWS, Azure or Cloudflare under Zambian law?

Almost every Zambian software company I talk to runs something on a foreign cloud. The app is on AWS, the email goes through a US provider, the error tracker is hosted in Ireland, and the backups sit in a region nobody chose on purpose. Then someone reads the Data Protection Act and asks: is all of this allowed?

The honest answer is that it depends, and that parts of it are still unsettled. I’ll lay out how I think about it. This is an engineer’s reading, not legal advice, so use it to ask better questions of your counsel rather than as a ruling.

What the Act says, in plain terms

The Act leans toward keeping personal data in Zambia. As written, controllers are expected to process and store personal data on servers or data centres located in the country. There is room for exceptions: the minister can set out categories of data that may be stored elsewhere, and sensitive personal data is meant to stay in Zambia regardless.

Moving data out is treated separately. In general, you need the person’s consent plus an approved safeguard, such as contract terms or an intra-group arrangement that the Commissioner has accepted. Other routes exist, including a specific approval from the regulator and a limited set of narrow exceptions. And if you send data abroad, you remain responsible for what the receiving party does with it.

That’s the structure. The detail is where it gets slippery.

What’s still unsettled

Two things make this hard to answer with confidence.

First, the exceptions depend on instruments that must be issued under the Act, such as the categories the minister can allow offshore. Commentary I’ve read disagrees on how much of that is in place today, and the position may have moved since. Check the current state with the ODPC or your counsel before you build on any assumption.

Second, there are no widely published examples of how the regulator treats ordinary cloud hosting. Nobody I’ve spoken to can point to a clear ruling on whether, say, a database in an AWS region outside Zambia needs a specific approval. Until that’s clear, the careful position is to treat it as a risk to manage, not a settled yes.

A practical way to sort your data

Rather than argue about the whole system at once, sort what you hold into three piles.

Sensitive data. Health records, biometrics, anything the Act marks as sensitive. This is the pile where the rule is strictest, so I’d plan for it to stay in Zambia, or take proper advice before it goes anywhere else.

Ordinary personal data. Names, contact details, account records. This is where most of your product lives, and where the transfer routes and consent matter.

Data that isn’t personal. Aggregated, anonymised or purely technical data. Properly anonymised data can often sit wherever is cheapest, though “anonymised” has to survive scrutiny, and hashing an email address doesn’t make it anonymous.

Once the piles are separate, the architecture questions get much more concrete.

What this means for how you build

A few habits make you flexible whichever way the rules settle.

Keep personal data in a small number of identifiable places, not scattered across services. When it’s everywhere, moving it later is a rewrite.

Know your sub-processors. List every third-party service that touches customer data, where it runs, and what it sees. Analytics, support chat, email delivery and error tracking are the usual forgotten ones. Strip personal data out of logs and error reports before they leave your system.

Separate sensitive data in the design from the start, with its own store and its own access rules. If you later need that store in-country and the rest elsewhere, the seam already exists.

Check your backups and replicas. Teams often pick a region for the main database and forget that the backup, the read replica and the disaster-recovery copy are somewhere else.

Put the terms in writing. Your contracts with cloud and software vendors should say where data is held and what safeguards apply, and your own customer contracts should say the same about you.

Your cloud provider can offer a compliant region. It can’t tell you whether your use of it is compliant.

When local hosting makes sense

For some workloads, such as government systems, health records and anything with heavy sensitive data, keeping things in-country is the simpler route even if it costs more or offers fewer managed services. For others, a foreign region with the right safeguards and consent is a reasonable call. The decision should be made deliberately, written down, and revisited when the rules or the regulator’s guidance change.

If you’re choosing hosting for a new system or reviewing an existing one, we can talk through the options, and our in-house legal counsel is available to Bitsmiths clients for the legal side. For the wider picture of what the Act asks of you, start with our overview of the Data Protection Act.

• Ali