Where Your Knowledge Actually Lives

Most software asks you to take data storage on faith. It’s “in the cloud”, which is a comforting way of saying “somewhere, we’ll handle it.” For a lot of teams that’s fine.

If you work somewhere regulated, it isn’t. Where your data physically sits is a question you have to be able to answer. A regulator, a risk team, or a due diligence questionnaire will eventually ask it. “In the cloud” is not an answer that will pass. So here’s how we think about it, plainly.

Your data stays in the region you pick

When you set up KnowledgeScout, you choose where your data lives: Sydney, London, or Dallas. If you’re an Australian team and you need your knowledge base to stay in Australia, it stays in Australia. It doesn’t quietly get copied to a cheaper region overnight. The region you choose is where it sits.

That sounds like a small thing until you’ve had to fill in a vendor assessment that asks, in writing, which country your customer data is stored in. “We’re not sure” loses you the deal. “Sydney, and here’s the detail” doesn’t.

You’re not sharing a database with strangers

Here’s the part most people don’t think to ask about. In a lot of multi-tenant software, everyone’s data lives in one big shared database, kept apart by a column that says which company each row belongs to. It works right up until a query is written wrong, and then it very much doesn’t.

We don’t do that. Every customer gets a completely separate database. Physical isolation, not a shared table with a label on each row. One company’s search can never reach another company’s content, because there’s no shared pool to reach into. If something went wrong with one, it’s one, not everyone.

It’s more work for us to run it this way. It’s also the honest answer to “how do you make sure our data can’t leak into someone else’s account”, and I’d rather do the work than give a hand-wavy answer to that question.

Encryption and backups, the boring detail that matters

Data is encrypted in transit and at rest. Backups are encrypted too, and stored off the main server, so a problem with the live system doesn’t take your safety net with it. Backups run nightly. We keep daily copies for a week, weekly for a month, and monthly for three months, so if something gets deleted or corrupted, there’s a way back.

None of this is exciting. It’s not meant to be. It’s the plumbing that lets a risk team tick the boxes they’re required to tick, and it’s exactly the stuff that tends to be vague or missing in newer tools. We wrote it down on purpose.

The honest bit

Two things worth being straight about.

First, none of this makes us the right choice for the largest, most locked-down enterprises with their own bespoke compliance regimes and a procurement process measured in quarters. We’re built for growing teams that need to be genuinely trustworthy with data, not for a bank’s core banking platform. If you need a private single-tenant cloud in a data centre you nominate, that’s a different kind of product.

Second, choosing a region is about where your knowledge base lives. It is not a claim that every AI query stays in that region. If you use our default AI, the question goes to the model provider. If that distinction matters to you, bring your own keys on Business or Enterprise and you control where that processing happens.

Security is never finished, and anyone who tells you their setup is bulletproof is selling something. We made the harder choices, separate databases, regional storage, encryption everywhere, because the teams we’re building for can’t afford the easy ones. And we’ll keep publishing what we do rather than asking you to assume it.

If data residency is on your checklist, that’s a good sign you’re the kind of team we built this for. Ask us the hard questions. We’d rather answer them now than have them come up later.

The KnowledgeScout Team