Multi-institution: what strict isolation means technically

A sentence that means nothing on its own

Every shared-platform vendor states that client data is isolated. The sentence is true in almost every case — and it says nothing about the level at which isolation is applied, nor what happens if that level is crossed.

Three questions are enough to tell structural isolation from isolation by convention.

First question: at what level is isolation applied?

Application-level isolation rests on every query filtering correctly. It holds as long as no developer forgets a filter. It is the most common level, and the most fragile: one omission is enough.

Database-level isolation puts the filter beneath the query, inside the engine itself, so that a query without context returns nothing rather than everything. An omission becomes an empty result, not a leak.

Audit-level isolation further guarantees that the trace itself is partitioned: a log shared between institutions is a frequently overlooked leakage channel.

Second question: what happens with no context?

This is the question that separates. On a solid system, a query executed with no institution context fails or returns nothing. On a fragile one, it returns everything.

The formulation to take to a security committee: “no query executes without an institution context.” It is verifiable, and it is testable — through automated cross-institution access attempts, run on every change and blocking if any succeeds.

Third question: and if logical isolation is not enough?

Some security policies exclude sharing, whatever the level of isolation. The honest answer is not to argue, it is to offer a dedicated instance — physical isolation — or deployment inside the institution's own infrastructure.

That answer presupposes a platform designed to be deployed elsewhere. A vendor whose architecture rests on proprietary services cannot give it, and generally discovers this in the security committee.