Entrazure
“Our data is in Canada Central. Legal says that is not enough.”
That sentence, or its French equivalent, opens a large share of these engagements. The team is not wrong about the region. They are discovering that residency was the easy question and that three harder ones were never asked.
The pattern behind it is consistent. Someone selected a Canadian region when the subscription was created. Nothing enforces that choice, so a developer can deploy to East US on a Tuesday and nobody finds out. Diagnostic logs, backups and a couple of platform services quietly egress somewhere else. The keys are managed by the platform, which was never a decision so much as a default. And if the board asked how long it would take to leave, no one could answer with a number.
Why the usual answer fails
The usual answer is a slide that says “hosted in Canada” and a contract clause. It fails for three reasons, all of them mechanical.
Nothing enforces it. A region chosen in a portal dropdown is a preference. A region enforced by Azure Policy assigned at the management group level is a control, and it is inherited by every subscription created after it, including the one an acquisition brings with it. That distinction is the difference between a claim and evidence, and it is why this work is inseparable from an Azure landing zone.
Location is not jurisdiction. A datacentre in Quebec operated by a company headquartered in the United States sits inside two legal systems at once. This is a statement of fact, not an argument against Azure. Most workloads can live with it perfectly well once it is written down and accepted deliberately. The failure mode is not the exposure, it is that nobody ever named it, so the organization cannot say which workloads it decided to accept it for.
Nobody tested leaving. Exit is treated as a contract clause rather than an engineering problem. A clause gives you the right to leave. It does not give you a data format, a target, a sequence or a number of weeks, and without those four the right is theoretical.
What we design
A jurisdiction register. Every service in scope, its operator, where it runs, where its telemetry and backups go, and the legal instruments that reach it. This is a working document, not a legal opinion, and it is the artefact that ends the circular meetings. Once each row has an owner and an accepted or rejected status, the argument becomes a decision.
Residency enforced as code. Allowed regions, allowed services, encryption requirements, diagnostic destinations and tagging, all assigned as Azure Policy at the management group level and deployed through a pipeline. Exceptions exist and are fine. They are just exceptions with a name, an expiry and an approver rather than a gap.
Key custody. Customer-managed keys in Key Vault or Managed HSM where they change the answer, platform-managed keys where they do not, and an honest account of the operational cost either way. Key custody creates an availability risk that has to be rehearsed. We build the rotation and recovery procedure alongside the design rather than after an incident.
A data flow map for regulated data. Where personal information enters, where it rests, where it is processed and where it leaves. This is also what a Loi 25 privacy impact assessment needs, and what a compliance architecture engagement builds evidence against, so the same map serves two purposes.
Identity, because it is where sovereignty leaks. Standing administrative access from an unmanaged device in an unrestricted location makes every residency control decorative. Privileged Identity Management, conditional access with location and device conditions, and access reviews are part of the design, not a follow-on project. The full scope is in cybersecurity and Entra ID.
The exit path, which is the part nobody builds
An exit path names a target, a data format, a sequence and a duration. For a data platform that means the export format and where the semantic layer is reconstructed. For infrastructure it means whether the Terraform is provider-portable or has a hard dependency on a proprietary service, and what replacing that service costs in weeks. For an AI workload it means whether the prompts, the evaluation set and the retrieval index are yours, in your repository, or trapped in a vendor console.
Organizations that have already been through a VMware exit need no persuading here. They have paid for the version of this lesson that arrives as a renewal quote.
We then rehearse one tier-one workload. An unrehearsed runbook is a hypothesis.
The engagement that delivers it
Start with the two-week assessment: current estate against the four questions, a written opinion, and a ranked backlog with a cost against each item. Sovereignty design work then runs four to eight weeks depending on estate size, and where the landing zone does not yet exist the four-week landing zone build comes first, because there is nowhere to assign the policy set otherwise.
Who this is not for
If you need a document that says “sovereign” for a tender next month and no architecture behind it, we are the wrong firm. If the requirement is to remove all US-headquartered technology from the estate, that is a different program with a different budget, and an Azure design does not satisfy it. Say so on the first call and we will tell you honestly whether we are useful.
Related
- Novarque by Entrazure, the offer this page sits inside.
- Klarvant namespace intelligence, the third-party product we resell and operate.
- GDPR and HDS, for European and French health data obligations.
- Healthcare, where residency clauses now arrive in every contract.
Questions we get
Does choosing a Canadian region make us sovereign?
It makes you resident. Region restriction controls where bytes physically sit, which matters and is worth enforcing properly. It says nothing about which legal system reaches the operator, who holds the keys, who can read the telemetry, or how long departure would take. Four questions, one answered.
Do customer-managed keys stop a foreign disclosure order?
They change the shape of the problem rather than removing it. With customer-managed keys in Key Vault or Managed HSM, the operator cannot decrypt data at rest without a key you control, and a revocation is observable. They do not cover data in use, they do not cover anything you have configured to be decrypted by a service, and they introduce a real availability risk if key custody is not operated properly. We say all of that before recommending them.
How long does an exit path take to build?
Designing and documenting one for a defined workload set is three to four weeks inside a sovereignty engagement. Rehearsing it, meaning an actual restore of data and configuration into the alternative target, adds one to two weeks and is the part that turns an assertion into evidence. We recommend rehearsing at least one tier-one workload.
What evidence do we get at the end?
A data flow map for regulated data, a jurisdiction register naming each service, its operator and the legal instruments that reach it, the policy set as code that enforces residency, a key custody design, and an exit runbook with a target, a sequence and a cost. All of it in your repository.
Can you do this without rebuilding our estate?
Usually yes for residency and identity, which are policy and configuration changes applied over what exists. Not always for data flows, because a service that was never designed to keep personal information inside one boundary sometimes has to be re-plumbed. We tell you which category each finding falls into during the assessment, before you commit budget.
We are not in Quebec. Is this relevant?
The driver changes, the architecture does not. NIS2 for European operations, HDS for French health data, HIPAA and state privacy law in the United States, and increasingly a residency clause in your own customers' contracts. The design questions are identical.