Skip to main content
zatersio

Choose Data Residency: A Guide for IT and Compliance

Choose Data Residency: A Guide for IT and Compliance

Decorative title card illustration for data residency guide

Choosing data residency comes down to one sequence: classify your data by legal risk, map where it actually flows today, pick the region or regions that match your obligations, and then verify every vendor promise before you sign. That order matters. Teams that skip classification end up pinning everything to one region at premium cost, and teams that skip verification end up with a vendor contract that says “in-region” while logs, backups, and AI inference happen somewhere else entirely.

This week, you can move on three fronts without waiting for a full audit cycle:

  • Kick off a data classification pass with legal and product, tagging categories that trigger residency obligations (health records, financial data, personal information under the Privacy Act).
  • Send a residency questionnaire to your top three vendors, asking directly what data categories are in-scope for their residency controls.
  • Shortlist two or three candidate regions based on where your users and legal obligations actually sit, not where compute is cheapest.

Pro Tip: Ask for these three things before you sign anything: the Data Processing Addendum’s exact residency clause, the current subprocessor list with regions, and proof of in-region processing for any AI inference involved. If a vendor can’t produce all three in writing, that’s your answer.

Key Takeaways

Choosing data residency correctly requires classifying data by risk, mapping true data flows, and verifying vendor claims with contractual proof rather than marketing statements.

Point Details
Classify before you choose Tier data by legal risk first; forcing all data into strict residency wastes budget on low-risk categories.
Storage residency isn’t inference residency AI workloads need separate verification that model execution, not just data storage, stays in-region.
Demand documented proof Require a DPA with residency language, a current subprocessor list, and SOC 2 or ISO 27001 reports before signing.
Watch the excluded categories Logs, backups, and metadata often sit outside residency guarantees by default across major vendors.
Design residency in from the start Zatersio builds Australian data residency and inference design into new MVPs and automations from the first sprint.

Table of Contents

How to Choose Data Residency Without Guessing

Most procurement teams treat “data residency” as one concept when it’s really three overlapping ones, and mixing them up is how compliance gaps happen.

Data residency means the physical or logical location where your data is stored and processed. Data sovereignty means that data stored in a jurisdiction is subject to that jurisdiction’s laws, regardless of who owns it. Data localization is a legal mandate requiring certain data to stay within a country’s borders, often with no exceptions.

The differences show up fast in a contract review:

  • Residency is a technical and contractual choice (you can pick a region).
  • Sovereignty is a legal fact (the government of that region can still compel access or impose rules on data stored there).
  • Localization is a regulatory mandate (some jurisdictions require it outright; most don’t).

Global analysis found 62 jurisdictions had some form of localization provision, but only 18 imposed absolute localization across all categories. Most countries run a conditional model, not a blanket rule.

Australia is a clear example of the conditional approach. The Australian Privacy Principles don’t mandate that personal information stay in the country. Instead, they require organizations to take “reasonable steps” before sending personal data overseas, an accountability model rather than a hard localization law. Under the European Union’s GDPR, by contrast, cross-border transfers require mechanisms like standard contractual clauses or an adequacy decision. When your procurement team asks for “data residency,” what they usually mean is a combination of all three: pick a storage location that satisfies sovereignty concerns and any applicable localization rules.

Why Data Residency Matters for Compliance and Risk

Residency decisions aren’t a checkbox exercise. They shape whether you pass an audit, whether your app performs well for users on the other side of the planet, and whether a regulator can compel disclosure of data you thought was safely offshore.

Three forces usually drive the decision:

  • Regulatory exposure. GDPR’s transfer restrictions, sector rules for health and finance data, and Australia’s accountability-based obligations under the Privacy Act all create documentation requirements, not just storage requirements.
  • Operational performance. Pinning data to a single region cuts latency for local users but can degrade experience for distributed teams, and it complicates disaster recovery if your backup region isn’t also compliant.
  • Audit readiness. Regulators and enterprise customers increasingly ask for proof, not assurances. A vague answer about “where data lives” is now a common procurement blocker.

The risk that catches teams off guard isn’t usually storage location. It’s the parts of the system nobody thought to ask about: application logs, monitoring data, and backups that quietly replicate outside the region you approved. A field guide to data residency practice calls this the “residency illusion,” where customer content sits neatly in-region while support tooling and telemetry sprawl globally. That gap is exactly what auditors probe first.

A Checklist to Decide Which Residency Approach Fits

Treat this as a working methodology, not a one-time form. You’ll revisit it every time a new vendor, product, or AI feature enters the stack.

Checklist diagram for data residency decision process

1. Classify data by risk tier

