A tenant isolation checklist for SaaS products

SaaS tenant isolation means one customer organization cannot read or change another’s resources through any product path. Adding a tenant column to database tables is only the start. Exports, background jobs, file downloads, and support tools need the same boundary.

A useful review follows data out of the database and through the places where engineers are tempted to assume the context is already trustworthy.

Establish tenant context once, then verify its use

Resolve the active organization from the authenticated user’s authorized memberships. A browser can request an organization switch, but the server must verify that switch. A supplied tenant ID is a selector, not proof of access.

AWS’s tenant isolation guidance explains that isolation strategies vary with the deployment and business context. Separate infrastructure and shared infrastructure both require an explicit design; the checklist below is not a substitute for choosing that design.

Identify which resources are tenant-owned and which are genuinely global. Document any permitted sharing. An unclassified table or storage path is an unresolved decision, not an exception the implementation should guess.

Check the boundaries outside ordinary requests

Surface	Review question	Negative test
API reads and writes	Is tenant ownership enforced with object access?	Submit another tenant’s object ID
Background jobs	Does the worker validate persisted tenant context?	Run a job with mismatched resource ownership
File storage	Is access checked before issuing a download?	Request another tenant’s export
Cache and search	Are keys and filters scoped correctly?	Repeat identical queries across tenants
Support tools	Is privileged access explicit and recorded?	Try ordinary credentials on support endpoints

Database constraints should also prevent relationships that cross tenants accidentally. A valid project ID and a valid customer ID do not necessarily belong together. Review bulk updates and administrative scripts separately from the main request layer.

Logs and diagnostic attachments can contain customer data too. Restrict access to them, and avoid placing raw payloads in broad internal dashboards. Isolation review should include the people operating the platform.

A hypothetical export leak

Imagine a scheduling SaaS with two organizations, both using the report name “Monthly activity.” The request endpoint verifies membership correctly and queues the export.

The worker writes both exports to a shared filename derived only from the report name. A download endpoint then serves whichever file was written last. All database queries were scoped, yet the file boundary failed.

Use distinct tenant-scoped storage keys and persist the export’s owner. Verify access again when serving it. If using temporary signed URLs, treat their validity period and sharing behavior as part of the design rather than assuming they continuously reflect membership changes.

Make isolation a release check

Create two test tenants with deliberately similar names and overlapping local identifiers. Exercise creation, search, downloads, deletion, restoration, and job retries. Include a user who belongs to both tenants so organization switching gets tested as well.

Do not accept a hidden button as evidence of denial. Call the endpoint directly and inspect the returned data and side effects. Any unexplained cross-tenant access blocks release until understood.

Start the next review with one export’s complete path, including storage and support access. That bounded exercise gives a custom software development team concrete boundary tests it can extend to the rest of the SaaS product.