Find out which country your customer data is actually stored in
Somewhere in an agreement you’ve signed, there’s a sentence naming a country. Data will be stored in Australia, or within the EU, or wherever it happens to say. Most people signed that without checking, because checking felt like it would be hard. It takes about fifteen minutes.
Data lives in a building. That’s the part that gets abstracted away by the word cloud, and it’s the part the sentence in your contract is actually about. A rack, in a room, in a town, in a country whose laws apply to the machines in it.
Which building was a choice somebody made, usually in a dropdown, usually years ago, often by whoever set the thing up in a hurry. It might be exactly what you promised. It might be a default that was never revisited.
The awkward part is that the vendor’s website will happily tell you the answer is fine. Compliance pages describe what a provider offers: which regions exist, which certifications they hold, what a customer can select. None of that is a statement about what you selected.
The vendor’s page tells you what’s possible. Your console tells you what’s true.
Before you start
Fifteen minutes and login access to whatever holds your customer records. No tools.
We’ll use AWS as the worked example in step 3 because it’s the common case, but the method is the same everywhere: find the region field, in the account, for the specific resource.
List where customer data actually lives
Not servers. Systems.
Write down every place that holds something about your customers. The list is usually longer than the one people say out loud:
- The app database
- File and document storage
- Backups, which are frequently somewhere else entirely
- Email, and anything in a support inbox
- Your CRM, your invoicing tool, your analytics
- Any AI tool you’ve pasted customer information into
You don’t need to check all of them today. You need the list, because the promise you made covers all of them and not just the one you were thinking of.
Start with the one holding the most
Pick the single system with the most customer data in it. Usually the database, sometimes file storage.
Do this properly on one, rather than badly on eight. The point of the exercise is finding out whether your answer is grounded, and one grounded answer beats a page of assumptions.
Find the region in the console, not the marketing page
For S3, open the S3 console, select the bucket, choose the Properties tab, and read AWS Region in the bucket overview. From a terminal:
aws s3api head-bucket --bucket your-bucket-name
Whatever your provider, the shape is the same. You’re looking for a field attached to the specific resource, in the account, that names a region. ap-southeast-2 is Sydney. eu-west-1 is Ireland. us-east-1 is Virginia, and it’s also the default that things end up in when nobody chose.
Write down the region code and the country it maps to. That’s the real answer for this system.
Don’t accept an answer that isn’t one
Some things look like the answer and aren’t. This is the step that catches them.
If your site is behind a CDN, the response carries a header naming the datacenter that served the request. Cloudflare’s Cf-Ray ends in a three-letter code, like -SJC for San Jose. That’s genuine and it’s interesting and it isn’t data residency. It’s where a copy of a page was served from, not where your records are stored.
Same for the compliance page, the trust center, and the badge in the footer. Those describe available capability, not your configuration.
The test for any answer: could you point at the field in your own account that produced it? If not, you have a claim rather than a fact.
Chase the three places data leaves the region on its own
A workload can run in one country while its data quietly makes copies in others. Three of these account for most of it.
Backups. Frequently in a different region on purpose, because that’s the point of a backup. Find where yours go, and check that country against your promise, because your promise almost certainly didn’t carve out an exception for backups.
Logs. Application logs, error trackers and analytics routinely ship somewhere central, and they routinely contain email addresses, names and IDs. A log aggregator in another country is customer data in another country.
Support access. If your vendor’s support team can view customer records to help you, the country their staff sit in matters, and it’s usually different from where the data rests.
Compare it to the sentence you signed
Put the two side by side: what the contract says, and what the console says.
Three outcomes and they need different things from you.
- They match.
- Write the region down next to the clause. Done, and now it’s checkable in thirty seconds next time.
- They don’t match.
- That’s worth knowing today rather than during a security questionnaire. Moving a region is usually a migration, not a setting, so it’s a plan rather than an afternoon.
- There is no clause.
- More common than you’d expect. Nothing is broken, but you now have a decision to make on purpose instead of a gap that shows up in somebody else’s due diligence.
A boundary worth knowing about
Where data rests and who can reach it are different questions, and only the first one has a dropdown.
Data stored in Frankfurt can be accessed by a support engineer in another country, and a provider headquartered elsewhere may be subject to legal requests from its own government regardless of where the disk is. Region settings are a real control and they’re a control over geography, not over jurisdiction. If your obligation is genuinely about which government can compel access, that’s a harder question than this guide answers, and the honest move is to say so rather than to point at a region code.
The other edge is that this is true today. Providers add regions, migrate services and change defaults, and nothing tells you when a component moves. That’s the argument for writing the answer down with a date on it.
If you have staff
Somebody should be able to answer this in a minute. Not research it, answer it. That means a short written list of system, region, country, and the date it was last confirmed, kept where contracts live rather than in one person’s notes.
Onboarding a new tool is when this changes. Somebody signing up for a support desk or an analytics product on a Tuesday afternoon is the most common way customer data quietly moves country. One question in the signup habit, where does this store data, prevents the whole problem.
The short version
- List every system holding customer data, including backups, logs and email
- Start with the one holding the most
- Find the region field on the resource itself. S3: bucket, Properties, AWS Region
- Reject answers that aren’t answers. A
Cf-Raycolo code is where a page was served, not where data lives - Chase backups, logs and support access separately, because each leaves the region on its own
- Compare it to the clause you signed, and write the answer down with a date
Sources
- GetBucketLocation, Amazon S3 API reference — bucket region lookup, that
us-east-1returns an empty location constraint, and that AWS now recommends HeadBucket for this - Cloudflare HTTP headers —
Cf-Rayand its three-letter datacenter suffix, which identifies the serving colo rather than where data is stored
Written August 2026. Console paths and header behavior checked against the AWS and Cloudflare documentation on 23 August 2026.
Prints to PDF from your browser — colours and all.