Teams tell us their system is resident because the primary database is in an in-Kingdom region. Then we trace the data and find it leaving through six doors nobody drew on the diagram.
The six doors
Backups replicated to a paired region for durability. Logs and traces shipped to an observability vendor. Error reporting that captures request payloads. Managed service control planes that terminate outside the region. Email and notification providers. And model inference calls to an API endpoint in another continent.
The last one is the most common and the least noticed. A perfectly resident application that calls a hosted model API has exported every prompt, and prompts in an enterprise context routinely contain the most sensitive text in the system.
Residency is a property of the whole path
The practical test we use is simple: pick one record and follow every copy of it. Where is it written, where is it cached, where is it backed up, where is it logged, and who could read each of those without asking you. Anything you cannot answer is a finding.
This is also why we treat residency as an architecture constraint rather than a deployment setting. It changes which managed services you can use, which is a decision that is expensive to reverse late.
None of this is an argument against cloud, and it is emphatically not an argument for running your own hardware. Both major providers operate capable in-Kingdom regions. It is an argument for drawing the full data path once, honestly, before the first deployment rather than during the first audit.