Answer by naming your isolation model (separate databases, separate schemas, or shared tables with row-level security), saying where the tenant check is enforced, and describing how you test that one customer cannot read another's data. Specific, testable statements beat the phrase "logically separated".
The three questions behind the question
A reviewer asking about tenant separation wants to know:
- Where does the boundary sit, in the database, the application, or both?
- What happens if application code forgets to filter by tenant?
- How do you know it works?
Pick the model you really use
The OWASP Multi-Tenant Security Cheat Sheet lists the common database isolation strategies: separate databases, separate schemas, shared tables with row-level security (RLS), or a hybrid. Separate databases give the strongest boundary but cost the most to run. Say which you chose and why, and do not describe a shared table design as if it were separate databases.
| Model | Strength | Typical trade-off |
|---|---|---|
| Database per tenant | Strongest boundary | Higher operating overhead |
| Schema per tenant | Strong, simpler than separate databases | Migrations across many schemas |
| Shared tables with RLS | Efficient | Depends on the policy being right everywhere |
Where the check should live
OWASP's guidance is useful wording for your answer:
- Establish tenant context early in the request and treat a client supplied tenant ID as a selector only. Verify the signed in user's membership in that tenant.
- With RLS, use a least-privileged request role, avoid superuser or BYPASSRLS roles on request paths, and fail closed when tenant context is missing.
- Treat application level ORM filters as defense in depth, because raw SQL and bulk jobs may bypass them.
- Include the tenant ID in cache keys, partition object storage by tenant, and scope signed URLs narrowly.
If your design does these things, write them in plain sentences. If it does not, fix the gap before you claim it.
How to describe your testing
OWASP suggests testing cross-tenant denial for every RLS protected table with the same role and connection pooling as production, deriving the list of tenant tables from the schema so new tables are not missed, and checking for session leakage across pooled connections. A good answer says "we run automated cross-tenant tests in CI" only if you do.
Also mention what else is tenant aware: background jobs, search indexes, exports and logs. A boundary that covers the database but not the export job is a common finding.
Offboarding and keys
If you offer per-tenant encryption keys, say so and say what happens to them when a customer leaves. OWASP notes tenant keys should be retired as part of offboarding under your retention policy. If you use a shared managed key with enforced access context, say that instead. Both can be acceptable.
Quick check
Is "logical separation" a good enough answer?
Usually not. It does not say where the boundary is or how you test it. Name the model and the enforcement point.
Do application filters alone count as isolation?
OWASP treats ORM filters as defense in depth only, since raw queries and bulk operations can skip them. Add a database level control where you can.
Safeguard's reachability analysis and dependency scanning help show which known issues in your libraries are reachable in your own code, which supports this kind of answer. The free scan works on a repository.
Sources
- OWASP, Multi-Tenant Security Cheat Sheet. Paraphrased.
Last reviewed: 19 October 2026.
