# 68 Multi-tenant compartmentalization

> v0.0.2 · role: Prevent · edition: All (per-tenant $) · [policy: #22 · #15](https://docs.google.com/spreadsheets/d/1nOztaPd1Y7eNeRSR_hdovYy-ncpx-bAx/edit?usp=sharing&ouid=115159875779023172526&rtpof=true&sd=true)

A high-threat sub-population — a legal team, an investigative desk, an executive group — is moved into its own Workspace tenant, so a compromise of the main tenant reaches nothing in theirs. It is the strongest boundary available here, because it is the only one that is not a setting inside the thing being attacked.

Documentation: [Best practices for planning accounts and organizations](https://docs.cloud.google.com/architecture/identity/best-practices-for-planning)

## Caveats

- It is the most expensive control in this catalog — a separate tenant is a procurement and operating-model decision, and it doubles every other control's operational surface.
- Compartmentalisation only holds if the tenants share no identity, no admin and no device — one shared super admin collapses two tenants back into one.

_Process control — carried out offline; no Admin Console walkthrough._

## Ongoing maintenance

- **[requires a human]** Quarterly: review the tenant map — which identities, data and controls live where — for drift.

## How to verify

1. From a staff account in one tenant, attempt to access the other tenant’s resources — it must fail as an ordinary external, with none of the home tenant’s privileges carrying over.