Not every dataset needs the same residency treatment. Split your inventory into tiers: data with a legal mandate for localization, data with strong sovereignty or contractual sensitivity, and data that can reasonably stay global (marketing analytics, for instance). Forcing everything into strict residency multiplies cost without reducing real risk.

Hands sorting folders by data risk tier

2. Map data flows end to end

Draw the actual path data takes, not the path you assume it takes, using an AI-native API platform to generate, test, and govern these flows for better accuracy. Include:

  • Primary storage and processing region
  • Backup and disaster recovery locations
  • Where logs, metrics, and support tickets land
  • Where AI features run inference, if any product in your stack uses generative AI

Cross-reference your risk tiers against the jurisdictions your organization operates in. The UNCTAD global registry of data protection laws is a practical starting point for mapping which countries impose transfer restrictions versus which rely on accountability models like Australia’s.

4. Interrogate vendor claims directly

Before shortlisting any vendor, ask these questions in writing:

  • Which specific data categories are covered by your residency guarantee?
  • Does residency extend to AI inference, or only to storage at rest?
  • Where are backups and disaster recovery copies stored?
  • Who are your subprocessors, and which regions do they operate in?
  • What is your migration timeline if we need to move regions later?

5. Watch for red flags that should stop the process

Some vendor answers are a reason to walk away, not negotiate harder:

  • No published subprocessor list, or one that’s out of date
  • Vague DPA language like “data may be processed in various locations” with no residency clause
  • No audit rights or unwillingness to share SOC 2 or ISO 27001 reports
  • Silence on whether cross-region replication happens for resilience or backup purposes

Pro Tip: If a vendor’s sales team can’t answer “does this cover AI inference or just storage” without escalating to engineering, that’s a sign the answer is probably no, and they haven’t had to say it out loud before.

This checklist approach mirrors what practitioner guidance recommends: classify, map, run a gap analysis, remediate, then monitor for ongoing changes as vendors update their infrastructure. Residency isn’t a decision you make once and file away.

How Major Vendors Actually Implement Residency

Vendors don’t implement residency uniformly, and the differences matter more than most sales decks suggest.

Atlassian lets organizations pin specific in-scope app data to a chosen region and publishes its supported region list directly, but notes that enabling residency can affect performance for users located outside that region. Microsoft Azure allows customers to select a geography for most services, but acknowledges that some services replicate data across geographies and that single-region guarantees don’t extend to every product in the catalog. Google Cloud similarly lists which services support configurable data location, calling out AI and machine learning services as a separate category with their own terms.

Amazon Web Services follows a comparable pattern across its regions: customers choose where workloads run, but auxiliary services and certain managed offerings can behave differently depending on configuration. Notion covers specific customer data categories at rest for data residency, while other features and categories may remain global, and enterprise customers typically need a sales-assisted migration to move into a data region rather than a self-service toggle.

OpenAI draws a sharper line between two concepts that most vendors blur together: data residency, which stores customer content at rest in a chosen region, and inference residency, which keeps model execution itself in-region for supported locations. Inference residency requires data residency to already be enabled, and it’s only available in specific eligible regions.

The pattern across all six: vendors treat customer content as the in-scope category worth marketing, while account metadata, authentication systems, and logs often stay global by default.

Pro Tip: Ask every vendor the same question in the same words: “What data is explicitly excluded from your residency guarantee?” The answer tells you more than the marketing page does.

Why Inference Residency Changes the Calculation for AI

Storage residency and inference residency are not the same guarantee, and treating them as interchangeable is where most AI procurement reviews go wrong.

Storage residency answers “where does the data sit at rest.” Inference residency answers “where does the model actually run when it processes a prompt.” A system can satisfy the first while failing the second entirely, meaning your prompt data crosses a border the moment it’s processed, even if the stored copy never leaves the approved region. This is an emerging compliance gap that storage-only residency reviews consistently miss.

Not every AI product supports inference residency, and eligibility is often narrower than the storage residency footprint. Before you commit, verify with:

  • Test prompts. Send a request and check response headers or logs for region identifiers where available.
  • Network tracing. Capture outbound traffic during an inference call to confirm the destination region matches the contract.
  • Contractual proof. Require the vendor to name the specific region in the DPA, not just “your selected geography.”
  • Audit logs. Ask for exportable logs that timestamp and geolocate processing events.

When a vendor can’t offer inference residency for your use case, the fallback options are architectural, not contractual: customer-managed encryption keys, edge or on-premises inference for the most sensitive workloads, or an isolated deployment inside your own cloud tenancy. Teams weighing that trade-off for legal work have found on-premises inference worth the added engineering cost when client confidentiality is on the line.

Pro Tip: If inference residency isn’t available, ask whether the vendor can guarantee zero data retention for model training instead. It’s a weaker guarantee than in-region execution, but it closes part of the gap.

