Audit-clean multi-tenancy: running many insurers on one backbone without mixing their data.

You are being asked to put your claims data on a platform built to carry your competitors as well.

A tenant is one organisation's walled-off share of such a platform: its own records, its own users, its own permissions, running on shared software but never on shared data. Multi-tenancy is the practice of running many of them on one system.

The commercial logic is not the hard part. The hard part is the security assessment your risk team will send, the outsourcing notification you may have to file, and the question your group CISO will ask that neither of those covers. All three come down to the same two things, and they come in a fixed order. Can anyone else see it. Can you show your regulator that nobody did.

Those are not the same question and they do not have the same answer. Separation is a property of a design. Proof is a record.

Where separation lives

If separation depends on every database request remembering to filter by tenant, it works right up until one request forgets. Nothing breaks visibly at that moment. The first sign is somebody seeing data that is not theirs.

Trisilva makes the tenant part of the identity of a record, and part of the authorisation decision on every access path. A mistake cannot reach another tenant's data.

The tenancy in a claims deployment is layered, and the layering is where the difficult cases sit. A primary tenant holds the operator users and the claim handlers. Each insurer is a sub-tenant scoping its own claim notifications, claim files and certificates. Each service centre is a sub-tenant scoping its own work estimates, repair plans and inspection reports. And there is a fleet-oversight tenant with read access across service centres and claims.

That last tenant is the case worth examining, because it shows the shape of the problem rather than an exception to it. Your claim handler and a competitor's claim handler both work claims on vehicles from the same dealer group. The dealer needs to see its own vehicles across both. It needs to see nothing else of yours. A legitimate cross-tenant view has to exist without becoming a general one.

What makes that tractable is a scope catalogue. Every actor on the platform is granted a specific list of permitted actions, its scopes. That covers insurers, brokers, distributors, claimants and repair partners. The list is granted separately for each tenant the actor can reach. The question answered on each request is not who is this. It is what is this actor permitted to do inside this tenant, right now.

Where the data sits

Separation between tenants and the physical location of data are routinely discussed as one topic, and they are two.

In the Vietnamese deployment the split is explicit. All personal data sits inside Vietnam, hosted by a Vietnamese data centre operator as sub-processor. That includes every record belonging to a Vietnamese resident, every piece of processing that touches an individual's data, and every uploaded document, which in motor means inspection photographs, scanned forms and copies of identity papers.

Aggregate, non-personal processing runs on separate infrastructure. Before anything crosses, a gate inside the Vietnam tier strips or replaces the personal fields, and the keys that would let anyone reverse that never leave Vietnam. The aggregate side does no per-record processing and cannot identify a person from what it holds. Because that data is not re-identifiable, it is not personal data under the Law on Personal Data Protection, Law 91/2025/QH15, and Decree 356/2025, so the arrangement creates no cross-border transfer of personal data.

Two honest qualifications on that.

The boundary is enforced by network and identity controls: components on the aggregate side have no route and no credentials to the personal-data store. That does not remove trust, it concentrates it into one place that can be enumerated and tested during due diligence, rather than spread across a policy that people have to remember. A control is checkable on a given day. That is the claim, and it is narrower than structural safety.

Re-identifiability is also the most contested question in this area. If a regulator disagrees with the assessment, the arrangement is a cross-border transfer and the design has to change. That is worth asking about specifically rather than accepting as settled.

The cost of the shape is real. The Vietnam side carries all personal-data processing plus all document handling, which concentrates the load, and capacity has to be sized for that before anyone commits to a performance figure.

What the audit log has to be

An audit trail assembled on request is a reconstruction. Trisilva writes the log as the work happens, by the same path that does the work, so no version of events exists outside it.

Every state change lands with the actor who caused it, a correlation identifier that threads one claim across services, and a before-and-after picture of exactly which fields changed. An insurer gets the sequence for any policy or claim, in order, with the actor on each step, without a project to produce it.

The log also has to hold non-human actors on the same terms. As AI surfaces ship into the platform in stages, each one is specified to write into the same log as a first-class actor, carrying how certain it was, which model version decided, the prompt identifier and the evidence it drew on. In a regulated claims operation, an automated decision has to be reconstructable a year later. Without that it is unusable, however accurate it was.

What that record does not yet answer

Here is the gap in the argument so far, and it is the second of the two opening questions.

Everything above gives you a complete record of what happened inside your own tenant. It is not, by itself, evidence that nobody outside your tenant read your data. Proving that negative needs three further things: read-access logging and not only write-access, tamper-evidence on the log itself, and coverage of the platform operator's own staff reads.

Those are a different piece of engineering from the one described above, and an insurer evaluating any shared platform should ask for them by name rather than accepting a write-side audit trail as an answer to a read-side question.

What to ask for

Four requests will tell you most of what you need.

Ask for the complete event sequence on one real claim, with actors, and time how long it takes to arrive.

Ask who can read your data from outside your tenant, including the platform's own staff, and ask to see the log of those reads.

Ask what enforces the residency boundary, and ask to see it rather than a description of it.

Ask what lands in the log when an automated decision is made, and whether you could reconstruct that decision a year later for somebody who will not simply accept your account of it.

Nothing else on the platform is worth buying until multi-tenancy holds, so it belongs early in an evaluation rather than in the security annexe at the end.