Key Takeaways

Contents

Key Takeaways 1

Introduction. 2

From “Sovereignty” to Enforceable Control 3

The Missing Question: Which Systems Need This Level of Control? 4

Security and Industrial Policy Are Different Problems 5

Why “Sovereign Cloud” Fails on Security Terms 6

Why It Fails on Economic Terms 8

Designing for Enforceable Control 9

Conclusion. 10

Endnotes 11

Introduction

Canadian governments and institutions depend heavily on digital infrastructure operated by firms subject to foreign law. For example, under the U.S. CLOUD Act, American authorities can compel providers under U.S. jurisdiction to produce data regardless of where the provider stores that data.[1] The Trump administration’s willingness to use economic leverage against longtime allies in ways previously considered to be unlikely has made some reevaluate the risks posed by depending on U.S. technology providers.[2]

In response, some policymakers want to pursue “sovereign cloud”: domestically owned and operated infrastructure that does not allow data to leave the country’s borders. The federal sovereign cloud procurement process and growing private-sector investment in Canadian-based infrastructure reflect this shift.[3] For example, one company has pitched its investment as ensuring Canadian data is “managed by Canadians under Canadian laws,” while another aims to provide “unquestionably reliable, sovereign infrastructure.”[4]

Advocates of the sovereign cloud model often highlight legitimate goals such as protecting sensitive data, ensuring continuity of access to systems, limiting exposure to foreign legal or geopolitical pressure, improving cybersecurity, reducing industrial dependency, and maximizing domestic value capture. But sovereignty is a poor vehicle for achieving them. The concept groups together several distinct challenges—such as data control, operational resilience, and legal jurisdiction—under a single label. This framing then nudges governments toward treating ownership and infrastructure location as the default solutions, even though they are weak and often misleading proxies for the conditions that actually determine control.

The more useful task is to separate these concerns and ask what determines control in practice. Some issues are legal, including who can compel access and under what safeguards. Others are technical and operational, including who holds the keys, who can administer the system, and whether access is logged and auditable. Others are economic, including where value is created, how firms scale, and whether industrial policy is being confused with security policy. Once the problems are framed this way, the question is no longer how to replicate infrastructure, but rather how to directly govern access, continuity, and dependence.

The analysis that follows identifies the prerequisites for enforceable data control and proposes six concrete measures to deliver it:

1. Targeting real access risks by designing sensitive workloads around how breaches actually occur, not where servers sit.

2. Using procurement to ensure that encryption, access controls, audit rights, and breach liability are standard, non-negotiable conditions of service.

3. Building continuity into critical systems through redundancy and recovery planning.

4. Preserving portability and interoperability to prevent lock-in and maintain users’ ability to switch providers.

5. Enacting a blocking statute stipulating that compliance with foreign disclosure orders must align with Canadian law, and requiring providers to challenge or narrow foreign orders that do not align.

6. Reserving the strictest controls for the narrow set of workloads, defence, intelligence, and classified systems, where they are actually justified.

From “Sovereignty” to Enforceable Control

The Government of Canada defines digital sovereignty in terms of autonomy over digital infrastructure, data, and intellectual property and the ability to make independent decisions about digital assets regardless of where the underlying technologies are developed or hosted.[5] In practice, however, that definition folds together several different issues: who can access data, who can administer systems, what legal demands providers can be subject to, whether organizations can maintain continuity, and where firms capture economic value. Those questions are better addressed separately.

Control over cloud environments is not achieved through any single design choice. It operates across several layers, and a gap at any one of them can expose data or undermine resilience. Breaking control down into those layers makes it easier to distinguish between measures that genuinely reduce risk and those that simply relocate infrastructure.

Technical control determines whether data and systems can be accessed without authorization. Encryption is essential, but it alone is not enough. What matters is who holds the keys. If the provider holds them, it can access the data, and technical access creates legal exposure if the provider is compelled to disclose it.[6] Technical control also depends on identity and access management: who can log in, how access is granted, and how privileges are limited. Without strong key and identity controls, domestic hosting does not prevent access.

Operational control determines who can administer and intervene in systems. Privileged administrators, support staff, and service operators all represent potential access points. Monitoring, auditability, and segregation of duties are what make technical controls meaningful. If those controls exist only on paper, they do not stop unauthorized access.

Legal control shapes how providers respond when governments or courts request access. Providers can sometimes challenge, narrow, or redirect those requests, or refuse demands that conflict with domestic law.[7] But legal tools work most effectively if they are paired with technical and operational constraints. For example, a foreign jurisdiction cannot compel a provider to turn over data that it does not have technical access to.

