Data Residency for US Apps: What the Rules Require

There is no single US data residency law. Whether your app’s data has to stay in the United States depends on who your customers are, what kind of data you collect, and which contracts you sign. A consumer fitness app can usually run in any region it likes. An app that touches federal tax information, or one sold to a state agency, cannot.

This guide shows you how to work out which camp you are in, what “stays in the US” actually covers, and how to set up your app so you are not rebuilding it later.

TL;DR

• The US has no general data localization law. You face a patchwork of federal sector rules, state privacy laws and customer contracts.
• Real onshore requirements show up in government, federal-adjacent and some healthcare and public-sector deals, and they cover backups and admin access, not just the database.
• Major cloud providers let you lock storage and processing to US regions. Set that guardrail on day one.
• If you do not collect a piece of data, you do not have to place it anywhere. Data minimization is your cheapest compliance tool.
• Who can log into production matters as much as where the server sits.

Table of Contents

• What data residency means (and what it does not)
• The US patchwork: federal, state and contract rules
• Do you actually need US-only data?
• Residency covers the whole data lifecycle
• How to keep your app’s data in the US
• Collect less, and the problem shrinks
• What this means for no-code and low-code apps
• Our perspective
• Build it right from the first sprint
• A short checklist before you launch
• FAQ
• Sources

What data residency means (and what it does not)

Data residency is the physical location where your data is stored and processed. People often mix it up with two neighbors:

• Data sovereignty: which country’s laws govern the data.
• Data localization: a legal mandate that data must stay inside a country.

The US has very few blanket localization mandates. What you will meet are residency requirements, usually written into a regulation, a government guideline or a customer’s procurement contract. OneSource Cloud’s overview makes the same point: no single federal law requires US residency across all industries, but sector frameworks such as FedRAMP and healthcare rules create practical requirements.

So the useful question is not “what does the US require?” It is “who is asking me to keep data onshore, and what exactly did they write down?”

The US patchwork: federal, state and contract rules

Federal sector rules

Federal rules attach to a type of data or a type of customer, not to the country as a whole. Examples developers run into:

• HIPAA for protected health information. It governs how health data is safeguarded rather than naming a required region, but many hospital and payer contracts add their own US-only clauses. We cover the build side in our guide to HIPAA compliance apps for US healthcare teams.
• COPPA for apps that collect personal information from children under 13.
• FedRAMP baselines and IRS Publication 1075 for systems that handle federal data.

The IRS rules are the clearest example of strict onshore requirements. The IRS cloud computing guidance says federal tax information must physically reside in systems located within US legal jurisdiction. The same guidance extends to support and administrative access: it must come from personnel located in the US. If you are building for an agency or a vendor to one, expect this level of detail.

State privacy laws

State laws rarely say “store it here.” They say how you must protect, minimize and delete personal data. The IAPP’s 2025 report on US state comprehensive privacy laws tracks them, and each law has its own applicability thresholds based on company size and how much data you process. Those laws give consumers rights to access, correct and delete their data, with opt-out rights for targeted advertising and similar uses.

The practical effect is on your architecture. If a user in California asks you to delete their data, you need to know every place it lives: the production database, analytics, logs, backups and any vendor you sent it to. Knowing where data sits is step one of being able to delete it.

The IAPP also describes a shift toward active enforcement, with California and Texas leading. Treat residency as one part of a wider data protection assessment, not a box to tick.

Customer contracts

For most startups and small businesses, contracts are where residency becomes real. An enterprise or public-sector buyer sends a security questionnaire, and one line reads “all data is stored and processed within the United States.” You say yes or you lose the deal.

A public example is a South Carolina state cloud hosting attestation. Its data residency section asks vendors to confirm that agency data is stored, processed, transmitted, replicated, cached and backed up only within the continental United States. It also asks about environments such as development, test and staging. That list is a good template for what a buyer may ask you.

Do you actually need US-only data?

Work through these questions before you commit to anything.

