When buying a multi-tenant SaaS product, require evidence that one customer cannot access another customer's data through the interface, API, files, exports or background processing. A tenant identifier in the database is only part of the design. Tenant isolation must remain effective across the whole product and its operational tools.
This guide addresses Lithuanian SaaS founders and product teams procuring remote engineering support. TuniCyberLabs serves these buyers remotely. The focus is a concrete technical buying decision, not a claim that all businesses in Lithuania share the same architecture or regulatory requirements.
Define what a tenant means in your product
Before reviewing a proposal, agree which business entity owns data. A tenant could be a company, a workspace or a separately administered subsidiary. A user may belong to several tenants, and an administrator in one may be an ordinary member in another.
Consider an illustrative compliance-workflow product sold to several consulting firms. Each firm manages its own clients, documents and reviewers. A consultant who works with two firms needs distinct access in each context. Treating the user's login as the whole authorisation model would miss that distinction.
Write a short ownership map: tenant, user, membership, role and resource. Include what happens when a membership is removed, an organisation merges or a customer leaves. These lifecycle decisions affect the development estimate.
Ask the partner to explain the isolation approach
A proposal should say which resources are shared and which are separated, why that choice fits the product and what operational responsibilities follow. Shared infrastructure can be appropriate, as can stronger separation for selected resources. The relevant question is how the chosen design enforces the required boundary.
The AWS guidance on SaaS tenant isolation explains that isolation approaches depend on the product, deployment model and services used. It is a useful discussion reference, not evidence that a specific implementation is secure.
Ask how the application derives tenant context. Can a caller alter a tenant identifier and gain another customer's data, or is access checked against an authenticated membership? Ask the same question for server-to-server jobs and administrative operations.
Turn tenant boundaries into acceptance scenarios
Create at least two test tenants with deliberately similar data. Use users with different roles and one user who belongs to both tenants. This setup makes incorrect assumptions easier to expose than testing a single demonstration account.
For the consulting product, acceptance scenarios might include:
- ▸A member of Firm A cannot retrieve Firm B's document by changing its identifier.
- ▸A user switching workspaces sees only the selected tenant's permitted resources.
- ▸A removed member cannot continue using an old session to access protected records.
- ▸A search result, count or autocomplete response does not reveal another tenant's records.
- ▸A report export includes only the requesting tenant's authorised data.
- ▸An administrator action records which tenant was affected and who performed it.
State expected outcomes precisely. “The request fails” is incomplete if an error message still reveals a private document name. Include tests of both access and unintended disclosure.
Inspect the paths that ordinary demonstrations miss
Background jobs, caches and file downloads deserve explicit review. An export task may run after the requesting session ends. Its worker still needs a trustworthy tenant context and an appropriate access decision. A cache entry should not be reusable across tenants merely because two requests share the same URL.
For files, ask how the storage location relates to tenant ownership and how download permissions are checked. If the design uses temporary links, define the intended expiry and what happens after a user's access changes. Test the actual behaviour rather than assuming a link is private because it is difficult to guess.
Support tooling also needs a boundary. Decide who may inspect customer records, for what purpose and with what record of the action. A secure customer-facing interface can be undermined by an unrestricted internal screen.
Treat database controls as one layer
Some architectures use database row-level security as part of the design. PostgreSQL's row security documentation explains that enabled policies can restrict row access, but superusers and roles with bypass privileges are exceptions; table owners normally bypass policies too.
If a supplier proposes this mechanism, ask which database role the application actually uses and how tenant context reaches the policy. Require tests using the production-equivalent role, not only a specially constrained test account. Review privileged maintenance tasks separately.
This is not an argument for a particular database. It illustrates a procurement principle: the presence of a security feature is less informative than its configuration, execution context and verified behaviour.
Include isolation in the operating model
Ask how the team will detect a missing tenant filter or a job that processes the wrong scope. Logs should help diagnosis without becoming a second place where unnecessary customer data accumulates.
Define tenant-aware support and recovery procedures. Can the team identify which customer an incident affected? Can it export a customer's records completely? What are the limitations of restoring one tenant from a shared backup? These questions can materially affect support commitments and architecture.
Also discuss resource consumption. A tenant that submits unusually large jobs can affect neighbours even when data access remains separated. Specify the workload assumptions, limits and observable signals that matter for your product. Keep performance and confidentiality requirements distinct so each can be tested.
Make the deliverable an evidence package
Before acceptance, request an isolation design note, automated test results, documented exceptions, support-access rules and a tenant lifecycle walkthrough. Include known limitations and the person responsible for resolving them. Review material architecture changes against the same scenarios after launch.
Use the software vendor scorecard to compare suppliers. For teams still choosing between a custom platform and existing tools, the build-versus-subscribe guide helps frame the earlier product decision.
Our software engineering services can support SaaS design, implementation and verification. Discuss your tenant model with the customer relationships, roles and sensitive workflows your product needs to support, so scope starts with a testable boundary.