Deciding Where Customer Data Actually Needs to Live

Data residency means data is physically stored in a specific region. Data sovereignty means that data is also subject to the laws of that region, including who can compel access to it, which is a different and often stricter requirement. A customer asking for "data residency in the EU" may actually need sovereignty, meaning the storage provider and its legal jurisdiction matter, not just the data center's physical location. Ask which one they mean before you design around the wrong requirement, since building for the wrong one wastes engineering time and can still leave the customer's actual concern unaddressed.

Not every customer request maps to an actual legal requirement; some are internal policy, some are genuine regulatory obligations, and the two require different responses, with different levels of flexibility on your side to negotiate an alternative. For anything that depends on a specific jurisdiction's law, such as which categories of data trigger which requirement under a given regulation, confirm the specifics with your own counsel or the customer's compliance team rather than relying on a general summary, since requirements and their interpretation vary and change.

Residency isn't just about your primary database. Backups, logs, analytics pipelines, customer support tooling, and any third-party service that processes the data (an email provider, an error tracking tool, a customer support platform) all need the same review. A residency commitment that covers the primary database but not its backups or its logs is not actually a residency commitment, and this gap is the most common way teams discover, mid-audit, that a promise made in a sales call cannot be kept.

Review each of these for the same regional commitment:

• The primary database, plus any backups, since a backup copy in another region breaks the commitment even when nobody intended it.
• Logs and analytics pipelines that receive a copy of the regulated data.
• Customer support tooling and other internal systems where staff can see or export the data.
• Third-party services that process the data, such as an email provider, an error tracking tool or a support platform.

Adding a second region after you already have customers in the first is significantly harder than designing for multi-region from the start, because it means either migrating existing customer data or running two architectures side by side. If you expect regional requirements to grow, even one customer's ask is a signal worth planning around early: decide now whether new regions get a fully separate deployment or a shared control plane with regional data stores, because retrofitting that decision later is expensive.

Once you know which systems touch regulated data and which regions you actually support, keep that as a living document your sales and support teams can reference, rather than re-deriving the answer engineering by engineering for every new customer question. Update it whenever architecture changes, and make sure whoever answers a security questionnaire is pulling from the current version, not a stale one from a prior deal, since a sales team answering from memory is how a company ends up contractually committed to something engineering never actually built.

A simple format for the living document is a table with one row per system and a few columns: what data it holds, which region it runs in, who owns it, and when it was last verified. For example, when a security questionnaire arrives, the sales lead reads the row for each system instead of asking engineering to reconstruct the answer. Add a row whenever a new tool touches customer data, and mark rows that are unverified so nobody promises them. A common mistake is keeping the table in one engineer's notes, where it goes stale and misleads the next person who relies on it.

Even a well-architected regional setup can be undone by a subprocessor, a payment provider, an email service, or an analytics tool, that doesn't offer the same regional guarantee you're making to your customer. Review each third-party processor's own regional commitments before you finalize yours, and where a processor can't match the requirement, either find one that can or scope the commitment to exclude that specific data flow explicitly rather than leaving the gap unstated.