Skip to main contentMain content

Boardroom Answers · Technology & Platform · Technical Architecture & Scalability

Multi-Tenant Data Isolation: How to Prove Separation

The question a Chief Solutions Architect (Enterprise B2B SaaS) asks: “One database, all tenants. One missed WHERE clause and I am reading my competitor's board risks. Why is that impossible rather than merely unlikely?”

The short answer

Every query is filtered to your organisation and CI fails any build where one is not; identity comes only from the verified token; row-level security stands behind it for anything that reaches the database directly.

The full executive answer

The honest answer starts by conceding your premise: on a live request, the organisation filter is exactly what protects you. Our application talks to the database with a server-side service credential that bypasses row-level security, so every tenant query carries an explicit filter to the organisation resolved from your verified sign-in. What stops a missed filter from shipping is the build: an automated cross-tenant test reads every tenant-table query in the codebase and fails the build if one appears without that filter, and its list of reviewed exceptions can only shrink. Row-level security is enabled on every tenant table as the second line — it is what stops anyone who reaches the database directly, for example with a leaked public key, from reading another tenant's rows. So the difference is not 'our code is careful'; it is 'our code is not allowed to merge without the filter, and the database has a second lock behind it'.

Now the two questions a good architect asks next. Where does the identity come from? Only from the verified sign-in token — the organisation is resolved server-side from the authenticated session in our standard middleware, and our working agreement is explicit that it is never, ever read from a request body or URL, so the boundary cannot be forged from the client side. And what stops the next table from forgetting the policy? A static test in the CI pipeline scans every one of our database migrations, and if any table carrying tenant data lacks its row-level-security policy, the build fails — the mistake is caught before the code can even merge, by machine, every time. There are also dedicated cross-tenant access tests in the suite attacking the boundary directly.

Honest completion of the answer: 'impossible' is not a word I will use about any system, and the boundary has not yet been validated by an external penetration test — that is an explicit, funded roadmap item before enterprise go-live, and I would welcome your security team's own attempt during the pilot. What I can say is that the isolation is enforced on every query, machine-guarded against regression, backed by row-level security in the database, and aligned with OWASP ASVS access-control verification — which is the strongest claim any multi-tenant vendor can truthfully make ahead of third-party validation.

Grounded in: OWASP ASVS V4 (access control); AWS SaaS Lens tenant-isolation guidance

Want this answered live, on your data?