There is a version of this conversation that happens in almost every Canadian municipal software procurement, usually late in the process, usually after a preferred vendor has already been selected. Someone in IT or legal raises the question of where the data will actually be hosted. The vendor says something reassuring about Canadian servers. The procurement team moves on.
Six months after go-live, the municipality discovers that "Canadian servers" meant a Canadian edge node for content delivery, while the primary database and backup infrastructure sit in US-based data centres covered by a US parent company's standard cloud agreement.
This is not a hypothetical. It is a recurring pattern in Canadian public-sector software procurement — and it is entirely avoidable if the right questions are asked at the right stage of the process.
Why data residency matters for Canadian municipalities
Canadian municipalities hold a significant volume of data that is either legislatively required to stay in Canada, operationally sensitive if it crosses the border, or subject to access and disclosure obligations that change depending on the jurisdiction in which data is processed and stored.
The categories of data in a typical municipal ERP implementation include employee personal information and payroll records, resident utility account data and payment history, property ownership and assessment records, permit applications and supporting documents, business licence records, financial transactions and bank account details, and vendor records including payment information.
For each of these categories, two questions matter: where is the data stored, and who has legal access to it under the laws of that jurisdiction?
The second question is the one that most procurement discussions underweight. Data stored in the United States is potentially subject to the US Cloud Act, which allows US federal authorities to compel disclosure of data held by US-based cloud providers regardless of where the physical servers are located.
Data stored in Canada is subject to Canadian privacy legislation and the jurisdictional constraints that come with it. For a Canadian municipality processing resident personal data, that difference is not academic.
What Canadian privacy legislation actually requires
No single piece of federal legislation mandates that all municipal data must be stored in Canada. The picture is more nuanced than that — and understanding the nuance is important for structuring your procurement requirements correctly.
At the federal level, PIPEDA (the Personal Information Protection and Electronic Documents Act) governs how private-sector organisations handle personal information in commercial activity. It does not apply directly to provincial or municipal governments, but it shapes the standard against which vendor data handling practices are evaluated.
At the provincial level, the picture varies significantly:
In Ontario, MFIPPA (the Municipal Freedom of Information and Protection of Privacy Act) governs how municipalities handle personal information. MFIPPA does not prohibit offshore storage outright, but it requires municipalities to take reasonable steps to prevent unauthorised access — and the Information and Privacy Commissioner of Ontario has issued guidance indicating that municipalities should conduct privacy impact assessments before moving personal data outside Canada, and should disclose to residents when their data may be accessible to foreign authorities.
In British Columbia, FOIPPA (the Freedom of Information and Protection of Privacy Act) is more prescriptive. It historically required that personal information in the custody of public bodies be stored and accessed only in Canada, with limited exceptions. Amendments and guidance from the BC Privacy Commissioner have evolved this position, but BC municipalities remain subject to some of the strongest provincial data residency expectations in the country.
In Alberta, FOIP (the Freedom of Information and Protection of Privacy Act) governs public bodies including municipalities. Like MFIPPA in Ontario, FOIP does not contain an absolute prohibition on offshore data storage, but Alberta municipalities are expected to assess and manage the risks of cross-border data flows.
The practical implication for procurement is this: even where the legislation does not prohibit offshore storage, it requires municipalities to conduct due diligence, manage the risk, and in some cases disclose the arrangement to affected individuals. A vendor who cannot specify where your data will be stored and processed is a vendor who is making your due diligence obligation impossible to discharge.
What "Canadian hosting" actually means — and what to verify
Cloud vendors have become skilled at producing hosting language that sounds reassuring without committing to anything specific. These are the distinctions worth understanding before signing a contract.
Data centre region vs. data processing jurisdiction. A vendor can truthfully say that your data is stored in Canadian data centres while that data is simultaneously accessible to, processed by, or backed up through systems in other jurisdictions. Storage region and processing jurisdiction are not the same thing. Ask for both to be specified explicitly.
Primary storage vs. backup and disaster recovery. Your primary database might sit in Toronto while your backup infrastructure sits in a US region. Under some provincial privacy frameworks, backup data is still personal information and subject to the same protections as primary data. Ask where your backups are stored and who has administrative access to them.
The parent company question.Many cloud ERP and civic software vendors are Canadian subsidiaries or resellers of US parent companies. The Canadian entity may store data in Canadian regions, but if the parent company's employees or systems have administrative access to that infrastructure for support, maintenance, or development purposes, the data has effectively crossed the border — not physically, but jurisdictionally. Ask whether employees or systems outside Canada can access your data and under what circumstances.
Subprocessors. Most cloud software products rely on third-party services for functions like email delivery, analytics, logging, monitoring, and support ticketing. Each of these subprocessors potentially has access to some of your data. A thorough data residency review includes the subprocessor list, not just the primary hosting infrastructure.
Support and professional services access.When your implementation partner or the software vendor's support team accesses your environment to resolve an issue, from which country are they doing it? Remote support access from outside Canada is data access from outside Canada, regardless of where the server sits. Ask whether your contract includes provisions that restrict remote access to Canadian-based staff or require notification when foreign access occurs.
What to put in your contract, not just your RFP
The RFP stage is where data residency requirements should be specified. The contract stage is where they need to be enforceable.
These are the provisions worth including:
- A data residency commitment specifying the countries and regions in which your data — including backups, logs, and data processed by subprocessors — will be stored and processed. "Canadian regions" is not sufficient; name the specific data centre locations.
- A subprocessor disclosure obligation requiring the vendor to provide a current list of subprocessors with access to your data, and to notify you before adding new subprocessors that would involve data access from outside Canada.
- A foreign access notification obligation requiring the vendor to notify your organisation if it receives a legal demand from a foreign authority for access to your data, to the extent that applicable law permits such notification.
- A data return and deletion obligation specifying that on contract termination or expiry, your data will be returned to you in a usable format and deleted from the vendor's systems within a defined timeframe — including from backup systems.
- A right to audit or at minimum a right to receive third-party compliance certifications (SOC 2 Type II, ISO 27001, or equivalent) demonstrating that the vendor's security and privacy controls are operating as described.
The procurement conversation you should be having earlier
The data residency conversation typically surfaces late in a municipal procurement because it is treated as a technical detail rather than a foundational procurement requirement. The consequence is that it becomes a negotiation under time pressure, after a preferred vendor is already selected and switching costs are significant.
The more effective approach is to treat data residency as a threshold requirement in the RFP — not a scored criterion, but a pass/fail condition. Vendors who cannot demonstrate Canadian data residency for primary storage, backups, and processing are excluded from evaluation. That framing protects your organisation from the post-selection negotiation problem and signals to the market that your municipality takes its privacy obligations seriously.
It also concentrates your evaluation effort on vendors who have already solved the problem — which means the residency question does not consume procurement committee time that should be focused on implementation capability, civic module depth, and post-go-live support quality.
A practical starting point
Before your next ERP or civic software procurement, ask your current software vendors — not just prospective ones — to specify in writing where your data is currently stored and processed, who has access to it, and what their obligations are under applicable Canadian privacy legislation.
The answers may be reassuring. They may also surface compliance gaps in your current environment that are worth addressing before they become audit findings or resident complaints. Either way, knowing is better than assuming.