Somewhere in every enterprise procurement pack is the same question: how is our data protected from your other customers? It is a good question. The answers it usually gets are not.
Most SaaS platforms store every customer in one shared database, with a tenant ID column deciding whose rows are whose. The separation is real, but it is enforced by code: every query, every report, every new feature has to remember to filter correctly, forever. The vendor's answer to the isolation question is, in effect, "we are careful". That is a policy promise, and policy promises depend on nobody ever making a mistake.
Isolation by architecture, not by promise
There is a stronger answer available: do not put customers in the same database in the first place.
ocapii gives every customer site its own database. Not a partition, not a filtered view of a shared schema: a separate database, with file storage segregated per tenant on Google Cloud. Each site runs on its own subdomain, with routing, caching and queues that are tenant-aware from the ground up. A query against your site's database cannot return another customer's rows, because another customer's rows are not in it.
The distinction matters most when things go wrong, which is exactly when you want structure rather than discipline doing the work. A misconfigured feature or a bug in shared-schema systems can leak data across tenants. In a database-per-site architecture, the blast radius of that class of mistake is structurally contained.
It is worth being fair about why shared schemas are the industry norm: they are cheaper to run and easier to build. One database is simpler than a thousand. For many products, at many price points, that trade-off is reasonable. But operational data is not ordinary data. Temperature histories, audit submissions, incident records and sign-off trails are the evidence a business relies on in front of an inspector or an insurer. Evidence deserves stronger walls than a WHERE clause.
The rest of the posture
Isolation is the foundation, not the whole building. Data is encrypted in transit over TLS and at rest on Google Cloud. Passwords and PINs are hashed with bcrypt. Integration secrets are stored encrypted, and API tokens are hashed and shown once. Support access is permission-gated, hard-blocked from cross-tenant shortcuts, and every use is recorded in the audit log.
And because confidence should not depend on lock-in, the path out is structured too. Data arrives through a validated, reversible migration process and can leave the same way. A vendor that is confident in its platform does not need your data as a hostage.
Isolation also pays operational dividends that rarely make it into the sales conversation. Each site running on its own subdomain with its own database means one site's heavy reporting day does not slow another's service. Backups and restores are per-site, so recovering one site never means touching another. And regional or contractual data requirements can be met per customer rather than argued about platform-wide.
There is a data protection dividend too. When a customer's data lives as a unit rather than as rows scattered through shared tables, the obligations that worry a DPO get simpler. Locating everything you hold, exporting it, and erasing it at the end of a contract are operations on one database, not a forensic exercise across a shared platform. Structural isolation does not just answer the security questionnaire; it makes the privacy commitments practical to keep.
Questions worth asking any vendor
Vendors with structural answers will enjoy this conversation. Vendors with policy answers will steer it back to certifications and assurances. Both responses tell you something.
The grey man test
The strongest security claims are the ones that do not need to be believed, because they can be inspected. Architecture is inspectable. "We are careful" is not. When the isolation question comes up, and it always does, the best answer is the one where trust is optional.