Data sovereignty means your organization decides who can access its data, and no other country’s government can order the company holding it to hand it over. Where the data physically sits is part of that. It is not the whole of it. A copy in a Toronto data centre is a fact about geography, and it tells you nothing about who holds the encryption keys, which support engineers can log in to the live system, or which country’s courts can order the company holding it to hand it over. You have sovereignty only when all three answers are the ones you want: where the data sits, who can reach it, and whose law applies to the company holding it. I have sat through a lot of these reviews. The one I remember was a Thursday call, twenty minutes in, when the IT manager said “it is hosted in Canada” and everyone on the line relaxed. Then the security lead on the other end asked who has administrator access to the account. Support turned out to be a round-the-clock rota staffed from three countries. Backups replicated to a second region for durability. An analytics add-on sent usage data somewhere nobody on the call could name. Nothing anyone said was untrue. The Canadian address was real. It just was not an answer to the question being asked. I am not a lawyer and none of this is legal advice. The rule text and a compliance professional govern what your organization actually has to do. What follows is how I break the question into parts before I get to them. What does data sovereignty actually mean? Three separate questions get collapsed into one word, and they have different answers. Residency is geography. Which racks, in which buildings, in which country, hold the data at rest. Backups and replicas count. Disaster recovery counts. Control is engineering and operations. Who can technically reach the data. Who holds the keys. Which administrators, which support staff, which service accounts, which other companies the vendor passes data to (its subprocessors), and which routes nobody thought to list, like copied log files and crash reports. Jurisdiction is law. Whose courts and agencies can compel the company that holds your data to produce it. Several countries have laws that let a government order a company under their jurisdiction to hand over data it controls, wherever in the world that data happens to sit. A Canadian address does not protect data held by a company whose parent is incorporated somewhere else. Your level of sovereignty is set by the weakest of the three, not the strongest. That is the whole idea, and most of these reviews never get past the first question. Why data residency in Canada is the easy part Residency is easy because it is the only one of the three that fits in a checkbox. Most data sovereignty conversations start there, and plenty of them end there. Vendors can answer it, procurement can record it, and everyone can move on. It is also the question that changes the outcome least. A vendor can be entirely honest about a Canadian region and still hold your keys, still support you from three time zones, still be a subsidiary of a company that answers to a different legal system. Nothing there is a scandal. It is normal platform architecture. It just means the checkbox you ticked did not measure what you thought it measured. So stop asking where the data sits and start asking who can reach it, and who can be ordered to hand it over. Who can reach the data, and who can be ordered to hand it over List the systems, people, and networks you actually control, then write down every place data leaves that list. Most of those places are ordinary, which is why they get missed. A support engineer who takes a screenshot of production and attaches it to a ticket has moved your data into a ticketing system in another country. An integration that pushes a nightly extract to a reporting tool has created a second copy under a second set of rules. Crash reports carry pieces of the data that was being processed. Backups live under whatever contract the backup vendor signed, which is often not the one you read. None of that is a reason to panic. It is a reason to have the list. A boundary you have written down is one you can defend in an audit. A boundary you have only assumed does not hold up the first time somebody asks a second question. The questions to ask any vendor Print this. Ask all of it, of every vendor. Any vendor worth signing with can answer in writing. Where does the data sit at rest, including backups, replicas, and disaster recovery? Name the regions. Which legal entity am I contracting with, where is it incorporated, and who owns it? Who holds the encryption keys? Can I hold them myself, and what breaks if I do? Which of your people can reach production data, from which countries, and what does it take for them to do it? Do I approve it, and do I see the log afterward? List every subprocessor and what each one touches. Not the categories. The names. Where do logs, telemetry, and support tickets go, and how long are they kept? If a government where you or your parent operates serves you an order for my data, what happens, and will you tell me? Can this run inside an environment I control, and what do I give up if it does? On exit, what comes back to me, in what format, how fast, and what gets deleted? How they answer tells you as much as what they answer. Specific, written, dated answers mean somebody at that company has done the work. Vague answers mean you will be the one doing it, later, under pressure. A test you can run this week Pick one dataset. A production order, a batch record, a work order, a student file. Then write down every place a copy of it exists right now: the source system, the middleware, the warehouse, the reporting extract, the vendor cloud, the backup, the analyst laptop, the attachment in last month’s support ticket. Every time I have watched someone do this, the list came out longer than the person who owns the system expected. The difference between the copies you assumed and the copies you found is how much of your data you actually control. It costs an afternoon and it makes the rest of the conversation concrete. The day you need these answers is the day somebody else is asking for them. An incident. An audit. A customer’s security review two weeks before a contract renewal. Either you made these arrangements months earlier, or you make them under pressure, and under pressure you get whatever your vendors already decided for you.