A multi-tenant business application holds customer data for tens of thousands of organisations, each with its own compliance obligations. Which governance model actually works at that scale?

Why central review fails

A central team reviewing every change has a fixed capacity and an unbounded queue. It becomes the organisation's throughput ceiling, and the predictable response is that teams route around it — which produces worse governance than having none, because the controls exist on paper and not in the system.

What the working model looks like

• Invariants enforced by the platform, not by review. Tenant isolation, encryption, audit logging and retention floors are properties of the platform that a tenant cannot switch off.
• A configuration surface for what genuinely varies by tenant — residency, retention beyond the floor, field-level restrictions, consent categories.
• Delegated administration, so a tenant's own administrators manage their users and policies within boundaries the platform sets.
• Governance as code, evaluated at deployment and continuously, so drift is detected rather than assumed absent.
• Evidence generated automatically, because the audit burden across thousands of tenants is otherwise unmanageable.

The distinction that makes it tractable

Separate what must be universally true from what is legitimately tenant-specific. Universal invariants belong in the platform and are non-negotiable. Everything else is configuration with defaults.

Organisations that fail here usually fail by making too much configurable: every tenant-specific option is a combination that must be tested, supported and reasoned about during an incident, and the combinatorial surface grows faster than the team.