Security.

Kaima

Where client data sits

One of the clearest enquiries we have received asked to do this properly, protect client data and be compliant and safe, in the opening message, before any discussion of what to build. It is the right first question.

The answer starts with a boundary, not a promise: in most engagements your data stays in the systems it already lives in. We build things that read from them and write back to them. Where data does have to be held somewhere new (an index, a queue, a store the system needs to work), that is a decision made explicitly at the start, written down, with the location and the retention agreed rather than assumed.

Residency is part of that decision and not an afterthought. If it matters to you that data stays in Australia, say so at the beginning: it constrains which services can be used and is expensive to retrofit.

Where ours sits, and the part we have not decided

The answer above is about your systems. This one is about ours, because a page that only answers the first question has answered the easy one. Where we do hold something (an index, a queue, the store a system needs in order to work), this is where it sits.

The database is in Sydney, for production and for testing. The application that reads it runs in the United States, because that is the hosting default and nobody changed it; that is true of every project we run, not one of them. The AI, email and queue services are in the United States as well.

Which makes one sentence the one to hold us to: at rest in Australia, processed in the United States on every request.

Nothing about that has yet been required of us by a client or a regulator. That is the difference between a policy and a practice, and it is worth assuming about anyone who describes their arrangement without being asked. And one question that sentence does not answer, which you should ask us and ask anyone else: which of those services sees your content, and what its provider is permitted to do with it. That belongs in a written data-handling position. Ours is not published yet, so ask us directly and hold the answer against the notice when it arrives.

The part that cannot be undone

The region a database sits in is fixed when it is created. It cannot be moved afterwards, only rebuilt somewhere else and migrated into, which for a database holding your records means moving your data rather than changing a setting. So it is decided before a project exists rather than during it, and for anything holding a client’s business information the answer is Sydney.

And the part still open

Whether to move the application to Sydney too. That is a trade-off between speed, cost and how much sits in one place, not a formality, and it has not been settled. It is on the page rather than in a footnote because the sentence above is only true until it is.

Who can reach it

Two separate questions, and they get separate answers.

Who at your end

Whatever the system can reach, the people using it can reach through it, so access is designed at the start rather than added later. A system that can read everything, used by someone who should see some of it, is a permissions problem wearing an AI system's clothes.

Who at our end

Both founders, and nobody else, because there is nobody else. Access is the minimum needed to do the work and it is removed at the end of an engagement rather than left in place in case it is useful. If you want that written into an agreement, we will.

What we log

Enough to answer what did it do, and why after the fact. A system that takes actions and keeps no record of them cannot be trusted, because the first surprise has no explanation and there is nothing to look at.

So actions are recorded, what ran and on what and what it decided, and where a system was uncertain, that is recorded too. The uncertain cases are the useful ones: they are where the design was wrong, and they are invisible if you only log successes.

What happens when something goes wrong

You are told. Quickly, by one of the two people who built it, with what happened and what it affected, including when the answer is that we do not yet know.

Then it gets fixed, and the reason it happened gets written down and turned into a check, so the same failure has to be new to happen twice.

And what we have not finished, on our own platform

Said here because this is the page where you are already asking. There is no monitoring on the platform our own client work runs on: the way we find out something has broken is that a client tells us. The backups have never been restore-tested, which means we have a backup policy rather than a restore capability. There is no error tracking on it.

Those are our failings and they are published on purpose. Every one is the sort of thing a buyer discovers in month four, and a firm that lists them up front is easier to check than one that does not.

We would rather set that expectation than publish a set of reassuring words about our commitment to security. Every firm has those. What tells you something is whether the people who built the thing are the ones who ring you, and how long it takes.