Verifying Vendor Claims Before You Sign

A residency claim on a marketing page isn’t evidence. Procurement and legal need documents they can attach to an audit file.

Request these five items before signing:

  1. A Data Processing Addendum with explicit residency language, naming the region, not a general statement about “data protection.”
  2. A current subprocessor list with regions, updated on a schedule the vendor commits to in writing.
  3. SOC 2 Type II or ISO 27001 attestations, with the actual reports available on request, not just a badge on the website.
  4. Right-to-audit language, specifying whether you can request a report or conduct a review directly.
  5. Published migration and deletion timelines, stating how long data persists in the source region after a migration or contract termination.

Push for specific contract wording rather than accepting general assurances:

  • A pinned-storage clause naming the exact region for each in-scope data category.
  • An inference residency clause, if AI features are part of the deal.
  • Backup and disaster recovery locality terms, including whether DR copies sit in a different jurisdiction.
  • An explicit right-to-audit clause with a defined process and response window.

Verification also means testing, not just reading. Ask for exportable audit logs you can review independently, and request a written, sales-assisted migration plan with dates attached, not a general commitment to “help you migrate when needed.”

Costs, Performance, and a Realistic Timeline

Residency isn’t free, and the cost shows up in a few predictable places:

  • Premium or dedicated-region pricing tiers, often above standard multi-region rates.
  • Data egress and replication fees when moving data between regions.
  • Engineering time for migration, testing, and validation.

Pinning to one region also affects performance for distributed teams: users far from that region see added latency, which matters for real-time tools more than for batch processing.

Migration timelines vary by vendor model:

  1. Self-service migration (toggle a region setting): days to a few weeks, depending on data volume.
  2. Sales-assisted migration (enterprise-tier vendors like Notion or Atlassian): typically weeks to a few months, with a formal cutover plan.
  3. Full re-architecture (moving to a sovereign or on-premises deployment): several months, driven by engineering scope more than vendor process.

What Residency Guarantees Usually Don’t Cover

Even a strong residency commitment usually excludes a few categories by default: application logs, telemetry, authentication metadata, and some backup copies. Vendors also reserve the right to replicate data across regions transparently for resilience, and emergency access provisions can override normal residency boundaries during incident response.

When full residency isn’t achievable for a given system, mitigate with encryption using customer-managed keys, and limit integrations that would otherwise pull data outside your approved region.

How Teams Actually Make This Call

In practice, teams don’t wait for a perfect residency map before moving. They start with the highest-risk data classes, health records, financial data, anything under legal privilege, and accept a conditional model for everything else. A hard localization demand only makes sense when a specific regulation requires it; otherwise it adds cost without reducing measurable risk.

Hands marking high-risk data categories in folders

The real friction usually isn’t technical. It’s getting security, legal, and product to agree on risk tiers before procurement starts negotiating price.

How Zatersio Builds Compliant Residency Into New Systems

If your organization is building a new system or migrating an existing one, the residency decision works best when it’s designed in from the start rather than retrofitted after a vendor contract is signed. Zatersio builds MVPs and custom automation with Australian data residency as a standard option, not an add-on negotiated after the fact.

Zatersio

Zatersio’s engineering team designs the data flow, inference architecture, and storage location together, so you’re not discovering a residency gap six months into a vendor relationship. That includes AI agent deployments where inference residency matters, covered in detail on our AI agents page, and full custom builds where residency requirements shape the architecture from day one. Projects run on fixed pricing with a dedicated engineering team you can reach directly, no ticket queue.

If you’re scoping a new build or a migration and need residency handled correctly from the first line of code, start with an MVP development consultation and bring your data classification notes to the first call.

Frequently Asked Questions

What’s the difference between data residency and data sovereignty? Data residency is where data is physically or logically stored; data sovereignty is the fact that stored data remains subject to the laws of whatever jurisdiction it sits in, regardless of contractual promises.

Does Australia require data to stay within the country? No. Australia uses an accountability-based model under the Privacy Act, requiring organizations to take reasonable steps before sending personal data overseas rather than mandating localization outright, as OAIC guidance explains.

Is inference residency the same as data residency for AI tools? No. Storage residency covers data at rest; inference residency covers where the AI model actually executes when processing a request. A system can meet one without meeting the other.

What should I ask a vendor before signing a residency-dependent contract? Ask which data categories are in-scope, whether inference is covered, where backups and subprocessors are located, and whether they’ll provide SOC 2 or ISO 27001 reports on request.

How long does a residency migration usually take? Self-service toggles can take days to weeks; sales-assisted enterprise migrations typically run weeks to a few months depending on data volume and system complexity.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources