A company signs up for "the cloud" and considers the matter closed. Few stop to ask what country that server sits in, who answers for it if something goes wrong there, and what happens the day the company needs to pull its data out of that place. It sounds like a technical question. It isn't — it decides whether the company is complying with the law, who it can hold accountable when something fails, and even how fast the system feels day to day.
"The cloud" is not an abstract place. According to Microsoft's official list of Azure regions, Azure runs a data center called "Brazil South," in São Paulo, with a second, access-restricted site in Rio de Janeiro. That's a real building, with a real address, real power supply, and local law that applies to it — except most cloud contracts never make clear, to whoever signs them, which region was picked or why.
Whoever approves the budget rarely asks. And when someone does ask, no one in the company can always answer without opening the contract — assuming it's in a language they read, and assuming anyone has actually read it.
Where Your Data Actually Lives
Every cloud system runs inside a specific region, chosen the moment the account was set up — usually by whoever configured the service, not by whoever signs off on the budget. That choice is rarely revisited later, even as the company grows, changes support providers, or starts serving clients who require the data to stay inside the country.
Brazilian data protection law does not ban a Brazilian company's data from sitting outside the country, but it sets specific rules for that move — a recognized contractual clause, a guarantee that the destination offers equivalent protection, or the data subject's consent, depending on the case. Brazil's national data protection authority is the one that enforces this. In practice, a company that never asked where its data sits also can't say whether it's meeting that requirement.
The problem shows up in a much less legal way day to day: a contract in a foreign language, support that answers from a different time zone, and no one in the company able to explain, when a client or an auditor asks, where their data actually lives. "It's in the cloud" doesn't answer anything.
There's also a practical side no one notices until the system feels slow: the farther away the server physically sits from the people using the system every day, the longer every screen takes to load, every report takes to run. Picking the wrong region isn't just a legal question — it's an operational one.
There's also the most common confusion of all: assuming "being in the cloud" hands over all responsibility to the provider. It doesn't. The provider takes care of the building, the power, the physical equipment and the infrastructure underneath the service; the company stays responsible for who has access to each system, what data it keeps there and for how long, and for flagging it if something moves out of place. Reading the contract is exactly how a company finds out where that line falls — and it isn't the same line with every provider.
Why Trusting the Word Cloud Falls Short
The common approach is to sign up for a cloud service through a reseller, accept the standard proposal, and move on without asking anything else. "It's in the cloud" has become shorthand for "it's safe" and "it's handled" — when in fact it only describes where the system runs, not who takes care of it or under what rules.
That habit gets expensive at exactly the moment a company can least afford it: in the middle of an incident. When something leaks or disappears, the first question is always "where was this stored and who had access" — and a company that never wrote that answer down loses precious time reconstructing it, in a panic, when it should have been on file from the start.
The size of the problem, when it lands, is not small. The average global cost of recovering from a data breach was $4.44 million in 2025, according to IBM's report on the cost of data breaches — down from the year before, but still high enough that no company, of any size, should treat it as abstract.
What Has to Be in Place
A well-run cloud setup doesn't rely on luck or on taking the provider's word for it. It relies on simple, checkable mechanisms, reviewed from time to time.
Knowing which country and which provider each system runs in. No one needs to memorize it, but someone in the company should be able to point to it without an hour of searching.
A contract read before signing, not just filed away after. What it says about where the data sits, what changes if the company switches providers, and who answers for a failure on the cloud provider's side.
An inventory of what lives in each cloud. Systems, spreadsheets, backups and mailboxes scattered across different contracts with no list anywhere is exactly why no one can answer fast when it matters.
An exit plan for the provider. A deadline to export what belongs to the company, the file format, and what happens to whatever gets left behind — agreed before it's needed, not in the middle of a dispute.
One person who can explain the setup, whether to a client who asks or an auditor who requires it. A clear answer is worth more than any certificate on the wall.
A cost estimate before switching provider or region. Moving cloud has a migration price, and deciding without that number in hand is deciding in the dark.
This is how Skills IT works: mapping which region each client's system is hosted in, documenting what each cloud contract promises, and keeping ready an inventory of what would need to be exported the day it's time to switch providers.
What the Company Gains From Knowing
The gain isn't abstract, and it isn't only legal. It's the difference between negotiating a cloud contract knowing what's at stake and signing on the seller's word.
A company that knows where each system is hosted negotiates better: it asks for the right region, understands the price of changing later, and doesn't end up stuck with one provider for lack of anywhere else to go. That's the power to choose, and it costs less than it looks — the real cost sits in not having that information when it's needed.
There's also a quieter gain: when a client, a partner or an auditor asks where the company's data sits, the answer comes right away, on file — instead of turning into an internal investigation that stalls everything else while someone tries to piece the story back together.
And there's the gain of staying at the right pace: a system hosted in the right place, for the right audience, responds faster — and a team that trusts the system's speed is a team that doesn't waste time waiting for a screen to load.
None of this means switching providers tomorrow, or rushing to migrate anything. It just means the next cloud decision — signing, renewing or expanding — gets made with the right question on the table: what country will this sit in, and what do we do if we ever need to pull it out.
Questions to Bring to Your Next Meeting
Before signing the next cloud contract, or reviewing the one already in place, it's worth asking:
- Can anyone here say, without checking, which country each important system is hosted in? If the answer is "we'd have to check," the first step is already clear.
- Does the current contract say what happens if we switch providers? Without that clause, switching costs more than it should — and takes longer than it should.
- Is there an inventory of what sits in each contracted cloud? Without one, every question turns into an investigation.
- Who in the company can explain this setup to a client or an auditor, if asked? If the answer is "no one," it's worth deciding who takes that on.
- Have we ever asked for a cost estimate to migrate, in case it's ever needed? Deciding without that number is deciding with half the information.