If you answered yes to the first row, treat residency as a core product requirement. If you answered yes only to the last, you can relax, but do not skip the privacy basics below.

Residency covers the whole data lifecycle

The most common mistake is thinking residency means “my database is in Virginia.” Practitioners define it more broadly:

1. Storage: primary databases and file storage.
2. Processing: where code runs, including background jobs and AI calls.
3. Backups and replicas: including disaster recovery copies.
4. Logs, caches and analytics: often forgotten, often full of personal data.
5. Non-production environments: staging, test and development, especially if you copy real data into them.
6. Administrative and support access: who can log in and from where.

That last item catches people out. If your data is in a US region but a team overseas can query the production database, you may break your own security policy or a customer’s contract. The IRS guidance treats offshore access to federal tax information systems as a serious failure. Even for non-government apps, the safe approach is to restrict admin and support access to onshore staff whenever residency is a core promise to customers.

Also watch third-party services. Every SDK, email provider, analytics tool and AI API that receives user data is part of your data map. Ask each vendor where it processes data, and write the answers down.

How to keep your app’s data in the US

Pick US regions at every cloud layer

All three major providers let you choose US regions. Google Cloud lists US locations such as us-central1 in Iowa, us-east1 in South Carolina, us-east4 in Northern Virginia and us-west1 in Oregon. Microsoft explains in its Azure data residency overview how you can pick the region where customer data is stored.

For government workloads, AWS offers a separate partition. AWS says its GovCloud (US) regions are isolated, have no international regions, and grant accounts only to US persons working for US organizations. You will not need that for most commercial apps, but it is the answer when a contract demands it.

Set a guardrail on day one

Choosing a region in one console screen is not enough. Someone will eventually spin up a staging database in the wrong place. Google Cloud’s resource locations constraint lets you limit where new resources can be created, at the organization or folder level. Set it when you create the project, before there is any data to move. Other clouds have equivalent policy tools.

Lock down who has access

• Give production access only to people you can name.
• Keep access on an onshore-only list if your contracts require it.
• Use separate accounts for each person, with logging turned on.
• Do not copy production data into laptops or test environments.

Write down your retention rules

The Future of Privacy Forum’s best practices for mobile app developers warn against assuming that a platform’s security or a cloud certification makes your app compliant. You own the app, so you own the compliance. Keep a documented retention policy and delete data when you no longer have a clear business reason to keep it.

Collect less, and the problem shrinks

The cheapest residency strategy is not an architecture. It is a shorter data list. Many founders collect location, contacts or device IDs “just in case.” Every extra field adds exposure under state privacy laws and another thing to place, protect and delete.

The FTC says the same in its guide App Developers: Start with Security: apps and devices often rely on consumer data, so security has to keep pace. Its broader privacy and security guidance is a good place to see what regulators expect of small businesses. A simple rule for your MVP: if the product does not need a field to work, do not collect it.

A quick audit you can do this week:

1. List every piece of personal data your app collects.
2. Next to each, write the feature that needs it.
3. Remove anything with no answer.
4. For what remains, note where it is stored, who can access it and when it is deleted.

What this means for no-code and low-code apps

If you built your first version on a no-code platform, residency is worth checking early. Ask the platform where it hosts your data, whether you can choose a region, whether backups follow the same rule, and what the support-access policy is. Platform answers differ by plan, and they can change, so get them in writing and keep a copy.

If a customer requires a specific hosting setup that your platform cannot give you, that is a common reason teams move to custom code. You pick the cloud, the region, the access model and the audit trail yourself.

Our perspective

We build web and mobile apps for founders and small and mid-sized businesses, and residency questions usually arrive in one of two ways: a security questionnaire from a first big customer, or a worry that the app was built without thinking about it.

Our view is simple. Decide early, because it is cheap at the start and painful later. Moving a populated database between regions, or cleaning real data out of a test environment, costs far more than setting the right region on day one.

