The regulators stopped being theoretical. Kenya's data commissioner has been issuing penalties since 2023, Uganda's office found Google in breach and ordered it to register locally in 2025, and Zambia's commissioner opened enforcement with a hard deadline. Where your server physically sits is now something a regulator can ask about, and "somewhere in the cloud" is not an answer that holds.
At CloudSpinx we provision and manage servers for clients across East Africa and a range of sectors, and this data-residency question comes up on almost every regulated workload we touch. Here is the plain-language version of what the four main laws require about where data can live.
This is orientation, not legal advice, so confirm your own position with counsel.
| Country | Law | Must data stay in-country? | Hosting abroad is allowed if |
|---|---|---|---|
| Kenya | Data Protection Act, 2019 | Only specific state-interest categories | You have appropriate safeguards; sensitive data also needs consent |
| Tanzania | Personal Data Protection Act, 2022 | Not under this law, but see the banking rule below | You get a prior transfer permit from the regulator |
| Uganda | Data Protection and Privacy Act, 2019 | No | The destination has equivalent protection, or the person consented |
| Zambia | Data Protection Act, 2021 | Yes, and sensitive data always | Only for carved-out ordinary data, with consent and approved contracts |
That table is the general law, and it is the whole answer for most businesses. If you hold a license from a central bank, read the sector section before you use it.
Zambia is the one that catches people
Most of the region lets you host abroad if you do the paperwork. Zambia does not. Section 70 of its Data Protection Act says personal data is stored in-country by default, and sensitive data, which covers health, biometric, financial and more, must always stay in Zambia with no exception. So a Zambian business holding customer records cannot legally put them in Johannesburg or Frankfurt, however good the price or the latency looks. If you operate in Lusaka, that decides the hosting location before anything else does.
One thing to clear up: people sometimes cite Zambia's Electronic Communications and Transactions Act as a second localization rule. It is not. The storage requirement lives entirely in the Data Protection Act.
Kenya, Tanzania and Uganda gate the exit rather than the location
The other three let data leave, on conditions. Kenya only reaches data processed for a strategic interest of the state, things like civil registration, elections, public finance and basic health and education records, and even there regulation 26 gives you two ways to comply: process through a server and data center in Kenya, or store at least one serving copy in a Kenyan data center. That second limb is worth real money on an architecture, and we walk through when it applies and what else catches you separately. Everything outside those categories can go abroad with appropriate safeguards, and sensitive data needs consent on top. The fine is capped at KES 5 million or 1 percent of turnover, whichever is lower.
Tanzania takes no localization stance in its data protection law but makes you get a permit from its commission before personal data leaves the country, so the transfer is a step you complete beforehand, not something an auditor finds later. Uganda is the simplest of the three: you may host abroad if the destination protects data at least as well as Uganda's law does, or if the person consented. Consent alone is a valid basis, which is why Uganda rarely blocks a well-run transfer.
A sector regulator can close a door the act leaves open
Tanzania is the clearest case in the region. Its data protection law will license the transfer, and its central bank will not.
The Cloud Computing Guidelines for Financial Service Providers, 2025, issued by the Bank of Tanzania under section 71 of the Banking and Financial Institutions Act 2006 and section 56(3) of the National Payment Systems Act 2015, replaced the 2023 version and drew a line the transfer permit cannot cross. Guideline 7 classifies every application system as mission critical or not. Then, in the same guideline: "A financial service provider shall not host a mission-critical system or any other system whose data are considered critical for the operations of the financial service provider as determined by the Bank, in a primary data Centre or Cloud service provider whose hosting infrastructure is outside Tanzania."
The definition is deliberately wide. A mission critical system is one "essential to the survival of a financial service provider", and the guideline goes on to catch "any IT component (software, hardware, database, process, application, etc.) that performs a function essential to business operation". A core banking platform is in. So is the database sitting behind it.
What is left can go to cloud, but not quietly. Guideline 8 requires prior written approval before a non-mission-critical system moves or an existing arrangement changes, and guideline 11 requires the contract itself to be approved by the Bank before implementation. An institution that was already on cloud when the guidelines commenced has twelve months to apply for approval or stop. The sanctions in guideline 18 run from a civil money penalty on the institution or on the responsible director, through suspension of lending operations, to revocation of the license.
Both columns still need the transfer permit. Holding no license removes a layer, not the paperwork.
Kenya's central bank went the other way and imposes no localization rule of its own. What it does require is approval before you sign, which is a different problem with its own sequence, and we cover it in CBK outsourcing approval.
The general lesson survives the specifics: find out which regulator licenses you before you read what the data protection act allows. The strictest instrument in the room decides, and it is rarely the one written for everybody.
The gap nobody mentions in the sales call
Here is the fact that turns all of this from paperwork into an architecture decision. None of AWS, Microsoft Azure or Google Cloud runs a live region physically inside Kenya, Tanzania, Uganda or Zambia. The only hyperscaler regions on the continent are in South Africa. AWS announced a Nairobi region in September 2025 targeting late 2026, Oracle announced one in January 2026 that is in build, and the Microsoft and G42 geothermal project at Olkaria stalled over grid capacity and guaranteed capacity payments. Announced is not operational.
So when Zambian law says the data stays in Zambia, clicking "africa-south1" in a cloud console does not satisfy it, because that region is in Johannesburg. Genuine in-country residency right now means local colocation or a dedicated server placed in a datacenter in that country. That is the practical reason regulated workloads keep landing on dedicated hardware rather than public cloud.
How to decide
Work it in this order. Whose data is it, and which country do those people live in, because that is the law that binds you. Who licenses you, since a central bank instrument overrides the general position. Is any of it sensitive, which is where every one of these laws tightens and where Zambia closes the door entirely. If you can host abroad, can you actually complete the step the law asks for.
Only once that is settled do latency and cost get a vote, and for East African users a regional server usually wins both, which we cover in where to host your servers.
If you are not sure which bucket your workload falls into, send us the shape of the data through the quote form or on WhatsApp at +254 713 403 044. We will tell you where it can legally and quickly live, no charge for the answer, and the hardening and monitoring that sit on top of residency are our cybersecurity team's job either way.