Tenant isolation means keeping each customer's data completely separate inside a shared software platform, so one organization can never see or change another's data. Most SaaS platforms are multi-tenant: many customer organizations ("tenants") share the same application. Tenant isolation is the set of controls that guarantees each tenant only ever sees and changes its own data — through separate databases or schemas, tenant-scoped queries, separate encryption keys, and checks on every request.
Common tenant isolation models
| Model | How data is separated | Trade-off |
|---|---|---|
| Database per tenant | Each customer has its own database | Strongest separation; more to operate |
| Schema per tenant | One database, a separate schema per customer | Good separation; shared database resources |
| Shared tables | All customers in the same tables, filtered by a tenant ID | Cheapest to run; relies on every query being filtered correctly |
Why it matters
Asset registers contain locations, values, custodians and sometimes sensitive operational details. A failure of isolation would expose one customer's data to another, so it is one of the first things security reviewers ask about.
Questions to ask a vendor
- How is data separated between tenants?
- Are secrets and keys stored per tenant, and where?
- Is data encrypted in transit and at rest?
- Can we export all our data at any time?
In Asetavo
Asetavo isolates tenants at the database level: each company workspace runs in its own isolated database, with its own token-signing secret, so a token from one workspace cannot be used on another. Traffic is encrypted in transit with TLS, and reader signing secrets are AES-encrypted with a key held outside customer databases. You can export your register to Excel or CSV at any time. Data-residency options for Enterprise are on the roadmap. See how Asetavo keeps asset data secure.
