The first essay in this series drew a line and stopped at it. Residency is a question about geography. Jurisdiction is a question about law. The CLOUD Act operates on jurisdiction, so a “Canadian region” answers the geography question well and leaves the law question untouched. That argument was made for one surface: the vendor that holds the data. This essay walks the rest of the surface, because the data-holder isn’t the only place where Canadian-hosted and Canadian-jurisdictional come apart. They come apart at every layer of a running deployment.
The principle underneath that claim isn’t a vendor’s framing. It’s how the courts and regulators that have actually tested the question reason about it. In September 2025 the European Union’s General Court, dismissing the challenge in Latombe v Commission, restated the standard the Court of Justice used to strike down two successive US adequacy decisions: the lawfulness of a data transfer turns on the legal regime of the jurisdiction that receives the data, not on where the data physically sits, and the arrangement stands only as long as the receiving country’s law is unchanged.1 The US statute reaches the same destination from the other side. The CLOUD Act test is “possession, custody, or control,” a test on the corporate entity, and US courts can require a parent company to produce data held by a foreign subsidiary.2 Geography is not a term in either equation.
A deployment is touched by more than one entity. Something operates the platform. Something vouches for the artifacts the platform runs. Something supplies those artifacts in the first place. Something answers the deployment’s calls while it runs. And something owns each of those somethings. Hosting locates the bytes, while jurisdiction asks, of every one of those entities, whose law can compel it, observe it, change what it ships, or stop serving it. The first essay answered that question for the data-holder. There are five more surfaces, and the answer diverges on each.
The operator surface
The first surface past the data-holder is the entity that operates the platform. Operating it means holding administrative access to the control plane, shipping the updates that change the running software, and debugging incidents under the operator’s own corporate governance. None of that work happens where the data sits. It happens wherever the operator is incorporated.
AWS European Sovereign Cloud is the cleanest 2026 specimen. It launched with full EU data residency, EU-based personnel, and a German holding-company structure built specifically to answer the sovereignty objection. It also remains wholly owned by Amazon.com, Inc., which keeps the offering subject to US law for its European operations. The reading from outside the marketing was blunt: the structure “does nothing to protect customer data from being accessed by the US government,” because courts can require a parent to produce what its subsidiary holds.3 The operator’s own admissions have said the same thing under oath, as the first essay recorded.4 A German GmbH operating a German region is still an operator whose ultimate parent answers to a foreign legislature. The region sits in Europe while the operator’s law sits across an ocean.
The trust-root surface
When a cluster verifies that an artifact is what it claims to be, it consults trust infrastructure: a certificate authority that vouches for signing identities, a transparency log that records what was signed, and a trust root that anchors the whole chain. Over the last five years the cloud-native ecosystem converged on a single free, public instance of that infrastructure, and most clusters that verify anything verify against it.
That public instance is foreign-jurisdictional in every layer that matters. The trust root is distributed from a US-operated content-delivery network, anchored by a rotation of keyholders drawn from US companies and US universities, and governed by a US foundation.5 The identity providers the signing chain federates are operated by US-incorporated companies. A cluster sitting in a Canadian data centre that verifies its workloads against that infrastructure has imported US jurisdiction into the verification step, regardless of where the bytes sit. The verification only reads as sovereign if the deploying organization does the deliberate, non-default work of standing up its own certificate authority, its own transparency log, and its own trust root. The default posture reaches across the border every time it checks a signature. The integrity properties of that signing path, as distinct from its jurisdiction, are the subject of a later essay in this series; the point here is only that hosting the cluster in Canada does nothing for the jurisdiction of the thing it trusts.
The supply-chain surface
Before any of that runs, the artifacts arrive from somewhere. Base operating-system images, language runtimes, the platform’s own component images, every vendored dependency: each is published by an incorporated entity under some jurisdiction. The first essay made this point about a single vendor, that a prime running OpenShift on its own Canadian bare metal still pulls images whose trust path resolves to a US-incorporated entity. The observation generalizes past that one vendor. Every registry pulled from and every dependency vendored carries the jurisdiction of whoever publishes it, and that jurisdiction governs what they can be compelled to ship, what they can be ordered to stop shipping, and what they can be made to change before it reaches the cluster. Hosting the running cluster in Canada doesn’t change the jurisdiction of what is put into it.
The runtime surface
A workload that has been hosted, operated, and assembled inside Canadian jurisdiction can still reach across the border every time it runs. Identity lookups against a foreign-operated provider, license validations, telemetry beacons, secrets fetched from a foreign-operated backend: each is a live runtime dependency on an entity under foreign law, and each is a channel that the same law can compel or observe. The first essay framed this as the air-gap-correctness question, the question of whether a product can operate with the deployment network disconnected from the public internet at all. Stated as jurisdiction rather than as connectivity, the rule is shorter: a deployment is only as sovereign as its least sovereign runtime dependency.
The corporate-control surface
The surface the other four reduce to is ownership. A Canadian subsidiary, a Canadian region, a Canadian reseller, a Canadian office: none of these changes which country’s law governs the parent that controls them, and the parent is the entity a foreign court compels.
Canada’s own Defence Industrial Strategy concedes the gap in plain language. It observes that foreign firms “frequently privilege their own priorities” when meeting their obligations, “investing into indirect work in their Canadian subsidiaries,” and its answer is a graduated Canadian Content Value test, a “Canadian Company Boost” that raises procurement credits for firms at 70 to 100 percent Canadian content.6 That measures content rather than control. It counts how Canadian the work is without asking whose law can compel the firm doing it. Canada’s cyber-certification regime doesn’t close the gap either: the program now becoming mandatory for defence suppliers measures cyber hygiene against a Canadian adaptation of NIST 800-171, and foreign ownership is assessed in an entirely separate track, the foreign-ownership, control, or influence evaluation under the Contract Security Program.7 The second essay in this series called the surface-level version of this the “Canadian company” definitional leak. The jurisdictional reading is sharper still. A firm can pass a content threshold, pass a cyber-hygiene certification, and host every byte in Montréal, and a foreign parent can still be served a foreign order that the firm is bound to obey.
What the test actually is
Five surfaces sit past the data-holder the first essay covered: the operator, the trust roots, the supply chain, the runtime dependencies, and the corporate parent. On each of the five, in-country hosting answers the geography question and leaves the law question exactly where it found it. A procurement evaluation that asks “where does this run” has tested one surface and declared the building secure.
The test that actually separates Canadian-jurisdictional from Canadian-hosted is the same question asked of every entity in the deployment, not just the one that holds the data: whose law governs the operator, whose law governs the trust roots, whose law governs the supply chain, whose law governs the runtime dependencies, and whose law governs the corporate parent of each. A vendor that is Canadian-incorporated, with a Canadian-jurisdictional answer on every one of the five, can answer all five with one word. A vendor with a foreign parent and a Canadian region can’t answer any of them, however well it answers the geography question. The full procurement checklist, with the evidence each surface demands, is the closing essay in this series. The distinction the checklist rests on is the one this essay has walked: residency is a question about geography, jurisdiction is a question about law, and they diverge on every surface that matters.
Northfleet is a Canadian-incorporated vendor building the sovereign supply chain that wraps a customer-operated classified cluster: a deploy-time bundle protocol, attestation chain, and tamper-evident audit trail. The customer’s cleared engineering teams operate the cluster on Canadian-jurisdictional infrastructure, under their own keys. Northfleet holds no customer data and no customer signing keys. Every release Northfleet ships carries provenance binding it to the source it was built from, which the customer can check without Northfleet’s participation. The architecture assumes the vendor can be compromised or compelled. That assumption is what stops a compelled vendor from silently changing what runs in the cluster.
If you’re evaluating sovereign infrastructure for classified workloads, and the evaluation has only tested where the bytes sit, the conversation is open.
Footnotes
-
Court of Justice of the European Union (General Court), judgment in Latombe v Commission (Case T-553/23), summarized in Court press release CP No 106/25, September 3, 2025. The General Court dismissed the action and upheld the current EU-US Data Privacy Framework, while restating that the Court of Justice had “declared the two previous adequacy decisions concerning the United States to be invalid, on the ground that they did not ensure a level of protection … essentially equivalent to that guaranteed by EU law,” and that the Commission may “suspend, amend or repeal” adequacy if US law changes. The substantive standard turns on the receiving legal regime, not on data location. An appeal to the Court of Justice remains possible. https://curia.europa.eu/site/upload/docs/application/pdf/2025-09/cp250106en.pdf. Analysis: https://iapp.org/news/a/european-general-court-dismisses-latombe-challenge-upholds-eu-us-data-privacy-framework. ↩
-
The 2018 US CLOUD Act amends the Stored Communications Act so that the obligation to produce data attaches to data within a provider’s “possession, custody, or control,” irrespective of where the data is stored. Congressional Research Service, “Cross-Border Data Sharing Under the CLOUD Act,” report R45173. https://crsreports.congress.gov/product/pdf/R/R45173. ↩
-
AWS European Sovereign Cloud launched with EU-resident data, EU-based personnel, and a German holding-company governance structure, while remaining wholly owned by Amazon.com, Inc. Industry analysis noted that the offering “remains subject to U.S. jurisdiction for its European operations” under US law and that the parent-subsidiary structure “may prove insufficient legally, as courts can require parent companies to produce data held by their subsidiaries.” InfoQ, “AWS Launches European Sovereign Cloud,” January 2026. https://www.infoq.com/news/2026/01/aws-european-sovereign-cloud/. See also: https://www.computerworld.com/article/4118639/aws-european-cloud-service-launch-raises-questions-over-sovereignty.html. ↩
-
Anton Carniaux, director of public and legal affairs at Microsoft France, testifying under oath before the French Senate, June 18, 2025, when asked whether Microsoft could guarantee that French customer data would never be transmitted to US authorities: “Non, je ne peux pas le garantir.” Primary record: https://www.senat.fr/actualite/commande-publique-audition-de-microsoft-5344.html. Coverage: https://www.theregister.com/2025/07/25/microsoft_admits_it_cannot_guarantee/. ↩
-
The reference here is the de facto public-good signing and transparency-log infrastructure the cloud-native ecosystem standardized on (the Sigstore project), governed by the US-based Linux Foundation and OpenSSF. The trust root is delivered through a US-operated content-delivery network and was established at a public key-signing ceremony by a rotation of keyholders drawn from US companies and US academic institutions; the federated identity providers it relies on are operated by US-incorporated companies. Self-hosting the certificate authority, transparency log, and trust root is supported but is a deliberate, non-default deviation. Project security and trust-root documentation: https://docs.sigstore.dev/about/security/; https://github.com/sigstore/root-signing/blob/main/README.md. ↩
-
Department of National Defence, “Security, Sovereignty and Prosperity: Canada’s First Defence Industrial Strategy,” launched February 17, 2026. The Strategy notes that foreign firms “frequently privilege their own priorities when meeting ITB obligations, investing into indirect work in their Canadian subsidiaries,” and commits to “introduce a Canadian Company Boost to increase credits for investments in Canadian firms with 70-100 per cent Canadian Content Value (CCV) at verification.” https://www.canada.ca/en/department-national-defence/corporate/reports-publications/industrial-strategy/security-sovereignty-prosperity.html. Procurement-law analysis: https://www.blg.com/en/insights/2026/02/how-canadas-defence-industrial-strategy-reshapes-defence-acquisition-and-procurement-law. ↩
-
The Canadian Program for Cyber Security Certification (CPCSC) is built on the Canadian Centre for Cyber Security standard ITSP.10.171, a Canadian adaptation of NIST SP 800-171, covering cyber-hygiene control families (access control, multifactor authentication, boundary protection, and similar). It contains no foreign-ownership or jurisdictional-compulsion control; foreign ownership, control, or influence is assessed separately under the Contract Security Program. Level 1 (self-attestation) becomes required in select defence contracts beginning summer 2026, the first of three levels. Public Services and Procurement Canada: https://www.canada.ca/en/public-services-procurement/services/industrial-security/security-requirements-contracting/cyber-security-certification-defence-suppliers-canada.html; https://www.canada.ca/en/public-services-procurement/news/2026/04/government-of-canada-introduces-level-1-of-canadian-program-for-cyber-security-certification.html. ↩