ARCH-6 Tech Due Diligence

Tech Due Diligence ARCH-6: Multi-Tenancy and Data Isolation

What This Control Requires

The assessor evaluates the multi-tenancy architecture, including how customer data is isolated, whether cross-tenant data access is architecturally prevented, and the scalability implications of the chosen tenancy model.

In Plain Language

For any SaaS product serving multiple customers, a data leakage incident where one customer can see another's data would be catastrophic - both legally and reputationally. That is why multi-tenancy architecture gets intense scrutiny during due diligence.

Assessors examine the tenancy model in use: shared database with row-level isolation (most common for early-stage SaaS), schema-per-tenant (moderate isolation and operational complexity), or database-per-tenant (maximum isolation but highest operational overhead). Each model has trade-offs around isolation strength, operational complexity, cost efficiency, and scalability.

The review goes beyond the database layer. Assessors check tenant isolation across the entire stack: application-level tenant context enforcement, API-level scoping, file storage isolation, cache namespacing, queue isolation, and logging separation. A single missing tenant filter in one database query could expose customer data, so architectural enforcement mechanisms are far more trustworthy than relying on individual developer discipline.

How to Implement

Pick your multi-tenancy model and document the justification clearly. For most early and mid-stage SaaS companies, shared database with row-level isolation works well. Make sure every table containing customer data has a tenant identifier column, and enforce tenant filtering at the ORM or data access layer rather than in individual queries.

Implement tenant context as a cross-cutting concern applied automatically throughout the request lifecycle. Extract the tenant identifier from the authenticated session or API key at the start of each request and propagate it through all data access layers. Use ORM-level query scoping or middleware to apply tenant filters automatically.

Write automated tests that explicitly verify tenant isolation. Confirm that a user from tenant A cannot access tenant B's data, that API endpoints always scope results to the authenticated tenant, that file storage paths are tenant-scoped, and that administrative operations are properly authorised.

Consider offering stronger isolation for sensitive customers. Enterprise or regulated-industry clients may need schema-per-tenant or dedicated infrastructure. You can maintain shared tenancy for standard tiers while providing elevated isolation as a premium option.

Secure the tenant resolution mechanism itself. Tenants should be identified through secure, authenticated channels rather than guessable URL parameters. Support staff tenant impersonation should be logged and auditable. Tenant configuration changes should require appropriate authorisation.

Plan for tenant-level scaling as your largest customers grow. Ensure large tenants do not degrade performance for others (the noisy neighbour problem), that tenant-level usage monitoring enables proactive capacity management, and that you can migrate individual tenants to dedicated infrastructure if needed.

Audit tenant isolation regularly through security testing, code reviews, and penetration tests. Any new data access pattern should be reviewed for proper tenant scoping before it reaches production.

Evidence Your Auditor Will Request

Multi-tenancy architecture documentation with isolation model
Tenant filtering implementation in the data access layer
Automated tests verifying cross-tenant data isolation
Tenant-level usage monitoring and performance metrics
Security audit records covering tenant isolation

Common Mistakes

Tenant filtering applied inconsistently; some queries miss tenant scope
Shared caching without tenant namespacing allows cross-tenant data exposure
No automated tests for tenant isolation; reliance on manual verification
Noisy neighbour problem: one tenant's heavy usage degrades performance for all
File storage not tenant-scoped; path manipulation could access other tenants' files

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.8.3	Related
SOC 2	CC6.1	Related

Frequently Asked Questions

Is row-level isolation sufficient for enterprise customers?

For many enterprise customers, well-implemented row-level isolation with proper testing and auditing is perfectly adequate. That said, some enterprise and regulated customers will insist on stronger guarantees like schema or database-level isolation, or even dedicated infrastructure. Being able to offer different isolation levels as part of your pricing tiers is actually a competitive advantage worth building towards.

How do we test for tenant isolation bugs?

Create automated integration tests that spin up two test tenants, populate each with data, and verify that API calls authenticated as tenant A never return tenant B's data. Run these tests in your CI pipeline on every build. On top of that, include cross-tenant access attempts in your penetration testing scope - automated tests catch known patterns, but pen testing catches the creative edge cases.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment