A SaaS buyer should ask how one customer's resources are kept separate from another customer's work, and what evidence demonstrates that boundary. The answer needs to cover users, APIs, background tasks and support access. A tenant label in the interface does not explain how the rest of the system applies it.
Start with business acceptance questions, then agree the engineering and specialist security work needed to answer them. This guide provides requirements and hypothetical checks. It is not an assessment of a live platform, a penetration-testing method or proof that an application is secure.
Define the tenant boundary in business terms
Describe what a tenant represents in your product. It might be a customer organisation, a business unit or another contractual boundary. Identify the records, files and workflows that belong within it, and whether a person can legitimately work in several tenants.
For wider product planning around these controls, see the SaaS development stages.
Separate tenant membership from role. A reviewer in one organisation is not automatically a reviewer in every organisation where the same email address appears. Likewise, a platform support operator has a different purpose from an administrator acting for one customer.
Ask how the product handles shared resources. A public template, a reusable catalogue and a customer's private document may need different policies. Making those categories explicit helps the team avoid either exposing private resources or blocking legitimate shared functionality.
Ask where tenant context is applied
Request a plain explanation of how a request acquires its tenant context and how the application checks it against the requested resource. Avoid accepting a statement such as “the database separates customers” as a complete answer when exports, files or other services are involved.
The AWS SaaS Lens testing guidance identifies tenant-specific validation, including isolation and multi-tenant workload behaviour. It provides a reason to request targeted evidence, not a certification that a particular architecture meets your requirements.
Interactive requests
Include direct API requests and links to resources, not only navigation through the expected screens. Decide what an authorised user should receive when requesting an unavailable or unauthorised record, and what useful diagnostic evidence the team can inspect without disclosing protected content.
Background jobs and support tools
Ask which identity and tenant policy govern a queued export, scheduled report or support action. These operations may run after the original session ends. Their requirements should explain how membership changes and administrative access affect the work already waiting to run.
Write cross-tenant acceptance scenarios
Use fictional tenants and controlled records in an authorised environment. Describe the actor, resource, action, expected decision and evidence for each case. A test description that merely says “check tenant security” is too vague to review or repeat.
The following scenario cards are examples of requirements a buyer can discuss with the delivery team:
Card A: a record belonging to another customer
A user acting within tenant A requests a record owned by tenant B. The agreed result denies the unauthorised access and does not include the protected record in the response. Evidence should identify the relevant access decision without spreading private data through screenshots or support tickets.
Card B: an export created before a membership change
A user requests an export and then loses access before the job runs. Specify whether the job stops, is re-authorised or follows a separately approved policy. Review the exported file's later access as well as the initial job decision.
Card C: platform support enters a customer context
A support operator needs to investigate a problem for one tenant. Define who authorises that access, its resource scope and how it ends. The acceptance question is whether the actual support route implements the agreed policy, not whether a broad administrator account can see everything.
OWASP's authorisation guidance supports explicit access decisions and checks beyond screen visibility. Apply that principle to each route being reviewed; a hidden button is not evidence of a denied operation.
Check changes in membership and configuration
Static demonstrations are useful, but a product also changes over time. Include users moving between teams, role changes, suspended accounts and shared links created under an earlier policy. Ask what causes those changes to reach every place that makes an access decision.
Consider a fictional user who belongs to two tenants. Switching the visible workspace should not leave a background request using an unintended tenant context. Record what the system does when the resource and the selected context disagree, rather than assuming that the interface always sends the expected combination.
Files and cached results deserve attention because their lifetime can differ from the screen that created them. Request a policy for generated downloads, preview links and stored reports. If access expires or ownership changes, identify who can demonstrate the intended behaviour.
Keep configuration changes within scope too. A changed tenant status or service tier may affect availability and allowed actions. The buyer should understand which transitions are automatic, which require operations work and which evidence shows that the transition completed.
Request evidence and separate security assurance
Ask for reproducible acceptance records tied to the relevant version and configuration. Useful evidence identifies the scenario, actor context, expected result, observed result and unresolved issue. A screenshot of a successful normal workflow says little about a cross-tenant denial.
Use a defined scope for software verification and testing and separately agree any specialist security assessment.
Keep the boundaries between reviews clear. Product acceptance checks whether the specified behaviour was delivered. Architecture review examines design decisions and assumptions. A specialist security assessment has its own scope, authority, methods and reporting. Do not present one as a substitute for all the others.
When evidence is incomplete, record the limit accurately. A team may have checked tenant-specific API access while file exports remain outstanding. That is more useful than a broad “isolation passed” label, which could lead a buyer to rely on controls that were never examined.
Also ask who can reproduce a failure and close the resulting issue. Evidence that nobody owns is difficult to maintain when features and tenant models change. Include the affected scenario in later regression review rather than leaving it as a one-off demonstration.
Extend the fictional tenant test to a copied reference. A user in tenant B submits an export identifier originally created in tenant A. The expected outcome must follow the current user's authority, even if the identifier is valid and the underlying file still exists. Check the download route as well as the screen that lists exports. Otherwise a filtered list can appear correct while a separately handled resource remains accessible through its direct reference.
Set review boundaries before commissioning SaaS work
Bring product, operations and engineering together to define the protected resources and legitimate cross-tenant exceptions. Resolve those business questions before asking a testing team to verify them. A reviewer cannot determine whether support access is excessive without knowing the authorised support process.
The practical output is a boundary description, a set of representative scenarios, named evidence owners and a list of specialist work still required. Keep each statement proportionate to what has actually been reviewed. No checklist can establish that every possible disclosure path has been eliminated.
Discuss tenant boundaries and the evidence you need when planning a multi-tenant SaaS with ZakCodeX.
