The gap between awareness and proof
Canadian organizations know the rules are changing. They understand the CLOUD Act. They’ve heard of Law 25. They know that storing data in Canada on a US-owned platform doesn’t insulate it from US legal process.
What most organizations don’t have is the documentation to prove they’ve addressed these risks.
A 2026 survey of 286 security, compliance, and IT professionals across Canada, Europe, and the Middle East — published by Kiteworks in their 2026 Data Security and Compliance Risk: Data Sovereignty Report — puts numbers to this gap. Among Canadian respondents:
Nearly a quarter of Canadian organizations have already experienced a sovereignty-related incident. More than half don’t have the internal expertise to manage compliance. And more than half of their customers now ask about sovereignty practices.
The pattern is clear: awareness exists. Operational readiness does not.
What “data sovereignty” actually means
Data sovereignty is often confused with data residency. They are not the same thing.
Data residency means your data is stored on servers physically located in a specific country. Many SaaS vendors offer “Canadian data residency” as a configuration option — your data sits on a server in Toronto or Montreal.
Data sovereignty means your data is subject only to the laws of the country where you operate. This depends on who controls the infrastructure — specifically, the legal jurisdiction of the parent company.
The distinction matters because of laws like the US CLOUD Act, which allows US federal law enforcement to compel US-headquartered companies to produce data regardless of where that data is physically stored. A Canadian server operated by a US parent company is not insulated from US court orders.
In Upper Harbour’s database of 715 SaaS tools commonly used by Canadian organizations, 89% of tools offering Canadian data residency remain CLOUD Act exposed because their parent companies are US-controlled.
Canadian data residency does not equal Canadian data sovereignty. Configuring a tool to store data in Canada does not change which government can compel the company to hand it over.
The regulatory landscape in 2026
Canadian organizations face sovereignty obligations from multiple directions simultaneously. The pressure is not coming from one law — it’s coming from a regulatory environment that is tightening at every level.
Law 25 (Quebec)
Quebec’s privacy law — the strictest in Canada — has been in force since September 2023. It requires a Transfer Impact Assessment (TIA) before any personal information leaves Quebec, written agreements with all service providers processing personal information, a designated Privacy Officer, and a breach incident register maintained for five years. Penalties reach $25 million or 4% of worldwide turnover.
For any Quebec organization using US-based SaaS tools (which is virtually all of them), each tool requires a documented TIA. Most organizations have not completed a single one.
PIPEDA (Federal)
The federal privacy law makes organizations accountable for personal information transferred to third parties — including cross-border transfers to SaaS vendors. While PIPEDA does not explicitly mandate TIAs, the Office of the Privacy Commissioner has made clear that organizations must ensure an equivalent level of protection when data leaves Canada.
The proposed Consumer Privacy Protection Act (CPPA), if enacted, would introduce mandatory TIAs at the federal level and administrative monetary penalties. Organizations preparing now will be ahead when it passes.
Government procurement
Federal and provincial RFPs increasingly require documented data sovereignty positioning. The Government of Canada’s Digital Sovereignty Framework identifies foreign technology dependencies as strategic risk. Organizations selling into government without sovereignty documentation are increasingly disqualified at the procurement stage.
The CLOUD Act
The US CLOUD Act is not a new development — it was enacted in 2018 with bipartisan support. But awareness of its implications has sharpened. In the Kiteworks survey, 21% of Canadian respondents identified it as a direct sovereignty threat, and 40% cited changes to Canada–US data-sharing arrangements as their top regulatory concern.
The CLOUD Act does not expire with any US administration. It is statutory law. For any Canadian organization using US-parented technology — which is the vast majority — the exposure is structural, not political.
What organizations need to prove
When a regulator, procurement officer, board member, or client asks about your data sovereignty posture, they’re looking for specific documentation. Verbal assurances and policy statements are no longer sufficient.
| What they ask | What you need to produce |
|---|---|
| “Which of your vendors are under foreign jurisdiction?” | A jurisdictional map of your SaaS stack — each tool traced to its parent company, headquarters, and CLOUD Act status |
| “How do you manage cross-border data exposure?” | Transfer Impact Assessments for each tool processing personal information outside Canada (mandatory under Law 25) |
| “What agreements do you have with your vendors?” | Executed Data Processing Agreements with each SaaS vendor, reviewed for Law 25 or PIPEDA adequacy |
| “Who is responsible for privacy in your organization?” | A designated Privacy Officer with contact information published on your website |
| “What happens if there’s a breach?” | A documented breach incident response plan and an incident register maintained for five years |
| “How do you track changes in your vendor environment?” | Ongoing monitoring process — vendor acquisitions, jurisdiction changes, hosting region changes, regulatory developments |
Most organizations cannot produce any of these documents today. The Kiteworks survey found that 65% of Canadian respondents say technical infrastructure changes are their largest resource drain — the highest rate among all regions surveyed. Organizations know they need to act. They lack the capacity to document what they know.
The mid-market exposure gap
Large enterprises spend millions annually on sovereignty compliance — dedicated privacy teams, GRC platforms, external counsel. The Kiteworks report found that large organizations report annual sovereignty spending above C$5 million.
Mid-market organizations face the same regulatory exposure with a fraction of the resources. Only 19% of mid-market firms (500–999 employees) reach that spending threshold. But Law 25 penalties apply regardless of company size. Procurement requirements apply regardless of company size. Client expectations apply regardless of company size.
This asymmetry — enterprise-level obligations, mid-market budgets — is where the documentation gap is widest. And it’s where automated sovereignty tooling becomes essential rather than optional.
Where to start
If your organization cannot produce the documentation listed above, here is a realistic path forward, in order of impact:
1. Map your SaaS stack
Before you can prove compliance, you need to know what you’re exposed to. Identify every SaaS tool your organization uses that processes personal information. For each one, determine the parent company, its jurisdiction, and whether it’s subject to the CLOUD Act. This is the foundation everything else depends on.
HarbourScan maps your SaaS stack against the 715-tool Sovereignty Index in about 10 minutes — directly in your browser. It flags CLOUD Act exposure, identifies compliance gaps, and shows you the scale of the documentation work ahead.
2. Designate your Privacy Officer
Under Law 25, the highest-ranking person in your organization is the Privacy Officer by default (typically the CEO). You can designate someone else. Either way, publish their name and contact details on your website. This is a quick, high-impact action.
3. Start TIA documentation
Begin with the tools that process the most sensitive data — employee records, client files, health information, financial records — through foreign-jurisdictioned vendors. You don’t need to complete every TIA simultaneously. But you need to demonstrate you’ve started and have a plan to complete them.
4. Execute Data Processing Agreements
Most large SaaS vendors have DPA templates available on request. Contact your vendors, request their DPAs, review them for Law 25 or PIPEDA adequacy, and sign them. Having a vendor’s DPA available is not the same as having one executed with your organization.
5. Establish your incident register
Law 25 requires maintaining a register of confidentiality incidents for five years. Start a documented process — even a structured spreadsheet. The key is having something you can produce when asked.
6. Plan for ongoing monitoring
Sovereignty compliance is not a one-time project. Vendors get acquired. Corporate structures change. Hosting regions shift. Regulations evolve. A point-in-time assessment becomes outdated within months. Build monitoring into your compliance process from the start.
The shift from policy to proof
The trajectory is clear. Sovereignty compliance is moving from legal interpretation to operational documentation. Organizations are being asked not whether they have a privacy policy, but whether they can produce evidence of how their data flows, who controls it, and what happens when a foreign government asks for access.
The Kiteworks survey found that 54% of Canadian respondents plan to invest in compliance automation within two years. More than half of their customers now ask about sovereignty practices. The question organizations face is no longer whether to address this — it’s whether they can produce proof when someone asks.