An MSP service may present many customers in one console while still needing strict separation of their data and authority. Tenant isolation means that every request and derived artifact remains within the tenant scope the current principal is allowed to access. A customer selector in a browser is not a security boundary.
Map the boundaries
List report records, domain inventory, configuration proposals, exports, audit events and scheduled jobs. Identify how each object carries tenant context and where access is enforced. OWASP's multi-tenant guidance treats tenant context as a security concern across application and data layers; its authorization guidance recommends default denial and checking every request.
Derive tenant scope from trusted authenticated context and approved membership. Treat a tenant ID supplied in a URL or payload as untrusted input to validate, not as sufficient authority. When a background job runs, preserve the initiating tenant and recheck the permissions required for its action. Cross-customer MSP analysts need explicit multi-tenant grants, not a bypass inferred from their job title.
Test resources and operations independently
Use two fictional customers with distinct reports and domain objects. Attempt a permitted read, then swap only the resource ID. Repeat for export download, proposed DNS write and user-management change. Test direct API requests because an invisible button does not prevent a crafted request. Confirm denial does not disclose report content or object details unnecessary for the response.
Test cached results, search indexes and generated exports as well as database queries. A correctly scoped query can still leak data through a cache key that omits tenant identity. Export storage and download authorization need their own negative tests. Include role changes, suspended accounts and removed membership; a stale session must not preserve withdrawn privileges indefinitely.
Follow a report into its exported artifact
Suppose tenant A’s report API correctly denies tenant B, but a previously generated export can be downloaded by changing only its object identifier. The API test passed within its scope, yet export isolation failed. Preserve the request and artifact evidence without collecting unnecessary customer data, restrict affected access through the authorized incident process and investigate the exposure before expanding the pilot.
In a separate case, an analyst leaves the account after scheduling an export. The job consumer must re-establish trusted tenant context and check current authorization when it performs the work; a historical queue submission is not an enduring grant. These are hypothetical failure scenarios, not results from an actual product. Test both a valid scoped download and prohibited requests at the real API, job and storage boundaries, retaining identity, tenant, operation, object and observed result without secrets.
Define recovery and evidence
Keep isolation failures distinguishable from ordinary missing-resource errors in restricted operational logs while avoiding unnecessary disclosures to callers. Record the incident scope, affected artifacts, containment and re-test results. Do not silently delete evidence to make the test clean.
Acceptance requires successful allowed paths and failed forbidden paths across every relevant operation. A single passed matrix does not prove all application code is isolated. Re-run tests after permission-model, storage, cache, export or job-system changes. Assess shared infrastructure and privileged support access explicitly, with time-bounded grants and audit review where needed.