Canadian data residency
Your data stays in Canada. So does the AI.
Plenty of security vendors will tell you their database is in Canada. Ask the follow-up question: where does your AI run? For most of them the answer is a United States model provider, and for some of them the answer is that nobody has checked. Lavawall® runs its ticket triage and incident analysis on Amazon Bedrock in Canada, tokenises identifiers before anything reaches a model, blocks medical terms from model processing entirely, and lets no client data train any model.
Answer a security questionnaire Publish your own Trust Centre
AWS Montréal & Calgary · AI processing in ca-central-1 · no training on your data · other geographies on request
What is held in Canada
| Data | Held by | Location |
|---|---|---|
| Console, application and database | ThreeShield-controlled servers, and AWS | Montréal, QC and Calgary, AB |
| SIEM, log and event data | AWS | Montréal, QC |
| Microsoft 365 and Google Workspace monitoring data | AWS | Montréal, QC |
| Reported-phishing submissions | AWS | Montréal, QC |
| Domain and network scanning; Tenable Nessus results | ThreeShield-controlled computers | Calgary, AB |
| Agent compilation | ThreeShield-controlled computers | Calgary, AB |
| Outbound notification, report and ticket email | ThreeShield's own mail server, delivered direct to the recipient's mail exchanger, DKIM-signed | Canada |
| Backups | ThreeShield-controlled servers, and AWS | Montréal, QC and Calgary, AB |
Canadian storage is the default. Other geographies are available on request, which matters if you are an MSP with clients under EU, UK or Australian expectations.
The question most vendors dodge: where does the AI run?
Security tooling now runs language models over exactly the material you would least like to leave the country — log excerpts, ticket text, incident detail. Very few vendors disclose where that happens, and a growing number of privacy officers have started asking. Here is our answer, in full.
| Purpose | Model and provider | Processed in | What is sent |
|---|---|---|---|
| Support ticket analysis | AWS models such as Amazon Nova Lite, via Amazon Bedrock | Canada | Ticket text, with sensitive number patterns and email addresses tokenised. Tickets containing medical terms or keywords such as “patient” are blocked and never sent. |
| Security incident analysis | Anthropic Claude, via Amazon Bedrock | Canada | Incident and log data, with every IP address, email address, personal name and company name tokenised before transmission. |
| Supplementary model processing | Additional third-party models | United States | Tokenised and anonymised data only. Nothing that identifies you is transmitted. |
The four controls, stated plainly
Full identifier tokenisation
For incident analysis, and for anything processed outside Canada, every IP address, email address, personal name and company name is replaced with a token before transmission. No information identifying you or an individual reaches the model.
Medical-term blocking
A support ticket containing medical terms, or keywords such as “patient”, is blocked from model processing entirely and handled by a person. Clinics and health-adjacent businesses get a control, not a promise.
No training on your data
Every model, in Canada and outside it, is configured to prevent client data being used for training, and we contract with our providers on that basis.
Model processing is not storage
Data sent for model processing is not retained outside Canada. The output is written back to the console in Montréal or Calgary.
What does leave Canada, and why we list it
A residency page that claims everything stays home is a page nobody should believe. Four things cross the border, none of them carrying your reports or your ticket content:
| What | Provider and location | What passes through it |
|---|---|---|
| SMS and authentication codes | Twilio, United States | Telephone number and message text only |
| Email address verification | Amazon SES, Ireland | Verification of control of an address, and authentication codes. No report content, no ticket content. Notification, report and ticket email is sent from our own mail server in Canada. |
| Content delivery and installer distribution | Cloudflare, global edge | Console traffic in transit, encrypted end to end; agent installers |
| Meeting and call transcription | Transcription tooling, United States | Recordings and transcripts, where you have not opted out. There is no Canadian-resident option in this market today, so: you can opt out in writing at any time; we never transcribe silently, joining Teams as an obvious named participant or saying so verbally on a call; and we stop transcription the moment sensitive information is disclosed and delete what was captured. |
Why this shows up in your deals
It is on the questionnaire
“Where is personal information processed, and can a service provider outside Canada access it?” appears on nearly every security review. Answer it once, from a page you can send.
It creates an obligation for your client
Under Alberta PIPA section 13.1, using a service provider outside Canada means notifying individuals about it. Every offshore vendor in your stack becomes paperwork for the client. Fewer offshore vendors, less paperwork.
Health and public sector treat it as a gate
Provincial health information acts and public-sector procurement often treat residency as pass/fail rather than a preference. A US-hosted tool can end a bid before the features are discussed.
Questions worth asking your other vendors
Not rhetorical. These are the five that separate a real residency claim from a marketing one, and they are the same five we have answered above.
- Where does your AI inference run? Not where the database is — where the model call goes. If the answer is a US model provider, that is cross-border processing of whatever was in the prompt.
- What exactly is in the prompt? Log excerpts and ticket bodies routinely contain names, addresses and, in a clinic, clinical detail. Ask what is stripped before transmission and what is not.
- Is our data used for training or evaluation? “We do not train on your data” and “our subprocessor does not retain your data” are different claims. Ask for both in writing.
- Where is support ticket content processed? Ticketing is the quiet one. It is where free-text sensitive information actually accumulates, and it is rarely covered in a residency statement.
- Do you record and transcribe our meetings, and where does that go? Meeting transcription is the least-disclosed processor in most stacks, and the most likely to capture something sensitive verbatim.
Where to see the current position
Our sub-processor list and processing locations are maintained in our own Trust Centre and in our privacy policy, and we give clients not less than thirty days' notice before adding or replacing a sub-processor that can access client data. If you are building your own answer to these questions, Lavawall® will generate it: the Trust Centre publishes your frameworks, sub-processors and processing locations from data the platform already holds, and data-flow documentation maps where your information actually goes.