Every few months a client asks some version of the same question: why does your software run on our servers instead of yours? Everything else they buy is a login and a monthly invoice. We turn up with a Docker container and the enthusiasm of people who have read one too many breach post-mortems.
The short answer is that compliance data is the one kind you really shouldn't hand to someone else, and a vendor's security badge doesn't change that. A SOC 2 report tells you the vendor runs a tidy shop. It tells you nothing about which government can subpoena your data, or what happens to it the day that vendor gets acquired, breached, or quietly priced into a tier you can't afford. You can outsource where the bytes live. You can't outsource being the person who has to explain, on a Friday afternoon, where they went.
That's not a fashionable position in 2026. The default has hardened all the way to "of course it's SaaS, what else would it be," somewhere between Slack and oat milk. So it's worth saying out loud why we keep landing on the other side of it, at least for the data that would hurt the most on its way out the door.
Residency is a postal code. Sovereignty is a jurisdiction.
Here's the distinction the SaaS pitch tends to skate past. Data residency is where the bytes physically sit. Data sovereignty is whose laws can reach them. They sound like the same thing. They are not, and the gap between them is exactly where compliance teams get caught.
A US-headquartered provider can absolutely store your data in a Canadian or European region, and the marketing page will say so proudly. But the parent company is still subject to US law, and under the CLOUD Act a US provider can be compelled to produce data it controls no matter which country the server lives in. Your data can be resident in Toronto and reachable from Washington at the same time. Residency is a postal code. Sovereignty is the harder question: who holds the keys, who operates the system, and which courtroom the order arrives from.
This is where someone usually produces a SOC 2 report with a flourish, as if it answers the question. It answers a different one. A SOC 2 attestation tells you the vendor has controls and follows them, which is genuinely useful. It tells you nothing about the legal regime that vendor lives under, or what that regime can compel them to do with your data on an otherwise quiet Tuesday. Mistaking "they passed an audit" for "my data is out of reach" is one of the more expensive category errors in compliance.
Data sovereignty isn't a feature you buy back from a hosting-region dropdown. It mostly comes from where the data lives in the first place, and who can reach it from there.
The data you'd least want leaked is the data you're shipping out
Step back and look at what compliance data actually is. A finished assessment is an inventory of your security posture, which is a polite way of saying it's a ranked list of where you're soft. The gap analysis is worse: it's the same list with the soft spots circled and a note on how long they've been that way. Pen test findings, risk registers, the access reviews you keep meaning to tighten. Put it together and it's the single most useful document a competent attacker could ask for, and you generated it yourself.
So it's a little strange that the reflex is to upload all of it to someone else's servers and move on. We lock the production database behind six controls and a threat model, then keep the map of every weakness in that database in a third-party tool because the onboarding flow was pleasant. The sensitivity got inverted somewhere. The data describing your defenses ends up less guarded than the things it describes.
None of this means a breach of your compliance vendor is likely. The good ones are careful. It means the blast radius is wrong. If that tool gets compromised, or subpoenaed, or just quietly decides your "anonymized" data is fair game for training, the thing that leaks isn't a list of email addresses. It's the blueprint. And a blueprint of your gaps doesn't expire the way a stolen password does. You can rotate a credential in an afternoon. You cannot rotate the fact that someone now knows exactly where you're thin.
For Canadian teams, the question shows up with a deadline
If you operate in Canada, this stops being philosophy and starts being paperwork. PIPEDA lets you move personal data across the border, but it does not let you move the responsibility with it. Hand your data to a US processor and you are still the one accountable for protecting it, CLOUD Act and all. The transfer is allowed. The accountability is not transferable.
Quebec raised the bar further. Under Law 25, before you send personal information outside the province you are expected to assess whether it will get adequate protection where it's going, and to be able to show your work. It is not a flat "data must stay in Quebec" rule, despite how often it gets described as one. It is a requirement to think it through, document the assessment, and stand behind it. The penalties for getting it wrong reach into the millions, which tends to focus the mind.
Here's the practical version. Sooner or later a regulator, an enterprise customer's security team, or your own auditor asks a simple question: where does this data live, and who can reach it? If the honest answer involves a US-owned platform and a shrug about the CLOUD Act, you are now writing a justification under time pressure. If the honest answer is "on our own infrastructure, in this country, and the list of who can reach it is short and ours," the question is already closed. Self-hosting is one of the few ways to make that second answer true without an asterisk.
Where this stops being a religion
Self-hosting has a bill, and it's only fair to read it out. Something has to run that container: patch it, back it up, keep it alive at 2am when it decides not to be. If you have nobody who owns infrastructure and no appetite to, a managed SaaS tool with a real ops team behind it may genuinely protect your data better than you would. "It's on our servers" is not a security strategy if your servers are a forgotten VM nobody has logged into since the trial.
So we're not purists about it. Most of the stack should be SaaS, and ours is. Email, calendars, the CRM, the helpdesk, the hundred tools where the data is mundane and the convenience is the whole point. The reflex to reach for SaaS is right far more often than it's wrong. The argument was never "self-host everything." That way lies a server room and a nervous breakdown.
The line we draw is about consequence. For the data that would hurt the most if it leaked, the assessment evidence, the gap list, the map of where you're exposed, the math changes. There, the operational cost of self-hosting buys you something specific and hard to get any other way: a short, known list of who can reach it, and an honest answer when someone asks. For everything else, swipe the card and enjoy the convenience. For the data that maps your weaknesses, keep it home.
Where we land
We didn't build NISTForge self-hosted to make a point. We built it that way because we kept giving clients this exact argument and then handing them tools that did the opposite.
So it runs on your infrastructure, not ours. It ships as a Docker container with the AI model running locally through Ollama, which is a technical way of saying there are no API keys, no calls home, and nothing about your assessment leaves your network. The data describing your weaknesses stays on the same side of the firewall as the systems it describes. For teams that need it fully sealed, there's an air-gapped deployment with no internet at all, which is about as short as the "who can reach it" list ever gets.
Fair warning: it's not out yet. NISTForge is in its waitlist stage, with the public beta landing this summer and founder pricing held for the people who get in early. And if you'd rather have a hand with the assessment work itself, that's what our team is for, self-hosted tools or not.
Either way, the principle outlives the product. Your compliance data is a map of where you're vulnerable, so treat it like one. Keep it close, keep the list of who can reach it short, and when someone finally asks where it lives, make sure the answer is one you're glad to give.