Ask how customer data is separated at the application, database and storage layers, how access is checked on every request, and what testing covers cross tenant access. Then verify with evidence: a recent independent penetration test summary and a pilot test using two tenants of your own.
Why this is a real question
A multi tenant SaaS product serves many customers from shared infrastructure. Your findings, SBOMs and policy data sit in the same service as everyone else's. The standard failure is an authorization bug where a request for one customer's object succeeds for another customer's user. OWASP's authorization guidance stresses validating permissions on every request, enforcing checks centrally and denying by default. Those principles are what you are asking the vendor to demonstrate.
Layers to ask about
| Layer | Question |
|---|---|
| Application | Is the tenant identifier enforced by shared middleware, or checked per endpoint by hand? |
| Database | Separate databases, separate schemas, or shared tables with row level controls? |
| Storage | Are reports and uploads stored per tenant, with per tenant keys or paths? |
| Compute | Do scans from different tenants share workers, and is the workspace wiped between jobs? |
| Support | How do vendor staff access a tenant, and is that logged and approved? |
None of these answers is automatically right or wrong. Separate databases are easier to reason about, shared tables can be fine with disciplined enforcement. What you want is a clear explanation and evidence it is tested.
Ask for evidence, not adjectives
- A recent penetration test summary that mentions authorization and tenant boundary testing. See how to read a vendor's pen test summary.
- A description of how the vendor tests for broken object level access, for example automated tests that sign in as tenant A and request tenant B objects.
- Whether a bug bounty or disclosure policy covers the product. CISA's Secure by Demand guide asks buyers whether a public policy authorizes security testing.
Test it in the pilot
If the vendor lets you create two trial tenants, do this:
- Create a project in tenant A and note its object identifier from the URL or API.
- Sign in to tenant B and request that identifier, through the UI and the API.
- Try the same with exports, webhooks and report links.
- Confirm the request is denied and that the denial appears in the audit log.
Only test within terms the vendor has agreed in writing. Unauthorised probing of a vendor service can breach the pilot agreement.
Single tenant and self-hosted options
If isolation requirements are strict, ask about a dedicated or self-hosted deployment, and what changes: who patches, who monitors, and which features differ. For a related review approach, see security review of a compliance platform before you connect it.
Safeguard offers SBOM and dependency scanning and a free scan at gold.safeguard.sh/scan.
Quick check
Is a shared database a red flag?
Not by itself. Ask how the tenant boundary is enforced and tested, and look for evidence such as penetration test coverage.
Can we run our own cross tenant test?
Only with the vendor's written permission. Agree the scope in the pilot terms first.
Sources
Last reviewed: 19 October 2026.
