How to answer
How is one customer's data kept separate from another's?
Logical separation is the true answer for nearly every SaaS, and also what somebody says when they have not thought about it. The difference is whether you can say how the boundary is enforced and tested.
Customer data is logically separated. Every record carries a tenant identifier, and every query is scoped to the authenticated tenant at the data access layer rather than by application code. [Object storage is partitioned by tenant prefix with per-tenant access policies.] There is no shared-schema path that returns another tenant's rows.
Square brackets are yours to fill in. FillTrust grades an answer like this implied, not stated when your documents support it.
- Answered from
- Your architecture or system description, whichever names the tenancy model. In a SOC 2 report this is usually in the system description rather than the controls.
- Evidence to attach
- Rarely anything. If pressed, the section of the architecture document that describes the tenancy boundary, never a diagram of the whole system.
- Where it is asked
- CAIQ v4.0SIG LiteISO 27001 Annex A
This question is asking one thing and checking another. The thing it asks is how your architecture separates tenants. The thing it checks is whether you have thought about it at all, because the failure mode it exists to catch is not an exotic one: it is an ordinary query that forgot its WHERE tenant_id = ?.
So answer the architecture question briefly and spend the rest of the answer on enforcement. "Logical separation, enforced at the data access layer" is worth more than three sentences describing your schema, because it says the boundary is somewhere a developer cannot casually step around. If scoping is applied by each query individually, say so honestly. That is a weaker control and a reviewer who finds out later that you described it as centralised will re-read everything else you wrote.
Name the places the boundary has to hold, not just the database. Almost every real segregation incident happens somewhere other than the primary datastore: an object store bucket with a shared prefix, a search index that was populated without the tenant field, a nightly export into a warehouse where the join was written once and never reviewed, a cache keyed on something that turned out not to be unique. A reviewer who has seen a few of these will be reassured by an answer that lists the surfaces, and unmoved by one that describes the database beautifully and mentions nothing else.
The strongest version of this answer includes a test. Design is a claim about intent; a test is a claim about what happens on the day somebody forgets. "Our integration suite runs every read as a second tenant and fails if any row comes back" is a sentence that ends this line of questioning, and it is worth building for that reason alone if you do not already have it.
Two things not to claim. Do not say "physical separation" unless each customer genuinely runs on infrastructure that is not shared, which for a company small enough to be answering this questionnaire by hand is almost never true. And do not say "encrypted per tenant" as though it answered the question: per-tenant keys are a good control and they do not prevent a query returning the wrong rows, because the application decrypts whatever it is handed.
How this one goes wrong
Specific to this question, not general advice.
- Answering "logical separation" and stopping there. It is the true answer for almost every SaaS and it is also what somebody says when they have not thought about it, so on its own it reads as the second.
- Claiming physical or dedicated separation because each customer has their own database schema. A reviewer means separate infrastructure, and correcting that later is worse than not claiming it.
- Describing the boundary in the application and forgetting everything beside it: the object store, the search index, the analytics warehouse, the queue, the backups. Segregation is only as good as the least careful of them.
- Having no answer for how the boundary is tested. "We scope every query" is a design; "the test suite fails if a query is unscoped" is a control.