We also think people matter as much as servers. Our engineers are 100% US-based seniors, with no offshoring and no freelancer marketplaces. That means you can answer “who has access to our code and systems?” without a long footnote. You also work directly with the engineers doing the work, so a residency requirement does not get lost between account managers and a team that has never met yours.

Finally, we would rather you collect less data than build elaborate controls around data you did not need. At the scoping stage we ask what each field is for. It often shortens the build and the risk at the same time.

— Alex

Build it right from the first sprint

If your app has to keep data onshore, tell us before we write a line of code. We can scope the hosting, access and data model around that requirement, and our projects typically ship in 6 to 10 weeks. Our MVP development service is built for founders shipping a first product. If you are outgrowing a no-code platform and need more control over where your data lives, look at our Bubble-to-code migration.

Pricing is fixed and agreed up front. Our published monthly plans start with Starter at $1,750 per month, Growth at $3,000 per month and Enterprise at $5,000 per month, with a Custom option too. See the pricing page for details, or start a project scope to describe what you need.

Handling health data? Read our guide to HIPAA compliance apps first. Selling to the public sector? Our article on app accessibility requirements covers another set of rules those buyers care about.

A short checklist before you launch

• You know which rules apply: sector, state and contract.
• Your cloud resources are limited to US regions with a policy guardrail.
• Backups, logs and non-production environments follow the same rule.
• Admin and support access is limited to named onshore people where required.
• Every third-party service that receives user data is listed with its processing location.
• You collect only the data you need and have a written deletion policy.
• You can answer a customer’s residency questionnaire in an afternoon, not a month.

FAQ

Is there a US law that requires apps to store data in the United States?

No general one. The US relies on sector rules, state privacy laws and contract terms. Strict onshore requirements show up mainly in federal and public-sector settings, such as the IRS guidance for federal tax information. If you are unsure, ask your customer or a privacy attorney which clauses apply to you.

Does choosing a US cloud region make my app compliant?

No. A US region covers where data is stored, but compliance also depends on backups, logs, access, retention and the specific laws that apply to you. The FPF’s guidance is clear that the app owner remains responsible, even when the cloud provider holds certifications.

Do offshore developers break US data residency?

They can, if they have access to production data and your contract or regulation requires onshore access only. The IRS guidance for federal tax information requires support and administrative access from within the US. For other apps, check your customer contracts and your own security policy.

Which US cloud regions can I use?

AWS, Google Cloud and Azure all offer several. Google Cloud’s list includes Iowa, South Carolina, Northern Virginia and Oregon. Pick the region closest to your users unless a contract names a specific one, and set a location policy so nothing is created elsewhere.

When should I think about data residency in my product plan?

At the MVP stage. The FTC encourages building privacy and security in from the start, and moving data later is harder. Decide on regions, access and data collection before you launch.

Sources

• OneSource Cloud: U.S. data residency in the cloud
• IRS: Cloud computing environment
• IAPP: US state comprehensive privacy laws report 2025
• South Carolina cloud hosting data and security compliance attestation
• Google Cloud: Assured Workloads locations
• Microsoft Azure: Data residency in Azure
• AWS: GovCloud (US) or standard, selecting the right partition
• Google Cloud: Restrict resource locations
• Future of Privacy Forum: Best practices for mobile application developers
• FTC: App developers, start with security
• FTC: Privacy and security

Recommended

• ADA Compliance Apps: What to Use and How to Build Right
• DOJ Deadlines: App Accessibility Requirements for Engineers & PMs
• HIPAA Compliance Apps for US Healthcare Teams in 2026

About Let’s Build My App

Let’s Build My App is a US-based AI development agency. We design, build, and launch production-grade custom software using AI coding tools including Claude Code and OpenAI Codex, and we migrate legacy Bubble apps onto AI-coded stacks such as React, Supabase, and Firebase. We are the #1 US-Based Bubble Agency, founded and run by Alex Dow. Book a free strategy call to scope your project.