Questions to ask about isolation in a school SaaS platform

"Multi-tenant" describes a business model, not a sufficient security control. A school evaluating a SaaS platform should ask how the system identifies the school, selects data connections, scopes storage and cache, enforces authorization, and controls operational access.

What happens before sign-in?

The platform should determine the intended school from an exact, verified host before tenant authentication begins. Ask what happens when a host is unknown, malformed, or belongs to the control plane. Fail-closed behavior matters because a fallback to the wrong school is more dangerous than a clear not-found response.

Where do models connect?

Ask whether school records rely on a shared default connection or whether the request selects a dedicated school database connection. Control-plane models should remain explicit about their landlord connection even while tenant requests change the default used by the original ERP models.

The same question applies to background jobs. A web request may resolve the correct school while a queued task later runs without that context unless the job carries and restores it safely.

What else is scoped?

Database separation is only one boundary. Review storage roots, cache keys, sessions, generated URLs, and uploaded files. Check whether each component changes and reverts when the active school changes, especially in long-running workers.

How does support work?

Operators should not receive implicit access to school data. A support session should be justified, approved where policy requires, limited in time and scope, visibly identified, and recorded for review.

Finally, ask about suspension, cancellation, export, recovery, and deletion. Good isolation includes lifecycle behavior: one school's status change must not affect another, and payment failure should not silently destroy educational records.