7 SaaS data residency has moved from an occasional enterprise request to a standard procurement requirement. European customers ask for data to stay in the EU or in their own country. Public sector buyers in France, Germany, the UK, Japan and the Gulf states often require in-country hosting. Regulated industries everywhere want clear answers about where their data, backups and logs live and who can access them. For SaaS providers, offering regional residency is now a condition for winning large deals, and getting the architecture right determines whether it becomes a competitive advantage or an operational burden. This article explains how SaaS providers architect regional data residency, what data must stay in region, how requirements differ by country and how to operate multiple regions efficiently. For the broader file storage picture, see our hub on SaaS file storage. What customers mean by residency Customer requirements vary, but typically include: Primary data location: where the customer’s records and files are stored. Backups and replicas: where copies are kept, which customers often overlook until a security review asks. Processing location: where data is processed, including analytics and AI features. Metadata and logs: where usage logs, audit logs, search indexes and telemetry are stored. Support access: who can access data, from which countries, and under what controls. Sub-processors: which third parties handle the data and where. Residency is related to, but distinct from, sovereignty, which concerns which laws apply and who can compel access. Requirements by region European Union: GDPR restricts transfers outside the EEA without safeguards. Many customers ask for EU-only processing as a contractual commitment, and some public bodies require national hosting. Germany: public sector and regulated customers often expect C5 attestation from the BSI and German data centers. France: sensitive public sector and critical operators may require SecNumCloud-qualified services from ANSSI. United Kingdom: UK GDPR applies, and public sector buyers often prefer UK hosting. Japan: customers may expect domestic hosting under APPI considerations, and government buyers look for ISMAP-registered services. Middle East: the UAE, Saudi Arabia and others require in-country storage for certain government, health and financial data. United States: federal customers require authorized services, and some data must stay in the US with US-based personnel. Other markets: Australia, Canada, India and others have their own government cloud programs and sector rules. Architecture patterns Regional cells The most robust approach deploys a complete copy of the application stack, often called a cell or pod, in each region: application servers, databases, object storage, search, queues and caches. Each tenant is assigned to one cell, and all of its data stays there. Cells are independent, which also limits the blast radius of incidents. Global control plane, regional data plane A small global control plane handles sign-up, routing and billing, while all customer data lives in regional data planes. The control plane must hold as little customer data as possible, since anything it stores is global by definition. Tenant pinning and routing Each tenant is pinned to a region at creation, and requests are routed to the right region based on the tenant’s domain, login or a directory lookup. Moving a tenant between regions becomes a deliberate migration with verification. Regional object storage Customer files live in object storage within each region, with buckets or accounts per region and replication only to other sites in the same region. S3-compatible storage lets the same application code run against hyperscaler regions, local cloud providers or the provider’s own infrastructure, depending on where regions are needed. Data that is easy to forget Residency programs often fail on secondary data: Backups replicated to another continent by default. Logs and telemetry shipped to a central observability platform. Search indexes built in a central cluster. AI features that send content to models hosted elsewhere. Support tooling that copies customer data into tickets. Analytics pipelines that aggregate data across regions. Audit every data flow and decide what is allowed to leave each region, if anything. The scality.com blog covers metadata residency and storage telemetry data boundaries. Where regions come from Providers can build regions on hyperscale cloud regions, national or sovereign cloud providers, colocation facilities with their own infrastructure, or a mix. Hyperscale regions are convenient but not available in every country, and some customers prefer local providers for sovereignty reasons. Running S3-compatible object storage in colocation facilities lets providers open regions where hyperscalers are absent or where customers require domestic operators. Operating many regions Automation Every region should be deployed and updated from the same automation, so regions stay consistent and new ones can be added quickly. Capacity planning per region Growth varies by region. Plan storage and compute separately for each, and avoid regions that are too small to operate efficiently. Resilience within the region Customers expect residency and availability. Use multiple sites or availability zones within each region, with replication that stays in region. Support model Define support access controls: regional support teams, just-in-time access, customer approval for access and logging of every action. Cost Each region adds fixed costs. Price residency options accordingly, for example as a premium for dedicated or in-country regions, and design shared services to minimize per-region overhead. AI features and residency Generative AI features have become a new residency challenge. Summarization, search and assistant features may send customer content to models hosted in other regions or by third parties. Customers with residency requirements increasingly ask where prompts, documents and embeddings are processed and stored, and whether data is used for training. Options include hosting models within each region, using regional endpoints from model providers that commit to in-region processing, letting tenants disable AI features or offering AI only in regions where processing can stay local. Embeddings and vector indexes derived from customer content should follow the same residency rules as the content itself. Choosing which regions to offer Not every country justifies a dedicated region. Providers usually start with a small set, such as the US, the EU and one or two large national markets, and add regions where revenue, regulation and customer demand justify the fixed cost. Some offer dedicated single-tenant deployments for very large or highly regulated customers instead of full shared regions. Track lost deals and procurement requirements by country to decide where the next region should go. Contracts and evidence Customers want residency commitments in contracts and data processing agreements, plus evidence: architecture documentation, sub-processor lists with locations, certifications and audit reports. Make residency a documented, testable property of the platform, not just a promise. Migrating existing customers When a new region opens, existing customers may ask to move. Tenant migration involves copying databases and files, verifying every object, switching routing and deleting data from the old region with evidence. Build tenant migration tooling early; it will be used repeatedly. Testing residency Periodically verify residency in practice: trace where a test tenant’s data, backups, logs and indexes actually land, review network egress from each region and confirm support access logs match policy. Treat any unexpected flow as an incident to fix. Checklist: SaaS data residency Define which data types must stay in region, including backups, logs and indexes. Choose regional cells or a regional data plane with minimal global control plane. Pin tenants to regions and route requests accordingly. Use regional object storage with in-region replication. Audit secondary data flows, AI features and support tooling. Build regions where customers need them, including via colocation. Automate deployment and updates across regions. Control and log support access. Document residency in contracts and provide evidence. Build tenant migration tooling. Putting it together SaaS data residency works when it is built into the architecture rather than bolted on: regional cells, tenant pinning, regional object storage and strict control over backups, logs, AI features and support access. Requirements vary across the EU, Germany, France, the UK, Japan, the Middle East and the US, but customers everywhere want clear commitments and evidence. S3-compatible storage lets providers open regions on hyperscale clouds, local providers or their own infrastructure with the same application code. Frequently asked questions What is SaaS data residency? A commitment that a customer’s data, including backups and logs, is stored and processed in a specified country or region. How do SaaS providers keep data in a region? By deploying regional cells, pinning tenants to regions, using regional storage and controlling secondary data flows. Do backups count for data residency? Yes. Customers and regulators generally expect backups and replicas to stay in the agreed region. What if a hyperscaler has no region in a country? Providers can use local cloud providers or run S3-compatible object storage in colocation facilities to open regions there. How do providers prove residency? With contractual commitments, architecture documentation, sub-processor lists, certifications and audit reports. Further reading SaaS file storage Telco personal cloud storage Self-hosted file sync and share storage Consumer photo and video storage Data sovereignty vs data residency