Structural control determines whether you can switch providers. The ability to move data and software between providers determines whether organizations can switch systems and avoid lock-in and maintain operations if a provider changes terms, exits a market, or faces other disruptions. Without portability, switching can become prohibitively costly or in some cases, infeasible, and dependence becomes a constraint on future decisions.

Together, these dimensions provide a diagnostic framework. A sovereignty proposal that does not specify how it delivers technical, operational, legal, and structural control is, at heart, just a protectionist location requirement.

The Missing Question: Which Systems Need This Level of Control?

The relevant question is not who “sovereign cloud” is for in the abstract, but rather which systems actually require unusually strict technical, operational, legal, and structural control. The answer is narrow, because the constraints needed to achieve that standard fit only a limited set of workloads.

The constraints required to reach that level of control do not fit how many organizations, especially those in sectors that rely on cross-border trade and digital links, actually operate. A fully Canada-only cloud environment would likely mean fewer links to outside systems, tighter limits on cross-border data flows, and less compatibility with global software. Most firms instead rely on global software ecosystems and integration with foreign partners, suppliers, and customers.[8] Imposing strict sovereign-cloud constraints on that reality would not eliminate exposure. It would more likely break workflows, fragment systems, and increase costs without delivering much additional control.

There are, however, contexts wherein such constraints are justified. Those are cases in which integration requirements are minimal and control requirements are exceptionally high. The clearest examples are defence systems, intelligence workloads, and sensitive classified government applications. In those contexts, the costs of restricted integration and reduced interoperability may be acceptable because the risks of exposure are exceptionally high. Even in such cases, the answer is access controls, not domesticity.

The same logic applies in adjacent domains. Some AI workloads may require highly controlled domestic compute environments but only in a narrow set of high-sensitivity government contexts such as defence, intelligence, and classified analytics. Data residency requirements for particularly sensitive records are a different tool again. The risk is that these narrow exceptions become the template for digital policy more broadly.

Once sovereignty is accepted as a general rationale to act on control issues, it does not stop at cloud infrastructure. It can be used to justify preferences for domestically developed AI models, Canadian-only software procurement, or broader localization requirements across public systems. But in these domains too, domestic ownership is usually a weak proxy for actual control. A Canadian model provider may still rely on foreign chips, foreign cloud infrastructure, open source components developed abroad, or cross-border service relationships. A domestically procured software vendor may still create lock-in, weaken interoperability, or offer worse security than a global alternative would. The result is that governments may end up paying more for narrower choices without materially improving security, resilience, or strategic autonomy. These tools should therefore be used only wherever the control problem is specific, concrete, and important enough to justify the costs.

Security and Industrial Policy Are Different Problems

Canada’s cloud sovereignty debate blends two distinct goals: security and industrial policy. These are not the same problem, and they cannot be solved with the same tools. Security objectives focus on risk reduction and control: protecting sensitive data, ensuring resilience to disruption, and managing exposure to foreign legal processes. Industrial policy objectives point elsewhere: building domestic capability, capturing economic value, and reducing industrial dependency. One is primarily about enforceable control. The other is about scale, integration, and value capture.

In practice, both objectives are often folded into a preference for domestic provision of digital infrastructure. That reflects legitimate concerns about dependency and value capture, but it is also reinforced by commercial incentives. For certain firms competing against hyperscalers, sovereign cloud is not just a security argument. It is also a sales pitch.

Strengthening domestic capability and ensuring that Canadian firms capture more value are legitimate policy aims. But both the conditions required to satisfy security objectives and those to support broad economic adoption often pull in opposite directions. Security-focused design pushes toward tighter controls, reduced exposure, and constrained integration. Commercial adoption pulls the other way. Firms need compatibility with global platforms, integration with external systems, and easy deployment across markets and partners. Those are the conditions under which cloud services generate value.

A system hardened for highly restricted or security-sensitive use, with limited external connectivity and constrained data movement, cannot also simultaneously serve as the shared platform for firms that rely on global software ecosystems, cross-border data flows, and interoperability with foreign partners. Tightening controls to meet security objectives constrains the system to the point where it no longer supports the economic use cases used to justify the investment. Loosening those controls to enable adoption reintroduces the dependencies the system was meant to reduce.

Consider a Canadian research institution running a multisite clinical trial on a U.S.-based cloud platform. The concern is continuity: if access is restricted or the provider withdraws from the Canadian market, the institution could lose access to patient records, trial monitoring tools, and the systems required to keep the study running. But domestic infrastructure ownership does not solve that risk. A Canadian-owned cloud that cannot match the redundancy, security, or operational resilience of a leading global provider may leave the institution exposed to the same continuity risk through different failure modes.

