1 Introduction
Sales intelligence platforms hold some of the most sensitive data a company generates. Call recordings capture pricing discussions, customer objections, hiring plans, and strategic decisions that were never meant to leave the room. Beyond the content of calls, these platforms also hold personal data: names, contact details, and behavioural records of customers and prospects.
When that data is held by a third-party SaaS vendor, a company’s exposure is not limited to its own security practices. It extends to how the vendor stores and isolates data across their entire customer base.
A breach in a shared-schema environment can potentially expose data across the entire customer base. The reputational and legal consequences: GDPR notifications, customer trust erosion, incident disclosures fall on the companies whose data was held, not only on the vendor who was breached.
Most enterprise buyers never ask the question that determines this exposure: how is my data stored relative to every other customer on this platform?
This article explains what that question means architecturally, what the honest tradeoffs are between the two dominant approaches, and what to ask a vendor before signing a contract.
A note on framing: this article uses Sales Signals as a concrete example because I built it and can speak to its architecture directly. The analysis applies to any SaaS product making the same choices.
2 Executive summary
Most SaaS tools store all customer data in a shared database, using row-level security (RLS) to filter query results per tenant. This architecture can be made secure, but isolation depends on sustained application correctness and operational discipline across every layer of the stack.
Shared-schema SaaS is not inherently insecure. Stripe, Notion, Slack, and Linear use it at massive scale. The question is not whether it can be made secure, but how much resources are required to maintain isolation over time. Even the big players have had RLS-related incidents.
Sales Signals uses per-tenant isolated infrastructure: one database, one container environment, one subnet per customer. Cross-tenant data exposure risk is substantially reduced and structurally constrained at the primary customer data plane.
This simplifies several ISO 27001 Annex A controls. The isolation controls that an RLS-based system must satisfy through process and code discipline are satisfied by the architecture itself.
Buyers evaluating sales intelligence platforms should ask how tenant isolation is implemented — not only whether the vendor is certified.
3 What to ask your SaaS vendor
These five questions give a practical evaluation framework for any sales intelligence platform under consideration. They are designed to be asked in a vendor conversation to reveal meaningful differences in architecture, maturity, and risk posture.
Most vendor security pages describe certifications and compliance frameworks. Very few describe the underlying architecture or incident history. These questions surface what the security page does not.
1. If your system had a bug that bypassed your access controls, how many customers’ data would be at risk?
This is the single most revealing question. A vendor with shared-schema infrastructure will answer with controls and safeguards because the honest answer is “potentially all of them.” A vendor with per-tenant isolated infrastructure will say “only that one customer’s environment — others run on separate infrastructure.” The difference in answers is immediate and does not require technical interpretation.
2. Has your platform ever had a security incident involving customer data? How was it contained?
Experienced procurement teams ask this question. The answer reveals both track record and containment capability. An isolated architecture vendor can describe exactly which tenant environment was affected and why others were not. A shared-schema vendor’s containment story is necessarily more complex. The quality of the answer — whether the vendor can describe specific containment boundaries — is as informative as the incident history itself.
3. What does your vendor security review process look like, and what evidence can you provide?
This is the question that separates vendors who have thought seriously about security from those who have not. A mature vendor will have audit reports, penetration testing results, or a completed ISO 27001 assessment to share under NDA. A vendor who responds only with a security page or a self-assessment questionnaire has not yet invested in verifiable evidence. The answer also prompts disclosure of certification status and compliance posture without requiring you to ask separately.
4. What happens to our data if we stop using your product?
This question covers offboarding, data retention, and deletion — all of which have direct contractual and regulatory implications. The answer reveals the underlying architecture: a vendor with isolated infrastructure can describe a specific, complete deletion process. It also reveals whether the vendor has a documented retention policy and what contractual obligations they accept around data removal. Under GDPR, the right to erasure is not optional and the answer to this question determines how cleanly it can be exercised.
5. If one of your customers experienced a data breach, would we be notified?
This is the GDPR angle, and it is directly relevant to any European buyer. The answer reveals two things: whether the vendor has a mature incident response process with defined notification procedures, and whether their architecture allows them to scope a breach to a single tenant. A vendor who cannot answer this question clearly does not have mature incident response, regardless of their certification status.
3.1 Certification versus architecture
A vendor can be ISO 27001 certified with a shared-schema architecture. Certification audits the existence and operation of an information security management system; it does not mandate a specific architecture. What certification does not reveal is whether isolation controls are structurally enforced or depend on every developer, every release, and every background job maintaining perfect tenant discipline indefinitely.
ISO/IEC 27001:2022, Annex A. The standard specifies controls and outcomes, not implementation methods. Two products with fundamentally different architectures can both achieve certification if their information security management systems satisfy the required controls and operate effectively.
4 How multi-tenant SaaS stores data
4.3 Isolated stack
Per-tenant isolated stack gives each customer their own database server, container runtime, and network subnet. The containment scope of any failure is structurally limited to one tenant. Provisioning overhead is higher — a new tenant requires spinning up infrastructure, not inserting a row. Shared-schema systems generally optimise infrastructure utilisation and provisioning efficiency, particularly at smaller scales. At larger scales, per-tenant isolation can become operationally advantageous in other dimensions: tenant-specific maintenance, incident containment, regional placement, and customer migrations become straightforward when each tenant runs on an independent stack. Whether the efficiency tradeoff is justified depends on the sensitivity of the data being processed.
In practice, many enterprise SaaS platforms adopt hybrid models: tenant sharding, cell-based architectures, or dedicated infrastructure tiers for larger customers. These approaches attempt to balance infrastructure efficiency with cross-tenant exposure reduction, and represent a meaningful middle ground between the two ends of the spectrum described here.
| Shared schema + RLS | Isolated stack | |
|---|---|---|
| Provisioning | Insert a row | Spin up infrastructure |
| Isolation mechanism | Software policy | Network + infrastructure |
| Cross-tenant exposure scope | Potentially platform-wide | Structurally limited to one tenant |
| ISO 27001 compliance complexity | Higher | Lower |
| Operational overhead | Lower at small scale | Lower at large scale |
| Data deletion | Scoped DELETE across tables | Database and storage removal |
5 What ISO 27001 actually requires
5.1 Technological controls
ISO 27001:2022 Annex A contains 93 controls across four domains. Section 8 covers technological controls: 34 requirements governing how information systems handle data security. These are the controls most directly relevant to a SaaS vendor’s architecture.
ISO/IEC 27001:2022 is the current version of the standard, published in October 2022. It superseded ISO 27001:2013 and consolidated 114 controls into 93.
The standard draws no explicit distinction between architectural compliance and policy-based compliance. But the evidentiary difference is significant. A control satisfied by a verifiable infrastructure configuration can be confirmed from an ARM template or infrastructure export. Isolation enforced primarily through application-layer controls generally requires deeper review of code paths, testing procedures, and operational safeguards — a larger audit scope that depends more heavily on ongoing process discipline. Architecture matters most during failure conditions.
5.2 Where architecture and RLS diverge
8.3 — Information access restriction. With RLS, access restriction is enforced by a database policy every query must pass through correctly. With an isolated database, the restriction is enforced by the network — there is no connection path from one tenant’s application to another tenant’s database. The control is satisfied by containment, not by code correctness.
8.22 — Segregation of networks. RLS-based SaaS places all tenants on the same network segment with application-layer separation. An isolated stack with per-tenant subnets provides evidence-based segregation at the infrastructure level, independently of application behaviour.
8.27 — Secure system architecture and engineering. This control addresses design, not just operation. Isolation enforced by network boundaries and separate databases is verifiable from an infrastructure-as-code export. Isolation enforced by RLS policies requires a code review of every query path — a fundamentally larger audit scope.
8.6 — Capacity management. Shared infrastructure introduces the noisy neighbour problem. Per-tenant infrastructure eliminates it by design.
8.10 — Information deletion. A database drop is a complete, auditable deletion event. Scoped DELETE statements across a shared schema require verification that nothing was missed.
6 Where shared schema falls short
Shared-schema SaaS is not inherently insecure. The failure mode is not that RLS is fundamentally broken — it is that RLS only governs one layer of a SaaS application, and that layer is narrower than most buyers assume.
6.1 The single layer RLS actually protects
There is no unrestricted cross-tenant query path at the database layer when RLS is applied correctly. The problem is that correct application requires sustained discipline across five additional layers that RLS does not reach: the cache, the connection pool, background workers, analytics pipelines, and admin tooling. Each layer requires its own tenant isolation mechanism, its own testing, and its own ongoing operational discipline.
6.2 Documented failure modes
CVE-2024-10976 — RLS in PostgreSQL itself. Disclosed in November 2024, this vulnerability described incomplete tracking of tables with row security, where a reused query could view or change rows from a different tenant. Cases where a subquery, WITH query, security invoker view, or SQL-language function referenced a table with a row-level security policy could result in incorrect policies being applied. It is the third in a series — CVE-2016-2193 and CVE-2023-2455 addressed related edge cases in earlier versions — suggesting that RLS interactions with query planning are genuinely complex and difficult to fully enumerate.
CVE-2024-10976, disclosed November 14, 2024. National Vulnerability Database. CVSS Base Score 5.4. See also: CVE-2023-2455 and CVE-2016-2193, which addressed related interactions between row security and user ID changes in earlier PostgreSQL versions.
Beyond CVEs, practitioners document a consistent pattern of silent misconfiguration: not enabling FORCE ROW LEVEL SECURITY so that table owners bypass policies; using SET instead of SET LOCAL with connection poolers so that tenant context leaks between clients; admin paths connecting as superusers that bypass RLS entirely.
“Postgres Row-Level Security Footguns”, Bytebase, 2025. Documents the following silent failure modes: enabling RLS without FORCE allows table owners to bypass; USING without WITH CHECK permits inserts tenants cannot see; tenant context not reset on pooled connections produces cross-tenant results.
Shared cache — OpenAI ChatGPT, March 2023. A vulnerability in the Redis client library used by ChatGPT allowed some users to see other users’ conversation titles and first messages. The same bug exposed billing information — names, addresses, credit card types, and the last four digits of card numbers — for approximately 101,000 users. The root cause was improper isolation of session data in a shared Redis cache. RLS on the underlying database was not involved: the breach happened before any database query was made. The incident illustrates that shared caches are independent isolation boundaries that must be secured separately from the database layer.
OpenAI disclosed the incident on March 24, 2023. The Redis client library redis-py contained a vulnerability that allowed cross-user session data access under high concurrency. OpenAI confirmed exposure of chat history titles, first messages, and billing information for approximately 1.2% of ChatGPT Plus subscribers active during a nine-hour window on March 20, 2023. Source: OpenAI blog, “March 20 ChatGPT outage: Here’s what happened”, March 2023.
Connection pool contamination. When a database connection is returned to a shared pool without resetting session variables, the next tenant that acquires it inherits the previous tenant’s context. Their queries execute under the wrong tenant identity — bypassing RLS entirely because the database believes it is still serving the previous tenant. The correct mitigation is using SET LOCAL inside transactions or executing DISCARD ALL on connection return, but this requires explicit configuration that is easy to omit.
The correct mitigation requires using SET LOCAL inside a transaction rather than SET, or executing DISCARD ALL when connections are returned to the pool. Many connection poolers require explicit configuration to enforce this. PgBouncer in transaction pooling mode does not reset session-level variables by default.
Background jobs and analytics pipelines present the same class of risk. Async workers run outside the HTTP request lifecycle with no middleware to set tenant context. Analytics queries are often written separately from the core application, use raw SQL rather than ORM-level query scopes, and connect with elevated privileges. A single missing WHERE clause in an analytics query returns data from every tenant in the database. For a sales intelligence tool, where the analytics layer is the product, this is the failure mode with the highest consequence.
6.3 Silent failure problem
Named-company disclosures of RLS-specific failures are rare — not because they do not happen, but because most are silent. The ChatGPT incident became public because users could see each other’s data directly in the UI. A background job that writes analytics results to the wrong tenant’s dashboard may never surface. A connection pool leaking session state may produce subtly incorrect results attributed to a data quality issue rather than a security incident.
“Multi-Tenant Audit Logging: The Architecture Mistakes We Made”, DEV Community, April 2026. A disclosed startup incident: “The data leak we had was caught quickly and affected a small number of events. We disclosed it to the affected customers, did a full incident review, and rebuilt the system properly. But it could have been much worse.”
An isolated architecture eliminates the unrestricted cross-tenant execution path. There is no shared database to query across, and no application-layer policy that must be correctly applied to every code path.
7 How isolation by design maps to ISO 27001
7.1 Sales Signals architecture
Each Sales Signals tenant runs on a fully isolated stack:
A dedicated PostgreSQL 16 Flexible Server on its own private subnet, with no public endpoint. Reachable only from within the virtual network via a private DNS zone.
A dedicated Container Apps environment on its own /23 subnet, isolated from all other tenant environments.
A dedicated Azure File Share for the tenant’s runtime configuration, mounted as a volume at startup.
A shared virtual network with non-overlapping subnets per tenant, a shared container registry, and centralised log aggregation — the right things are shared, the sensitive things are not.
A separate resource group for connector infrastructure, so that data import jobs cannot affect tenant-facing workloads even if they fail or are compromised.
Each tenant’s subnet uses a /23 CIDR for the container environment and a /28 for the PostgreSQL server. Subnets are non-overlapping and network security rules prevent tenant-to-tenant communication.
Application images are immutable and pulled from a single container registry. A new tenant gets an identical stack — not a row in a shared table.
7.2 Control-by-control mapping
The following reflects the current state of Sales Signals with Phase 1 and Phase 2 documentation completed.
Controls 8.23, 8.30, and 8.34 are marked N/A: web filtering is not applicable to a server-side application; development is not outsourced; audit testing has not yet been conducted.
| Control | Requirement | Status | How satisfied |
|---|---|---|---|
| 8.3 | Information access restriction | ✅ | Per-tenant DB with private endpoint. No network path between tenant databases. |
| 8.6 | Capacity management | ✅ | Per-tenant container and database. No noisy neighbour. Containers scale 1–3 replicas. |
| 8.9 | Configuration management | ✅ | context.json on Azure File Share decouples tenant config from the application image. |
| 8.10 | Information deletion | ✅ | Primary tenant data removed via database and storage deletion. Backup retention governed by documented policy. |
| 8.13 | Information backup | ✅ | PostgreSQL Flexible Server automated backup. Retention period and restore procedure documented. |
| 8.15 | Logging | ✅ | Centralised Log Analytics Workspace. All container stdout/stderr aggregated. |
| 8.17 | Clock synchronisation | ✅ | Azure manages NTP for all managed services. |
| 8.19 | Software installation on operational systems | ✅ | Immutable container images via ACR. GitHub Actions controls all deployments. |
| 8.20 | Network security | ✅ | VNet with isolated subnets. Private DNS. No public DB endpoints. TLS at load balancer. |
| 8.21 | Security of network services | ✅ | Azure-managed load balancer. TLS termination. Private-only PostgreSQL access. |
| 8.22 | Network segregation | ✅ | Per-tenant /23 ACA subnets and /28 PostgreSQL subnets. Connector in separate resource group. |
| 8.24 | Cryptography | ✅ | TLS in transit. Encryption at rest confirmed for PostgreSQL Flexible Server and Storage Account. |
| 8.27 | Secure system architecture | ✅ | Isolation by design. Per-tenant infrastructure verifiable from ARM template export. |
| 8.31 | Separation of dev, test, production | ✅ | Dev tenant explicitly separated from production. Same stack, different environment. |
7.3 What isolated architecture does not solve
The controls above are satisfied by architecture. A further set require process and application-layer work regardless of architecture:
8.26 (Application security requirements) — authentication, input validation, API security.
8.28 (Secure coding standards) — dependency management, secrets management, logging policy.
8.29 (Security testing) — penetration testing, vulnerability review.
8.11 (Data masking) — restricting support access to raw call content
A well-run shared-schema SaaS can achieve ISO 27001 certification. The isolated architecture reduces cross-tenant exposure scope and the compensating control overhead required — it does not eliminate the need for process controls.
8 Conclusion
Tenant isolation is an architectural question before it is a compliance question. Certifications matter as they signal that an information security management system exists and operates. But they do not reveal how customer data is actually separated, what the containment scope of a failure is, or how many independent layers of operational discipline stand between a bug and a breach.
Buyers should ask the architecture question directly: is each customer’s data physically and infrastructurally isolated, or primarily separated through logical controls within shared infrastructure? The answer tells you more about your actual risk exposure than any compliance badge.
Sales Signals was designed around isolated tenant infrastructure from the beginning: one database, one container environment, one subnet, one file share per customer — because we believe that customer data segregation should be enforced structurally wherever possible. The isolation controls of ISO 27001 Annex A Section 8 are satisfied by the infrastructure itself. We are working toward full certification.
See Also
Here are some of my other about security, architecture, and SaaS design:
No matching items