For vendor risk reviewers and data owners
A filter written in application code is one forgotten clause away from returning a neighbour’s record with no error raised anywhere. Enforced beneath the application, the same mistake returns nothing and the failure is visible immediately. This page says which of those is in use, what remains a shared surface, and how you would test it yourself.
A cross-customer disclosure notice has a recognisable shape. A change was made, a filter was omitted in one path, a small number of records belonging to one organisation became visible to another, the exposure ran for some period before anyone noticed, and there is no evidence the records were accessed. The last clause is doing an enormous amount of work and everybody reading it knows so.
What makes those notices arrive is almost never a break-in. It is an ordinary change made by a competent engineer in a code path where the separation depended on that engineer remembering something. The exposure is not caused by an attacker; it is caused by an omission that nothing was watching for.
That is why the wording of a vendor answer matters so much to a reviewer. Logical separation covers two completely different arrangements: one where the boundary is a condition somebody has to write correctly every time, and one where the boundary belongs to the storage layer and the request simply does not reach a neighbour’s record. Both get described with the same phrase, and only the second one survives an ordinary mistake.
The blast area also lives in places the diagram does not draw. Caches that key on an identifier that was not scoped, background jobs that process a batch assembled by an earlier query, search indexes rebuilt from a source that lost the qualifier, exports assembled by an internal tool nobody reviewed. These are where the real incidents came from, and a vendor who answers only about the primary datastore has answered a narrower question than the one asked.
And there is the part reviewers rarely say out loud: if this fails, the notice goes out under your organisation’s name, to your customers, on your regulator’s clock. The vendor writes a paragraph. You run the incident.
When separation is a condition application code must remember, an ordinary omission returns a neighbour’s record and raises nothing — so the exposure window is bounded by when somebody happens to notice rather than by any control.
The arrangement described here puts the qualifier below the application. Every request carries the organisation it belongs to as part of its execution context, the storage layer applies that as a mandatory condition, and a query that omits it returns nothing rather than returning everything. The mistake still happens — engineers are human and the omission is easy — but its result is an empty page and a bug report on the same afternoon, not a notice eight weeks later.
That is the whole argument and it is worth being blunt about what it does and does not buy. It does not make a mistake impossible. It converts a class of mistake from invisible to obvious, which is the only property that reliably survives a growing codebase and a changing team.
The surfaces beyond the primary store are the ones that actually produce incidents, so they are addressed by name. Cache keys are constructed with the organisation identifier as part of the key rather than as an assumption about who is asking. Background work carries the same execution context as the request that created it rather than inheriting an ambient one. Search and derived indexes are built per organisation rather than filtered at read time. Exports are produced through the same path as any other read, not through an internal tool that skipped the review.
What is genuinely shared is named rather than hidden, because a reviewer will find it and the finding is worse than the disclosure. Compute is shared. The scheduling of background work is shared. Rate limiting is shared, which means an unusual load pattern in one organisation is capacity another organisation is not using. Those are real and they are a different risk from data visibility, and collapsing the two is how a vendor answer becomes untrustworthy.
Whether an omitted qualifier returns a neighbour’s record or nothing — measured by a deliberate omission in a test environment, and observing an empty result rather than another organisation’s data.
Whether cached values can cross organisations — measured by inspecting a cache key and confirming the owning organisation is part of it rather than assumed.
Whether background work carries the same boundary as its request — measured by tracing one queued job and confirming its bound context matches the request that created it.
Whether exports use the same path as ordinary reads — measured by confirming there is no internal export route that bypasses the constraint.
What is genuinely shared, stated rather than discovered — measured by a written list of shared surfaces you can compare against your own review findings.
Time from an omission to it becoming visible — measured by whether the failure mode is an empty result on the same afternoon or a notice weeks later.
no claim that a mistake is impossible, no claim of physically separate infrastructure per customer on the shared arrangement, and no independent attestation that any of this held — a SOC 2 Type II attestation is in progress and no report exists yet. Compute, scheduling and rate limiting are shared and that is a real and different risk from data visibility. Where a customer requires physical separation, that is a different deployment shape and is described on its own page rather than implied here.
Every account that reaches the platform is governed by your identity provider, so the question of who belongs to which organisation is answered by your directory rather than by a local record we maintain. That matters for this subject specifically: a separation model is only as good as the assignment of people to sides of it, and the assignment should belong to whoever runs the leavers process.
Events reaching your logging carry the owning organisation, so a review of who touched what is something your own tooling can answer without asking us to produce a report about ourselves. A vendor-authored access report is the weakest possible artefact for this question.
Where an organisation requires that its records never share storage with anybody else’s, that is a deployment decision rather than a configuration flag, and it changes the cost and the operating model. It is described honestly as a separate arrangement rather than presented as a setting, because a vendor implying otherwise is describing something they will not deliver.
Enforced means the constraint is applied by a layer the application cannot forget. Shared means a resource genuinely serves more than one organisation and the risk is real even though it is not a data-visibility risk. Attested means an independent party examined it. This page uses the three words for three different things and a reviewer should hold it to that.
The shared list is short and it is stated because it is checkable: compute, background scheduling, and rate limiting. An unusual load in one organisation consumes capacity another organisation is not using, and the mitigation is per-organisation limits rather than a promise that it will not happen. A vendor claiming complete isolation on a shared platform is claiming something the architecture does not support.
On independent assurance the accurate statement is unchanged from every other page here: a SOC 2 Type II attestation is in progress and no report exists yet, so nobody can be handed one. It is an attestation with a scope and a period rather than a certification, and the two words are not interchangeable.
The most useful thing a reviewer can do is ask for the failure demonstration rather than the design description. Omit the qualifier deliberately and see what comes back. That single test distinguishes the two arrangements this whole page is about, and it takes minutes.
Insist on the demonstration rather than the description. Ask to see what a request with the qualifier omitted returns. If the answer is an empty result, the separation is where this page says it is. If the answer is a nervous explanation, you have learned the thing you came to learn.
Ask for the shared-surface list in writing and compare it with your own findings. A vendor whose written list matches what your review independently discovers has demonstrated something more useful than any control description: that their disclosure is complete.
Ask how a suspected exposure would be investigated, and by whom. The answer should involve your logging and your tooling, because an investigation that depends on a vendor producing a report about themselves is not an investigation your regulator will find satisfying.
And be explicit in your own record about which arrangement you approved. A shared platform with enforced separation and a single-tenant deployment are different risk entries, and approving one while recording the other is a common and expensive filing error.
One test-environment demonstration of what a request with an omitted owning condition returns, plus the written shared-surface list, before any evaluation of features begins.
That demonstration is the shortest path to a decision on this subject and it does not require a pilot, a contract or a discovery call. It answers the only question that matters here, and it answers it in a way a written description cannot.
The shared-surface list belongs in your risk register whatever you decide afterwards, because the entry you file should describe the arrangement you actually approved rather than the impression the evaluation left.
If the answer to either is unsatisfactory, stopping here has cost your team an hour. That is the correct outcome and it is a better use of this page than a longer evaluation that arrives at the same place.
The phrase covers two arrangements and only one of them survives an ordinary mistake. If the qualifier is a condition application code must remember, an omission returns somebody else’s records and raises nothing — that is how most disclosure notices are written. If the qualifier is applied by the storage layer, the same omission returns an empty result and somebody files a bug that afternoon. Ask for the demonstration rather than the sentence: omit the condition deliberately and see what comes back. It takes minutes and it is not a question a description can settle.
Compute, the scheduling of background work, and rate limiting. An unusual load pattern in one organisation consumes capacity another organisation is not using, and the mitigation is per-organisation limits rather than a promise it will not occur. Those are real risks of a different kind from data visibility, and any vendor claiming complete isolation on a shared platform is describing something their architecture does not support. If shared compute is unacceptable for your data, that is a single-tenant arrangement rather than a setting, and it changes the cost.
It does, and that asymmetry should shape what you ask for. Two things follow from it. First, notification commitments and their timings belong in the contract before you sign rather than being discovered during an incident. Second, the investigation should be answerable with your own logging rather than depending on us producing a report about ourselves — access events reach your stream carrying the owning organisation, so your team can establish what happened without our cooperation being on the critical path.
That matches the record, which is why those surfaces are named here rather than left to the general answer. Cache keys include the owning organisation as part of the key rather than as an assumption about the caller. Background work inherits the bound context of the request that created it instead of running under an ambient identity. Derived indexes are built per organisation rather than filtered when read. And there is no internal export tool that skips the ordinary read path — which is the one that produced several of the incidents you are thinking of.
No. A SOC 2 Type II attestation is in progress and no report exists yet, so nobody can be handed one, and this page marks every enforcement property as designed rather than attested for that reason. Record it that way in your risk register — a design intent that has not been independently examined is a real position and it is a weaker one than an attested control. What you can do without waiting for anybody is run the omission demonstration yourself, which tests the property directly rather than trusting either of us.