SaaS tenant isolation: keeping each customer’s data separate

The risk

A SaaS product often serves many organisations from the same application. Tenant isolation means one organisation cannot read or change another’s information. Separate dashboards are not enough: the checks must apply wherever data is accessed, including APIs and background tasks.

Prepare two test organisations

In an environment you are authorised to assess, create two organisations with synthetic records and clearly different names. Give each its own ordinary user and administrator. Write down which records each role should be able to view, edit, export and delete.

Check more than the main dashboard

With permission to test, compare requests made by each account. A server must reject access to another tenant’s record even when the identifier is known. A difficult-to-guess identifier is not an access-control mechanism.

• Include search, attachments, invoice downloads and exports
• Check invitations, organisation switching and shared links
• Review scheduled reports, queues and cached results
• Check that support and administrator privileges have explicit boundaries

Build the boundary into data access

Derive the tenant from the authenticated user’s authorised memberships rather than trusting a submitted tenant ID. Apply the boundary consistently to database queries and storage access. Where an operation spans organisations, define and audit the exception rather than bypassing isolation silently.

Evidence worth keeping

Record the account roles, affected operation and expected result without including real customer data. Add regression tests for any missing boundary. A scoped penetration test can examine these paths; it does not prove that every future feature will preserve isolation.