For several years the residency question had an unsatisfying answer: workloads with data location requirements stayed on owned infrastructure, because the alternative meant a region outside the Kingdom. The expansion of in-Kingdom cloud capacity has changed that, and it has changed the shape of the design conversation more than the technology.
Residency is not one requirement
It is worth separating three things that get discussed together.
Where data is physically stored. The most commonly stated requirement and the most straightforward to satisfy with in-Kingdom capacity.
Where data can be processed and transit. Often overlooked. A workload can store data in-Kingdom while processing it elsewhere, or route it through infrastructure in another jurisdiction. Backup destinations, disaster recovery targets, log aggregation and management planes are common places where data leaves without anyone intending it to.
Who can access it, and under what legal authority. The hardest to evaluate, because it depends on the provider's corporate structure and the jurisdictions it is subject to rather than on where the servers are.
Practical consequences for architecture
Map data flows rather than data stores. Most residency gaps found in review are in secondary paths — a monitoring platform aggregating logs to a regional endpoint, a backup replicating to the nearest available region, a SaaS integration exporting records for processing.
Check the management plane separately from the data plane. Control planes for cloud and SaaS platforms frequently operate from a different region than the workload, and metadata carried there can be more sensitive than expected.
Treat disaster recovery as in scope. A DR target in another region is a copy of production data in another region. This is one of the most common findings in residency reviews and one of the easiest to design around once identified.
Where this is heading
The direction is toward residency being an ordinary architectural parameter — something specified per workload and satisfied through configuration, rather than a reason to keep an entire estate on owned hardware.
That makes the useful internal exercise a data classification one. Which systems hold data with actual location requirements, and which have inherited the assumption from a policy written when the answer was simpler? The second category is usually larger than expected.