SaaS tenant isolation testing asks a direct question: can a person from one organisation obtain or change another organisation's information? A convincing demonstration needs two tenants and deliberate attempts across their boundaries. A screen that filters a list to the current company is a useful interface, but it does not prove the server enforces the same boundary.
For a hypothetical purchasing platform, create two unrelated businesses with separate orders, users and documents. Give one user an ordinary role and another an administrative role within the first business. None should gain access to the second business merely because an identifier or download link is known.
Map access to actual business objects
List the objects that carry tenant information: orders, notes, attachments, invoices, search entries and exported files. For each one, identify who can read, change, approve and delete it. Include objects created automatically by imports or background jobs.
Write down whether an administrator manages one customer organisation or the whole service. Those are different responsibilities. A support feature that crosses tenant boundaries needs an explicit design and controlled use; a broadly named admin role should not silently become universal permission.
Exercise direct and indirect routes
Test a request for a known record belonging to the other tenant. Repeat the attempt through a download, a search query and an export filter. Confirm that failure does not reveal the record's sensitive fields in an error message, preview or response metadata.
Check the paths that are easy to overlook. A scheduled report may execute later under a different process identity. An attachment may be served from separate storage. The access decision must still reflect the organisation and permissions relevant to that operation, rather than trusting a value submitted by the browser.
Test membership changes during a workflow
Remove a user's membership after opening a page but before submitting a change. Repeat the journey with a role reduction and with a person who belongs to two organisations. Check that switching the selected organisation does not mix drafts, cached results or attachments.
Agree how long a prepared export or shared download remains available after access changes. The desired behaviour depends on the service, but it needs to be specified. Revocation should have a testable meaning across the application and its supporting delivery mechanisms.
Ask for evidence that survives a demonstration
Request an access matrix, representative automated tests and a record of the test accounts used. Keep tenant identifiers fictional and isolated from customer data. Record the denied result as carefully as the successful result; both establish the intended behaviour.
A passing sample does not establish a complete security audit. It does provide a concrete acceptance starting point and a way to catch regressions. Brainbaby Labs can discuss the application journey and ownership boundaries with your team before development. Bring the different user roles and one sensitive workflow, so isolation becomes part of the design and delivery criteria.