Residency requirements are frequently stated as a blanket rule. In practice, obligations vary by sector and by the kind of data involved, and treating them as one rule leads to architectures that are either needlessly expensive or quietly non-compliant.
Separate the questions
- Where may it be stored? Sector regulators, particularly in financial services, are the strictest here.
- Where may it be processed? Often more permissive than storage, which matters for analytics and backup design.
- What must be demonstrable? Frequently the binding constraint is proving location and access on request, not location itself.
The architectural consequence
Classify data before choosing regions. Most organisations find a minority of their data carries the strict obligations and the majority does not. A design that keeps the regulated subset local and places the rest on cost or latency grounds is usually both compliant and affordable.
Prove it, do not assert it
Auditors ask where a record physically sits, who accessed it, and when. Systems that can answer from logs pass. Systems relying on a vendor's marketing page do not. Build the evidence trail as part of the architecture.
This is general information about how residency shapes architecture, not legal advice. Confirm your obligations with your regulator or counsel.