Contents
A customer sees only its own records on screen. That observation does not establish whether files, exports and background jobs respect the same boundary. To assess data isolation in a multi-tenant SaaS product, follow a record through its copies and recovery process. This produces evidence to request before bringing more customers onto the platform.
The proposed protocol uses two fictional organizations and describes expected outcomes. It does not report completed tests. The implementation team needs to adapt it to the actual architecture, run it in a controlled environment and retain observed results, including failures.
Identify the isolation boundary
A SaaS product can share tables, separate database schemas or maintain a database for each customer. The choice depends on risks, volume and operating requirements. A separate database simplifies some boundaries, but cannot automatically correct an export service that selects the wrong customer.
The AWS tenant isolation documentation distinguishes authentication from restricting resources by tenant. A user can be properly authenticated and still reach another organization’s data when an isolation boundary is missing.
When planning a custom web application, request a diagram showing where tenant context is established and checked. Include the API, database, files, cache and background workers. Identify administrative functions that are expressly permitted to cross the boundary and the identities that may use them.
Build a lab with two fictional customers
Create the fictional companies Boreal Workshop and Horizon Manufacturing. Give each an administrator, an employee, an invoice and an attachment. Deliberately reuse a filename and invoice number across the two organizations. These collisions help expose keys and lookups that omit tenant context.
Add a person who belongs to both companies with different roles. That person should be able to switch workspaces without carrying over the first workspace’s privileges. Prepare a suspended user and a support account too. Document what each identity may do before attempting to read or change any record.
Keep the dataset entirely fictional. Put recognizable markers in each company’s documents and record the expected owner in an inventory. Retain that inventory with the application version and lab configuration. It helps identify exposure even when the request itself appears technically successful and returns a normal response.
Follow the paths beyond the screen
Start by substituting Horizon’s record identifier into a request made by Boreal. The expected result is a refusal that contains no Horizon content. Repeat the scenario for reading, updating and deletion. Hiding a button is insufficient when the API still accepts the underlying request.
Next, start an export in Boreal and open an equivalent Horizon record before processing finishes. Verify that the completed file belongs to the organization that started the job. Notifications raise a similar question: which tenant context does the worker use after the browser session changes or disappears?
The OWASP multi-tenant guidance addresses tenant context, caching and storage. Include a file with the same name in both companies and a cached search result in your acceptance work. Request evidence about returned content rather than relying entirely on HTTP status codes.
Integrations with a custom CRM or ERP need the same attention. An external connection must belong to the appropriate organization. A worker should not select a provider account solely from a value that the requester can freely change in a submitted payload.
Repeat checks when the system changes
Give each scenario an identifier and associate it with a specific boundary. An export engine change calls for export checks. Membership changes call for role, session and revocation checks. Maintain a smaller baseline series that crosses the main access paths for every release as well.
For each run, record the version, account, action, expected outcome and observed result. Add an evidence reference without exposing production information. A screenshot can complement an API log, but cannot describe everything that happened inside a background job or establish which credentials the worker used.
Plan to stop a release when a scenario exposes the other company’s data. Preserve the result, correct the cause and rerun the affected scenario. Then assess related paths using the same component. A cache change can affect several features even when their screens and API contracts appear unchanged.
Recover one customer without changing the other
Suppose Boreal requests recovery of a deleted invoice. A shared backup may also contain Horizon. Prepare recovery in a separate resource, then select Boreal’s information through an authorized procedure. A customer should never receive a raw backup containing other organizations’ data simply because it requested a recovery.
Before reintroducing the invoice, verify ownership, dependencies and current access rules. An older backup may contain a member whose access was subsequently revoked. Recovering content must not silently restore that person’s privileges. Explain how attachments and search indexes will be handled, including any rebuilding that the process requires.
The expected outcome has two parts: Boreal’s targeted information is recovered within the agreed scope, and Horizon remains unchanged. Compare both companies’ markers before and after the exercise. Recovery duration and acceptable data loss are objectives to agree on and measure during an actual exercise, rather than results to assume.
Include agents and knowledge sources
A RAG knowledge base adds document fragments, indexes and sometimes conversation records to examine. Repeat the lab with a question resembling content held by both customers. The search scope and cited passages must remain within the current user’s authorized information.
A useful decision record brings together the architecture, fictional inventory, scenarios and dated results. Include known limitations and the person responsible for each correction. This evidence supports a release decision and gives future reviewers a repeatable starting point. It does not replace a security assessment tailored to the platform.
Related implementation guides
Frequently asked questions
Are two fictional customers enough?+
They provide a readable starting lab. Extend it with roles, volumes and configurations that represent your actual risks, especially support functions, external integrations and shared administration.
Does one database per customer guarantee isolation?+
It provides a useful boundary for some operations. Application services, administrators, files and exports must still select and authorize the correct customer throughout the workflow.
Should the protocol include refused requests?+
Yes. Verify that one organization cannot read, modify or export the other organization’s data and that error responses do not disclose its contents.
Can we restore a shared backup directly?+
A global restore can affect every customer. For targeted recovery, prepare a controlled extraction in a separate environment and verify dependencies before putting the selected data back.
Prepare usable evidence of tenant separation
Daillac can help your team define the fictional lab, the paths to verify and acceptance criteria for targeted customer recovery.
D