Gaia-X illustrates the same pressure at a broader level. Launched as a European project meant to advance both digital sovereignty and a competitive alternative to U.S. hyperscalers, it narrowed over time toward interoperability, governance, and standards rather than becoming a broadly adopted sovereign cloud competitor in its own right.[9] That does not make it a failure in absolute terms, but it does show how quickly projects framed around both control and competitiveness are pulled toward one objective or the other once implementation begins.

Recent European practice offers a clearer model. In France and Germany, Microsoft has backed nationally tailored cloud arrangements in which the technology remains foreign but the operating structure, legal framework, and compliance model are localized.[10] The U.K. Ministry of Defence has taken a similar approach with Google Cloud, using procurement, technical architecture, and control arrangements to make foreign technology serve sovereign ends.[11] In both cases, the objective is not autarky. It is to secure enforceable control without forgoing the capabilities of global platforms.

Why “Sovereign Cloud” Fails on Security Terms

Even on security grounds, broad sovereign-cloud proposals are weaker than they appear. The federal government’s own white paper on data sovereignty and public cloud makes the basic point that data residency does not mitigate the application of foreign laws, while encryption, contractual safeguards, and careful workload selection are the more relevant tools for risk mitigation.[12] It also notes that localization can narrow the market for solutions and create trade risk.

In Plixer International, Inc. v. Scrutinizer GmbH, a German company with no U.S. office, employees, or phone number was still found subject to U.S. jurisdiction because it operated a website serving American customers.[13] Switching to a Canadian provider does not escape the architecture of the CLOUD Act, even if that provider has U.S. operations, U.S. investors, or U.S. customers.

Other cross-border access frameworks and lawful access mechanisms exist elsewhere through the Budapest Convention, EU e-Evidence frameworks, and the U.K. Crime (Overseas Production Orders) Act.[14] Canada’s own legal system works in much the same way. An Ontario court recently compelled OVHcloud, a French provider storing data in France, to disclose data through its Canadian subsidiary.[15] This means that Canada is not merely subject to extraterritorial reach. It exercises it.

Lawful access also operates less dramatically in practice than sovereignty rhetoric implies. Governments do not gain access merely because a provider has some foreign nexus or because a workload runs on cloud infrastructure. Access requires a legal process tied to a specific crime, with requests that must be targeted rather than broad. The scope of the order, the provider's ability to produce the requested data, and the safeguards governing notice, challenge, and disclosure all shape what actually gets disclosed. That is why claims that Canadian or “sovereign” providers are immune from foreign law are often overstated: providers with foreign operations, affiliates, personnel, or technical access paths may face similar exposure.

When organizations retain exclusive control of encryption keys, providers cannot access the content of encrypted data in a usable form and therefore cannot disclose that content in a readable form in response to external demands. This is not simply a matter of contract or policy. If the provider does not hold the key, it cannot turn the encrypted data into something readable. More broadly, exposure depends on whether the provider can technically access customer data at all and whether access is logged and auditable.

Legal tools can reinforce technical controls. Blocking statutes, for example, can prohibit compliance with foreign disclosure orders that conflict with Canadian law and require providers to challenge or narrow orders that do. In the European Union, Article 48 of the GDPR limits compliance with foreign courts or administrative orders unless the transfer is otherwise grounded in EU or member-state law, or in an international agreement such as a mutual legal assistance treaty.[16] In the United States, the Stored Communications Act limits when providers may disclose customer communications and records, and the CLOUD Act framework has also been used to create cross-border U.S. bilateral agreements, with the United Kingdom and Australia, that channel access requests through defined legal procedures.[17] These laws create meaningful legal friction and shape how foreign access requests are handled in practice.

The legal architecture for cross-border access exists. But public transparency reporting from Microsoft, Google, and Amazon Web Services shows no disclosed instances of Canadian-enterprise cloud content being turned over to U.S. law enforcement, despite tens of thousands of global law enforcement demands.[18] That makes the risk of foreign legal orders too thin a basis for redesigning Canada’s cloud infrastructure around domestic ownership.

