Data Has an Address: Why Customers Now Ask Where Your Database Lives

Somewhere in most enterprise security questionnaires, there is a cell that wants a place name. The buyer asks where customer data is held, and the supplier types back a country, a region, a provider’s name, or the phrase that answers nothing at all: we use the cloud. The cell is small. The question underneath it is not one question but three, and they can have different legal, security, contractual, and operational consequences for a deal.

What has changed is who asks. Data location used to be a topic for legal review, raised late and settled between lawyers. It now arrives early, from a procurement or security team working through a standard list. That makes the choice of region a commercial decision, and because distance costs milliseconds, a product decision too.

Buyers’ instincts point the same way. In Cisco’s 2025 Data Privacy Benchmark Study, which surveyed 2,600 privacy and security professionals in 12 countries, 90% of organizations said they see local storage as inherently safer. Yet 91% also said a global provider would protect their data better than a local one, which is why the question has shifted from which vendor to which region.

“Where is your data?” is three questions in one

Data residency, localization, and sovereignty are often used interchangeably, but they describe different issues. Residency is a fact about infrastructure, localization is a rule, and sovereignty is the widest of the three. Each one calls for different evidence:

Sovereignty is where confident answers usually fail. Saying that data sits in Virginia, Oregon, or Europe answers residency and sovereignty only partly, because the laws that can govern access to data do not necessarily stop at the physical location of the server.

For U.S. providers, the CLOUD Act of 2018 is the concrete case. It amended U.S. law to make clear that a provider subject to U.S. jurisdiction may be required to disclose data within its possession, custody, or control regardless of whether that data is located inside or outside the United States.

A European region run by a U.S.-controlled company therefore answers the residency question without necessarily removing U.S. legal exposure. The same distinction matters in reverse when an American company uses providers, subsidiaries, or infrastructure operating under other jurisdictions.

Procurement asks, and U.S. privacy rules make the answer matter

The question has become routine in due-diligence packs. The compliance consultancy CloudSapio publishes a list of twenty security questionnaire questions it says stall enterprise SaaS deals, and “Where is customer data stored? Can we choose the region?” sits fifth on it, under data protection.

The firm sells the readiness it describes, so the list is a supplier’s view of its own market and not neutral research, but it is a fair signal of what buyers send.

In the United States, there is no single comprehensive federal privacy law equivalent to the GDPR that imposes one general data-residency rule across every industry. Instead, companies can face a combination of federal sector-specific requirements, state privacy laws, contractual commitments, and customer security requirements.

That distinction matters. A U.S. company may not be legally required to keep all customer data inside the United States, but it may still have to tell customers where information is processed, identify service providers or subprocessors, implement contractual safeguards, or meet sector-specific security and privacy requirements.

State privacy laws add another layer. California’s Consumer Privacy Act, as amended by the California Privacy Rights Act, imposes obligations around the handling and sharing of personal information and the relationships between businesses, service providers, contractors, and third parties. Other states have enacted their own comprehensive privacy laws, making the applicable requirements dependent in part on the customers and data involved.

Sector requirements can go further. Organizations handling protected health information may have obligations under HIPAA, while financial institutions may face requirements under laws and regulations such as the Gramm-Leach-Bliley Act and its Safeguards Rule. Government contracts can introduce still more specific security, hosting, and access requirements.

For U.S. suppliers serving international customers, European rules remain relevant as well. Article 44 of the GDPR, for example, establishes the general principle for transfers of personal data to third countries or international organizations: such transfers may take place only where the conditions in Chapter V are met, including for onward transfers, so that the level of protection guaranteed by the GDPR is not undermined.

The practical lesson for a U.S. supplier is not that every database must stay in one country. It is that “we use the cloud” is rarely enough. Customers increasingly want the actual region, the organizations that can access the data, the contractual protections that apply, and what happens when data crosses borders.

The farther the region, the slower the click

The second reason to care about region has nothing to do with law. A request to a database has to cross a network and come back, and the floor on that round trip is set by physics. The RIPE NCC, which runs one of the largest public measurement networks on the internet, offers a working figure: as a ballpark, 100 kilometers of physical distance increases latency by roughly 1 millisecond of round-trip time.

Applied to distant regions, the arithmetic is blunt. A database hosted thousands of miles from its users introduces network latency before any routing, queuing, or query execution is counted.

An application making six sequential database calls to render a screen can therefore spend a substantial portion of its response time on distance alone, and no amount of index tuning recovers it, because the delay is in the map rather than the query plan.

That figure is a floor, and floors are optimistic: fiber routes run longer than great-circle distances, and congestion adds to the total. Measuring the real path is what RIPE Atlas exists for, using a global network of probes and anchors that actively measure internet connectivity and can show what a specific route actually costs.

For a U.S.-focused application, this can turn the choice between East Coast, Central, and West Coast infrastructure into a product decision rather than merely an administrative one. A region close to most users can reduce latency, while applications serving customers across the country may need replication, caching, or other architectural choices to keep response times consistent.

It is the backup that decides how long the data exists

Three architectures cover most cases:

• Single region: the simplest to operate and the cleanest residency answer, at the price of holding every copy in one place.
• Primary region with remote backups: a recovery plan that survives the loss of a whole region, with its own cross-region RPO and RTO, and potentially a second jurisdiction to explain.
• Read replicas near users: less distance for read-heavy work, and more places where a copy of the data lives.

Each pattern trades a residency story for an operational property, at an exchange rate set by legal and contractual requirements, the recovery objective, and the shape of the traffic.

When a team provisions a cloud database as a managed service, the selected region becomes one of the most important facts in the residency answer. The provider’s own documentation should identify where database nodes, replicas, and backups can reside and whether customers can control those locations.

Backup retention is one of the most useful numbers for anyone filling in a questionnaire, because it answers a question buyers increasingly ask: once we delete a record, how long can a copy of it still exist?

A 30-day backup retention period, for example, does not necessarily mean deleted information remains readily accessible for 30 days in production. It does mean the organization’s deletion and retention explanation should account for copies that may remain in protected backups until those backups expire under the provider’s retention process.

It is worth being clear about what the region setting does not buy. Picking a U.S. region settles part of the residency question but does not, by itself, settle sovereignty, because ownership, corporate control, government access rules, subprocessors, and applicable law are separate from the location of the hardware.

A three-node cluster inside one region survives the loss of a node, not necessarily the loss of the region, so the pattern that fixes that gap—a cross-region replica or backup with its own RPO and RTO—is the same pattern that can add another location to the questionnaire.

Encryption narrows the sovereignty gap without closing it. Customer-managed keys, whether generated in a key management service (KMS) or imported by the customer (BYOK), can limit access to plaintext data depending on how the system is designed and who can reach the keys. Where the keys live, who controls them, and under what circumstances they can be accessed are therefore additional questions worth asking.

Even when the address is right

A strong answer names things:

• The region hosting the primary and the regions hosting replicas and backups, with retention periods.
• The privacy and data-processing agreements governing the service, including relevant subprocessors and cross-border transfers.
• Each certification or independent assurance report and the scope it actually covers, rather than simply listing security logos.
• What happens at failover, including whether data can land in another region or jurisdiction while an incident is running.
• Who controls encryption keys and where those keys are stored.
• The date on which the information was last verified.