Data localisation requirements — laws that require certain categories of data to be stored and processed within a specific country or territory — have been expanding rapidly in emerging markets. Nigeria, Kenya, Indonesia, Vietnam, and a growing list of other jurisdictions have enacted or are enforcing data localisation obligations. For multinational technology companies, the naive response is to run separate production stacks in each country — a solution that satisfies the legal requirement and is operationally untenable at scale. The architecture that satisfies localisation requirements without 10 separate production deployments requires deliberate design.
The Regulatory Landscape
Nigeria's National Data Protection Regulation (NDPR) and the Nigeria Data Protection Act 2023 require that personal data of Nigerian citizens be processed in Nigeria or in countries with "adequate" protection. AWS, Azure, and Google Cloud have South Africa presence but not Nigeria-specific regions as of early 2026 — meaning on-premises or local provider infrastructure may be required for strict NDPR compliance. Kenya's Data Protection Act (2019) requires that personal data of Kenyan citizens be processed in Kenya unless the transfer is to a country with comparable data protection laws or subject to contractual protections. Indonesia's Personal Data Protection Law (2022, effective 2024) requires that certain categories of strategic data be stored in Indonesia. Vietnam's Law on Cybersecurity (2018) requires that data about Vietnamese citizens be stored in Vietnam.
The absence of major cloud provider regions in some of these jurisdictions is a genuine architectural constraint. Organisations must evaluate whether to use available adjacent regions (South Africa for Nigeria/Kenya, Singapore for Indonesia/Vietnam) with contractual protections for data transfers, or to engage local cloud providers or colocation facilities in-country. The contractual protection route requires executed Standard Contractual Clauses or equivalent mechanisms under each jurisdiction's law — not a single agreement covering all transfers.
The Multi-Region Architecture Without Multiple Stacks
The architecture that satisfies multiple localisation requirements without running entirely separate production stacks has four components: a shared control plane (CI/CD, monitoring, secrets management, developer tooling) that does not process customer personal data; jurisdiction-specific data planes (the compute and storage that handles personal data for each localisation-required jurisdiction); a data routing layer that classifies personal data by originating jurisdiction at ingestion and routes it to the appropriate regional data plane; and a shared application tier that runs in a single region but queries jurisdiction-specific data through the routing layer.
The key insight is that localisation applies to personal data storage and processing, not to application logic. The application code can run in any region — it is the data that must be localised. A web application serving Nigerian users can run its application servers in any region, but when a Nigerian user's personal data is written to a database, it must be written to the Nigerian-region database. The routing layer enforces this constraint transparently to the application code.
Data Classification for Localisation Routing
The routing layer requires that every personal data record be tagged with a jurisdiction at creation. The jurisdiction tag must be determined at the point of first contact — when the user registers or when the first personal data point is collected — because subsequent data points for the same user will follow the jurisdiction established for that user. The jurisdiction determination logic must handle edge cases: a Nigerian citizen accessing the application from the UK, a user who provides an IP address in one jurisdiction but a phone number registered in another. Changing a user's jurisdiction tag after the fact requires migrating their data to a different data plane and should be treated as an exceptional case.
- Conduct a jurisdiction mapping exercise: identify which current and target markets have active localisation requirements and what those requirements specifically mandate
- Evaluate cloud provider region availability for each localisation-required market and identify the gaps requiring alternative infrastructure
- Design the data routing layer before building the application tier — retroactively adding localisation routing requires data migration, not just code changes
- Determine jurisdiction at first contact and store it as an immutable attribute of the user record — this drives all subsequent data routing decisions
- Execute jurisdiction-appropriate transfer mechanisms (SCCs or equivalents) for data flows to countries without adequacy decisions
- Test localisation enforcement quarterly: attempt to write data tagged with a localisation requirement to an out-of-jurisdiction data store and verify the attempt fails
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.