On most vendor signup screens, the data region is a dropdown next to the timezone. You pick Frankfurt or Singapore, the form submits, and somewhere in a shared database a column called region is set to the value you chose. Everything else about the system is the same system it was a second earlier: one control plane, one set of administrative credentials, one support console that can see every customer in every region, and one engineer on call who can reach all of it.
That arrangement can still be honest. Records really may be stored in the country named. But it is a different thing from what the word region implies to the person reading your security questionnaire, and the difference is worth being precise about, because it is the whole question.
A setting is only as strong as whoever can change it
If separation is implemented as configuration, then separation is a permission. Somebody can change it: an administrator, a migration script written under time pressure, a support engineer resolving a ticket at speed, an attacker who has taken over an internal account. Nothing about the storage location prevents a query written in one place from returning rows that belong somewhere else, because the rows are in the same database and the boundary between them is a predicate.
If separation is a deployment boundary, the equivalent mistake is not available. There is no query that crosses, because there is no shared database to query. There is no credential that reaches, because the credential that opens one region does not exist in the other. The failure mode changes from “somebody could get this wrong” to “somebody would have to build something new to get this wrong”, and that is a materially different sentence to write in a due diligence response.
This is the same principle that makes people prefer enforcement inside the database over enforcement in application code, which we have written about in the HR data security guide. Controls that depend on everyone remembering are weaker than controls that make forgetting impossible.
The questions that separate the two
Four questions do most of the work, and none of them are answered by a page saying “data residency available in eight regions”.
Is the database shared? Ask directly whether there is one database with a region column, or a separate database per region. If the answer arrives wrapped in the word logical, as in logically separated, you have your answer and it is the first kind.
Is there a cross-region key? Every vendor with regions has an internal support and administration surface. The question is whether that surface reaches across regions using a fan-in credential. A single console that can see all customers everywhere is convenient for the vendor and it is the highest-value credential in the company. Ask whether it exists. Ask what happens if it leaks.
Where do backups live, and where are they restored? Backups are the classic leak in a residency story, because they are operational plumbing rather than product, and it is easy for a global backup bucket to sit under a set of regional databases. Restores matter as much as storage: a restore drill performed by copying a regional backup into a convenient staging environment somewhere else has quietly moved the data.
Who can read it from where? Support staff are people with logins. If the support tool is global, then support is global, wherever the bytes are resting. If staff hold a separate login per region, the answer is different, and so is the offboarding process, because leaving the company now means being removed from each region individually.
Two sentences that are not the same sentence
“We store your data in your region” is a statement about storage. “Your data cannot leave your region” is a statement about reachability. Vendors say the first and buyers hear the second.
The gap between them is where the interesting failures live. Data can be stored in Frankfurt and read from a console in another continent. It can be stored in Frankfurt and copied nightly into a global analytics warehouse for product metrics. It can be stored in Frankfurt and processed by a background job running elsewhere. None of that necessarily breaks a residency claim as worded, and all of it may matter to the reason you asked.
So ask for the second sentence explicitly, and ask what would have to be true for it to be violated. A vendor with a real boundary will describe the manual, ticketed procedure that exists for moving a tenant, and will tell you it is the only path. A vendor with a setting will describe intentions.
The tradeoffs of doing it properly
It is worth saying that the boundary model costs the vendor real things, because a post that only listed benefits would be selling.
You lose the global view. Support cannot see every customer at once, so consolidated reporting is per region and stitched together by hand. Staff need a login per region and offboarding has to enumerate them. Every new region multiplies operational surface: another deploy target, another set of backups to verify, another monitoring configuration, another privacy assessment before it can accept anybody. That is why regions should open one at a time, driven by a customer or a regulatory requirement, rather than announced as a list on a website.
You also lose the easy migration. Moving a customer between regions becomes an export, an import, a verification and a deletion, performed by people and logged. That is worse for the vendor’s marketing and better for everyone reading the security review.
The same trade lands on you if you employ people through entities in more than one country. A multi-entity record held in one region is one directory you can report across; the same record split across two regions is two directories reconciled by hand. Which of those you want is a decision to make before signup rather than after, because the region is the choice that is not adjustable later.
Where Capstan stands
Capstan’s regions are deployment boundaries. One database is one region. Nothing is global: no shared control plane, no global identity system, and no cross-region service key anywhere in the architecture, which is a stronger statement than governing such a key carefully, because it does not exist to be governed. The internal console runs inside each region and reads only that region’s data, so staff hold one login per region rather than one login for the world.
The choice is settled before you sign up, and the mechanism is unusually blunt: the application you sign into IS your region. There is no email-to-region resolver on the marketing site, because the site holds no database connection of any kind; it carries a versioned list of live regions and redirects you. After signup the choice is permanent. Changing it is the manual, ticketed export, import, verify and delete described above, not a switch.
Today India is the one live region, and further regions open one at a time, each named here only on the day it is actually serving. One honest compromise travels with that sentence and is published rather than buried: stored data for the India region is in India, and compute currently runs from a nearby location outside the country, which we will co-locate when the vendor offers it. The controls, and the limits beside each of them, are on the security page, and the reasoning about publishing limits at all is on the manifesto.
Where the data rests is only half the picture for an Indian workforce. The other half is what you owe the employees themselves: the notice you give them, the ground you rely on to hold their records, and how long you keep them afterwards. That is the Indian position under the DPDP Act, and it attaches to you as the employer whatever region your vendor sits in.