The broader security claim is no stronger. Domestic infrastructure is not inherently more secure. Hyperscale providers invest in cybersecurity at a level no domestic alternative can match, with global threat visibility and dedicated security personnel and spending measured in the tens of billions.[19] Smaller providers have fewer resources and less capacity to detect and respond to intrusions. Cyberthreats are not geographically bounded. Canadian systems face the same threat actors, tools, and vulnerabilities as does any other connected system.[20] Reducing scale does not reduce exposure, but it does reduce defensive capacity. The breaches at Global Affairs Canada and the Canada Revenue Agency were not failures of foreign cloud providers. They showed that practical exposure does not disappear when infrastructure is domestic.[21]

The documented threat record makes the calibration problem concrete. Over the past four years, at least 20 Government of Canada networks were compromised by actors linked to the People’s Republic of China, while reported fraud losses climbed from $383 million in 2021 to $567 million in 2023 and average ransom payments hit $1.13 million, up nearly 150% in two years.[22] None of those incidents involved a U.S. prosecutor with a warrant. The attacks that are actually compromising Canadian systems do not arrive through allied legal processes subject to judicial oversight, but rather through credential theft and misconfiguration. Domestic ownership addresses none of them.

Recent federal procurement activity reveals that the government still seems unsure about the policy goal. Shared Services Canada’s sovereign cloud process suggests some movement toward the more serious question of who controls infrastructure, access, and continuity.[23] But the procurement logic still does not fully answer that question in practice. Instead of specifying the controls required for sensitive workloads, it falls back toward Canadian ownership, domestic provision, and reduced reliance on foreign infrastructure. Once those concerns are converted into excluding foreign providers, the policy starts to look less like targeted risk management and more like industrial preference through procurement. That has already drawn U.S. trade objections, and regardless of whether those objections are persuasive on the merits, they are not costless.[24] That kind of procurement conflict would not stay confined to cloud policy. It could invite quid pro quo pressure on Canadian firms seeking to sell in U.S. public procurement markets.

Why It Fails on Economic Terms

As an industrial strategy, sovereign cloud is misaligned with how value is created in digital systems. The premise treats cloud infrastructure as something that should be domestically owned in the same way as water systems, power grids, or transportation networks. But those are geography-bound systems. Their performance depends heavily on proximity, and their scale is constrained by territory. Cloud works differently. Its capabilities and cost efficiency improve with the aggregation of demand across very large markets. Fragmenting that scale tends to reduce capability and increase cost.

Take GPS (Global Positioning System) as an example. Aircraft and ships use it to navigate, telecom networks use it to synchronize signals, banks use it to time-stamp transactions, and emergency responders use it to locate incidents. Yet, Canada does not own the underlying system, nor would domestic duplication be a sensible route to security or economic advantage. Strategic importance alone does not mean the relevant policy response is domestic ownership of the infrastructure layer.

The same logic applies to cloud. Canadian firms do not need to own the infrastructure layer to retain control over what matters commercially: their data governance, intellectual property, products, and customer relationships. Cloud is capital intensive and scale dependent, and owning the base layer is not the same as capturing the value built on top of it. A less capable and more expensive domestic cloud would only raise costs for Canadian firms while doing little to solve Canada’s actual constraints in technology adoption, commercialization, and scaling.

If strategic importance implied a need for building a Canadian copy, the same logic would extend to operating systems, search engines, and enterprise software. Few policy programs pursue that logic explicitly, and where they do, as in recent EuroStack proposals, they make clear how resource intensive and strategically difficult it is to reproduce globally scaled digital infrastructure within regional boundaries.[25] The issue is not only cost but also that ownership of the infrastructure layer does not determine where most value is created.[26] Canadian AI and software firms can still retain control over their products, data, and business operations while relying on globally scaled infrastructure to develop and deliver them and without reducing access to the tools and markets on which many of them depend.

More importantly, pursuing control for control’s sake in the name of sovereignty comes with an opportunity cost. Whatever Canada’s infrastructure gaps may be, its most immediate constraints are weak technology adoption, weak commercialization, and limited firm scaling.[27] Policies that redirect capital and institutional focus toward duplicating global systems risk deepening these weaknesses rather than addressing them. Replicating cloud capacity would do little to ameliorate Canada’s relative economic decline. Doing so would shift capital and policy attention into a layer where Canada is poorly positioned to compete, because advantage in this market depends heavily on global scale, enormous capital intensity, and capabilities already concentrated in a small number of incumbents.

That is especially true for AI. The competitive advantage in AI does not accrue to countries because they own data centres. It accrues to those that deploy AI effectively across their economies: in manufacturing, agriculture, health care, and financial services. A domestically owned compute layer that lags behind global leaders on capability and cost does not give Canadian firms an AI advantage. It gives them a slower, more expensive starting point. The question for Canadian AI industrial strategy is not whether the servers are in Vancouver or Seattle. It is whether Canadian firms can access frontier compute on controlled terms, build applications on top of it, and deploy them at scale. Procurement standards and access governance deliver that. Infrastructure replication does not, but it does divert valuable resources away from more meaningful investments.

