Canadian data residency for WordPress: hosts, realities, and the WPE question
In a Hamilton meeting room, a federal research team kept circling back to the same question: where does the data actually live? "We host in Canada" answers one of four questions you need answered. Here are the other three.
A few months ago I was sitting in a meeting room at the Canada Centre for Inland Waters in Hamilton, running a WordPress hosting evaluation for a federal research facility, and the same question kept circling back to the table no matter how we approached it.
Where does the data actually live? Not where the vendor’s sales page says it lives. Not where the account rep gestured toward on a slide. Where does it physically sit, what paths does it travel, where do the backups land, and which humans can reach into the system and read it.
That question opened a much longer conversation than anyone expected, and I have since had a version of it with other Canadian organizations carrying the same binding requirement. The short version is this: “we host in Canada” is a real answer to exactly one of the four questions you need answered, and most buyers only ever ask that one.
This is the WordPress Practice case for Canadian data residency requirements. If your requirement is a marketing checkbox rather than a binding compliance obligation, this post will frustrate you. It is written for procurement and IT-security officers who need the real answer rather than the reassuring one.
If your requirement covers the data, it covers the copies of the data.
What “data residency” actually covers
When a procurement officer writes a data-residency requirement into a contract, they usually picture a server in a Canadian building. That picture is incomplete. Data residency is four separate claims, and a host can satisfy some of them while quietly failing the others. You have to verify each one on its own.
Data at rest. This is where the production database and uploaded files physically live: the disk in the datacentre. When a vendor says “our servers are in Canada,” this is the claim they are making, and for the better hosts it is usually true.
Data in transit. This is every path the data takes once it leaves that disk. The connection from your user to the server, yes, but also the route through a content delivery network, the telemetry feeding a monitoring tool, the snapshot a support engineer pulls into a ticketing system. A CDN with edge nodes in US cities will route Canadian traffic through US infrastructure by default, and that is transit your residency requirement may not permit.
Backups. Backup copies very often live in a different region from the primary server, because redundancy is the entire point of a backup and “the same building” is poor redundancy. A host can hold your live data at rest in Toronto and replicate your nightly backups to a US region without ever saying anything untrue in the sales call. If your requirement covers the data, it covers the copies of the data.
Access residency. This is the one almost nobody surfaces on their own: where the people with system-level access to your infrastructure physically sit. A support engineer in another country with root credentials is a residency consideration whether or not they ever log in, because the access exists. This is the question vendors are slowest to volunteer, and it is frequently the one that decides whether a host actually fits a government profile.
| Claim | What it covers | What to get in writing |
|---|---|---|
| Data at rest | The disk the production database and uploads live on | The region of the primary server |
| Data in transit | Every path the data travels: CDN edges, monitoring telemetry, support snapshots | Where each of those paths runs, CDN edge nodes included |
| Backups | Every copy of the data, including nightly replication | The region where backups are retained, and the default if you do not ask |
| Access residency | Where the people with system-level credentials physically sit | The countries the support and operations staff with root access work from |
A host can honestly tell you “our servers are in Canada” while running US-based backup infrastructure and a global support team holding access credentials. None of that is a lie. It is also not full Canadian residency. The buyer who only knows to ask the first question signs a contract that does not match the requirement, and finds out during an audit rather than during procurement. The four claims sit alongside the questions a senior buyer should ask on any platform decision.
The WP Engine question I was actually asked
WP Engine came up directly in the Hamilton conversation, because it comes up in almost every WordPress hosting conversation. It is one of the most common managed hosts in the market, and the team wanted to know whether it satisfied their residency requirement.
Here is what I can tell you honestly. WP Engine does operate Canadian-region infrastructure, so the data-at-rest claim is available there. What I cannot do is stand here and certify their current posture across all four questions as settled fact, because hosting products and regions and support structures all change. A policy I last read months ago may have shifted since, so the responsible answer is the framework rather than a frozen one.
Ask WP Engine (or any host) for a written attestation covering each of the four claims, and read it the way you would read a contract clause, because that is what it should become. The right answer from any vendor is a binding document they will put inside the contract. A marketing page can be rewritten without notice and a reassurance in a call binds no one. A signed attestation is the only version of the answer that survives an audit.
The honest host landscape
I am not going to invent specifics I cannot verify, because a fabricated detail in this kind of evaluation is worse than no detail at all. Here is the shape of the field.
Canadian-region options do exist. WP Engine has Canadian infrastructure. Kinsta runs on Google Cloud and offers a Toronto region. There are a handful of smaller managed hosts with Canadian footprints as well. Most of these can reliably say “data at rest in Canada,” and for many requirements that is a genuine starting point.
The four questions are what separate a starting point from a fit. Some of these hosts run global CDN edge networks that move data through US nodes. Some pair Canadian servers with support staff who hold server-level access from outside Canada. Some default backup retention to US regions unless you specifically ask otherwise. All of it lives in the written attestation, provided you ask for one that covers all four claims rather than accepting the pricing page and the sales-call summary as the whole story.
What Treasury Board expects, in plain terms
If you work inside a federal department, the Treasury Board of Canada Secretariat publishes direction on the secure use of commercial cloud services, and it sets data-residency expectations for departments handling protected data. The profile that governs most government web infrastructure is the Protected B, Medium-Integrity, Medium-Availability standard, usually shortened to PBMM. I am giving you the names rather than specific directive sub-section numbers on purpose. The exact citations should be confirmed against the current version of the directive by your own policy team, because they do get revised.
The part that actually matters at signing time: the host’s attestation has to match the profile rather than the marketing language. If you are operating under PBMM, a host with Canadian data at rest but US backup retention does not meet the requirement, no matter how prominently “hosted in Canada” appears on their site. That is precisely the gap I watched come into focus in the Hamilton conversation. The marketing answered one question. The profile asked four.
This is not legal advice. For the specific compliance call, the people to ask are your legal and compliance team, who can assess the live version of the directive against your situation. The framework underneath, though, is stable: four claims, each one in writing, each matched to your profile.
What “we host in Canada” answers, and what it doesn’t
“We host in Canada,” when accurate, answers the data-at-rest question and nothing else. It is silent on transit, backups, and access. Those are three separate questions, and an honest vendor will give you three separate answers without you having to drag each one out of them. The answer that gets volunteered least often is access residency. If a vendor offers it before you ask, that tells you something good about how they think about their clients’ obligations.
The mode you want to be in
The Hamilton conversation ended with me pulling the enterprise support-access documentation and going through it line by line at the table, reading what the documents committed to rather than what the summary implied. That is what this work looks like when it is done properly: a document review, before you sign the hosting contract rather than after.