Adding a geographic dimension to the authorization question
Data residency concerns where data is physically stored and processed, and it layers a geographic constraint on top of the ordinary authorization question of who's asking and what they're permitted to do. A request that would be fully authorized by identity and role alone can still need to be denied or rerouted specifically because of where the data resides, or because of where the request itself is originating from.
This means policy has to reason about location as a first-class input alongside identity and role — not a separate concern handled entirely outside the authorization system, but a dimension the authorization decision itself has to account for.
Enforcement has to reach beyond the access check
A correct residency decision at the authorization layer isn't sufficient on its own if the underlying infrastructure doesn't actually keep the data within the intended boundary — storage location, backup location, and routing paths all have to align with what the policy specifies, or the authorization check is enforcing a boundary that the infrastructure underneath it doesn't actually respect. This makes residency a case where the authorization decision and the infrastructure it depends on have to be designed together, not layered on independently.