Designing for Enforceable Control

The objective should not be to replicate digital infrastructure, but rather to ensure enforceable control across the same dimensions outlined earlier: technical, operational, legal, and structural. Not to build parallel solutions, but to ensure that any system used meets the following conditions simultaneously:

Target real access risks. Sensitive workloads should be designed around how breaches actually occur in practice, not around abstract concerns about where servers sit. In practice, that means controlling who can access data, under what conditions, and with what privileges. Organizations rather than providers should control encryption keys for sensitive data whenever practical, and strong identity and access management should be standard, with all access verified and privileges tightly limited. Systems should also be designed to reduce exposure to the most common failure points, including credential compromise, misconfiguration, and insider access.

Use procurement to enforce control. Governments do not need to invent new safeguards for themselves. They need to make existing ones mandatory through procurement. Procurement is the tool that allows governments to specify requirements, verify compliance, and impose consequences for failure. In cloud environments used for sensitive government data, that means making customer-controlled encryption, access restrictions, audit rights, notification of external legal demands, and clear breach liability nonnegotiable conditions of service. Major cloud providers already offer these as standard or available features; the gap is not capability but contractual obligation. Providers should also be required, where legally possible, to challenge or narrow external access requests and notify affected customers. This is broadly consistent with how high-sensitivity domains such as defence and telecommunications are already governed: through specified security requirements and controlled access.

Build continuity into critical systems. Control is incomplete if a system fails when one provider or region becomes unavailable, whether due to a cyberattack, a coding error, or a power outage. Continuity should be designed in from the start. That means avoiding architectures built around a single point of failure, requiring redundancy wherever the workload justifies it, and planning in advance for degraded service and recovery. The question is not only whether data is protected but also whether essential systems can keep operating when a dependency breaks.

Preserve portability and interoperability. Control weakens over time when organizations cannot move. Exit options matter because providers change terms, products are discontinued, and systems become harder to untangle the longer they run. Governments should therefore require workable ways to move systems and data, avoid unnecessary lock-in where alternatives are available, and use multicloud selectively wherever it improves resilience or negotiating leverage.

Create a blocking statute. Legal tools should reinforce technical and operational ones. A blocking statute would stipulate that compliance with foreign disclosure orders must align with Canadian law, and require providers to challenge or narrow foreign orders that do not align. Similar legal tools already exist in other jurisdictions. On their own, they are not enough. Paired with encryption, access controls, and procurement conditions, they make legal resistance more than symbolic.

Reserve stricter controls for narrow cases. Not every workload justifies this level of constraint. The strictest requirements should be limited to defence, intelligence, and a small set of high-sensitivity classified systems in which integration requirements are low and control over access is paramount. Tighter controls for certain government AI systems or especially sensitive records may also be justified, but these should be treated as separate instruments, used only in narrowly defined cases, and not extended across sectors that depend on global interoperability. The same logic applies to adjacent domains. Sovereign compute requirements for AI workloads are justified for a narrow set of high-sensitivity government applications: defence, intelligence, and classified analytics. Data residency requirements for sensitive records are a distinct instrument from cloud infrastructure mandates. Both should be evaluated on their own terms, scoped to where control requirements genuinely justify the costs, and not bundled into a sovereignty framework designed for a different problem.

Conclusion

The cloud sovereignty debate is being organized around a frame that obscures more than it clarifies. That misdiagnosis has consequences. From a security standpoint, it directs attention toward foreign legal exposure while doing less to address the failures that compromise systems in practice. From an economic standpoint, it pushes capital and policy attention into a layer where Canada is poorly positioned to compete, and where domestic ownership does little to strengthen firm capability, technology adoption, or value capture. The result is higher cost and poorer strategic prioritization.

Canada should not allow protectionism to enter economic policy under the cloak of sovereignty. The relevant test is not whether infrastructure is domestically owned, but whether policy delivers enforceable control, resilience, and value capture at reasonable cost. That means using procurement and technical safeguards to govern access directly, building portability and redundancy into critical systems, and reserving the strictest requirements for the small set of workloads that actually justify them. What Canada needs is a more disciplined approach to digital dependence, one that targets access, continuity, and legal exposure directly rather than trying to solve them through domestic ownership and symbolic replication.

Endnotes